Introduction to Design for Sigma. Developed By

Transcription

1 Introduction to Design for Sigma Developed By T. Lahdhiri, PhD, PE, PMP, BB-DFSS

2 Introduction Sigma and Design for Six Sigma

3 Measuring Quality - Sigma Quality: is the degree of completeness and perfection of a product, process or service from the customer s viewpoint Defect: If the outcome is too far from the target value, then a defect occurs Lower Spec Limit Target Upper Spec Limit Standard deviation (σ), is a measure of variation from the target Sigma Level, Z, of a process is: Defects s Defects Z = (Spec Limit - Target) Std Dev σ Sigma Level measures the probability of achieving a defect-free outcome 3s Sigma Level = 3

4 What is Six Sigma? Definition: The Sigma Capability of a process compares the Process performance with respect to the customer specifications. It is correlated to the defect rate and the complexity of the process/product. Objective: Fit the product performance curve within the lower and upper specification

5 Benefits of Six Sigma With six sigma, the process FITS well within the specifications, so even if the process shifts, the values fall well within tolerances

6 What is Design for Six Sigma DFSS is a design process DFSS is or not necessarily a statistical process as it sounds DFSS is fundamental, good engineering. DFSS is Structured, data-driven problem-solving methodology DFSS insists on evidence to support decisions. Show me are the DFSS main arguments

7 Why Design for Six Sigma Cause of Defects 30% Manufacturing 70% Design Methodologies used for problem solving 5% - Intuition 45% - Brainstorming 45% - Basic chart and Statistical Analysis 5% - Inferential Statistics DFSS supports making decisions where Data is the driving force quickly and efficiently (cost & time) that add value (benefit) while balancing risk

8 DFSS Process Identify objectives Identify customers Identify team Develop a plan Verify product performance Verify Process performance Test Identify Define Define requirements Define measures Define opportunities for enhancements Identify opportunities for enhancements Improve by identifying root causes Improve Design Develop concepts Evaluate concepts Select the appropriate concept

9 DFSS Identify Phase Objective: Develop a Plan

10 5 W s Questions 5 W s Questions Why: Define value for customers What: Define scope and objectives When: Define milestones, deliverables, and timeline Who: Create a team and responsibility chart Where: Define location The goal is to develop a plan for a robust design

11 Scope and Objective Define the objective of the project Example: Create a software package to automate the execution of test cases on the bench for Electronic Control Units (ECUs) Define current practices Define scope/boundaries: Use diagrams to define what is-cope and what is out of scope

12 Example: Bench Automation Project Specifications Interfaces Scripting Automation Software Simulation Instrumentation Report Bench

13 Team Identify everyone on the core team Their functional department Their general role on the project Their contact information Create a roles list and responsibility matrix Clarifying and communication tools Critical for elucidating cross-functional responsibilities Do early and update as more is known Keep the team list visible

14 Team Roles List Members Assignment Phone/ OEM Project Owner, OEM Project Owner: Budget approval + Group manager , group.manager@oem.com OEM Project Manager, OEM Project Manager: Business Case + Requirements + UATs + Supplier management + Technical reviews , project.manager@oem.com OEM Project Champion, OEM Project Champion: Techincal reviews + Product testing and evaluation , project.champion@oem.com OEM Bench Engineer, OEM Bench Engineer: Bench Application and setup + Product Integration , Bench.Engineer@oem.com OEM Model Engineer, OEM Model Engineer: Provide test vectors and modeling support , Model.Engineer@oem.com TEAM OEM Application Engineer, OEM Application Engineer: User Acceptance Test and HW platform support , Model.Engineer@oem.com OEM IT Representative, OEM IT Coordinator: System integration within the corporate network and deployment , it.coordinator@oem.com OEM Purchasing Representative, OEM Purchasing Coordinator: SOW + PO + Payments , it.coordinator@oem.com Supplier Team Leader, Supplier Supplier PM, Supplier Supplier Engineer-01, Supplier Supplier Engineer-02, Supplier Supplier: Develop and deploy the Automation Tool , Ext 232, Tech.Lead@supplier.com , Ext 249, project.manager@supplier.com , Ext 289, engineer.01@supplier.com , Ext 272, engineer.02@supplier.com

15 Scheduling/Estimating Steps Create a work breakdown structure Estimate work to complete the tasks Identify dependencies among tasks Assign resources to tasks Identify critical issues to track Include contingency plans Identify milestones to track

