Use of Systematic Continuous Improvement Model to Evaluate and Improve Technology Transfer

1. Use of Systematic Continuous Improvement Model to Evaluate and Improve Technology Transfer Michael Murphy, Principal Development Specialist Shire HGT September 2008 The information presented herein represents the views of the presenter, and not necessarily the views of Shire Human Genetic Therapies, Inc.

2. Overview • Why needed? • Quick intro to Continuous Improvement Model • Definitions • Process Overview • Summary

3. Why Continuous Improvement?? • Companies grow + Departments grow + Systems established within departments + Links created between individual systems = Non Value Added Links and Tasks, Systems that work well individually but need improvement as an overall system!

4. Key Concepts within Continuous Improvement Model • Data Driven • Knowledge and acceptance of variation!!! • Systems Driven • People • Equipment • Process

5. System Perspective Inputs Outputs Value Added

6. Understand the System Not Events! • Must manage the system, not the events • Tech Transfer is never right • PD doesn’t deliver a process that works • We never have enough time to transfer a process

7. Must View as an Extended System Supplier Value Added Customer Supplier Measurements Feedback Feedback

8. Another View of System Perspective Value Added Inputs Outputs Value Added Outputs Inputs Value Added Inputs Outputs And So On…….

9. Net Effect= Greater and Greater Variation (It all Adds up)

10. Basic Six Sigma Improvement • Define • Measure • Analyze • Improve • Control

11. Define? • Team Charter • Clarity is important • Charter needs to say what you will try to do and how you will get there. • Set Up rules • Scope includes do’s and don’t • Set up team rules (resolution and brainstorming) • Revisit as necessary

12. Construct a Flow Chart • Cross Functional Not Independent • Flag Non Value added steps/links • Flag where process may be simplified • Now that the process/system is understood, everyone is on the same page to come up with ideas to improve it.

13. How to Define Measurements • Select a Process • List the Outputs • List The Users • List User Needs (terms like good, timely, user friendly, effective, accurate) • List Key Measures

14. Process

15. Collect Data • Tools • Pareto • Count of the data and then plot • Agree on Classification before starting

16. Statistical Process Control Charts (Run Charts) • Determine normal variances, special causes • Is process stable (i.e normal variation) • Eliminate special causes through root cause analysis • Is process robust (i.e. does the normal variation satisfy our needs) • Improve robustness through process improvement

17. Must be Normal Variance to Use Statistics

18. Example of a Control Chart

19. What if There is No Data?? • Vote on the proposed causes • Each member votes for each proposed cause • Rated scores • Total the scores for most likely candidates for team to improve

20. Identify What to Improve • Highest Pareto • Highest Vote • Process Robustness not adequate • Brainstorm Solutions

21. Brainstorming Issues • People calling out ideas as they come to them (Talkative people dominate) • Arguments against ideas start immediately preventing the generation of new ideas • When technical experts/higher level people speak the ideas seem like • Blah Blah Blah • Blah Blah Blah • Expert’s Idea • Blah Blah Blah • Blah Blah Blah

22. Organized Brainstorming • Post topic • Allow for silent writing • Give ideas one by one in order • No comments/interruptions allowed • May Pass (doesn’t prevent from joining back in later)

23. Assign possible cause/effect Materials Methods Outputs Measurement Machines People

24. Track Improvements • Preferably using same data that was used to identify issue

25. Basic Process Improvement System

26. Case Study Examples • Areas of Opportunity Identifed By Tefen

27. Team Dynamics • Current Status: • An ad hoc group of individuals from various disciple attend meetings • Lack of accountability and ownership of members of this team • Lack of a joint decision. Individual departments own the process • Lack of continuity of the members through the life cycle of the transfer – from initiation to Phase I to Phase III to Commercialization • Not a team, but a group

28. Path Forward • Best practice: • A formal and joint group of individuals who work towards a common goal that is aligned to the vision of the overall organization is a Team • Autonomy to make decisions that affect the process but still within the parameters of the Program • Embrace decisions as a Team • Team leader to manage process and support team members • Consistent use of action logs • Meeting discipline practices (effectiveness and efficiency)

29. Structure • Best practice: • Single point contact in each organization • Team meets on a weekly basis for an hour • Each member updates the team on progress, decisions made and changes to process • Project Manager is the facilitator and coordinator between all departments

30. Team Leader • Current Status • Lack of cohesive person for the overall process • Current leader is acknowledged to be MTS, but with no formal authority • More of a reactive management than proactive • Unclear charter of the MTS organization in support of tech transfer activities

31. Path Forward • Best practice • Project Manager for a product-specific Tech Transfer • Project Manager is responsible for the Tech Transfer up to the PVR, and eventually responsible for future Tech Transfers of the product during commercial operations • Primary role is to ensure that the Tech Transfer process is aligned with the organization’s Tech Transfer vision

32. Technology Transfer Governance • No Formal Oversight • No Direct Link to Other teams (i.e. CMC, Program)

33. Path Forward • Senior Governance Structure Established • Regular Updates required • Interim Updates expected if issues arise • Methods established to link all program related teams

34. Next Steps

35. Questions?