16 - ryoma shiratsuchi & keita asaine_23 tocpa_us_21-22 march 2016

8/18/2019 16 - Ryoma Shiratsuchi & Keita Asaine_23 TOCPA_US_21-22 March 2016

1/30

23rd International Conference of the

TOC Practitioners Alliance - TOCPA

www.tocpractice.com 21-22 March, 201, Tennessee, !"A

If CCPM is a solution, then

what is the problem?

Ryoma Shiratsuchi & Keita Asaine, Juntos Consulting,Japan

March, 2016


2/30

23rd International Conference of the TOC Practitioners Alliance - TOCPAwww.tocpractice.com

Ryoma Shiratsuchi

Ryoma Shiratsuchi is the Co-President of Juntos Consulting Inc.,

and has over 10 years of TOC experience as practitioner, trainer

and consultant.Since 2007, he has been working with >15 companies for

implementing TOC logistical solutions – MTO, MTA and CCPM.

In 2008-2011, he was a faculty member of Goldratt Schools, and

participated in writing Goldratt Schools book – “TOC for Production

Management (2010)”

He taught Operations Management and Project Management as a

lecturer at Education & Research Center of Manufacturing, Kyushu

University.

He is also one of the Founding members of TOCPA – TOC

Practitioners Alliance.

[email protected]


3/30


Dr. Keita Asaine

Dr. Keita Asaine is the Co-President of Juntos Consulting Inc., and a CEO of Juntos Co. Ltd. He has over 10 years of TOC experience as practitioner, trainer and consultant.

Keita started his career at Juntos working in the Bridge Design Department, and gradually engaged in Sales, too.

His engagement with TOC started in 2004 as an internal consultant. Since 2007, he has been working with many companies for implementing TOC logistical solutions – MTO, MTA and CCPM.

In 2008-2011, he was a faculty member of Goldratt Schools.He has a Ph.D. in Engineering from Kyushu Institute of Technology (KIT) in Japan. He teaches TOC Thinking Processes, Production management and Project management for Masters program at KIT.

He is also one of the Founding members of TOCPA – TOC Practitioners Alliance. [email protected]


4/30


Aen!a

Insights into Multitasking

Case #1 – Big Single IT Project

Case #2 – Mold Manufacturing


5/30


"ac#roun!

• There are some discussions regarding the boundaries of CCPM.

• Some practitioners raised issues about applying CCPM into

Requirement Definition phase in IT projects.

• Recently, we can see more studies for integrating CCPM andother methods such as KANBAN.

• “What is CCPM?”


6/30


"ac# to the "asics$

“If Injection is a solution thenwhat is the problem?”

Different types of the problem requiredifferent applications of the solution…


7/30


8/30


Deman! (ariability

• High WIP makes people multitasking.

• High WIP happens when bigger work load (demand) is imposed

on available capacity.

• Demand has variability. It causes load fluctuation even if the load

was leveled in planning.

• It is important to reduce demand variability as much as possible.However, we can not eliminate but have to absorb and manage it.

Load (Demand)

Capacity

Time


9/30


• Project/Feeding Buffers absorb variability INSIDE the project.

• However, the reality shows that there are more situationssuffering from variability caused by factors OUTSIDE the project.

• Inserting Project/Feeding Buffers is NOT enough to immunize

against such disruptions.

• It is important to know the source of variability. For that, we haveto understand how multitasking occurs in the environment.

)he Role of Pro%ect*+ee!in "uffers

Pro#ect $%ffer

&eedin'

$%ffer


10/30


+our )ypes of Multitas#in

(1) Conflictin' wor*s within same phase

Shortwork

1

(3) Conflictin' wor*s in different phases (+) Pro#ect wor* s. Concept wor*

PROJECT

Shortwork

2

(2) Pro#ect wor* s. "hort wor*s

PO/CTO"T/AM 1

PO/CTO"T/AM 2

PO/CTO"T/AM 1

PO/CTO"T/AM 2

PROJECT 1

Concept work PROJECT 2


11/30


Manain (ariability

• We can see multitasking as a resulting compromised actioncaused by variability.

• Flow is characterized by demand and supply. Both of them havevariability. Managing flow requires managing variability.

• Variability can be buffered by:

▪Time

▪ Stock

▪ Capacity

• Capacity Buffer is established by limiting WIP (reduce & control).

▪ Note: Capacity Buffer is a real protective capacity. The term usedhere is different from the use of the term in multi-project CCPM.


12/30


Aen!a





13/30


"i Sinle I) Pro%ect

Project Overview

• Project Scope: Re-building IT project for Production area

• Combination with Package and Scratch Development

• Development team structure:

▪ External venders for Package Development

▪ Internal resources for Scratch Development

• Area of implementing CCPM:

▪

From Detail Design (DD) to Integration Test (IT)▪ Planned project duration was 6 months


14/30


riinal Pro%ect Plan

Task1 Task2 Task3Resource X

Resource Y

Resource Z

Detail Design

DD!

Co"ing

Co"ing!

#nit Test

#T!

$ntegration Test

$T!

Phase

&eat%re

DD: WS-A Coding: WS-A UT: WS-A%orkstrea& '

DD: WS-B Coding: WS-B UT: WS-B%orkstrea& (

DD: WS-C Coding: WS-C UT: WS-C%orkstrea& C

DD: WS-D Coding: WS-D UT: WS-D%orkstrea& D

IntegrationTest(IT)


15/30


-ow Multitas#in ccurs?

Pro'lesissues occur duringe&ecution of tasks

(Specification adjustent) Supporting resources*

Pro'lesissues occur ore and ore

Task Managers ha+ean, issues at the

sae tie（（（（$igh "IP on TMs））））

Task Managersiediatel, tr, to

resol+e issues whenha+ing pro'les

Multitasking of Task Managers

-ela,ed issueresolution

Tasks started too earl,

('efore issues are resol+ed*and progressed with

holding pro'les

!eed to show progressStanding idle is B.-

%i&ed Schedule

Specificationadjustent occurs

suddenl,


16/30


Solution for Problem

• WIP limits (Workstream level & Task level) based oncapacity of Task Managers


17/30


or#stream /e'el IP Re!uction

Plannin0 Re!uce )as# Mr1s IP

%$P Task!

on Task )anager

%$P %orkstrea&!

on Task )anager

