Parallel or serial?

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:

image

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:image

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?

Vjeko

Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 7 Comments

  1. Erik P. Ernst

    Good to see that you’re back! Not a lot of posts from you the last 5-6 months!

    1. Vjekoslav Babic

      @Erik: Hi there! Yes, I’m back, and I’ll try to post more. I hoped to get more free time when I choose the freelancing path, now I see that it isn’t that way, but still – I’ll do my best to keep this blog alive!

  2. Valentin

    I think you look from slightly wrong angle – theoretical … In theory parallel routing will give better result. But in real life nobody will produce “back and front wheel as part of work order for bicycle”. Or what I try to say – manufacturing process will be divided on sub processes/subassemblies and optimized by S&OP type of planning. So essentially you are doing parallel manufacturing but on subassembly level. Then you make your master schedule on weekly or monthly level and do some type of dispatching on the work center or employee or work order level.

    1. Vjekoslav Babic

      @Valentin: Hi, and welcome to my blog! What I tried to give here is the theoretical angle, and I asked for specific examples from the practice. I agree that in practice nobody will create front and back wheel as a part of work order for bicycle – what I gave here was an example which is easy to comprehend. How you approach your assemblies and sub-assemblies really depends on your type of production. If you are ATO or MTS – then of course you aren’t creating subassemblies as a part of your final assembly. But if you are MTO, then of course you do, don’t you? I’m currently working on a project in a true MTO environment, and looking at their processes, parallel routings – while possible – would create a nightmare in planning.

  3. Miklos Hollender

    “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.”

    Depends on what are you actually manufacturing. If you would be building a huge ship that takes 2 years to make, you’d be crazy NOT to use parallel routes.

    Er… guess what… they are building a lot of ships in Denmark. Especially Maersk. Which was once a huge NAV partner. So I think that’s actually not even a coincidence. 😉

    1. Vjekoslav Babic

      @Miklos: Hi there and welcome! That’s true – it always depends on what you are manufacturing. But tell me, would you really use manufacturing module to handle ship-building? IMHO, it is very similar to any construction project work, and Jobs module is far better for handling that type of “manufacturing”. But you are really right – NAV is mostly like what those guys in Denmark needed the most 😉

Leave a Reply