On Time Delivery

Contention 3:  Don’t use discrete data and measure shipped on time or not but use continuous data and measure difference between actual shipping date and scheduled shipping date.  That might give you more robust data for analysis.

Does the customer have a window of acceptability with regards to shipping?  Will they accept scheduled date plus/minus some time frame?  Is early OK or is that as bad as late?  Do yo have a good operational definition of “supposed to ship”?  Was the original ship date?  the revised ship date?  the expedited by customer request ship date?  Any reason you can’t use all three metrics?
Total shipped/Total scheduled = 10/30 = 33%  Overall performance.
Total shipped on time/Total shipped = 10/10 = 100%  At least the ones you shipped were on time.
|Scheduled Ship Date – Actual Ship Date| (absolute value to account for early being as bad as late) 

Customers are not going to bother how your measure your own metrics. You are free to tell the world that you are meeting all your metrics and look pretty good from your perspective!
Your customer is expecting all ordered quantity be delivered on-time. If they order 10 units from you, then they only expecting exact 10 good units are delievred on-time within the time frame stipulated to you.
If they change their mind to reduce order to 5 units, then just ship them 5 units exactly, no more and no less.

You are ALMOST right.  On-time delivery must be measured against the CUSTOMER’S requested date.  If you measure it against your promised date, you are internalizing your metrics.  “It is the customers stupid>”  Ring a bell?

datadan,
               Do a search at the top of this page on “SPAN”, there is an article about GE and their use of SPAN. Span is defined as the time the order is entered until it is delivered. This was a major project for GE several years ago in the ED&C area.
 
As for the other comments, I’d agree, that ALL orders/units should be counted. You may also wnat to go back to the customer and define what they want. In another life our SYSTEM gave us a delivery date and the customer keep hitting us for being late, we found out that the SYSTEM lead times were wrong. 
Also make sure who your customer is, the receiving site or the buyer, We have a Situation where the buyer wants it delivered on the 16th, however the warehouse can’t give us a delivery appointment until the 20th. We thought we were doing ok, we delivered on the 20th and still got hit with being late.

Hi
OTD = Two things, the proportion shipped in a given period at the time it was supposed to in order to reach the customer, and the aging profile for analysis.
Therefore:
OTD = Shipdate – (promisedate – freighttime). Internal. Freight time specific to customer….
Or OTD = Shipdate – (promisedate – Freighttime) within the limits of the certain customer, for example +zero days – minus2. Be careful on this one, you need to have the customer parameters on your system as well as the freight times somewhere.
Both versions will give you an aging profile whereby you can find out if you are continually missing by one day or by multiple days, also both will give you as good as it gets OTD. the one you chose depends on how good your data is.
Also find a way of stratifying out various product groups as line items plays a harsh role in OTD improvement projects.
You should look at all line items that were suposed to ship within a given period of time, anything else gives you skewed data and miss the reasons why product did not ship at all….
Just my thoughts.
T.
 

Datadan,
If you have data like that, then you have real issues!
It depends on what your customer wants…. will they accept product early? If yes you have 16% OTD to customer. If not then 5% OTD
Neither of your two scenarios!!!! Black and white it would be 5%OT  11% early and 84% late.
Otherwise follow previous postings…
Good luck.
T.

Hi Kumar,
Please see Stans reply.
Thanks.
T.

The requirements for early receipt should be defined during the initial contract review.  Customers normally allow some window for early delivery.  Unless it it cost feasible to track every shpment, product shipped to arrive during that window is “assumed” to be on-time unless notified otherwise by the customer.  Any portion not shipped to arrive in the window is assumed to not be on-time.  When your company renegotiates a new date for delivery of remaining product unavailable for shipment to meet the original promise date that product must then be shipped to meet the new comittment or it is late again.  Best to count against the promise date that is missed rather than the actual ship date.

Actually, neither is the correct metrics for on-time-delivery…both are approaches to on-time-shipping metric.  For an on-time-shipping metric, the data basis should be actual shipments in the period.  This approach will yield you absolute in-period metrics with full granularity of detailed shipping information and mots systems have very clean cutoffs for this data. 
Other metrics you may want to consider are Order-Fill-Rate…a great merics for businesses with stock products and immediate ship needs. This metric occurs at time of order entry and is based upon order line items.  For each item ordered was there immediate stock available to fill thne order.  Another is On-Time-Delivery.  For this mertic , your order system must be able to track customer requested delivery dates/times.  Although this a more meaningful, customer-facing metric, it is, also, more difficult to assure complete data as you muts rely on this data from your transporters, (preferably EDI/XML) and tends to be removed from  all other business reporting as the transactions lag.  
I would suggest all three metrics be used. Hope this helps.