Original

（*ig+ %$P Plan）1, Tasks - T) 1.2 %/ - T)

0ow %$P Plan Tasks - T) 1 %/ - T)

Original Plan Resource ConcentrationResource Concentration

%orkstrea& '

%orkstrea& (

P+ase

DD

Co"ing

Test

DD

Co"ing

Test

eature

Duration Peo4le Duration Peo4le


18/30



Plannin0 Con'ert to /ow IP Plan

DD: WS-A Coding: WS-A UT: WS-A%orkstrea& '

DD: WS-B Coding: WS-B UT: WS-B%orkstrea& (

DD: WS-C Coding: WS-C UT: WS-C%orkstrea& C

DD: WS-D Coding: WS-D UT: WS-D%orkstrea& D

Time

DD:WS-A

Coding:WS-A

UT:WS-A

%orkstrea& '

DD:WS-B

Coding:WS-B

UT:WS-B

%orkstrea& (

DD:WS-C

Coding:WS-C

UT:WS-C

%orkstrea& C

DD:

WS-D

Coding:

WS-D

UT:

WS-D%orkstrea& D

Time


19/30


20/30


Results

• Original planned project duration: 6 months

• Actual project duration: 5 months(Project cycle time reduced by 17%)

Comments from PMO:• All Task Managers were able to allocate resources based on priority.• Problems/issues were resolved quickly by the managers.• In consequence, waiting time was reduced.


21/30


Aen!a





22/30


Mol! Manufacturin

Fixed side

Moveable side

PartsProcessing

Assembly

ClosedOpen

Moldeditem


23/30


24/30


Solution for Problem

• WIP limits (Workstream level & Project level) withdedicated capacity for short works


25/30


3 mechanisms for maintaining Low WIP to avoid multitasking:

• Organization Level – Divide resources to Project pipeline and Short work pipeline

• Project Level – Limit WIP by phase, and release projects by one-out & one-in

•Workstream Level – Reduce workstream WIP in project planning

Project Pipeline

Short Work PipelineProject

ShortWork

One-out

One-in

Parts ProcessingPhase

Assembly Phase

Fixed side

Moveable side

Slide etc.

Workstream 1

Workstream 2

Workstream 3

Fixed sideMoveable

side

Slide etc.

Re!uce an! Control IP


26/30


Original schedule(Date-driven)

Resolved resource

contention(but delayed)

Low WIP & resourceconcentrated schedule



27/30


WIQ1

FK1

FK2

WIQ2

Project

CustomerAssessment

Project completed

OK

Adjustment

NG

Value

To Short work team

WIQ3

Shortwork

Short work completed

WIP – Work in ProcessWIQ – Work in Queue

One-out

One-inOne-outOne-in

One-out

One-in

WIP = 5FK

Parts ProcessingPhase

Short work

Assembly Phase

Pro%ect /e'el IP Re!uction

Phase3base! Release Control


28/30


Manain Short or#s


29/30


Results

Before Target After(2015/7-12)

% Var.

Overall Cycle Time 60d 45d 50d 17%↓

Production Cycle Time 22d 11d 14d 36%↓

Throughput 4/month 5.3/month 5.3/month 33%↑

36%reduced

Days

Production Cycle Time

22d 14

d

17%reduced

Days

Overall Cycle Time

60d

50d

33%increased

# of projects completed per month

Throughput

45.3

＊The above was achieved although average project size was 26% bigger than baseline.


30/30


Summary

• Solution is for solving the problem. Different types of the problemrequire different applications of the solution.

• CCPM is the solution that addresses the multitasking problem.There are four types of multitasking that determine the way ofapplying CCPM into the environment.

• Demand variability causes High WIP situation and makes people

multitasking.

• Project/Feeding Buffers are not for absorbing the variabilityoutside the project. If the organization suffers from it, anotherbuffer is required.

• Capacity Buffer can be established by limiting WIP. It protects theproject performance from the demand variability.

16 - ryoma shiratsuchi & keita asaine_23 tocpa_us_21-22 march 2016

Documents