On this week’s show, Paul Akers and Jon Lussier continue their Theory of Constraint (TOC) conversation with Bob Buckley from True32 Custom Cabinetry and author of True32 Flow Manufacturing.
Thanks guys. Another great set of shows.
It is interesting how every discipline starts finding the same face of god.
This reminded me of similar idea we have in the computer science field with locks, queues, and threads.
Because of the speed of innovation, many of those ideas are 50 years old, but still valid today.
For example:
Queue:
A queue is used to buffer up work between a producer and consumer thread. Analogy would be Inbox/Outbox.
Thread:
Threads are workers that do work. Analogy would be workers or machines.
ThreadPool:
A pool of threads that grab work from a queue. Analogy would be a finish room with multiple workers.
Amdahl’s Law:
States that an overall system can go no faster than the sequential part(s) of the system. In TOC,
the sequential area(s) of the system would be the constraint to focus on.
So if the constraint in a cabinet shop is the finish room, in a computer program we might turn the finish
process into 2 or more worker threads running in parallel (i.e. create 2 finish rooms with 2 workers).
In theory, that could double the output as long as other processes can keep the Input queue steady.
In that case, you may then be constrained by assembly or something else farther upstream.
We can still apply Amdahl’s law to find we can go no faster than the slowest sequential part of the
end-to-end system. And there will always be a new remaining constraint into infinity.
So another tool in the box can be to model the business processes as you would put together
an efficient program. This can help find the constraints or at least maybe offer other ideas.
Patterns
========
In CIS we define and publish patterns to describe best practices for particular problems.
We also define Anti-patterns to publish common mistakes to avoid. Both are extremely powerful
and allow a kind of cookbook reference to problem domains. I would like to see LEAN and TOC
publish patterns and anti-patterns. Both general and industry specific.
William: Thank you so much for your comment. Obviously, you are an advanced practitioner of theory and what you have to offer here is quite interesting. I think I would agree that the underlying concept of all successful theories are rooted in the same principles, as you have so eloquently pointed out. I would love to hear more about how you are applying these principles and the outcomes you are getting. Paul
One point I would like to see expanded on is the difference between Bob or Sam Carpenter’s adamancy about employee manuals or procedures and the apparent dearth of this with Lean.
Thanks guys. Another great set of shows.
It is interesting how every discipline starts finding the same face of god.
This reminded me of similar idea we have in the computer science field with locks, queues, and threads.
Because of the speed of innovation, many of those ideas are 50 years old, but still valid today.
For example:
Queue:
A queue is used to buffer up work between a producer and consumer thread. Analogy would be Inbox/Outbox.
Thread:
Threads are workers that do work. Analogy would be workers or machines.
ThreadPool:
A pool of threads that grab work from a queue. Analogy would be a finish room with multiple workers.
Amdahl’s Law:
States that an overall system can go no faster than the sequential part(s) of the system. In TOC,
the sequential area(s) of the system would be the constraint to focus on.
So if the constraint in a cabinet shop is the finish room, in a computer program we might turn the finish
process into 2 or more worker threads running in parallel (i.e. create 2 finish rooms with 2 workers).
In theory, that could double the output as long as other processes can keep the Input queue steady.
In that case, you may then be constrained by assembly or something else farther upstream.
We can still apply Amdahl’s law to find we can go no faster than the slowest sequential part of the
end-to-end system. And there will always be a new remaining constraint into infinity.
So another tool in the box can be to model the business processes as you would put together
an efficient program. This can help find the constraints or at least maybe offer other ideas.
Patterns
========
In CIS we define and publish patterns to describe best practices for particular problems.
We also define Anti-patterns to publish common mistakes to avoid. Both are extremely powerful
and allow a kind of cookbook reference to problem domains. I would like to see LEAN and TOC
publish patterns and anti-patterns. Both general and industry specific.
–William Stacey
William: Thank you so much for your comment. Obviously, you are an advanced practitioner of theory and what you have to offer here is quite interesting. I think I would agree that the underlying concept of all successful theories are rooted in the same principles, as you have so eloquently pointed out. I would love to hear more about how you are applying these principles and the outcomes you are getting. Paul
One point I would like to see expanded on is the difference between Bob or Sam Carpenter’s adamancy about employee manuals or procedures and the apparent dearth of this with Lean.