16 Project Timeline Set up tools for tracking Schedule software if desired Project Vision Milestone lists Critical issues list Action items, key decisions Design review checklists Testing and defect goals, tracking mechanisms Keep these tools visible to the team

17 Milestones 1. Project Initiation 2. Work break down structure 3. Design Document Milestones Description Project Kick-off meeting + Defining milestone, diliverables, and project timeline Supplier to provide the work break down structure and a high level design document Supplier to provide all input required to generate the Design Document required for the Toll-Gate Target Date Status 1/7/2011 Completed 01/11/11 2/1/2011 2/18/2011 Completed 02/01/11, Approved by PM Completed 02/21/11, Approved (TG, 3/1/11) 4. Toll Gate OEM Project Manager to go through an internal Toll Gate 3/1/2011 Completed 09/01/11 (Design Approved) MILESTONES 5. Data Type Definition Supplier to provide the XML DTDs 3/21/2011 Completed 09/21/11 6. Alpha release Supplier to provide the Alpha release + Demo 5/1/ Beta release Supplier to provide the Beta release + Demo 6/1/ Pre-Production Release Supplier to provide the Pre-production release + Demo 7/15/ OEM Feedback to Supplier Completed 09/01/11 Approved by (PM, PC) Completed 06/30/11 Approved (PM & PC) Completed 09/15/11 Approved (PM & PC) GM to provide fedback about the pre-production release 7/31/2011 Completed 09/01/ Final release Supplier to provide the Final release + Demo 8/15/ UATs + Documentation 12. Sign-off + Project Closing Completed 10/15/11 Approved (PM & PC) Finalize User Acceptance Tests + final documentation 9/1/2011 Completed 11/06/11 Approve the product and close the project 9/7/2011 Completed 11/11/11

18 Deliverables Deliverables Description Target Date Status Work Breakdown Structure Detailed work breakdown structure 2/1/2011 Completed 02/01/11, Approved by PM High level Design Document High level design document 2/1/2011 Completed 02/01/11, Approved by PM Detailed Design Document Final design document required for OEM Internal Toll-Gate 2/18/2011 Completed 02/21/11, Approved (TG, 3/1/11) DELIVERABLES Alpha SW Release Alpha Software: Functional software 5/1/2011 Completed 09/01/11 Approved by (PM, PC) Beta SW Release Beta Software and Initial System/User Documentation 6/1/2011 Completed 06/30/11 Approved (PM & PC) Final SW Release Final release and System/User Documentation and Pre Deployment Demo 8/15/2011 Completed 10/15/11 Approved (PM & PC) Closing the project UATs + sign-off 9/7/2011 Completed 11/11/11

19 DFSS Define Phase Objective: Define requirements

20 Customers Identify your customer Get input and understand the customer needs Define value for the customer Increase efficiency Consistency Speed of delivery Eliminate waste Reduce cost without reducing performance Increase market share

21 Define your System Identify the inputs and outputs of the system Understand the functionality of the system Define the system s function Inputs X1, X2, X3 System Description Function F(.) Y = F(X) Outputs Y1, Y2, Y3 Example: Temperature Regulation System Temperature Humidity Heat Vent Cooling (HVC) System HVC Controls

22 Functional Requirement Functional Behavior Data Performance Interfaces Non-Functional Requirements Usability Training Security Operating system and CM Tool Requirements Testing setup Testing tools Requirements Gather all specifications to define the best project requirements Discuss the requirements with customers and do not interpret them on your own way

23 Translating Requirements into Functional Measures It is not always obvious how to translate the requirements and customer needs. Customers do not use engineering terms. Customers convey their perceptions in their own terms (e.g. fast, reliable, friendly, etc...) Be careful not to jump to the wrong conclusion based on the voice of customers. Define functional measures to translate the requirements

24 Developing Functional Measures Use rigorous methods to develop evidence Hypothesis Use your understanding of the system and expertise to come up with a functional measure Test Test the hypothesis and collect data Conclusion Analyze data against hypothesis Make decision about adopting the hypothesis

25 DFSS Design Phase Objective: Create the best concept

26 Current Practices Identify the current methodologies being used Example: Testing of Vehicle Electronic Control Units - in-vehicle testing - Manual testing in the lab Gather data for all existing methods and processes Example: - How long does it to perform the complete test suite - Equipment and instrumentation needed - Cost - Reusability Use visual methods (graphs) to analyze data Define opportunities for enhancements