I have been following this thread & all the different interpretations of OTD.  If our customers request certain dates, then this is the calculated date.  But most have a contract on file w/the company that the system uses to caulate delivery time.  Most (not all) have it set up to ship w/i 48 hrs of receiving the order w/2 days transit time.  We calculate our OT by getting it out in the 48 hrs, but monitor whether we can ship in 12 or 24.  Then our carriers are responsible for the intransit time and must provide reports.  Fullfillment of the order is a separate metric as it affects a different part of the logicts train.  In all we use 6 items to monitor our customer service/satisfaction. 

Donna:   good points.   And I generally agree… that a contractual expectation is critical to a having a consistent OTD metric; otherwise it becomes “it depends” unless you have a consistent backup plan to measure things that do not have contractual delivery expectations.
Yet, and I think most of us would say… (without too many cliches) that world class supply chains see delivery as at the customer’s door.   Therefore the OTD measure (for the sake of arguement) contractual date (order entry) to the customer’s door.  And that one is the big one.  If you can hit that metric…wow.  See FedEx, UPS…etc. as they have good metrics… “got the package” to “delivered to customer.” 
All of the other logistical metrics could and probably are critical metrics as measures as to why a company hits or misses OTD….
As another gent posted earlier… y(OTD) = f(order date to order fulfillment{x} + shipping LT{x}+ etc.) and those can break into several metrics… but ASK… it what being measured worth the effort… and does it critical change the “y”.

I worked in Logistics company that calculated on-time delivery. We used three categories:
% Total pounds delivered early, on-time, and late
 

Hi,
I think that you should focus on the monthly OTD understood as delivered vs. required. Now, you’re going to say what about the ones that were supposed to be delivered and weren’t. Those are going to have to be reported to the next month and if you still don’t deliver to the next one and so on and so forth (if you don’t deliver for two months you better have a very good reason for your customer…) as at the end of the day you will get the bad OTD sometime. The only additional variable that has to be followed is “by how much” is your delievery overdue. And here, in order to better understand your performance and also to identify the worst offenders (the ones out of the process limits) you can add a flavour of SPC and use the necessary tools (histograms & charts) .
Gabe

Echo the SPAN comments.  Also, since miost SPAN metrics only look at what was shipped, I have found it helpful to track SPAN on unshipped (backorders) as well.  That reduces the gamesmanship significantly.

I give up. What’s OEE?

OEE??

not ahving the time right now to read the rest of the posts (I’m sure someone has replied with this answer, but if so it bears repeating) I respond that the definitive ‘paper’ is ‘published’ by your customer….in my experience On Time Delivery has been calculated (without exception) as teh number of line itmes shipped on time in any given time period divided by the number of line items that were due to ship as required by the cuctomer.  The customer makes the rules because they have the money.
 
Any other way makes the metric look better for you as the supplier but doesn’t make the customer any happier.

I think I have to agree with Gabe, below.  If there is a possiblity that the required date will change, you have to look at only those products that were shipped.
If something is already late, it will be late when it ships, unless the required date is changed.  So, if you ship 10 in one month and all 10 are on time, but 5 more were supposed to ship, those 5 will show up as being shipped late in your next months data–unless the required ship date was changed before the product shipped.
If there is any possibility of the required date being changed, the order being put on hold, or the order being cancelled, then you have to look at only the shipped orders data.  If an order is shipped, then there is no possibility of change.

Chaos theory:
Complexity is derived by simplicity / Simplicity is derived from complexity.
 
That little formula would certainly have saved Stephen Wolfram a lot of time.  He tended to think it was a bit more complex – the theory that is…
 Vinny

datadan,
You are creating doing what people seem to do so well. You are creating scenarios to excuse yourself from running the correct metric. If you promised it and it didn’t ship it is late – it counts. Take a look at that Black and Decker lazer level thing – they built advertisement around it but couldn’t get the product out of the factory in time for Christmas (2003). It didn’t ship. Lets ask the people in the stores if that was a late shipment. Of course it was – you are taking a producers view as opposed to a customers view and are creating a scenario that will allow the producer to build good metrics around crap performance.
All that junk about a shipment on hold – fix the system so you can put it in suspense and actually calculate the correct OTD. Having a broken system is not an excuse for calculating OTD incorrectly.
Just my opinion.
Good luck.

Hi Vinny,
Perhaps, but my mind was mush after spending a day and a half root causing a whole load of works orders in order to understand a little piece of why our company doesn’t deliver on time to an on time delivery metric which I wrote from the horrible MRP system that I am working with.
Hence my gratuitous analogy was given as I drifted in and out of MRP insanity and dealing with twits all day that just don’t get the point on OTD.
The apologetic square eyed, Tronan.

In the eyes of the customer how about
OTD = # of orders on time to customer request Date / # orders due
# of orders due = # of orders on time to customer request date + # of orders late to customer request date