Difference between revisions of "Lean Engineering"
| Line 1: | Line 1: | ||
| − | [[Lean Systems Engineering (LSE) (glossary)|Lean Systems Engineering (LSE)]] is the application of lean thinking (Womack | + | [[Lean Systems Engineering (LSE) (glossary)|Lean Systems Engineering (LSE)]] is the application of lean thinking (Womack 2003) to systems engineering (SE) and related aspects of enterprise and project management. LSE is an approach that is applicable throughout the system [[Life Cycle (glossary)|life cycle]]. The goal of LSE is to deliver the best life-cycle value for technically complex systems with minimal waste. Lean engineering is relevant to all of the traditional SE technical processes (see [[Concept Definition|concept definition]], [[System Definition|system definition]], [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], etc.). Lean engineering also interacts with and utilizes many of the [[Systems Engineering and Specialty Engineering|specialty engineering disciplines]] discussed in [[Related Disciplines|Part 6]]. |
==Lean Systems Engineering== | ==Lean Systems Engineering== | ||
| Line 12: | Line 12: | ||
#'''''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 prevent 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. | #'''''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 prevent 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 slips. This is the reason that every task owner or engineer needs to be in close communication with their internal customers to fully understand their needs and expectations and to coordinate their work. | #'''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 slips. This is the reason that every task owner or engineer needs to be in close communication with their internal customers 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. | + | #'''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. Systems engineers must 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, program budget and schedule) which define when an output is "good enough". In contrast, engineering and other ''processes'' must be continuously improved for 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, or plan effective solutions together by consensus to prevent a problem from occurring again. | #'''''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, or plan effective solutions together by consensus to prevent a problem from occurring again. | ||
| Line 18: | Line 18: | ||
In 2009, the International Council on Systems Engineering's (INCOSE's) Lean SE Working Group (LSE WG) released an online product entitled ''Lean Enablers for Systems Engineering (LEfSE)''. It is a collection of 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 on improving the program value and stakeholder satisfaction and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six lean principles outlined above. The LEfSE are not intended to become a mandatory practice but should be used as a checklist of good practices. LEfSE do not replace the traditional SE; instead, they amend it with lean thinking. | In 2009, the International Council on Systems Engineering's (INCOSE's) Lean SE Working Group (LSE WG) released an online product entitled ''Lean Enablers for Systems Engineering (LEfSE)''. It is a collection of 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 on improving the program value and stakeholder satisfaction and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six lean principles outlined above. The LEfSE are not intended to become a mandatory practice but should be used as a checklist of good practices. LEfSE do not replace the traditional SE; instead, they amend it with lean thinking. | ||
| − | LEfSE were developed by fourteen experienced INCOSE practitioners, some recognized leaders in lean and SE from industry, academia, and governments (such as the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. | + | LEfSE were developed by fourteen experienced INCOSE practitioners, some recognized leaders in lean and SE from industry, academia, and governments (such as the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They collected best practices from the many 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 also published by Oppenheim in 2009. | 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 also published by Oppenheim in 2009. | ||
| Line 25: | Line 25: | ||
===Works Cited=== | ===Works Cited=== | ||
| − | 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. "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. | 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. | ||
| Line 33: | Line 33: | ||
Oppenheim, B.W. 2011. ''Lean for Systems Engineering, with Lean Enablers for Systems Engineering''. Hoboken, NJ, USA: Wiley. | Oppenheim, B.W. 2011. ''Lean for Systems Engineering, with Lean Enablers for Systems Engineering''. Hoboken, NJ, USA: Wiley. | ||
| − | Oppenheim, B.W., E.M. Murman, and D. Secor. | + | Oppenheim, B.W., E.M. Murman, and D. Secor. 2011. "Lean Enablers for Systems Engineering." ''Journal of Systems Engineering.'' 1(14). |
| − | Womack, J.P. | + | Womack, J.P. 2003. ''Lean Thinking.'' Columbus, OH, USA: Free Press. |
===Primary References=== | ===Primary References=== | ||
| − | Lean Systems Engineering Working Group. 2009. "[[INCOSE Lean Enablers for Systems Engineering|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. "[[INCOSE Lean Enablers for Systems Engineering|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. |
| − | Oppenheim, B., E. Murman, and D. Sekor. 2010. "[[Lean Enablers for Systems Engineering]]." Systems Engineering. 14(1). Accessed on September 14, 2011. Available at http://cse.lmu.edu/Assets/Lean+Enablers.pdf | + | Oppenheim, B., E. Murman, and D. Sekor. 2010. "[[Lean Enablers for Systems Engineering]]." Systems Engineering. 14(1). Accessed on September 14, 2011. Available at http://cse.lmu.edu/Assets/Lean+Enablers.pdf. |
===Additional References=== | ===Additional References=== | ||
| Line 47: | Line 47: | ||
---- | ---- | ||
<center>[[Integration of Process and Product Models|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Concept Definition|Next Article >]]</center> | <center>[[Integration of Process and Product Models|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Concept Definition|Next Article >]]</center> | ||
| − | |||
[[Category:Part 3]][[Category:Topic]][[Category:Life Cycle Models]] | [[Category:Part 3]][[Category:Topic]][[Category:Life Cycle Models]] | ||
{{DISQUS}} | {{DISQUS}} | ||
Revision as of 13:58, 22 April 2013
Lean Systems Engineering (LSE) is the application of lean thinking (Womack 2003) to systems engineering (SE) and related aspects of enterprise and project management. LSE is an approach that is applicable throughout the system life cycle. The goal of LSE is to deliver the best life-cycle value for technically complex systems with minimal waste. Lean engineering is relevant to all of the traditional SE technical processes (see concept definition, system definition, system realization, system deployment and use, etc.). Lean engineering also interacts with and utilizes many of the specialty engineering disciplines discussed in Part 6.
Lean Systems Engineering
SE is an established, sound practice, but not always delivered effectively. Most programs are burdened with some form of waste such as: poor coordination, unstable requirements, quality problems, delays, rework, or management frustration. Recent U.S. Government Accountability Office (GAO), National Aeronautics and Space Association (NASA), and Massachusetts Institute of Technology (MIT) studies of government programs document major budget and schedule overruns and a significant amount of waste in government programs - some reaching seventy percent of charged time. This waste represents a productivity reserve in programs and major opportunities to improve program efficiency.
LSE is the application of lean thinking to systems engineering and related aspects of enterprise and project management. SE is focused on the discipline that enables development of complex technical systems. Lean thinking is a holistic paradigm that focuses on delivering maximum value to the customer and minimizing wasteful practices. It has been successfully applied in manufacturing, aircraft depots, administration, supply chain management, healthcare, and product development, which includes engineering. LSE is the area of synergy between lean thinking and SE, which aims 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 SE 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; however, 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:
- 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, such as: 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 prevent 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 slips. This is the reason that every task owner or engineer needs to be in close communication with their internal customers 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. Systems engineers must 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, program budget and schedule) which define when an output is "good enough". In contrast, engineering and other processes must be continuously improved for 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, or plan effective solutions together by consensus to prevent a problem from occurring again.
Lean Enablers for Systems
In 2009, the International Council on Systems Engineering's (INCOSE's) Lean SE Working Group (LSE WG) released an online product entitled Lean Enablers for Systems Engineering (LEfSE). It is a collection of 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 on improving the program value and stakeholder satisfaction and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six lean principles outlined above. The LEfSE are not intended to become a mandatory practice but should be used as a checklist of good practices. LEfSE do not replace the traditional SE; instead, they amend it with lean thinking.
LEfSE were developed by fourteen experienced INCOSE practitioners, some recognized leaders in lean and SE from industry, academia, and governments (such as the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They collected best practices from the many 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 also published by Oppenheim in 2009.
References
Works Cited
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, B.W. 2009. "Process Replication: Lean Enablers for Systems Engineering." CrossTalk, The Journal of Defense Software Engineering. July/August 2009.
Oppenheim, B.W. 2011. Lean for Systems Engineering, with Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley.
Oppenheim, B.W., E.M. Murman, and D. Secor. 2011. "Lean Enablers for Systems Engineering." Journal of Systems Engineering. 1(14).
Womack, J.P. 2003. Lean Thinking. Columbus, OH, USA: Free Press.
Primary References
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.
Oppenheim, B., E. Murman, and D. Sekor. 2010. "Lean Enablers for Systems Engineering." Systems Engineering. 14(1). Accessed on September 14, 2011. Available at http://cse.lmu.edu/Assets/Lean+Enablers.pdf.
Additional References
Lean Enterprise Institute. 2009. "Principles of Lean." Accessed 1 March 2012 at http://www.lean.org/WhatsLean/Principles.cfm.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus