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.

Overview

• Why needed?

• Quick intro to Continuous Improvement Model

• Definitions

• Process Overview

• Summary

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!

Key Concepts within Continuous Improvement Model

• Data Driven– Knowledge and acceptance of variation!!!

• Systems Driven– People– Equipment– Process

System Perspective

Inputs OutputsValue Added

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

Must View as an Extended System

SupplierSupplier Value Added

Customer

Measurements

FeedbackFeedback

Another View of System Perspective

Inputs Value Added

Outputs

InputsValue Added

Outputs

Inputs Value Added

Outputs

And So On…….

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

Basic Six Sigma Improvement

• Define

• Measure

• Analyze

• Improve

• Control

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

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.

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

1) Process

2) Outputs 3) Users/Customers

5) Key Measures 4) Needs

Collect Data

• Tools– Pareto

• Count of the data and then plot• Agree on Classification before starting

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

Must be Normal Variance to Use Statistics

Example of a Control ChartControl Chart Individual Measurement of Column 1

-2

0

2

4

6

8

10

12

Colu

mn 1

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34

Sample

Avg=5.20

LCL=-0.31

UCL=10.71

Moving Range of Column 1

-1

0

1

2

3

4

5

6

7

8

Colu

mn 1

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34

Sample

Avg=2.07

LCL=0.00

UCL=6.77

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

Identify What to Improve

• Highest Pareto

• Highest Vote

• Process Robustness not adequate

• Brainstorm Solutions

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

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)

Assign possible cause/effect

Materials Methods

Machines People

Measurement

Outputs

Track Improvements

• Preferably using same data that was used to identify issue

Basic Process Improvement SystemDefine System To Be Improved

Define Key Measures & Operational Definitions

Check Measurement System Capability

Gather Data

Stable?

Identify Potential System Changes For Improvement

Implement Proposed System Improvement

Monitor System Output For Improvement

Capable?

Institutionalize The System Improvement

Get Local Workforce Input To Attack Special Causes

YES

NO

YES

NO

Flow Chart

BrainstormingPresently Available Data

Data CollectionRun ChartsHistogramsControl Charts

Data Collection Repeatability StudyControl Chart(s)

BrainstormingFishbone DiagramsPareto DiagramsData Collection & Study Force Field Analysis

Data CollectionControl Charts

Process Capability Study

Publish Success Story

• Case Study Examples

• Areas of Opportunity Identifed By Tefen

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

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)

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

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

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

Technology Transfer Governance

• No Formal Oversight

• No Direct Link to Other teams (i.e. CMC, Program)

Path Forward

• Senior Governance Structure Established– Regular Updates required– Interim Updates expected if issues arise

• Methods established to link all program related teams

Next StepsAreas Goal Reason

PD Lab experiments Quicker lock down of process Robust process identified earlier

Materials Management Reduce complexity of ordering new materials

Bottle neck for new materials approval

Equipments Reduce capital cost Equipment ordered and shelved

Manufacturing runs Quicker learning during Scale up runs

Excessive paperwork delaying process

TTR Reduce iterations Causes excessive downstream changes

Batch Records Reduced number of change iterations and standardize

Excessive paperwork, training and confusion

SOPs Standardize process Excessive paperwork, training and confusion

• Questions?