Recently, within a greenfields container terminal tender there was the requirement for the Enterprise Asset Management System (EAMS) to 'reserve' parts against work orders.
It sounds like a useful thing to do – when the work commences the parts will be there – but we've learnt a thing or two over the last thirty-odd years at Mainpac and having reserved stock in our application in the past, we no longer do so in Mainpac 2011.
In Mainpac 2011 we 'allocate' parts against work orders, and while that might sound like I'm just being fussy, the distinction (and the why of us changing our mind) seemed like a worthwhile blog discussion.
Obviously, we see a difference between 'Reserving' parts and 'Allocating' parts.
And that difference is essentially one of ownership. As noted in the tender I'm responding to, and more widely described in other software applications, parts reserved against work orders have a monogamous relationship, as the parts are tightly coupled to the work order and cannot be issued to another work order.
In Mainpac 2011 allocated parts are treated differently; they are merely denoted as needed for the work order, they are not locked to the work order.
So why is that distinction important?
Because it is the consequence of reserving parts that we've come to view as the problem:
1. Systems that reserve stock typically reduce available parts by the reserved quantity. This can incorrectly suggest that part needs to be replenished because the 'available' amount is too low.
2. Parts can be 'hoarded' by creating dummy work orders.
3. You need to 'un-reserve' parts if your work order sequence changes. This is complex and time consuming for users…and in a breakdown situation the person authorized to un-reserve parts may not be available, leading to a delay fixing the breakdown.
This is why Mainpac 2011 uses material requisitions to allocate parts to planned/issued work orders, rather than reserving them. Our replenishment algorithm is aware of the quantity of parts required for upcoming work and triggers a purchase requisition if the projected demand would result in the part falling below its reorder point.
But the part is not locked away against the work order and can be issued to other work orders if required without any need to 'un-reserve' it.
Also, Mainpac 2011's stock on hand reflects your actual parts holding, not a value that will be correct if work orders are completed as planned.
As Ivan Winter, director at engineering consultancy Ingenia, noted to me, "You need tremendous discipline in your stores for parts reservation to work because the stores must track parts issue and returns with a high degree of accuracy and consistency.
"But when equipment breaks down, the guys are not going to take time to un-reserve the part in the system. They are just going to grab the part off the shelf and get to work fixing the problem. They may come back later and un-reserve the part and then reserve it to the breakdown, but that's not very likely so most of the time your inventory will be wrong.
"Basically, this type of hard reservation requires a lot of administration for not a lot of business advantage."
The extent of the administration becomes apparent when you consider the inventory/purchasing sequence through the different stages of a work order. This is a sophisticated process, as the diagram illustrates, and we feel that adding the complexity of parts being locked down – and then needing to be unlocked if you want to reassign them – is an unnecessary complication for users.
1. A work order is created:
a. From a template
c. From a PM schedule
d. From Condition Monitoring
2. The work is planned
a. The parts required are defined
b. A start date is scheduled (the estimated start date is set)
3. The parts are allocated and the replenishment process (recommended items) raises a purchase requisition if parts fall below reorder points
4. The parts are ordered and received
5. The parts are issued just in time to meet the maintenance schedule
6. The work is issued
So there you have it, we're down in the weeds of application functionality, which is not where such systems are usually sold. But this distinction between allocated and reserved is important to ease-of-use and data quality, which directly impact operational reporting, so it is a story worth telling.