Systems Approach or Process Approach? Micro level of managing

[Randy Stewart]

System Thinker,
Here is a couple we did with Ford engineering. If you can't read them (I had to chop the size to be attached) I'll send them to you email.
Let me add this;
I don't think that VSM by itself is the way to go. When you use them in conjuction with your process maps it is a very eye opening exercise. VSM is based on timing and throughput, and unless you have a defined process map you can miss the root causes.
Once again if you can't read them just let me know.

[Craig H.]

Systems Thinker:

I agree with what Greg just said. It really does not matter what we call it. Except so that we can use a name to describe a tool.

Ok, the lean process map, then. It seems to me that, at least in the case in the second link you so kindly provided, that the whole key here (and with Kaizen, too, if memory serves) is production scheduling, right? (Or not right?). This allows a reduction in WIP and finished goods inventory.

We have a situation where it seems like our production schedule is constantly changing. Being a raw materials supplier to raw materials suppliers, we feel any "whiplash effect" changes in scheduling all the way to the consumer, which can be several steps. Further, we have some customers who call and try to move shipments from next week to this Wednesday (this is Tuesday morning). I have actually had a customer tell me that if we instituted Just In Time, we could handle changes like this. I wanted to reply with something about Just Poor Planning, but I digress.

My questions are these: With a somewhat fluid scheduling stuation, how can we eliminate inventory and maintain current servicing levels? Is there any way to do this? How should I approach it?

Thanks for the input!!!

Craig

[Randy Stewart]

It really does not matter what we call it. Except so that we can use a name to describe a tool.

VSM and process maps are 2 different and separate entities that function with different targets.

I don't know if you've seen this before the second attachmentt is actually model after what Toyota does for their stamping dies. But it was mainly for getting a design from clay freeze to release. Something they accpmplish in about half the time that NA companies do.

I have actually had a customer tell me that if we instituted Just In Time, we could handle changes like this. I wanted to reply with something about Just Poor Planning,

Oh yes, the old indecision is the key to flexibility theory.
The VSM would help when looking at timing (we were attacking the design feeze problem) and the Process Map will define the required inputs and outputs necessary to perform the function.

Gotta run right now but I'll get back to you.

[systems_thinker]

In Reply to Parent Post by Randy Stewart

System Thinker,
Here is a couple we did with Ford engineering. If you can't read them (I had to chop the size to be attached) I'll send them to you email.
Let me add this;
I don't think that VSM by itself is the way to go. When you use them in conjuction with your process maps it is a very eye opening exercise. VSM is based on timing and throughput, and unless you have a defined process map you can miss the root causes.
Once again if you can't read them just let me know.

Your right, Randy, VSM is not the way to go in and of itself because its just a tool. Its value lies in its ability to allow you to visualize the overall system, the process parameters, sequences and interactions, and the material and information flows. Once that is done, you have a basis for identifying the waste, its sources and the set about eliminating them. The real power in the tool comes at the process parameter level, where by comparing process performance to takt time (the heartbeat of the factory), we can see the non-value adding steps.

To give an example: a company I am working with right now quotes a lead time of 25 days (typically they exceed this); VSM current state mapping shows that the actual production lead time is 25 days with the product only spending a total of 212 seconds (3+ minutes) in processing time (value-added time) moving through the plant. In other words, it takes a customer order 25 days to move through the production system while the total processing time required to make the product is 212 seconds.

Why the discrepancy? The answer is simple: the presence of non-value adding wastes in the system. Some of this waste is the waste of poor quality (the waste of defects), but there are also other wastes present. With VSM, we can identify the sources of the waste and then set about visualizing and designing a future state system where the wastes have been eliminated. How do we do that? Again by creating a VSM future state map showing an optimized system and then applying the appropriate improvement tools to move towards that state. In the case of this company, with the future state system we have mapped we will be building to takt and have a production lead time of 4.5 days with total inventory turns up from 12 to 55. Flow and pull production will be enabled mainly because we will have adressed the causes of poor quality within the system and eliminated them along with the causes of other wastes such as high queue, wait and setup times. While this is a big improvement, there will still be room for further optimization, achieved through subsequent iterations of the improvement process described above.

My point is that a "quality alone" approach could never achieve this. I don't say this to denigrate quality improvement - its a vital part of the overall war on waste. Yes, in the case above, with a quality improvement approach alone we could perhaps eliminate the defects, but we would still have the same batch-and-push production system which is incapable of delivering value because the other system wastes have not been addressed. We need to see poor quality as a systemic (as opposed to a process) waste, and not as something in isolation by itself. If we can tie quality improvement in to the objective of adding value by improving the total system, then we will have achieved something.

