iSixSigma

On Time Delivery

Six Sigma – iSixSigma Forums Old Forums General On Time Delivery

Viewing 51 posts - 1 through 51 (of 51 total)
  • Author
    Posts
  • #37817

    Datadan
    Participant

    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,

    0
    #112214

    Ken Feldman
    Participant

    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.

    0
    #112215

    Datadan
    Participant

    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.

    0
    #112218

    Ken Feldman
    Participant

    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) 

    0
    #112225

    Mike Carnell
    Participant

    Darth,
    This is one of those that I was refering to. I have to rely on you and Stan for the appropriate response.
    Regards

    0
    #112230

    Dog Sxxt
    Participant

    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.

    0
    #112267

    Tim
    Member

    I 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). 

    0
    #112269

    Wingman
    Member

    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?

    0
    #112281

    Datadan
    Participant

    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,

    0
    #112287

    GDS
    Participant

    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.

    0
    #112304

    Tim
    Member

    It’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). 

    0
    #112319

    Tronan
    Member

    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.
     

    0
    #112320

    Tronan
    Member

    Sorry being a twit,
     
    It is actual versus Shipped + on both versions….. not minus
    This is what happens when you rush…
    T.

    0
    #112329

    Datadan
    Participant

    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?

    0
    #112331

    Mikel
    Member

    datadan,
    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….

    0
    #112344

    Tronan
    Member

    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.

    0
    #112345

    Datadan
    Participant

    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.

    0
    #112347

    Datadan
    Participant

    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.

    0
    #112382

    Kumar
    Participant

    i 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.

    0
    #112393

    Tronan
    Member

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

    0
    #112394

    Tronan
    Member

    Hi 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.

    0
    #112831

    Tim
    Member

    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.

    0
    #113040

    MW
    Participant

    This 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
     

    0
    #113041

    Ole Watoosh
    Participant

    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.

    0
    #113046

    Bryan
    Participant

    I 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.

    0
    #113049

    Donna
    Participant

    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. 

    0
    #113050

    tgrimes
    Member

    We 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.
     

    0
    #113051

    Bryan
    Participant

    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”.

    0
    #113055

    Solo
    Member

    Bryan,
    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…
    -Solo

    0
    #113057

    howe
    Participant

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

    0
    #113061

    Jonathon Andell
    Participant

    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.

    0
    #113074

    Gabe
    Participant

    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

    0
    #113075

    Tim
    Member

    Just 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
     
     

    0
    #113081

    TMP
    Member

    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.

    0
    #113082

    Da Agent
    Participant

    OTD sounds like an OEE metric…..

    0
    #113085

    Jonathon Andell
    Participant

    I give up. What’s OEE?

    0
    #113086

    Dayton
    Member

    Overall Equipment Effectiveness

    0
    #113087

    gt
    Participant

    OEE??

    0
    #113096

    Datadan
    Participant

    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.–

    0
    #113097

    beverly daniels
    Participant

    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.

    0
    #113110

    Aloysious
    Participant

    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.

    0
    #113122

    np
    Participant

    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.

    0
    #113123

    Tronan
    Member

    Hi,
    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.

    0
    #113125

    Dayton
    Member

    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

    0
    #113128

    Tronan
    Member

    And so you miss my point too….
    T.

    0
    #113131

    Mike Carnell
    Participant

    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.

    0
    #113138

    Dayton
    Member

    Perhaps you addled a perfectly good point with an extraneous and gratuitous analogy?
    Vinny

    0
    #113160

    Tronan
    Member

    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.

    0
    #113165

    Dayton
    Member

    I 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…
     Vinny

    0
    #150946

    Wake4me
    Member

    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

    0
    #168849

    pcsharma
    Participant

    OTD MUST REQUIREMENT IN RUNNING INDT BECAUSE SPACE CONCERN SO THAT ANY UNIT ARE NO STORAGE THE WIP MATERIAL

    0
Viewing 51 posts - 1 through 51 (of 51 total)

The forum ‘General’ is closed to new topics and replies.