SolvingAnalysis problema, el pensamiento crítico, las herramientas Lean, resolución de problemas
PDCA VariantsIn mis últimos mensajes me explicó el PDCA (Plan, Do, Check, Act), errores comunes, y su historia. Sin embargo, hay todo un puesto de frutas de versiones adicionales con algunas modificaciones que han surgido: PDSA, SDCA, OODA, ODCA, DMAIC Lamda, Kata, y 8D – y probablemente más que yo no conozco. Voy a explicar un poco en las diferentes ramas y alternativas de la PDCA.
PDSA: planificar, hacer, el estudio, la Ley
El PDSA fue desarrollado por Deming. La principal diferencia es que el cheque fue reemplazado por el estudio. Deming, dijo que el cheque original significaría en Inglés de «contener», y por lo tanto se llama el PDCA original de una corrupción. Tal vez mi Inglés no es lo suficientemente bueno, pero «detenga» no habría estado en mi mente cuando escuché «cheque».
En cualquier caso, el significado implícito es casi el mismo. La parte del estudio analiza si efectivamente trabajadas y mejoró la situación, y también trata de aprender del Plan y partes.
OPDCA: Se deben observar, planificar, hacer, verificar, actuar
vigía de proa a bordo del USS NASSAU
Sin embargo, otra variante PDCA, esta vez con Observeadded al principio. Para mí, esto es parte de la Planin el PDCA original, pero también estoy bien con lo que supone una carta por separado. El plan de PDCA se beneficiaría de más letras de todos modos.
SDCA: Estandarizar, Do, Check, Act
Y sin embargo, otra variante PDCA, donde el Plan se sustituye por Estandarizar. Usted puede preguntarse por qué hay una Estandarizar al comienzo, mientras que en el PDCA es parte del Do. La idea es observar las normas actuales y ver donde los trabajadores se desvían de la norma. Puede continuar con Do, Check, Act si se desvían para averiguar por qué, y para cambiar el sistema que sea la norma se actualiza o el trabajador sigue la norma.
Sin embargo, en mi opinión, creo que esto limita la lista de problemas se pueden resolver. Si todos sus ciclos requieren que usted tenga un estándar de primera, entonces sólo puede mejorar las cosas que tienen un estándar. Esto excluiría medidas no estandarizadas (infrecuente o simplemente aún no acaba estandarizada), y limitar muchos otros enfoques, como problemas de la máquina o la calidad del producto. Por lo tanto, no me gusta demasiado.
DMAIC: Definir, Medir, Analizar, Mejorar y Controlar
Seis SigmaThis DMAIC (Definir, Medir, Analizar, Mejorar y Controlar) es una rama PDCA en el vástago de Seis Sigma de manufactura esbelta. A pesar de que tiene más palabras, el significado es algo similar. Sin embargo, sí creo DMAIC tiene algunos puntos débiles en relación a la PDCA.
El plan original de PDCA se divide en definir, medir y analizar. En primer lugar, el lado positivo: me gusta que el proyecto está claramente definido en el Definestep. Sin embargo, creo que la Medida y Analyzeare no siempre secuencial, sino iterativo. Por lo general, se mide, se analiza, y luego volver a medir un poco más. El objetivo al final de la etapa de analizar es comprender la causa raíz.
El desarrollo de la solución, que en PDCA sigue siendo parte del Plan, ahora se tritura junto con la implementación como el paso Mejorar. Lo que realmente me molesta es que tiene toda la DMAIC PDCA incluido como parte de la etapa Mejorar simplemente para probar las soluciones. Creo que es simplemente incorrecto. Pero entonces, Seis Sigma, en general, tiene una tendencia irritante para afirmar que está en la cima del mundo, e incluso «pobre» es sólo una herramienta en su caja de herramientas.
El último paso, control, tiene como objetivo asegurar que los resultados sean sostenibles, por lo general a través de estándares. Lo que echo completamente en el DMAIC es la parte chequeo de la PDCA. Lo que parece a ninguna parte no DMAMC realmente comprobar si la aplicación funcionó! Para mí, esto es un defecto fundamental si alguien sigue el DMAIC por los libros! En general, DMAIC va en la dirección correcta, pero se queda corto en algunas áreas clave.
LAMDA: Mira, Pregunta, Modelo, discutir, Ley
LAMDA es en realidad especializada en el desarrollo de productos (es decir, una tarea similar a la del ciclo original de Shewhart). También pretende ser un reemplazo PDCA en este campo, pero para mí tiene algunos defectos también. Además, diferentes fuentes definen de manera diferente. Por suerte, rara vez se utiliza.
La mirada representa observaciones in situ (es decir, el piso de la tienda). Pregunta gradas para hacer preguntas. Hasta aquí todo bien, similar a Genchi Genbutsu. El Modelpart crea modelos de ingeniería, simulaciones o prototipos. Discutir es más hablando de los modelos y el producto. Con la Ley, que creo que es el mismo que en PDCA, pero, por desgracia, no. Significa poner a prueba el experimento, sea la aplicación. Por lo tanto, está más cerca de la parte Do del PDCA. Otra definición de LAMDA he encontrado copias del Acta de la PDCA, es decir, intenta aprender del proceso anterior.
¿Se dio cuenta de que LAMDA nunca definió el problema? LAMDA nunca considera lo que quiere lograr, o cuál es el problema que desea resolver. Debido a la inconsistencia de la parte de la Ley, que nunca sea pregunta si efectivamente trabajadas, o que en realidad nunca se genera un producto terminado. De cualquier manera, demasiados agujeros en el método para mi gusto.
8D: Ocho Disciplinas Resolución de Problemas
Ford Motor LogoThis uno viene de Ford. Desde su creación, se añadió una novena «D» al principio. Por lo tanto, el 8 + 1D son:
D0: Plan de
D1: Utilice un equipo
D2: Describe el problema
D3: Desarrollar un plan de contención provisional
D4: determinar y verificar las causas fundamentales y escapar puntos
D5: verificar que las correcciones permanentes para el problema se resolverá problema
D6: Definir e implementar acciones correctivas
Prevenir los problemas del sistema: D7
D8: Felicite a su equipo
En general, no está mal, aunque todavía echo la marca de PDCA, donde se comprueba si efectivamente trabajadas.
Kata
Quizás se sorprenda al ver Kata aquí. En la actualidad bastante el bombo en la comunidad magra, Kata, creo, tiene un objetivo similar al PDCA, aunque está más orientado hacia el cuadro grande. En primer lugar, Kata no es una abreviatura, pero una palabra japonesa para ejercicios repetitivos en las artes marciales (entre otros significados). Los cuatro pasos de Kata son:
Determinar una visión o dirección
Agarre la condición actual
Definir la siguiente condición de diana
Avanzar hacia el destino mediante PDCA
Por supuesto, hay un poco más de detalle – por ejemplo, la definición exacta de la condición de destino (que no es un objetivo, sino más bien una visión a largo plazo). El PDCA es en realidad parte de la etapa de KATA 4. En general, creo KATA es útil, pero también demasiado exageradas en la comunidad magra. Después de todo, las ideas subyacentes no son realmente tan nueva, y ya existía, por ejemplo, durante la Segunda Guerra Mundial TWI (Training Within Industry) programa.
OODA: observar, Orient, Decidir, Ley
Departamento de Defensa de Estados SealThis una realidad proviene de los militares de EE.UU.. En la industria, a veces se utiliza para las decisiones estratégicas de alto nivel en lugar de la solución de problemas prácticos de la PDCA. Como tal, también es una posibilidad si usted tiene problemas estratégicos de alto nivel para resolver.
¿Cuál debo utilizar?
Está bien, así que ahora tenemos ocho variantes u otros métodos que se mueven similar a la PDCA. Cuál debe usar? Buena pregunta. Yo personalmente tiendo a usar PDCA, simplemente porque estoy acostumbrado a ella, aunque creo que el plan podría haberse beneficiado de una o dos letras adicionales para hacerlo más claro. PDSA y OPDCA también están bien. No soy muy aficionado a SDCA, DMAIC Lamda, y 8D. Kata y OODA son buenos para el pensamiento más estratégico. Para responder a la pregunta: Utilice el que se adapte a su problema mejor. Si en el pasado has tenido buenos resultados con DMAIC, seguir utilizándolo. Si usted es un fan de SDCA, adelante. Si usted es nuevo y apenas está comenzando este tipo de pensamiento, probablemente se adhieren a la tradicional PDCA, ya que tiene la mayor cantidad de información y soporte en línea, y evita algunos de los defectos de DMAIC Lamda, y SDCA.
En cualquier caso, independientemente del método que flota su barco, lo utilizan para salir y organizar su industria![:en]The Many Flavors of the PDCA.
Problem SolvingAnalysis, Critical Thinking, Lean Tools, Problem Solving
PDCA VariantsIn my last posts I explained the PDCA (Plan, Do, Check, Act), common mistakes, and its history. However, there is a whole fruit stand of additional versions with some modifications that have popped up: PDSA, SDCA, OODA, ODCA, DMAIC, LAMDA, Kata, and 8D – and probably more that I do not know of. Let me explain a bit on the different offshoots and alternatives of the PDCA.
PDSA: Plan, Do, Study, Act
The PDSA was developed by Deming. The main difference is that the Check was replaced by Study. Deming said that the original Check would mean in English to “hold back,” and hence he called the original PDCA a corruption. Maybe my English is not good enough, but “hold back” would not have been on my mind when I heard “check.”
In any case, the implied meaning is nearly the same. The Study part analyzes if it actually worked and improved the situation, and also tries to learn from the Plan and Do parts.
OPDCA: Observe, Plan, Do, Check, Act
Yet another PDCA variant, this time with Observeadded at the beginning. For me, this is part of the Planin the original PDCA, but I am also fine with giving it a separate letter. The Plan in PDCA would benefit from more letters anyway.
SDCA: Standardize, Do, Check, Act
And yet another PDCA variant, where the Plan is replaced by Standardize. You may wonder why there is a Standardize at the beginning, while in the PDCA it is part of the Do. The idea is to observe the current standards and see where the workers deviate from the standard. You can continue with Do, Check, Act if they deviate to find out why, and to change the system that either the standard is updated or the worker follows the standard.
However, in my view, I think this limits the list of problems you can solve. If all your cycles require you to have a standard first, then you can only improve things that have a standard. This would exclude non-standardized steps (infrequent or simply just not yet standardized), and limit many other approaches like machine problems or product quality. Hence, I do not like it too much.
DMAIC: Define, Measure, Analyze, Improve, Control
Six SigmaThis DMAIC (Define, Measure, Analyze, Improve Control) is a PDCA offshoot in the Six Sigma offshoot of lean manufacturing. While it has more words, the meaning is somewhat similar. However, I do think DMAIC has some shortcomings compared to the PDCA.
The original Plan from PDCA is split into Define, Measure, and Analyze. First, the positive side: I like that the project is clearly defined in the Definestep. However, I think that Measure and Analyzeare not always sequential, but rather iterative. Usually you measure, you analyze, and then you go back to measure some more. The goal at the end of the Analyze step is to understand the root cause.
The development of the solution, which at PDCA is still part of the Plan, is now mashed together with the implementation as the Improve step. What really irks me here is that DMAIC has the entire PDCA included as part of the Improve step merely to test solutions. I think that is just wrong. But then, Six Sigma in general has an irksome tendency to claim that it is on top of the world, and even “lean” is just a tool in their toolbox.
The last step, Control, aims to ensure the results are sustainable, usually through standards. What I completely miss in the DMAIC is the Check part of the PDCA. It seems at no part does DMAIC actually check if the implementation worked! For me, this is a crucial flaw if someone follows the DMAIC by the books! Overall, DMAIC goes in the right direction, but it falls short in a few key areas.
LAMDA: Look, Ask, Model, Discuss, Act
LAMDA is actually specialized on product development (i.e., a similar task as the original Shewhart cycle). It also aims to be a PDCA replacement in this field, but for me it has some shortcomings too. Additionally, different sources define it differently. Luckily, it is rarely used.
The Look represents observations on site (i.e., the shop floor). Ask stands for asking questions. So far so good, similar to Genchi Genbutsu. The Modelpart creates engineering models, simulations, or prototypes. Discuss is more talking about the models and the product. With Act, you would think it is the same as in PDCA, but unfortunately, no. It means to test the experiment or to implement. Hence, it is closer to the Do part of the PDCA. Another definition of LAMDA I have found copies the Act from the PDCA, meaning you try to learn from the previous process.
Did you notice that LAMDA never defined the problem? LAMDA never considers what you want to achieve, or which problem you want to solve. Due to the inconsistency of the Act part, it either never asks if it actually worked, or it never actually generates a finished product. Either way, too many holes in the method for my taste.
8D: Eight Disciplines Problem Solving
Ford Motor LogoThis one comes from Ford. Since it was created, a ninth “D” was added at the beginning. Hence, the 8+1D are:
D0: Plan
D1: Use a team
D2: Describe the problem
D3: Develop an interim containment plan
D4: Determine and verify root causes and escape points
D5: Verify that permanent corrections for problem will resolve problem
D6: Define and implement corrective actions
D7: Prevent system problems
D8: Congratulate your team
Overall, not too bad, although I still miss the Check from PDCA, where you check if it actually worked.
Kata
Maybe you are surprised to see Kata here. Currently quite the hype in the lean community, Kata, I think, has a goal similar to PDCA, although it is more oriented toward the big picture. First, Kata is not an abbreviation but a Japanese word for repetitive exercises in martial arts (among other meanings). The four steps of Kata are:
Determine a vision or direction
Grasp the current condition
Define the next target condition
Move toward the target using PDCA
Of course, there is quite a bit more detail – for example, the exact definition of target condition (it is not a target, but more of a longer term vision). The PDCA is actually part of the KATA step 4. Overall, I think KATA is useful, but also way too over-hyped in the lean community. After all, the underlying ideas are not really that new, and already existed, for example, during the World War II TWI (Training within Industry) program.
OODA: Observe, Orient, Decide, Act
United States Department of Defense SealThis one actually comes from the U.S. military. In industry, it is sometimes used for higher level strategic decisions rather than practical problem solving of the PDCA. As such, it is also a possibility if you have higher level strategic issues to solve.
Which One Should I Use?
Okay, so now we have eight variants or other methods that move akin to the PDCA. Which one should you use? Good question. I personally tend to use PDCA, simply because I am used to it, although I think the Plan could have benefited from one or two additional letters to make it clearer. PDSA and OPDCA are also fine. I am not too fond of SDCA, DMAIC, LAMDA, and 8D. Kata and OODA are good for more strategic thinking. To answer the question: Use whichever suits your problem best. If in the past you had good results with DMAIC, continue to use it. If you are a fan of SDCA, go ahead. If you are new and are just starting this type of thinking, probably stick to the traditional PDCA, since it has the most information and support online, and avoids some of the flaws of DMAIC, LAMDA, and SDCA.
In any case, whichever method floats your boat, use it to go out and organize your industry![:]