Difference between revisions of "Lean Engineering"
| Line 8: | Line 8: | ||
===Lean Principles=== | ===Lean Principles=== | ||
| − | + | Oppenheim (2011) describes the six Lean Principles for Product Development (PD) as follows (they are referred to by the undelined words): | |
| − | * | + | * Capture the value defined by the Customer. One cannot over emphasize the importance of capturing task or program value (requirements, CONOPS, etc.) with precision, clarity and completeness before resource expenditures ramp up to avoid unnecessary rework. |
| − | + | * Map the value stream (plan the program) and eliminate waste. Map all end - to - end linked tasks, control/decision nodes and the interconnecting information flows necessary to realize customer value. During the mapping process, eliminate all non - value added activities, and enable the remaining activities to flow without rework, backflow or stopping). The term information flow refers to the packets of information (knowledge) created by different tasks and flowing to other tasks for subsequent value adding: design, analysis, test, review, decision, or integration. Each task adds value if it increases the level of useful information and reduces risk in the context of delivering customer value. | |
| − | * | + | * Flow the work through planned and streamlined value - adding steps and processes, without stopping or idle time, unplanned rework, or backflow. To optimize flow, one should plan for maximum concurrency of tasks, up to near - capacity of an enterprise. Legitimate engineering iterations are frequently needed in PD, but they tend to be time consuming and expensive if they extend across disciplines. Lean PD encourages efficient methodology of fail early - fail often through rapid architecting and discovery techniques during early design phases. Lean flow also makes every effort to use techniques that obviate lengthy iterations, such as: design frontloading, trade space explorations, set designs, modular designs, legacy knowledge, and large margins. Where detailed cross - functional iterations are indeed necessary, Lean flow optimizes iteration loops for overall value. |
| − | * | + | * Let customers pull value. In PD, the pull principle has two important meanings: 1) The inclusion of any task in a program must be justified by a specific need from an internal or external customer, and coordinated with them, and 2) The task should be completed when the customer needs the output: excessively early completion leads to “shelf life obsolescence” including possible loss of human memory, or changed requirements; and late completion leads to schedule slip. These imply that every task owner or engineer be in close communication with their internal customer to fully understand their needs and expectations, and to coordinate their work. |
| − | * | + | * Pursue perfection of all processes. Global competition requires continuous improvements of processes and products. Yet, no organization can afford to spend resources improving everything all the time. We need to make a distinction between processes and process outputs. Perfecting and refining the work output in a given task must be bounded by the overall value proposition (system or mission success and program budget and schedule) which define when an output is good enough. In contrast, engineering and other processes must be continuously improved for never - ending competitive reasons. |
| − | *Respect people. | + | * Respect for people. A Lean enterprise is an organization that recognizes that its people are the most important resource. In a Lean enterprise people are not afraid to identify problems and imperfections honestly and openly in real time, brainstorm about root causes and corrective actions without fear, plan effective solutions together by consensus, to prevent the problem from occurring again. When issues arise, the system is blamed and not messengers. |
| + | |||
==Lean Enablers for Systems == | ==Lean Enablers for Systems == | ||
| − | In 2009, the Lean SE Working Group released a new online product named Lean Enablers for Systems Engineering (LEfSE). It is a [http://cse.lmu.edu/Assets/Colleges+Schools/CSE/Mechanical+Engr/LEfSE+Quick+Reference+Guide+(8+pages$!2c+pdf).pdf collection of | + | In 2009, the Lean SE Working Group released a new online product named Lean Enablers for Systems Engineering (LEfSE). It is a [http://cse.lmu.edu/Assets/Colleges+Schools/CSE/Mechanical+Engr/LEfSE+Quick+Reference+Guide+(8+pages$!2c+pdf).pdf collection of 147 practices and recommendations] formulated as “dos” and “don’ts” of SE based on Lean Thinking. The practices cover a large spectrum of SE and other relevant enterprise management practices, with a general focus to improve program value and stakeholder satisfaction, and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six Lean Principles. The LEfSE are not intended to become a mandatory practice. Instead, they should be used as a checklist of good practices. LEfSE do not replace the traditional SE; they amend it with Lean Thinking. |
LEfSE were developed by 14 experienced INCOSE practitioners, some recognized leaders in Lean and SE from industry, academia and governments (from the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They adopted best practices from the best companies, added collective tacit knowledge, wisdom, and experience of the LSE WG members, and inserted best practices from Lean research and literature. The product has been evaluated by surveys and comparisons with the recent programmatic recommendations by GAO and NASA. | LEfSE were developed by 14 experienced INCOSE practitioners, some recognized leaders in Lean and SE from industry, academia and governments (from the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They adopted best practices from the best companies, added collective tacit knowledge, wisdom, and experience of the LSE WG members, and inserted best practices from Lean research and literature. The product has been evaluated by surveys and comparisons with the recent programmatic recommendations by GAO and NASA. | ||
Revision as of 23:36, 1 March 2012
Lean engineering is the application of Lean Thinking (Womack, 2003) to engineering, project management, and related disciplines. It increases value by reducing waste.
Lean Systems Engineering
Systems Engineering (SE) is an established, sound practice, but not always delivered effectively. Most programs are burdened with some form of waste: poor coordination, unstable requirements, quality problems, delays, rework, and management frustration. Recent U.S. GAO, NASA and MIT studies of government programs document major budget and schedule overruns, and a significant amount of waste in government programs, reaching 70 percent of charged time. This waste represents a productivity reserve in programs and major opportunities to improve program efficiency.
Lean Systems Engineering (LSE) is the application of Lean Thinking to system engineering and related aspects of enterprise and project management. SE is focused on the discipline that enables flawless development of complex technical systems. Lean Thinking is a holistic paradigm that focuses on delivering maximum value to the customer and minimizing wasteful practices. Lean Thinking has been successfully applied in manufacturing, aircraft depots, administration, supply chain management, healthcare, and product development, including engineering. Lean SE is the area of synergy between Lean Thinking and SE, with the goal to deliver the best life-cycle value for technically complex systems with minimal waste. LSE does not mean less SE. It means more and better systems engineering with higher responsibility, authority, and accountability (RAA), leading to better, waste-free workflow with increased mission assurance. Under the LSE philosophy, mission assurance is non-negotiable, and any task which is legitimately required for success must be included, but it should be well-planned and executed with minimal waste.
Lean Principles
Oppenheim (2011) describes the six Lean Principles for Product Development (PD) as follows (they are referred to by the undelined words):
- Capture the value defined by the Customer. One cannot over emphasize the importance of capturing task or program value (requirements, CONOPS, etc.) with precision, clarity and completeness before resource expenditures ramp up to avoid unnecessary rework.
- Map the value stream (plan the program) and eliminate waste. Map all end - to - end linked tasks, control/decision nodes and the interconnecting information flows necessary to realize customer value. During the mapping process, eliminate all non - value added activities, and enable the remaining activities to flow without rework, backflow or stopping). The term information flow refers to the packets of information (knowledge) created by different tasks and flowing to other tasks for subsequent value adding: design, analysis, test, review, decision, or integration. Each task adds value if it increases the level of useful information and reduces risk in the context of delivering customer value.
- Flow the work through planned and streamlined value - adding steps and processes, without stopping or idle time, unplanned rework, or backflow. To optimize flow, one should plan for maximum concurrency of tasks, up to near - capacity of an enterprise. Legitimate engineering iterations are frequently needed in PD, but they tend to be time consuming and expensive if they extend across disciplines. Lean PD encourages efficient methodology of fail early - fail often through rapid architecting and discovery techniques during early design phases. Lean flow also makes every effort to use techniques that obviate lengthy iterations, such as: design frontloading, trade space explorations, set designs, modular designs, legacy knowledge, and large margins. Where detailed cross - functional iterations are indeed necessary, Lean flow optimizes iteration loops for overall value.
- Let customers pull value. In PD, the pull principle has two important meanings: 1) The inclusion of any task in a program must be justified by a specific need from an internal or external customer, and coordinated with them, and 2) The task should be completed when the customer needs the output: excessively early completion leads to “shelf life obsolescence” including possible loss of human memory, or changed requirements; and late completion leads to schedule slip. These imply that every task owner or engineer be in close communication with their internal customer to fully understand their needs and expectations, and to coordinate their work.
- Pursue perfection of all processes. Global competition requires continuous improvements of processes and products. Yet, no organization can afford to spend resources improving everything all the time. We need to make a distinction between processes and process outputs. Perfecting and refining the work output in a given task must be bounded by the overall value proposition (system or mission success and program budget and schedule) which define when an output is good enough. In contrast, engineering and other processes must be continuously improved for never - ending competitive reasons.
- Respect for people. A Lean enterprise is an organization that recognizes that its people are the most important resource. In a Lean enterprise people are not afraid to identify problems and imperfections honestly and openly in real time, brainstorm about root causes and corrective actions without fear, plan effective solutions together by consensus, to prevent the problem from occurring again. When issues arise, the system is blamed and not messengers.
Lean Enablers for Systems
In 2009, the Lean SE Working Group released a new online product named Lean Enablers for Systems Engineering (LEfSE). It is a collection of 147 practices and recommendations formulated as “dos” and “don’ts” of SE based on Lean Thinking. The practices cover a large spectrum of SE and other relevant enterprise management practices, with a general focus to improve program value and stakeholder satisfaction, and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six Lean Principles. The LEfSE are not intended to become a mandatory practice. Instead, they should be used as a checklist of good practices. LEfSE do not replace the traditional SE; they amend it with Lean Thinking.
LEfSE were developed by 14 experienced INCOSE practitioners, some recognized leaders in Lean and SE from industry, academia and governments (from the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They adopted best practices from the best companies, added collective tacit knowledge, wisdom, and experience of the LSE WG members, and inserted best practices from Lean research and literature. The product has been evaluated by surveys and comparisons with the recent programmatic recommendations by GAO and NASA. Oppenheim (2011) includes a comprehensive explanation of the enablers, as well as the history of LSE, the development process of LEfSE, industrial examples, and other material. Oppeneheim, Murman, and Secor (2011) provide a scholarly article about LEfSE. A short summary was published in 2009 by Oppenheim. The Lean SE WG public web page contains descriptions of LSE and LEfSE that vary from entry level (a brochure, short articles, power point presentation, and a video lecture), to full-length desktop Guidebook, and scholarly paper.
References
Works Cited
Lean Enterprise Institute. 2009. "Principles of Lean." Accessed 1 March 2012 at http://www.lean.org/WhatsLean/Principles.cfm.
Lean Systems Engineering Working Group. 2009. "Lean Enablers for Systems Engineering." Accessed 1 March 2012 at http://cse.lmu.edu/Assets/Colleges+Schools/CSE/Lean+Enablers+for+SE+Version+1.01.pdf
Lean Systems Engineering Working Group. 2009. "QUICK REFERENCE GUIDE LEAN ENABLERS FOR SYSTEMS ENGINEERING." Accessed 1 March 2012 at http://cse.lmu.edu/Assets/Colleges+Schools/CSE/Mechanical+Engr/LEfSE+Quick+Reference+Guide+(8+pages$!2c+pdf).pdf.
Oppenheim, Bohdan W. 2009. "Process Replication: Lean Enablers for Systems Engineering." CrossTalk, The Journal of Defense Software Engineering. July/August 2009.
Oppenheim, Bohdan W. 2011. Lean for Systems Engineering, with Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley.
Oppenheim, Bohdan W., Murman Earl M., and Secor Deborah. 2011. "Lean Enablers for Systems Engineering." Journal of Systems Engineering, No. 1, Vol. 14.
Womack, James P. 2009. Lean Thinking. Columbus, OH, USA: Free Press.
Primary References
No primary references have been identified for version 0.75. Please provide any recommendations on additional references in your review.
Additional References
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.