Difference between revisions of "Lean Engineering"
| Line 7: | Line 7: | ||
===Lean Principles=== | ===Lean Principles=== | ||
| − | Oppenheim (2011) describes the six | + | Oppenheim (2011) describes the six lean principles for product development (PD) as follows (they are referred to by the bold 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. | + | *'''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. | + | *''' ''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. | + | *'''''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. | + | *'''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. | + | *'''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. | + | *'''''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 == | ||
Revision as of 18:06, 29 August 2012
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: poor coordination, unstable requirements, quality problems, delays, rework, or management frustration are common issues. 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 70 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, 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 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, 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 bold 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 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. 2003. Lean Thinking. Columbus, OH, USA: Free Press.
Primary References
None.
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