Cheers

systems-thinker

[Sean Kelley]

Both. Tango with them as they both work together and you can't have one without the other.

[systems_thinker]

In Reply to Parent Post by Craig H.

Systems Thinker:

I agree with what Greg just said. It really does not matter what we call it. Except so that we can use a name to describe a tool.

Ok, the lean process map, then. It seems to me that, at least in the case in the second link you so kindly provided, that the whole key here (and with Kaizen, too, if memory serves) is production scheduling, right? (Or not right?). This allows a reduction in WIP and finished goods inventory.

We have a situation where it seems like our production schedule is constantly changing. Being a raw materials supplier to raw materials suppliers, we feel any "whiplash effect" changes in scheduling all the way to the consumer, which can be several steps. Further, we have some customers who call and try to move shipments from next week to this Wednesday (this is Tuesday morning). I have actually had a customer tell me that if we instituted Just In Time, we could handle changes like this. I wanted to reply with something about Just Poor Planning, but I digress.

My questions are these: With a somewhat fluid scheduling stuation, how can we eliminate inventory and maintain current servicing levels? Is there any way to do this? How should I approach it?

Thanks for the input!!!

Craig

Interesting question! One of the Lean guidelines is to schedule only one point in the value stream. This is contrary to orthodox push production scheduling which attempts to schedule and control all the points in the production system with powerful computers and software. In a Lean value stream, the point at which we schedule is called the pacemaker. The pacemaker process determines the speed at which the value stream will operate and regulates production through the value stream - increase its speed, you produce more product, slow it down and you produce less. (incidentally, the concept of pacemaker finds its equivalent in the "drum" of TOC's drum-buffer-rope production scheduling and control methodology, another reason why Lean and TOC are closely aligned).

How do you create a pacemaker process? By dedicating equipment into a cell or line to run a specific product or product family in continuous flow one piece at a time. In companies which produce only one product, that's relatively easy to do; in companies which produce multiple products (mixed model environments), its more complex.

The rule is that you must pull materials from upstream shared resources into the pacemaker, but out of the pacemaker you must flow downstream to the customer.

We will schedule the pacemaker by levelling the volume and mix of products that flow through it and then flow the output into a finished goods supermarket where it is held for customers.

There are several ways you can deal with changes in customer demand. One is to buffer your finished goods supermarket to handle the variability in demand. The supermarket contains an inventory buffer which you can calculate empirically by analyzing your demand variability. You can also vary the output of the pacemaker cell by varying the number of operators in it. For example, if demand for a day is down, we let the pacemaker run slower. If demand begins to exceed what we can produce, even with the help of the buffered supermarket, we may have to add equipment, operators or even another shift.

In short, the question has no simple answer because to implement the approach above you will have to change your system of production from push to pull with JIT flow. As part of that conversion, you will create a pacemaker process which you will then schedule to regulate the value stream. It will mean suspending the common notion of using more powerful computers and software to address scheduling issues in a push environment.

A good rule to follow is that the smaller we can make lead time, the less chaos in the system. Remember, as variation approaches 0, batch size can equal 1.

Hope this helps,

systems_thinker

[NYHawkeye - 2005]

In Reply to Parent Post by systems_thinker

My point is that a "quality alone" approach could never achieve this....Yes, in the case above, with a quality improvement approach alone we could perhaps eliminate the defects, but we would still have the same batch-and-push production system which is incapable of delivering value because the other system wastes have not been addressed. We need to see poor quality as a systemic (as opposed to a process) waste, and not as something in isolation by itself.

systems_thinker -

It seems as though you have a fairly narrow view of "quality". Why couldn't the quality process and the resulting QMS be established to cover the full breadth of issues you have raised in this example?

On the one hand you are providing a good description of systems thinking and providing some nice examples...then you seem to fall into the trap of putting "quality" in its own little box.

My guess is that this is based on your observations of how things are being done in most organizations but maybe it is more useful to define the role the QMS should/could play in supporting a fully integrated system rather than identifying the things wrong today?

Regards

[Randy Stewart]

Good question and good response.
The only thing I can add is that you may want look at the slowest point in your stream. It will be that operation that dictates the "drum beat" or sets the timing of the overall process. By increasing the throughput in the chosen operation you should increase overall throughput. But once again remember:
If you standardize a sub-par process - we all make junk the same way.
If you increase throughput in a sub-par process - we all make junk quicker!