27 Develop Concepts You can start with existing concepts Develop concept alternatives Compare and contrast alternatives: Benchmark. Use your understanding of the contrasts to develop better concepts Use the data to select the best concept for your application and not to defend any concept The best concept may not be in your concept list

28 Select The Best Concept Select the best concept for your application Method: Use the Pugh Concept developed by Dr. Stewart Pugh from the University of Strathclyde, Glasgow, Scottland This method is based on establishing selection criteria Criteria should be measurable You may need to rank the criteria (priority) Use data to compare criteria and not personal judjment

29 Concept 1 Concept 2 Concept 3 Pugh Matrix Score: S: Same +: stregth -: Wekness Criteria Priority Concept 0 Functional/Performance Criteria - Function of the concept - Performance Requirements - Additional functional Criteria identified Non functional Criteria - Cost - Time - Risk D A T U M Score - Sum of "+" - Sum of "-" - Sum of "S"

30 Concept 1 Concept 2 Concept 3 Sample of Pugh Matrix & Interpretation Score: S: Same +: stregth -: Wekness Criteria Priority Concept 0 Functional/Performance Criteria - Function of the concept - S + - Performance Requirements S S + - Additional functional Criteria identified S S + Non functional Criteria D - Cost A + + S T - Time U + S - - Risk M S S - Score - Sum of "+" Sum of "-" Sum of "S" Less expensive and Fast Does not add any value to customer Less expensive Does not add any value to customer Best for customer Has risk and timing issues Best Solution: Concept 4 = Hybrid of Concept 2 and 3

31 DFSS Improve Phase Objective: Optimize the Design and Improve the robustness

32 Optimize Design We have already defined the functional measures that drive customer satisfaction. This is the starting point of this phase Question: Can we develop better criteria? Answer: YES, better understanding of the customer needs and using physics thinking Example: Generator Requirements Speed (RPM) The customer focus is on the energy (electric energy) Mechanical W W = Tq*RPM Generator Generator Current Electric W W= V*I This may lead to different design and selection

33 Improve Robustness Robustness is a measure of the design sensitivity to noise factors Noises are undesired functions of the system or external factors acting on the system Examples: Digitization of signals introduces quantization noise (noise created by the process it self) Temperature may affect the overall system behavior for a sensor (external factor) Noise factors have an effect on measurements (e.g. vibration). Robust design involves deciding on the best values and/or levels for the control factors in the presence of noise factors.

34 Parameter Diagram (P-Diagram) The P-Diagram relates the inputs to desired outputs of a design that the engineer is creating. Also it takes into consideration non-controllable outside influences. P-Diagram with an example (Generator) Control Factor Power Rating Type Size Inputs Mechanical Energy System Generator Outputs Electrical Energy Noise Factors Temperature Symptoms Magnetic noise Aerodynamic noise

35 DFSS Test Phase Objective: Verify that the design meets requirements

36 Test and Verify Develop a test plan Implement the solution and test the product Collect data Analyze data Verify that the product works as expected Prove that all hypothesis are correct Verify that product meets requirements The key success in this phase is to define Use Cases

37 Use Cases Create use cases to test the product vs. requirements Use Case ID: Requirement-2013-UC-R.1.1 Script Generation Load Project Use Case Name: Script Generation Load Project Version No: Final End Objective: Load all script files from previous session. Created by: Bench Engineer On (date): 01/22/2013 Last Update by: Bench Engineer On (date): 01/29/2013 Approved by: PM On (date): 01/29/2013 Business Owner Name: Manager Contact Details: Trigger: Script Generation Load Project Frequency of Use: N/A Basic Flow Step User Actions System Actions 1 The Engineer selected Load Project The associated script generation files for the selected project are loaded. Each requirement should be mapped to a use case

38 DFSS Closing and Concluding Remarks

39 Finalizing the Project Closing the Project All phases are completed All critical issues are addressed Product is approved by customer Advertise your accomplishment: Documentation Complete and approve all documents related to the project Lessons Learned Conduct a lesson learned session Document what went good and wrong What can be done better in the future

40 Concluding Remarks DFSS is a design process that change a traditional Reactive Design Process into a Predictive Design Process Disciplined flow down and requirement development Controlled design parameters Data driven solution Robust design to minimize changes for flaws Quality is designed in DFSS Evolving and continuously changing design requirement Extensive and expensive design rework Performance and robustness is assessed by build and test Flaws discovered after putting the product in use Quality tested in

41 IT S TIME FOR QUESTIONS

42 Thank you for your time. Contact Information: Tarek Lahdhiri