Usar el Sentido Común (USC) se sostiene en base a la probabilidad de que el principio que estamos utilizando se pueda cumplir, ¿nos podemos mover de un lugar a otro pedaleando en una bicicleta estática? Y la respuesta USC es NO, pero cómo siempre en muchos lugares la respuesta es “depende”, si, y ensayo alguna argumentación ficticia en nunca escuché, “depende, si la bicicleta está sobre un camión que usa baterías para moverse que a su vez se cargan con la energía que se genera por pedalear, entonces nos movemos pedaleando con la bicicleta estática”…. ok …
Es obvio que este escenario no es común y es una excepción casi imposible que ocurra, pero puedo asegurar que argumentaciones parecidas las van a escuchar más veces de las que cree y no se sorprenda cuando vea soluciones que toman en cuenta la bicicleta estática como opción para movilizarse. Solucionar por excepción y no por regla es algo que se da en muchos casos, la realidad generada por torpeza o mala intención siempre supera la ficción.
Para evitar esa “dependitis” y poder tener un principio o punto de apoyo uso el término probable, Arquímedes dijo “dame un punto de apoyo y moveré el mundo”, en mi caso como buen reciclador reutilizo la frase con un ligero cambio “dame una probabilidad del 90% y empujaré el mundo”.
Aqui viene el principio probable que dice: «algo que no se pueda ver no se pueda mejorar», añadiría ni siquiera entender, menos repetir generando resultados similares, pero también podemos ver sin entender o entender desde una perspectiva errada o usar una perspectiva desalineado a los objetivos de la organización, como siempre cuidado “los modelos son malos algunos sirven” (G. Box).
Figura 1

Según la frase de Taichi Ohno ¿Cómo debe ser un área de trabajo?, debe ser una sala de exposición que pueda entenderse con simpleza, “la simplicidad es la máxima sofisticación” decía L. Da Vinci, ¿a qué se refiere Ohno cuando escribe estas frases? Se refiere al concepto Mieruka (Gestión Visual) parte de las bases del Toyota Production System (TPS), dónde todo lo importante para un trabajo se hace evidente basado en que “probablemente” algo que se pueda ver se puede mejorar, USC, pero ¿qué cosas se debería poder detectar aplicando Mieruka?, según la frase, sólo hay 3 cosas que se deben lograr [5]:
• Entender de una simple ojeada
• Hacer evidentes los defectos o problemas
• Ver la diferencia entre lo planeado y lo ejecutado
¡Genial! con Mieruka tenemos información para entender, detectar defectos y ver brechas de ejecución, ¿y ahora ?, todo esto ¿es sólo contemplar y analizar como una sala de exposición?, y la respuesta es NO, y aquí viene otro principio TPS: “la acción antes que la teoría” [1], si no ejecutamos no sirve, probablemente nadie sienta satisfacción por una gran idea que tuvo y que nunca puso en práctica, ¿entonces qué se hace?, la visualización te debe impulsar a la acción y la acción sin información es una lotería, por eso que el TPS son principios que se complementan.
Una de las principales herramientas usadas de Mieruka o la más conocida es el Value Stream Map (VSM), algo sencillo según el mismo Ohno, “sólo” hay que seguir el camino desde que el cliente solicita algo hasta que paga por lo que recibió (proceso punta a punta de gestión por procesos) y eliminar todo lo que no genere valor al producto, ósea cuando modelamos el flujo pensamos en Seriri (separar), Seiton (organizar) y Seisou (limpiar) con el objetivo de eliminar las 7 mudas (desperdicios), nuevamente otros principios TPS que se complementan sin contraponerse.
Figura 2 TPS no es sólo para manufactura
Fuente: Museo Toyota
Cada vez que explico este concepto, la objeción es inmediata “Mieruka cómo todo los de TPS sólo se puede aplicar en entornos de producción, en una organización que tiene procesos de servicios, no se puede” y la respuesta, otra vez es NO (Figura 2), si se puede aplicar, lo que debemos hacer es adaptar los principios pasando de un proceso físico de movimiento de materiales y uso de máquinas a uno abstracto de intercambio de conocimiento, documentos digitales y uso de aplicativos, el gran reto es convertir el conocimiento en algo tangible con ayuda de la digitalización entonces en lugar de hablar de VSM de la línea de producción hablamos de uno para la generación de servicios, la complejidad no está en el fenómeno sino en el sesgo del observador.
Figura 2: Oficina Municipal
Cuál es la propuesta para implementar el concepto de VSM, por ejemplo en una oficina de un Municipio que ofrece diversos servicios al ciudadano como el de la Figura 3, en esencia adaptar los componentes según el Cuadro 1, lugares de trabajo, insumos, métodos y herramientas, entendiendo que existen otros pero que son comunes como los ejecutores, tiempos, indicadores, etc.
Cuadro 1: Comparativo VSM vs. Modelo BPMN
Tal como lo mencionamos anteriormente si en VSM tenemos que abstraer lo material para representarlo gráficamente, en el servicio primero debemos materializar el conocimiento y luego como en el VSM representarlo gráficamente, con la ventaja que si usamos la notación Business Process Model & Notation (BPMN) con el soporte de un Business Process Management System (BPMS) de ejecución, no sólo tendremos el gráfico sino también la ejecución misma del proceso mediante un Process Driven Application (PDA) [6], si en TPS el Gemba era la planta, en una empresa de servicios el Gemba digital es el sistema BPMS porque ahí se materializa digitalmente el proceso.
Elaboremos un comparativo entre dos procesos (ver cuadro 2) , uno de ensamble de caja de fusibles y otro de servicio de solicitud de un certificado, tenemos 3 actividades que se realizan en un lugar físico o mediante un formulario de un aplicativo, las actividades tienen tareas que deben cumplir métodos, es decir tener un procedimiento manual o digital, pueden usar herramientas como desarmadores o aplicaciones de bases de datos o correo electrónico, los insumos pueden ser piezas o documentos digitales y generar productos físico o digitales finalmente.
[1] Miyagi, A., (2023), “Práctica en lugar de teoría”, https://acortar.link/W23Qyn
[2] Object Managemet Group. (2013). Business Process Model and Notation (BPMN). Obtenido de http://www.omg.org/spec/BPMN
[3] Schneid, K., Di Bernardo, S., Kuchen, H., & Thöne, S. (2021). Data-Flow Analysis of BPMN-based Process-Driven Applications: Detecting anomalies across model and code.
[4] Wroblewski,M., Villafuerte, J.,Miller, J., (2013) «Creating a Kaizen Culture: Align the Organization, Achieve Breakthrough Results, and Sustain the Gain»
[5] Japan Management Association (1989), Kanban y Just in Time
[6] Miyagi, A., (2024), “Fundamentos para desarrollar Process Driven Application (PDA)”, https://acortar.link/vzVY59