|
A Guide to Implementing the Theory of Constraints
(TOC) |
|||||
|
Multi-Project Drums |
|
|
|
Comparing Safety In Production & Projects There
are two groups of people who are likely to use these pages on projects; those
with prior knowledge of production operations (manufacturing) and those with
pure project backgrounds. For this
reason I want to compare and contrast between production operations and
project operations. The similarities
are much greater than the differences.
I want to do this for two reasons; 1.
Provide a bridge for people with production
operation experience in order to enter into the project domain. 2.
Show people with project operation experience that
the challenges that they face are not that different from those experienced
in production environments. So I
ask for your indulgence if you already feel slighted that “your” area of
expertise is apparently no more difficult than “their” area of
expertise. You see, we are basically
all in the same boat – and we are all at sea as well. Industrialization is new. We only have to check whether our parents’
generation ran projects or production operations as we do, and if they did,
then check out our grand-parents generation.
The scale and scope of operations today is vastly different from that
of just one or two generations ago.
For instance, just one generation ago we didn’t have computers to make
mistakes quite as quickly as we are able to today. In
fact, computers are now so ubiquitous that we can discuss operations in terms
of the software that drives them, or at least the generic approaches. For production operations the first
software was material requirements planning (mrp or small mrp – referring to
the use of lower case letters).
Material requirements planning allowed the building of bills of
material (BOMs) for a process; a list of all the bits and pieces and maybe
the places where, and the time when, they were required. It wasn’t long before this was beefed up to
materials resources planning (MRP or MRP II) with the addition of capacity
scheduling of each step in the routing that had been used to generate the
bill of materials. More recently this
has been beefed up once again to enterprise resources planning (ERP) where
schedules are wired across functions as well as within functions. Sales and marketing now know what
production is doing and vice versa (well it sounds good doesn’t it?) The
project operations equivalent of the mrp, MRP II, ERP, alphabet soup is
Critical Path Method, (CPM for short).
Critical Path Method tends to be associated with the Gantt charts that
are used to graphically present the relationships between tasks in a project,
but it is generated from an approach called program evaluation and review
technique (or PERT for short). In
fact, as we will soon see, program evaluation and review technique can be
equally applied to production operations as well as to projects. Indeed, maybe PERT is responsible for the
two short comings of both MRP and CPM.
Both approaches assume, even today, that there is more capacity at
each step in a production process, or task of a project, than is actually
required. Colloquially, we tend to
call this “infinite capacity” although we only mean that there is “more than
enough.” Before the advent of
computers when PERT was a manual exercise, this simplification made the
impossible possible. Also,
both MRP and CPM assume that safety is localized throughout the respective
operations. In production operations,
safety is localized in the queuing of product (work-in-process). Each queue represents a safety buffer that
allows late work to catch up to its schedule through the rearrangement of
items or “jobs” in the queue.
Historically, these types of scheduling approaches originated in
so-called job shop environments – places where machinery was likely to be
grouped according to function, rather than the flow-shops that are so much
more common in all but the smallest of facilities today. In Critical Path Method the safety is
localized not in the queue, but within each and every task in the project. Assumptions
of infinite capacity and the localization of safety throughout the operation
are the two aspects that cause so much trouble to modern operations. We won’t address the issues of infinite
capacity assumptions until the next page on Critical Chain Project
Management, because this is an important issue of itself and is to me the
distinction between Critical Chain Project Management and Critical Path
Method. On this page we will address
the issue of localized safety in each step or each task. Essentially we are going to move from
safety that is localized, specific, and everywhere, to safety that is
general, aggregate, and located in just a few critical places. Having
safety “embedded” in each step of a production process or each task of a
project ought, at first pass, seem to be an effective solution. After all you can size each individual
allocation as required – regardless of whether it is explicit within a
production process queue, or implicit within a project task. However, a number of operational and
psychological factors contrive against us.
The operational factors are the dependent nature of serial operations
and the inherent variability that occurs within each operation. The psychological factors are varied, and
probably more important for project-based operations than production-based
operations. We will deal with the
psychological factors as we come to them. In
order to develop the argument for the aggregation and placement of buffers in
project management, I am going to use a PERT diagram for both a production
process and a project. In order to do
that we must make use of the realization that a project is an “A” plant
tipped on its side. Let’s
look at this in more detail. A
project is an “A” plant tipped on its side (1). This is the “thing” that finally allowed me
to see the relationship between production operations and project operations
and their buffers or safety. But what
is an “A” plant you are asking? Theory
of Constraints sees 4 generic flows in production operations, they are; “V”
plants or divergent plants (divergent from the bottom of the “v” to the top),
“A” plants or convergent plants (convergent from the bottom of the “a” to the
top), “I” plants or linear plants, and “T” plants – a plant with a linear
stem and an explosion of choices at the top (assembly). Each type of plant is typical of particular
operations. “A” plants are typical of
situations where a number of different components from different raw
materials come together to form a final assembly. Let’s
draw a simple, a very simple, “A” plant on its side to see how it would look.
This
type of logic diagram is common in Theory of Constraints. The logic might coincide with the physical
layout of the plant; more often than not, it won’t. For an example of a more complex “A” plant
logic diagram and its corresponding physical layout, have a look at the
diagrams for the P&Q Question. If we
were to draw a very simple project, then apart from some different names, it
would look exactly the same, lets see.
The
logic diagram for production operations and project operations are exactly
the same, save for different labels.
Let’s put the two diagrams side-by-side.
Let’s
draw each respective diagram so that the steps and tasks are somewhat
proportional to the time taken.
Let’s
have a look at this waiting in queues.
This
raises a question; there isn’t any waiting in projects – right? Well, not explicitly, and it isn’t called
waiting, it is called safety – “things” in production might wait but people
in projects don’t like to be seen waiting, so we have to call it safety. Let’s
have a look.
Having
got this far (even if you really don’t think that there is any safety in projects
what-so-ever), we can now show the apparent differences between buffering in
production operations in Theory of Constraints and buffering in project
operations in Theory of Constraints.
If buffering is an unfamiliar concept to you, then please wait a short
while. We need to bury the devil which
says that buffering in the two approaches is different. Once we have done that, then we can start
all over again with the vexed question of why we even have buffers in project
management. Let’s
start first with our “A” plant process.
What if we accept that we can move from an MRP schedule to a
drum-buffer-rope (DBR) sequence. In
drum-buffer-rope the only things scheduled are the start and the finish (and
maybe the drum but we will leave that out here). If we accept that, then we can aggregate
the touch time and we can aggregate the waiting time. By aggregating the waiting time we make the
total waiting time available to the whole process. Let’s
have a look.
What happens next is that because the touch time in
production operations is so small (remember we have drawn it here 1 to 5 to
10 times too large) it is ignored completely. This is what our process looks like as a
consequence.
What
then if we accept that we can move from a Critical Path schedule to a
Critical Chain sequence. The only
things scheduled being the start and the finish. If we accept that, then we can aggregate
the touch time and we can aggregate the safety time. By aggregating the safety time we make the
total safety time available to the whole process. Let’s
have a look.
|
