On Time Delivery
Six Sigma – iSixSigma › Forums › Old Forums › General › On Time Delivery
- This topic has 50 replies, 28 voices, and was last updated 14 years, 4 months ago by
pcsharma.
-
AuthorPosts
-
December 10, 2004 at 9:58 pm #37817
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.I’m having a debate with my coworker about how to calculate on time delivery. Specifically in the starting point of availble chances for success.Contention 1: Look at all that ALL items that were supposed to ship and calculate which items shipped on time.Contention 2: Look at only those items that did ship and determine if those shipped on time.Both seem to have plusses and minuess I am being told that one method is proper and one is not. I appreciate any links that can help clarify this for me. Thank you,
0December 11, 2004 at 12:15 am #112214
Ken FeldmanParticipant@DarthInclude @Darth in your post and this person will
be notified via email.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.
0December 11, 2004 at 1:19 am #112215
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.hmmm, Problem: The measure then is only what we shipped and not what we were supposed to ship.
If we were supposed to ship 30 units in a month and we only shipped 10, but those ten went on time, then the OTD performance looks pretty good, even though it is not what the customer was expecting.0December 11, 2004 at 3:47 am #112218
Ken FeldmanParticipant@DarthInclude @Darth in your post and this person will
be notified via email.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)0December 11, 2004 at 11:36 am #112225
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.Darth,
This is one of those that I was refering to. I have to rely on you and Stan for the appropriate response.
Regards0December 11, 2004 at 12:32 pm #112230
Dog SxxtParticipant@Dog-SxxtInclude @Dog-Sxxt in your post and this person will
be notified via email.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.0December 13, 2004 at 12:00 pm #112267I don’t know why so many people want to pay games with this. Bottom line is if you don’t get the quantity of parts to your customer on the date promised they are late. If you were supposed to ship and did not, of course those have to be included in the calculation. Here’s the operational definition I use for On-Time.
On-Time Delivery: Product shipped as required to arrive at the specified destination by the original promise date, unless an adjusted date is initiated by the customer or caused by a customer action for which xxx Corporation has no control. Any amount of the order quantity not shipped in time to arrive at the destination by the promise date is considered late (customer notification of a late delivery and re-negotiating a new due date does not negate the original late delivery).0December 13, 2004 at 1:21 pm #112269You 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?
0December 13, 2004 at 4:46 pm #112281
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.There is no question that we are measuring against the customer’s requirement date. There are also quite a bit of tolerances to be accounted for (nodding in agreement).As a programmer my problem is the fundamental starting point. Is the universe of possibilities ONLY what we SHIPPED or is the universe of possibilities what we were SUPPOSED to ship.If we are supposed to included missed commitments (shipped or not) to customers that using all units shipped as a starting point is faulty logic. Also it is the logic of most OTD reports I’ve seen. Can someone point me to a definitive article expressing the point that OTD should take into account missed commitments that have not yet been shipped against. I have been unable to find an article about it yet.Thank you,
0December 13, 2004 at 7:06 pm #112287datadan,
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.0December 13, 2004 at 11:09 pm #112304It’s called contract review. You’re required to meet those customer requirements you’ve contractually agreed to (or promised). Although all good companies will do their best to meet all customer desires, existing material and/or process lead times have to be considered (although the company should be continually looking at reducing those lead times).
0December 14, 2004 at 12:01 pm #112319Hi
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.
0December 14, 2004 at 12:05 pm #112320Sorry being a twit,
It is actual versus Shipped + on both versions….. not minus
This is what happens when you rush…
T.0December 14, 2004 at 2:46 pm #112329
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.Tronan,Suppose you were scheduled to ship 100 units in November and you shipped 5 on time and 11 early, and 9 late.Does your November calculation then =
20% On Time
36% Late
44% EarlyOr is it:
5% On Time
9% Late
11% Early
75% Unknown presumed late?0December 14, 2004 at 2:53 pm #112331datadan,
Hey boys, this ain’t rocket science. You ship on time or you don’t. If you ship most early and still ship late, you have one heck of a problem – go fix it. It doesn’t matter how you report it.
PS- Didn’t Helen Reddy sing a song about you some years ago? Datadan, whats that flower you have on….0December 14, 2004 at 5:56 pm #112344Datadan,
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.0December 14, 2004 at 5:59 pm #112345
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.Re Helen Reddy –> Nope wasn’t me. No flower power here. Nope wasn’t me. No flower power here. Nope wasn’t me. No flower power here.Re OTD: I think I’m understand that all scheduled deliveries should be counted regardless of whether or not they actually shipped. However proposed calculations I’ve seen only look at those items delivered, which by definition does not include those items that were supposed to deliver.In the example I gave earlier with 100 units scheduled to deliver in November. All 100 should be evaluated. This means that I am not only looking at the delivered units but also the not-yet-delivered units.If I do this, then the November data changes if I run the report in late november, early december, or late january. Especially if users “change” commitment dates for undelivered products. My co-worker says this is a bigger problem than not counting “undelivered” units. Without consistenty in the result, people will not use the metric. “last week it said x about November, but this week it says y.
0December 14, 2004 at 6:05 pm #112347
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.Tronan,Following with your logic and melding it with my recent post on this issue:I run the report 12/1/04 with the results:
5% = OT
11% = Early
84% = Late. (which is 75 not delivered and 9 late)On 12/2/04 the sales group “revises” comitments to customers based upon new agreements for 50 units the undelivered material pushing the new commitment to January. On 12/3/04 I run the OTD report again:5% = OT
11% = Early
34% = LateThis was clean, but in a high mix, highly fluid evironment, the dates change daily, which of course will also change the % Late daily depending. Thus OTD varies depending on when the report was run and when/if sales revised their commitments.0December 14, 2004 at 11:25 pm #112382i was just wondering how fare we are in selecting only the dellivery time as the measure. i think the measure should also include other CCRS like right product, right quantity and expected quality along with time. according to me this would make things easier. i dont see much help from just considering the delivery time alone.
0December 15, 2004 at 8:30 am #112393Hi Kumar,
Please see Stans reply.
Thanks.
T.0December 15, 2004 at 8:44 am #112394Hi DataDan,
On 12/2/04 the sales group “revises” commitments to customers based upon new agreements for 50 units the undelivered material pushing the new commitment to January. On 12/3/04 I run the OTD report again:
Irrelevant. You have already promised it once, and now it is likely to be late again.
As the metric is retrospective, it is looking at the facts of a previous month. Find out if your system generates a rescheduled date as well as a Promise date. Calculate the metric from the promise date, and create a separate metric for the reschedule date.
Then once you have created the metrics, go find out why you can’t hold your promise dates, or at least create promise dates once with integrity. You will be annoying your customers!
Good luck!
T.0December 25, 2004 at 1:16 pm #112831The 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.
0January 3, 2005 at 12:46 pm #113040This is correct – start with the contract and service levels defined in the contract. This is the basis for customer expectations. If you are within your service level commitments this is your goal. Be cautious not try try to ‘exceed’ contractual commitments specific to a contract or you can create reason for amendments and other havoc. If you are trying to determine the “cycle time” for some other reasons (future new business opportunities) – then you have the freedom to define the parameters if it is not a contractual requirement. You will need to define the “why” you are doing metrics and validate the value in the scheme of your contractual deliverables whether current contract or future.
M
0January 3, 2005 at 1:00 pm #113041
Ole WatooshParticipant@Ole-WatooshInclude @Ole-Watoosh in your post and this person will
be notified via email.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.0January 3, 2005 at 2:50 pm #113046I strongly concur with Tronan and that interpretation of OTD. I also agree with ensuring a period is established: daily, weekly, monthly… and that might take a few key process owners to agree on the right metrics (GM, Controller, Marketing Manager, etc).
I would ask what are you going to do with the data? How is it reported? And to whom?
As suggested Order Fill Rate can be an internal metric… however I would suggest that it is an integral part of OTD… and if you did not get 100% fill, you missed OTD on that entire “order.” As the customer… I expect 100% of my order ONTIME. Not a fraction of it.
Another key point… OTD is WAY different than On Time Shipping. OTD is “by definition” when the customer receives it. Many organizations measure their “OTD” from when they shipped it. NOPE.
Last note from the pulpit: Ensure your “delivery” leadtime is well communicated to your customer, and that you are consistent with your leadtime policy. We all have probably experienced “I want it, and I want it now.” Only to shoot back a “promise date” because we could never fullfill (want it now!) and the customer does not acknowledge that date. ON THE OTHER hand… if you have an established leadtime and you send back a “promise” date that is longer because of backorders or delays… that is more than likely a OTD MISS!! It means your process has changed… not your customer.0January 3, 2005 at 3:48 pm #113049I 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.
0January 3, 2005 at 4:00 pm #113050We measure the two important variables to our customer and multiply them aginst eachother to determine our performance. We promise shipment three days or sooner from order entry and the order no matter how many line items must ship complete in three days or less:
on time x fill rate – example: 90% ot * 95% fill = 85.5% performance
We measure daily performance and reveiw it weekly. Our goal is 95% ot x fill which believe it or not is about 30% higher then any other company in my industry.
0January 3, 2005 at 4:09 pm #113051Donna: 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”.0January 3, 2005 at 6:04 pm #113055Bryan,
You wrote – “…and if you did not get 100% fill, you missed OTD on that entire “order.””
% On-Time and % Complete MUST be separated in order to understand any separate processes as they are. Why count against the on-time performance of a complete 1st line item order of springs, when it was the 2nd line item order of sprockets that were incomplete and therefore partially, if not totally, late?
In other words, if the process of part A is completely independant of the process of part B (other than, in this case, the fact that they are shipped/delivered together), why should they be lumped into the same metric? I might go down a dead end searching for the reason why so many springs are being shipped late when it is really just the sprockets… I’m sure the customer recognizes this independance as well…
-Solo0January 3, 2005 at 6:21 pm #113057I worked in Logistics company that calculated on-time delivery. We used three categories:
% Total pounds delivered early, on-time, and late
0January 3, 2005 at 7:50 pm #113061
Jonathon AndellParticipant@Jonathon-AndellInclude @Jonathon-Andell in your post and this person will
be notified via email.There have been some good replies, so I won’t try to reinvent the wheel. You just need to follow two rules:1. The best measure is one that reflects the needs and desires of the customers to whom the items are shipped. Without that focus, you are at risk of adopting measures that are politically motivated, or convenient-to-measure-yet-meaningless, or just plain silly. (Anecdotal anti-example: airlines once tried to deem their flights to be “on time” based on when the plane was pushed back from the gate — even if the aircraft sat on the tarmac and passengers arrived hours late.)2. As Darth astutely pointed out, time is a continuous variable, while on-time-vs-delinquent is an attribute variable. Continuous variables provide vastly more information, especially if you do a good job of following rule #1.
0January 3, 2005 at 11:34 pm #113074Hi,
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) .
Gabe0January 4, 2005 at 12:39 am #113075Just ask your customer when you were late. Was it when you didn’t deliver as committed & shut down their line or when you finally got around to shipping the product?
Tim
0January 4, 2005 at 1:19 pm #113081Echo 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.
0January 4, 2005 at 1:25 pm #113082
Da AgentParticipant@Da-AgentInclude @Da-Agent in your post and this person will
be notified via email.OTD sounds like an OEE metric…..
0January 4, 2005 at 2:06 pm #113085
Jonathon AndellParticipant@Jonathon-AndellInclude @Jonathon-Andell in your post and this person will
be notified via email.I give up. What’s OEE?
0January 4, 2005 at 2:08 pm #113086Overall Equipment Effectiveness
0January 4, 2005 at 2:13 pm #113087OEE??
0January 4, 2005 at 6:45 pm #113096
DatadanParticipant@DatadanInclude @Datadan in your post and this person will
be notified via email.Tronan,I appreaciate the response. My points are twofold.1) Looking ONLY at the units that actually shipped gives a false representation of OTD. It sounds from your tone that you do indeed agree with this….here’s the rub…
2) Scheduled deliveries, that have not yet shipped, may or may not be late. For example the customer may have asked us to put the item on hold and not ship it, but do not give a new date. The order remains in the system under the original scheduled delievery date. Then, after stats are rolled, (and that delivery has already been counted as late), they request a new delivery date somewhere in the furture. Aside from the same delivery being double counted (once last month, and once for an upcomming month), it has been counted as “late” which incorrectly drags overall performance down (according to the upper/ups).–I am surprised there is not definitive white paper on this topic.–0January 4, 2005 at 6:54 pm #113097
beverly danielsParticipant@beverly-danielsInclude @beverly-daniels in your post and this person will
be notified via email.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.0January 5, 2005 at 6:23 am #113110
AloysiousParticipant@AloysiousInclude @Aloysious in your post and this person will
be notified via email.basically to me it is just the first promise delivery date to the customers, if you cannot deliver to customer base on your first promise date to them, than it is not on time. And what you are to look out is what causes it to fail in your delivery.
0January 5, 2005 at 3:07 pm #113122I 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.0January 5, 2005 at 4:15 pm #113123Hi,
1, agreed.
2, For a given time period there are an amount of orders promised, some are late to those dates, late divided by total is OTD. If you have customers putting the products on hold, then firstly they are breaking contractual law, and you are too nice, and secondly, get a date!!!!
Chaos theory:
Complexity is derived by simplicity / Simplicity is derived from complexity.
You are attempting to do the first as is everyone else on this thread it seems…. Please refer to my previous posts on the customer persepctive…
Keep it simple!
have fun.
T.0January 5, 2005 at 4:43 pm #113125Chaos 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
Vinny0January 5, 2005 at 4:56 pm #113128And so you miss my point too….
T.0January 5, 2005 at 5:45 pm #113131
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.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.0January 5, 2005 at 6:55 pm #113138Perhaps you addled a perfectly good point with an extraneous and gratuitous analogy?
Vinny0January 6, 2005 at 9:03 am #113160Hi 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.0January 6, 2005 at 1:07 pm #113165I appreciate the good-natured response as I was only teasing a bit. I well understand the mind mush phenomena spending an inordinate amount of time there myself. And those twits, they abound…
Vinny0January 23, 2007 at 5:22 am #150946In 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 date0February 22, 2008 at 11:38 am #168849
pcsharmaParticipant@pcsharmaInclude @pcsharma in your post and this person will
be notified via email.OTD MUST REQUIREMENT IN RUNNING INDT BECAUSE SPACE CONCERN SO THAT ANY UNIT ARE NO STORAGE THE WIP MATERIAL
0 -
AuthorPosts
The forum ‘General’ is closed to new topics and replies.