“It’s just buying spares; it can’t be that difficult?!”
Kara Shaw, Principal ILS Engineer
This is often the opinion; buying spares is surely just like going to a supermarket for milk, or getting a replacement battery for your smoke alarm – how hard can it really be to just buy some items on behalf of your customer? If your customer is the Ministry of Defence (MoD), and you are buying items to support a complex project, it can be exceedingly difficult to “just buy spares”. If you don’t understand the “ins and outs” of the defence logistics system and you don’t seek to find out about it, it can be very difficult to purchase items and have them accepted into stores without any issues.
The Starting Line
The MoD supply chain is a unique entity; if you are a “normal person” working in a “normal commercial company” who has not encountered this strange world before, there are many “alien rules” to abide by. Importantly, in my opinion, there are stringent rules in place to ensure the people keeping us safe are safe themselves. So, a few examples of these “alien rules”…there are Defence Conditions (DEFCON’s) that govern the following, which by no means exhaustive:
- codification,
- delivery paperwork,
- hazardous materials,
- packaging,
- labelling,
- transport safety rules that must be considered.
If any of this is not 100% correct, your delivery will be detained upon arrival at stores – that is to say, a non-conformant receipt (NCR) will be raised – you will not be paid, and you will need to rectify the issue to get the item released from quarantine. If the part markings are not correct, an NCR will be raised. If the certificate of conformity is not correct, an NCR will be raised. If the expected paperwork is not complete, or it doesn’t align with the serial numbers and cure dates of the items delivered, an NCR will be raised. If the…if the…if the…and that’s even before considering the codification status, whether the item delivered aligns with the recorded unit of issue, or whether the shelf-life data reflects the same as “expected” on the base inventory system!
These are all problems that can arise after the spares have been placed on purchase order, let alone issues that can occur before delivery, during the quotation and purchasing processes, or before you even know what the spares are that you might need to buy.
Data Hurdles
Firstly, I will consider the raw input data itself. Support contracts should be placed in such timeframes so that Integrated Logistics Support (ILS) data is provided by contractors to allow ample time to analyse it, design a support solution, purchase spares (including some with extensive lead times) and ensure the support solution is operational in time for the Logistic Support Date (LSD). Raw input data used to produce an integrated support solution consists of data such as the design configuration, failure and the effect of that failure. Further, it consists of maintenance data, operation manuals, test equipment details, training information, and provisioning data about each individual item that can be bought as a spare to support the maintenance of that equipment.
For each item (of which there can be thousands in operation) provisioning data alone consists of part numbers, prices, packed quantities, unit of issue, material safety data sheets, shelf life data, storage maintenance data, criticality data, installation data, failure rates, packaging data, minimum order quantities, packed dimensions, unpacked dimensions, weights, hazard data, fit/form/function specifications, drawings, lead times, repair information – I could go on, but basically we need an extensive list of data attributes to do what we need to do – and that’s without considering the aforementioned operation manuals etc. And all the data needs to be correct; if bad sausage meat goes into the sausage machine…you will end up with bad sausages.
Ideally, this extensive ILS information that we use to conduct our series of analyses would be delivered as a single data set (an Logistics Support Analysis Report (LSAR) output, for example), or as a fully complete integrated suite of data so that the alignment of common data attributes across the ILS deliverables can be verified. Simply speaking, the part must be in the design configuration, it must be referenced in the maintenance schedule, the operators must have the ability to be able to change it, it must be codified so that it can be ordered, and it must be referenced in the technical documentation so that the end user knows how to maintain it. Having the received data tick all these boxes is the first hurdle.
If the data is separated into different deliverables that are delivered in from the contractors at different times, inevitably, some data elements will have to appear in different documents in the suite so that the holistic data set can be understood – those common values will probably not align across all deliverables. Often, the part numbers provided in the provisioning data are not referenced within the maintenance data, or they are not in the manual, or a manufacturers part number in “document A” is different to the manufacturers part number in “document B”, even though the contractor part numbers are the same. “Document A” indicates that “part X” has a shelf life of 24 months, but another document indicates that the same part (denoted by the same part number) doesn’t have a shelf life at all. “Document A” says an item weighs 50kg, yet “document B” references the same item weighing 20g. ILS alarms ring if anything is out of alignment because, for instance, “why would the contractor be saying I need this spare if there is no maintenance task that calls for it?”. This full alignment needs to be verified for every part. This hurdle tends to be repeated for a considerable time before a conformant dataset that can be used for analysis is obtained; by this time, design change and/or obsolescence has probably already started its journey to your front door…
You now have aligned documentation, so you submit the design control data that identifies each item without any ambiguity to the NATO Codification Bureau. Eventually, you end up with a set of NATO codified spares; that is, each unique provisioning item has been assigned its own unique numerical code based on the design data that was provided to you in the delivered ILS documentation. This process alone will more than likely present its own challenges, but that is not for now. In parallel with codification, you conduct your spares analysis that will enable you to provide a recommended list of spares to the customer. Simply speaking, you will submit a recommended shopping list to the customer to ensure the right items, in the correct quantities, will be stored in the right place, so that the scheduled maintenance tasks and any reasonably foreseeable failure rectification can be carried out at the right time.
Shopping Hurdles
Your analysis is complete. You have finally ranged and scaled the equipment using the data you have been given, and you have presented the recommended shopping list to the customer (which, believe it or not, is the easy part!). By the time the customer has looked at the list, they have decided what they want to consider buying and they have authorised you to request a formal quote, you may be several months down the line since you reviewed and verified the initial data set; in a complex design and manufacture world…that situation can result in a world of pain.
You request a quote from the contractor based on the spares data that was provided to you (and by this time you have likely also already codified everything, again, based on the data initially provided); the quote is returned and 75% of the parts are annotated as having different part numbers. Bearing in mind, you had an aligned suite of ILS documentation – the maintenance referenced the spares, which were reflected in the design and the technical documentation, and so on. Your initial thought is “have they made a mistake…either in their ILS data or their quote…have they quoted for the same parts, but it has just been an error in documentation?”; you query this with the contractor. No, the data initially provided was correct (at the time), and the quote is also correct (now); the answer from the contractor is that out of the 75% of items that have now changed, 50% is due to obsolescence (and their recommended replacements have been quoted for), and 25% is due to design change which was authorised last week and will be implemented in the manufacturer and documentation next month.
At this point, you check whether you have been made aware of the obsolescence; maybe you have, maybe you haven’t, but I can guarantee that, due to the rate of technology change now, some of the recommended replacements are still going to be going through the design approval loop…the contractor doesn’t know this and they have provided a quote for an item they believe is a suitable replacement for the part they can’t sell you anymore. The trouble is, often, the contractor team who write the ILS documentation is a different team to those who provide the quote – sometimes, on large contracts they can be in completely different countries, so the continuity of items recommended in the initial design data, and their current market status is at odds.
For an ILS engineer trying to buy spares, this is a huge problem; imagine if the part number change on the quote was not noticed for some reason…imagine if the replacement for the obsolete part was purchased. Firstly, it may not be completely the same fit/form/function as the original part; the replacement item would likely not be codified (because you never received the technical documentation to codify it), it would not be referenced in the maintenance schedule…or the technical documentation…the removal route maybe completely different, the fit form and function may need a modification kit to enable it to work…it may need special test equipment or tools to fit or remove, it may in fact, be very dangerous in the place it is due to be fitted. To the user on the front line, the list of potential catastrophic failures from buying this one part in place of an approved design part goes on, and commercially, you have only been authorised to buy “part A”, not “part B”. The sales team doesn’t necessarily know this; they are just selling spares – business as usual.
Delivery Hurdles
Let me come onto the interestingly tricky subject that is “Unit of Issue (UOI) and Denomination of Quantity (DofQ)”. UOI determines the unit by which an item is issued from stores to the end customer; if the item codified is a single pump, the UOI is “Each”, EA. If the item codified is a pack of fuses, the UOI is “Pack”, PK, and so on. The DofQ specifies the quantity of individual items associated with a single UOI; in the case of the pump, the DofQ would be 1 because the customer will receive 1 pump and it will be issued as 1 item. In the case of the fuses, the DofQ will depend on the “pack size”, or the number of fuses that 1 pack contains. You may buy a pack of 5 fuses, or a pack of 10 fuses and so on. When the item is codified, this data is associated with the NATO Stock Number (NSN), and the Customer orders their spares by NSN. So, if the customer wants 1 pack of 10 fuses, they will demand quantity 1 of the NSN for a pack of 10 fuses (because it was codified with a UOI of PK, and a DofQ of 10), and 1 pack of 10 fuses is delivered to stores, which should be receipted with no problems.
As mentioned earlier, the item has been codified based on the ILS data that the contractor provided to you in the first place. If the customer orders quantity 1 of the NSN associated with a pack of 10 fuses (because that is the data you were provided by the contractor for codification) and 1 pack containing 100 fuses is delivered to stores (because they can only be bought in packs of 100), an NCR will be raised, and the item will be quarantined. Using the correct UOI and DofQ is imperative for accurate stock accounting and supply chain processes; if the data initially provided for codification purposes was incongruent with how the item is sold in line with the associated part number, then there are guaranteed to be problems. If the item is sold in packs that is, for instance, 10 times greater than the amount the item was originally codified as, there can be a major volumetric problem when the order reaches stores. Imagine, if you will, the Customer orders quantity 20 of the NSN for “toilet roll”; the data provided for initial codification indicated the item was sold in a pack of 20 individual items (UOI = “PK”, DofQ = “20”), and so the pack of 20 toilet rolls was codified accordingly. The Customer therefore expects to receive 20 packs, each containing 20 toilet rolls; a total of 400 toilet rolls, for which there is sufficient space in stores to keep the total consignment.
The part number associated with the NSN is ordered from the contractor; however, what the contractor’s ILS team who provided the codification data in the first place didn’t know was that the sales department can only sell the toilet rolls in packs of 200 because packs of 20 don’t even exist. The sales department just processes an order for 20 packs of a part number; they don’t know that the data provided to codify the item wasn’t representative of how that part number is sold. The contractor ships 20 packs of 200 toilet rolls to the defence delivery point. Imagine being faced with a delivery consignment containing 4000 toilet rolls; suffice to say the quarantine area was full for a while! Going one step further…can you imagine if a mistake was also made during the codification of a goat (yes, there is in fact an NSN for a goat); the customer orders and expects to receive a single goat as the NSN indicates, but they are only sold in herds of 100 – the quarantine section of Defence Stores would be awash with 100 non-conformant goats and 4000 toilet rolls!
Ok, I made up the “goat fiasco”, but the toilet roll tale is a true story. Anyway, I digress.
“It’s just buying spares; it can’t be that difficult?!…”
Oh, how wrong you were….
