KPI: DIFOT - Deliver In Full On Time
DIFOT refers to your complete purchase order (PO) being delivered by the supplier as a complete delivery on or before the date you specified. Or is something far more more complex lurking underneath ?
DIFOT is one of the most commonly measured KPIs because it is simple to measure and simple to understand. However, its simplicity can lull you into a false sense of security in regards to ensuring the underlying data is accurate, what the measurement truly is and the implications of DIFOT results.
Lets start with measurement. For a PO, DIFOT is determined as:
(A / B) * 100. The result is expressed as a %
This consists of:
A: The number of lines Delivered in Full on or before the requested delivery date
B: The number of Requested Shipments with the requested data used in (A) above
The first complexity is revealed within the calculation itself. We will now examine challenges with calculation/measurement, data quality and implications of poor DIFOT results.
DIFOT Calculation/Measurement
Many procurement practitioners would tell you that DIFOT is a % of the total number of lines within a PO received as part of the first delivery from the supplier. That is only true if you state a single request date from the supplier.
If you specify a request date per PO Line, then for accuracy you should calculate as a grouping by request date. This is because DIFOT includes the word TIME and therefore the requested date has a crucial role to perform. Most procurement systems can specify different dates per PO Line, therefore it is important that your calculation aligns to this reality.
Lets have a look at the implications of using a DIFOT calculation that ignores the complexity of multiple requested dates. For example, consider a PO with 3 lines requested on the 5th March and another 2 lines requested on the 9th March. If we use a single date of 5th March, then the following DIFOT results can be assumed:
Single Delivery on 5th March: DIFOT = 100%
Single Delivery on 7th March: DIFOT = 0%
Delivery on 5th March and remainder on 9th March: DIFOT = 60%
All of the above calculations are inaccurate and therefore misleading. If you are trying to use DIFOT to improve your operations in this manner then you are wasting your time.
Some might argue that the first example above is an accurate representation of DIFOT and I understand why they would state this. This leads us into a complication on how we treat early delivery. Without delving too much into implications, it should be obvious that early deliveries may burden warehouse capacity and decrease cash flow due to an earlier than expected invoicing event which normally follows delivery.
How do we treat early deliveries ? The answer is a threshold of how many days early are allowed. In a similar manner, a threshold can also be applied to after the requested date. If a delivery falls outside of the calculated threshold range, then it is not treated as an "on-time" delivery.
An example of a threshold range would be to allow up to 3d early and 1d late for delivery before DIFOT is considered to be breached. Whatever values you use, you should consider also having that same logic incorporated into how you calculate the request date on the PO. Using this example, the request date should be at a minimum 1d before the PO Line(s) are to be "used" (consumed or picked and shipped).
Using the above information, if DIFOT were to be calculated accurately incorporating the line request date:
Single Delivery on 5th March: DIFOT = 60%
Single Delivery on 7th March: DIFOT = 40%
Delivery on 5th March and remainder on 9th March: DIFOT = 100%
The first example above gets a result of 60% due to the 2nd line requested for the 9th March has been delivered too early as it is before the 3d threshold.
Data Quality
The likely candidates for data inaccuracy is the request date and the delivery data. Whilst there may be others that apply to your company's systems and operations, we will concentrate on just these 2 due to the likelihood of it being the common source of quality issues.
Data Quality of Request Date
This is a target of data quality as it is a "calculated value". How is that date calculated by your systems ? A request date is treated as accurate if it includes agreed timescales from internal and external stakeholders. The 3 stakeholder groups that apply are:
Internal Stakeholders - determining the PO processing time from when the request date is first calculated through to when the supplier receives the PO. For example, if your request date = today + 2d, then it is inaccurate if it takes 3d to get the PO to the Supplier
Supplier Stakeholders - determining the supplier's processing time to get the PO Lines ready for shipment to your requested location
Delivery Stakeholders - this may be the same stakeholders as in (2) above. It represents the time taken to ship from the supplier to your requested location.
If your request date is not a calculation using agreed values, then it is going to be very difficult to get the above stakeholders to buy-in to improve DIFOT performance - and if you cannot do that, then why bother measuring it ?
To calculate an accurate request date is a topic in itself. However, to address this in its simplest manner:
Use existing PO data to calculate the average interval between a request initiating and the related PO being approved. If this is more than 3d it is worthwhile concentrating on improving this;
Agree supplier lead times with the supplier. If that is not possible or will take time to obtain that data, in the interim use existing PO data to calculate the average interval between PO transmission date and the first delivery date of that PO - this could be per item, category or supplier or across all suppliers depending upon what level of accuracy you desire;
Agree shipment times from the supplier location to your location. This gets complicated when considering different destinations for your requests, but in the absence of accurate data from your supplier or freight provider, it is can be assumed 1 or 2d within the same city and 2 or more days when regional and increasing as distance increases; and
Agree with internal stakeholders on a threshold buffer. For example, if the above 3 points arrive at a 5d lead time, then you may calculate the minimum lead time as 6d from the date of request to provide a 1d buffer.
Once the total lead time is determined and loaded into your system you may also wish to consider other complications such as business days and date calculation - do you include Saturday & Sunday in your calculations ? Are there other complications such as your warehouse or supplier not being available certain days ?
The determination and maintenance of this data is an ongoing task that over time will contribute to an accurate request date that stakeholders can realistically meet and therefore their performance against this measure becomes a meaningful discussion that can be agreed to improve upon.
Data Quality of Delivery Data
The likely culprit in this is the interval between the warehouse physically receiving the PO and entering it into the system. If that occurs within the same day, then it is unlikely to be an issue, but if, for example, orders received after 3pm are not entered into the system until the next morning, then it is very important that the system can accept a prior delivery date. An examination of internal procedures can uncover how accurate this date is likely to be.
Secondly is the ability to receive in different units of measure (UOM) as that stated on the PO. Any calculation of "Delivered In Full" must cater for conversion from the received UOM to the PO UOM. For example, if 64 Boxes of widgets was ordered and the warehouse received this as 1 Pallet, it is important that both the system and DIFOT calculation recognises that this is 64 boxes and therefore the FULL line amount has been received.
There are also niche scenarios like direct deliveries from supplier to customer that should either be excluded or measured separately due to their direct impact upon customer satisfaction. Having accurate receipt data in this scenario is likely a result of integration between the supplier or courier's dispatch system and your system.
Remember the GIGO rule: Garbage In = Garbage Out.
Never assume that your underlying data is accurate until you have verified that it is and ensure there is consensus with external parties when a performance aspect of an external party is involved.
Performance Implications
So what does DIFOT really mean to your business ? It depends upon the nature of the purchase being made, but the majority of uses for a purchase can be broadly classified as:
Services;
Goods for distribution/re-sell;
Goods for inputs into manufacture;
Goods for inputs into service/repairs;
Goods for other internal consumption/use;
The classification of the purchase will determine the implications of poor performance of DIFOT. Typically, the implications can be grouped as:
Increased labor;
Increased distribution costs;
Cashflow;
Increase in customer backorder times;
Increase in manufacture backlogs; and
Increase in service times.
Review the below explanations to see what applies to your business. This is not an exhaustive list, but is reasonably substantial and should give you insight on the implications of poor DIFOT from your suppliers.
Increased labor
Additional effort by warehouse/QA staff in receiving multiple deliveries and subsequent processing;
Additional effort by customer service and service in fielding inquiries from customers due to delays;
Additional effort by warehouse staff in performing multiple shipments to customers;
Increased manufacturing staff in maintaining manufacturing backlog whilst awaiting missing goods;
Increased procurement effort in managing supplier's backorders;
Increased Accounts Payable effort for processing multiple invoices as a result of multiple receipts; and
Increased managerial and administrative overhead.
Increased distribution costs
Additional freight to customers due to partial shipments.
Cashflow
Increased labor costs;
Increased outbound freight costs;
Earlier invoice maturity due to early receipts; and
Later invoice maturity due to late receipts is likely to be outweighed by the later receipt of customer receivables.
Increase in customer backorder times
Out of stock goods awaiting dispatch to the customer will increase if awaiting goods from the supplier that are late
The release of the finished good from manufacturing will also increase customer backorder times if the manufacturing input is late from the supplier
Increase in manufacture backlogs
The unavailability of a manufacturing input will cause the production flow to either stall or be re-routed to a less efficient route - both representing cost to your company.
Increase in service times
The unavailability of a repair or service input will delay the return of the item to the customer which has customer satisfaction and cashflow implications.
Conclusions
DIFOT is not as simple as it first looks. Due to the implications that it can have upon your business it is worth measuring and agreeing targets with suppliers that allow you to perform exception management and improvements over agreed timescales.
DIFOT is a powerful and meaningful KPI that has evolved in sophistication along with the underlying business conditions that surround it. If you are able to accurately measure and manage DIFOT you are on way to achieving a level of maturity in respect to the performance management of your suppliers. We hope that this analysis has given you something new and challenges you to look how to improve your procurement operations.