In very early versions of Match-IT the stock allocator was very simple and allocated stock on the basis of first-come-first-served and it allocated physical stock first and when that ran out allocated in-production stock or scheduled more production.
Intuitively that sounds correct, but in practice it leads to delivery compromises. Consider this simple situation using this legacy scheme:
- You have 100 widgets in stock.
- It takes 2 weeks to make a batch of widgets.
- An order arrives for 100 widgets due for delivery in 4 weeks time.
- The 100 widgets in stock are allocated to this order – you can meet the delivery date
Everything is fine so far. But, now consider what happens if another order is received for delivery next week. There is no physical stock left because the prior job has it, so a new batch has to be made and that takes 2 weeks, making this new job late!
With modern versions of Match-IT its stock allocator is far more sophisticated and can accommodate this scenario without compromising either job. It does this by treating physical stock as precious. What that means is that it tries to hang on to physical stock for as long as possible, leaving it available to allow you to be more agile. In the above example the allocator does as before when there is only the one order, but when the new order arrives this happens:
Pass 1
- Physical stock is allocated to order 1 – its on-time.
- A new batch is scheduled for production for order 2 – its late.
Pass 2
- The allocator notices that the new batch is on-time for order 1 so uses it, leaving the physical stock in place – its still on-time.
- The physical stock is still available for order 2, so its allocated – order 2 is on-time as well now.
You might ask “What happens if there are delays in production?” Could that cause order 1 to be compromised? The answer is no. The reason is that the scheduler is continually monitoring the situation and as soon as it notices that the batch in production is going to be too late for order 1, it will grab the physical stock back because it has priority. This means the lower priority order 2 job is compromised instead – as it should be.
This is a very simple example. Things can get far more complex when you are dealing with large assemblies with lots of common parts across different sub-assemblies. The stock allocator can cope with that too. Here’s a real life example that triggered the development of this new allocator (many years ago now):
This is what would happen with the legacy allocator:-
- You have a large contract due for delivery in 6 months, in that there are large numbers of sub-assemblies all needing lots of special bolts that take 3 months to make – the bolts are the critical path, the whole job can be made in 3 months once the bolts arrive.
- You have sufficient bolts in stock to meet this job (just).
- This large contract is very important so it has top priority.
- The stock allocator allocates the physical stock to this job – exhausting it.
- The next priority job also wants some of these bolts, but there are none in stock so has to order more, and wait 3 months for them to arrive.
- And the next..
- And the next….
So all short term jobs are compromised for the lack of a few bolts!
The modern allocator prevents this.
To use the modern allocator set the Use legacy batch scan order default to No. This default is in the XP module.