Blog

Long time no see, eh? I know I’ve promised to write about a lot of stuff here, and I see this queue of you hardly waiting to read my next topic on process manufacturing, but I am just far too lazy to think it out thoroughly. So, an easier one, but still about manufacturing.

I spent this week delivering two courses about manufacturing in Microsoft Dynamics NAV. Usually, these trainings are gatherings of partners who discuss geeky stuff over coffee breaks. This time, it was kind of different – there were two people from the customer front, and it was really amazing to listen to customer perspective when learning about standard NAV.

One of the points raised today, in the midst of closing of Manufacturing II course, was about parallel routings. Do we do them, or do we not. A tough one, indeed.

Parallel routing is a nice way to reduce the total manufacturing lead time, and to understand how it works, take a look at this diagram:

This is a diagram of an imaginary bicycle assembly process. Here, by executing six operations sequentially, and assuming each operation takes exactly 1 hour to complete, the whole bicycle is assembled in exactly six hours.

This is called serial routing. Serial, because you execute all operations in a series of steps, one after another.

Now, if you think about it, there is something fishy here, really. If you think of this process logically, you can see that if you produce first the front wheel, then the back wheel, then the chain, then you assemble the back wheel and chain together, then you assemble the frame and the front wheel together, you are actually wasting your time. If each operation is performed by a different person, why woudln’’t you do it in a different way, such as this:

Here, with exactly the same people doing exactly the same kind of job, you get it done in only three hours. This is called parallel routing, because you perform independent operations in parallel.

Generally, dependent operations must be executed serially, but independent operations can be safely executed at the same time without compromising anything about the manufacturing process.

In theory, assuming that each operation sends its semifinished product ahead to the next one immediately after completing it, in the first setup, a shift of 6 people working a full 8-hour working day could produce measly 3 bikes. In the second routing setup, the same people in the same amount of time could produce 6.

And then a guy in the class complained: “Setting up parallel routing in real-life is completely impractical and scheduling issues it creates are worse than those it resolves!” And this guy was a customer guy with about 25-years of experience with manufacturing planning – so I decided not to confront him out of a simple reason: never, ever in any of my manufacturing projects, and there have been tens of them, the company really used parallel routings.

So, instead of pretending to know everything (I do know everything, just not all at once ;)), I decided to ask you to share your experiences with setting up or operating with parallel production routes. What’s your experience with it? Have you been able to set it up successfully?

From a theoretical point of view, there are truly many issues with parallel routings, let me try to brainstorm a couple of them.

First, parallel is (or should be) the way to go if you produce one finished product. If those six fellows up there made only bicycle for the length of their lives, and worked six a shift, a shift a day, five days a week, then they will be more productive if they do it in parallel. Especially if each operation takes roughly the same amount of time. If you live in a cartoon, there is this kind of manufacturing. In real life? Oh, come on!

In real life you produce dozens, maybe hundreds of different products where each of the machines can work varying amounts of times on each of the products, and as soon as you start planning parallel routing, you are going to get a total hell of shifting bottlenecks.

Without arguing it is that way or highway, my observation is that with parallel routings and high product variety, bottlenecks must be jumping from one machine to another couple of times per day, and keeping all machines occupied most of the time is really a tough job. With serial routing, to me it seems much simpler. Also, with serial, it is much more predictable when you are going to get a bottleneck at which machine.

Bottlenecks require a lot of manual work to resolve, or if you know which machines cause bottlenecks you can set them up to allow only finite loading, and then the system takes care automatically. With serial routing this is easy, because you can easily predict which machine is going to become a bottleneck. With parallel, it is tougher, and you have either to seek refuge in setting up all machines with finite loading (which will result in a lot of underused capacity), or to stick with infinite loading for all machines, and then have an army of planners resolving bottlenecks and playing what-ifs all the time.

At least, this is my theory, which may be totally wrong (and it probably is).

What’s your experience with this?