Managing a mix of make-to-availability (MTA) and make-to-order (MTO)

A critical insight has emerged into TOC around 2,000:

There should be clear separation between customer orders, which specify quantities and due-dates, and work orders to stock!

This is NOT the common practice, which strives to merge the quantities required by customer orders with stock quantities based on forecast. TOC clearly refrained from merging customer orders with different due-dates into one work-order.  But, up to that time even the TOC methodology used to assign artificial due-dates to make-to-stock orders.  By realizing that no due-date should be assigned to stock orders TOC achieved a true separation between make-to-order and make-to-stock/availability.  This vastly simplified the production process by noticing two different types of flow with two different types of buffers: time and stock.

Standard products with good and relatively stable demand, certainly fast-runners, fit being produced to availability. Fully customized products naturally fit make-to-order.  In between the two groups there are products that could be treated either as MTO or as MTA.  There are several gray-area categories of products that can be treated this way or the other way. For instance, slow movers that the market still expects to be available or when the required delivery time in more than one day, but less than the current production lead-time.

In some cases a combination of make-to-order and make-to-stock is applied to the same item (SKU), like regular MTA, but dealing with few very large orders that could be bigger than the whole stock buffer is better handled as MTO. Another case, which is pretty common, deals with supplying big clients, like automobile producers, that give the supplier rolling forecasts for several weeks ahead, but then expecting to draw on the spot somewhat different quantities.  Here also a combination of MTO and MTA is the preferable direction of solution.

The situation where a company runs both MTO orders along their time-buffers and MTA orders, controlled by stock buffers, and both compete on the capacity of the same resources, should be very common. TOC is effective in maintaining the separation and by this every single order is exposed to the true priorities dictated by buffer management no matter what type of buffer it is.

Are there generic problems in managing a product mix that contains both MTA and MTO?

The MTO buffer is based on time. The order is released to the floor time-buffer prior to the due-date. So, the consumption of the buffer is linear – the buffer is consumed day by day in the same pace.  An important advance in the TOC methodology was to use the Planned-Load, the load on the weakest-link/constraint, to determine the “safe-date” for any incoming orders.  This provides a mechanism to flatten a temporary peak of demand by increasing the promised customer lead-time based on the incoming demand.  The safe-date mechanism smoothers the load and by that ensures stable performance.  During off-peak periods the company is able, depending on its strategy, to offer shorter response times.  This offering has to be carefully thought of as it might cause negative ramifications of customers expecting fast delivery at all times and, when relevant, refuse to pay more for truly faster response.

The MTA buffer is based on stock, so the buffer status depends on the actual sales. The immediate consequence is that the buffer status of an order can jump from Green to Red in one day.

On the other hand, an order in the Green might stay in Green for very long time when the sales of that item are very low. All in all we see more volatility in the buffer management sorted list of priorities due to MTA orders, while the MTO orders keep steady pace.

This difference in behavior is not relevant to the question: if we have two red-orders, one MTO and one MTA, which one is more urgent?

One insight has to be considered here:

Buffer Management is effective as long as there is a fair chance to deliver ALL red orders on time!

Both MTO and MTA radiate commitments made to the market. TOC uses its capability to stabilize the operational system in order to gain reliability in meeting all the commitments and make this a decisive-competitive-edge.  When violating at least one commitment given to the market the emerged conflict is which order should be delayed then a new question is raised:

Which order would create less damage when its specific commitment is violated?

The buffer management algorithm doesn’t consider the size of the orders, the throughput they generate and ignores the identity of the client. However, when it seems clear the company is (temporarily) unable to meet all its commitments then the truly critical information is: Who is the client?

The answer should generate more questions about how this particular client is going to react and how this might impact the other businesses the client has with the company.

So, when an MTO order competes with an MTA order which one would turn Black – then the deciding factor is the predicted damage and it could easily be either the MTO or the MTA order.

When the company manages a mix of MTO and MTA then there is relevancy to the question:

What is the ratio of capacity consumption of the weakest link between MTO and MTA orders?

The reason of having to ‘reserve capacity’ of, say, 40% to MTO and 60% to MTA, is to enable smoothing the load of the MTO part through the mechanism of the “safe-date”. In order to do that we assume that every day 40% of the available capacity, on average, would be dedicated to MTO.  Thus, we can consider the planned-load for the MTO orders, which means calculating how long it’d take the weakest-link to process all the current MTO orders.  That time is converted to a date, when only 40% of the daily capacity is considered.  The calculated date represents when the weakest link would be free to process a new MTO order just received. The safe-date for that order is the calculated planned-load date plus half of the time buffer for that order.

The reader can find more detailed description of the determining the safe-dates for MTO orders elsewhere. The very brief description is intended to explain that the average reserved capacity for MTO orders, in a mix environment, is required just for that mechanism.

The ratio of 40/60 might make the wrong impression that the weakest-link, the potential capacity constraint, is planned to utilize 100% of its available capacity. This is a major mistake.  The commitments of reliability in delivering MTO and maintaining excellent availability of MTA items at all times clearly requires a certain level of protective capacity.  When the mechanism of quoting safe-dates for MTO is working properly there is still a need for protective capacity to cover for unexpected downtime, need for rework and mainly inaccurate capacity data.

Maintaining excellent availability of the MTA items requires MORE protective capacity because of the impact of incidental peaks of load.

Dr. Goldratt required that the total capacity utilization of any resource in an MTA environment including a mixed environment would not be over 80% of the available capacity. Goldratt’s concern was not just the fluctuations in the total demand for MTA items, but also to have enough time to deal with an increase in the total demand.  Many simulations showed that when the demand is growing there is a point where suddenly the number of red-orders goes up sharply and then it is just a matter of time until many items become short.  Note, maintaining large buffers restrain the impact of lack of protective capacity just for short time.  The use of dynamic-buffer-management at that point in time makes the situation WORSE, because increasing the buffers increases the demand at that point of time, where too many red-orders compete for the limited capacity of the weakest-link, which turned to be a bottleneck.  The emergency policies at this stage should be reducing the buffers, while looking to quick means to add capacity as soon as possible.  We better not experiment too much the tolerance of the protective capacity, especially for MTA.

The idea behind setting the line of average utilization of the weakest-link to 80% is that when the total demand is up there is still an opportunity to increase the capacity before the reputation of the company as one that meets all its commitment will deteriorate.

Having to exploit the internal capacity constraint to only 80% of its theoretical capacity is problematic. When more potential demand exists the temptation to draw more of the constraint is considerable.  However, the risk of overexploiting the constraint and by that ruin the decisive-competitive-edge of reliability is also high.

The solution, offered by Goldratt, is to maintain a market with no, or very limited, commitment! For instance, when the constraint is idle it could produce to stock items that can be sold to another market segment without any commitment for future availability for that market segment.  These make-to-stock orders are definitely ‘The Least Priority’ orders – carrying less priority than green-orders.

This idea is based on an important insight that is good to end the article with:

Specific commitments that provide high value to the clients should be directed at specific market segments. Other segments could be offered less binding commitments

Advertisements

Published by

Eli Schragenheim

My love for challenges makes my life interesting. I'm concerned when I see organizations ignore uncertainty and I cannot understand people blindly following their leader.

2 thoughts on “Managing a mix of make-to-availability (MTA) and make-to-order (MTO)”

  1. Lovely, Eli! I like it.

    Just one thought, I have found an approach I like for mixed MTO/MTA or, similarly, Buy-to-order/Buy-to-availability when the same SKU has aspects of both: I like to split an order between MTA and MTO. There are three cases:
    * If the MTO order is small compared to the Buffer (say < 25% of the buffer), I fill it out of the MTA stock buffer completely. This helps build the buffer to be useful for future MTO orders and smooths demand the way combining products does. The timing should be delayed not to spoil the marketplace by raising their expectations of service.
    * Assuming the MTA buffer experiences frequent demand, then I like to split off 25% of the MTA Buffer and allow the remaining order to be produced/procured to order. All products should be shipped together.
    * Sometimes, an MTA buffer does not experience frequent consumption. Imagine the product is stocked for one main customer who buys every 6 weeks an amount which may be close to the whole buffer. If more of this product can be made/procured in 2 weeks, there are many times when the entire buffer can be used to meet the MTO need, breaking my 25% rule above. This alternative requires a decision each time.

    There is a small chance that the MTA buffer will be too utilized at the point of shipment due to a deep intrusion into its Red zone. When this happens, I recommend splitting the shipment into two parts and incurring the added cost of shipping a second time. It very rarely occurs but will eventually happen if used enough times. For me, the benefits offset the costs.

    Like

  2. These are sensible ways to deal with MTO/MTA for the same SKU. We can discuss some details, but nothing truly material.
    The concept of separation should be always recognized, even when we let certain cases where we split an order into two parts, one MTA and one MTO. The case of getting rolling forecasts from the client also requires a mixed approach of MTO and MTA (I call it MTO+). It might fit better your example of a client drawing every 6 weeks and be a more stable solution.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s