Q&A - On-time Delivery - OTD

The Contact Us function at the top of every page on the tl9000.org website is the preferred means for asking questions and receiving answers from the subject matter experts of the TIA QuEST Forum. Over the last few years many questions have been answered through this means. The number of each question is the ticket number in the Contact Us tracking system.

These questions generally relate to the On-time Delivery (OTD) measurement for purchase order line items (OTI) and service orders (OTS).

Question 9335 — In reporting On-Time Delivery, how are you defining "line item"?

Answer — A ‘line item’ is a single line in a purchase order that specifies a product. For example, if the purchase order contained the following:

Item	Quantity	Customer Requested Date
Screws	1000	March 1
Nuts	500	March 15
Washers	2000	April 1
Bolts	50	May 15

There are four line items here; not 3550. In order for a line item to be on time the entire quantity of each line item must be delivered on the due date. If they are delivered early they are not on time unless the customer agrees they can be delivered yearly. Please see the TL 9000 Measurements Handbook 5.4.4 b) 4).

Question 9339 — For software services, need more clarity on OTD calculation.

Answer — You would have no OTD to report if the customer downloads information off the server. You would then enter EXEMPT. For an example, please go to page https://tl9000.org/handbooks/mh_examples.html then click on the OTD examples.

Question 9723 — The customer requests an item for delivery on a certain date, the customer request date (CRD). You, the organization, ask the customer if you can deliver on a different date. The customer agrees to accept the item on the different date. Your question is whether the item was delivered on time.

Answer — Please see the last sentence of section 5.4.4 b) 6) of the counting rules which states 'Changes to the CRD may not be initiated by the organization.' Since you, the organization, requested the change in the CRD, then according to 5.4.4 b) 6) the order is not on time unless delivered on the original CRD. If the customer had contacted you first requesting the different date, then delivery on the new date would be on time.

Question 10255 — With respect to On-time Delivery (OTD – 7.2.2 / OTD – 7.5.1): If the delivery is delayed due to third party issues should it be considered as On-time delivery or should we consider that as delayed?

Answer — If the third-party is hired by the customer, then those orders may be excluded from the OTD measurement. If the third-party is hired by the organization, then the orders are to be included in the measurement.

Question 10553 — For software industry, for 7.2.2 and 7.5.2 if the delivery is made before the customer requested time, should we consider it as On-time delivery?

Answer — See 5.4.4 b) 4) of the TL 9000 Measurements Handbook, which states "Early order completions or deliveries are considered to have missed the delivery date unless authorized by the customer." There is no exception by category.

Question 10650 — OTD to Request: We would like to have clarification on the definition of this measurement with respect to request date. If a customer request date is an earlier date compared to the company's quoted lead times or ATP or they make same day booking, would this be a point against the OTD request measurement? Or is the request date based on the date that we acknowledge or promised that they as agreed?

Answer — The TL 9000 on time delivered measurement is per the customer requested delivery date (CRD). The company's quoted lead time or ATP has no bearing on the TL OTD measurement. This is still true if the organization suggests a different delivery date to the customer and the customer accepts as per rule 5.4.4 b) 6) only the customer may request changes to the CRD.

The same is true of a request for delivery the same day as the PO is received. The only allowable exclusion from the reporting is a purchase order where the requested delivery date is prior to the receipt of the PO.

Question 11232 — I have one question regarding the FR measurement (category 7.7.4) for the OTD measurement we calculate the DIa and DId as a number of "line items" meet on time but my question is, for the NPRs , FRsi, FRsy and FRst, which data are required ?, the number of line items for specific period or the total of units (products) that are include in line items?

Answer — The OTD measurement is related to the number of line items on a purchase order but the FR measurements it related to the number of boards delivered so NPRs, etc., all are related to the number of boards built and delivered. The answer is that OTD relates to line items on a purchase order and the NPRs, FRsi, FRsy, FRst related to the count of boards built and delivered.

Question 11894 — Clarification for the OTI Measurement: When the CRD is inside agreed product lead times and the customer wishes to obtain material as close to the original CRD as possible, does the organization need a separate authorization to ship early or is the CRD being inside contract lead times sufficient. Customers do not typically send individual authorizations for this situation but desire their material earlier than contract commitments. If shipped earlier than the contract specified lead time is this considered a miss for OTI? This situation may happen often with some customers as their procurement cycle delays the originator’s PO to the supplier.

Answer — The guiding item is paragraph 5.4.4 b) 4) that states early delivery are considered to have missed the delivery date unless authorized by the customer. If the customer agrees that delivery inside an agreed lead time is an on-time delivery then it is on time. The contract with the customer should cover all shipments under the contract unless the customer specifies otherwise. Being on time all depends on the customer. If they want it early and agree it is on time then it is on time. It doesn't have to be judged on a case-by-case basis. The contract can be written to cover all cases.

Question 11979 — When customer does not ask for item delivery time but only ask for service (usually is installation) delivery time in the contracts or other agreements, does this mean we can only calculate OTS, and do not calculate OTI for this contract?

Answer — The question about whether you report OTD data of OTI or OTS does not depend on your customer. It depends only on the category. The data submission template for the category will tell you which of the two measurements you report. You will report only one OTD measurement in the category and not both.

If the organization is registered in 7.1.1.1 Physical Installation, then there would be data to report in OTS.

Question 12040 — I have a question about the OTD measurement for 7.1.1.1 Physical Installation and 7.1.2 Provisioning. If one service order requires both Provisioning and Installations activities can the service order be counted for 7.1.1 and 7.1.2 for the OTD measurement? This feels like doubling counting and I’m unsure if this is allowed for TL 9000 measurements. A solution to this problem is if it’s possible to merge the measurements for 7.1.1.1 and 7.1.2 and submit only one OTD measurement under 7.1.

Answer — Yes, a single order containing multiple services is counted in each service. In this case, it would be counted in 7.1.1.1 and 7.1.2. This is not double counting as the data is being reported in different categories, the on-time delivery for the installation service in 7.1.1.1 and the on-time delivery for the provisioning service in 7.1.2. It should be noted that 7.1.2 is intended for the provisioning activity that sets up the equipment for the end user and not the telecommunications service provider. If the service being provided during installation only includes network level provisioning, there is no data to be reported in 7.1.2 as the service being provided does not fit the category definition.

Question 12173 — OTD measurements are required to be reported in the month the CRD occurs (per counting rule 9). If an organization claims they cannot report in that manner due to the way customers submit 'preliminary CRD's’ in order to drive ERP demand, assuming it is not allowable to permit the organization to report OTD based on month shipped, are there any other potential solutions?

Answer — We don’t quite understand the issue here. At some point the customer has to indicate to the organization when they wish to have the product. That date is the CRD and that is the date the organization has to track and report OTD against. Demand estimates or “preliminary CRD’s” are not CRD’s unless deliveries are made contractually required against those estimates (e.g. 400 units per month).

Question 12596 — In reviewing the TL 9000 OTD examples, I could not find how to count DVd & DVa when the customer changes the CRD to a later date. In many instances our customer will change our CRD due to the customer's major equipment suppliers inability to meet the required equipment delivery date. This impacts our ability, as the installation vendor, to meet the previously established CRD. If this equipment had been available, we, the installation vendor would have met the customer's CRD. The change in CRD has been shifted as much as 60 days due to major material not being available for installation.

Answer — As noted in Section 5.4.4 b) 6) “The CRD is the initial requested date as in the contract, or, in the case of customer requested changes, the revised date.” In other words, if the customer requested a new CRD, then your on-time delivery of the installation is measured against the revised date and not the original date. The original CRD would still be used if you, the organization, requested the change to the delivery date.

Question 12628 — We hold a hardware and software registration for category 1.2.7 Application Servers. Once we ship our hardware to a customer our professional services group will install it. For the OTD measure, am I correct in assuming that because we do not include “services” in our certification (HS) that our OTD measure would be based on CRD for the hardware and when the hardware was actually shipped? Additionally, the measurement template for 1.2.7 HS includes Dla and DId “Number of line items accepted and due,” and does NOT include DVa and DVd, “Number of services orders accepted and due.”

Answer — If the order is split into two separate transactions, one for the delivery of the hardware and one for the installation, with separate CRD’s and separate invoices, then the hardware delivery would be reported in OTI. If there is only one order for all activities which is not invoiced until the installation is complete, there would be no OTD data to report for your product in 1.2.7. The reason is that in this case, the hardware is actually being delivered to your installation group and not the end-customer.

Question 12677 — Comments in the category 7.3.1 If a maintenance activity on a Network element is scheduled with planning completed, and later on the maintenance activity is cancelled/postponed will this be recorded in any of the measurements (e.g., will it be regarded as an unsuccessful maintenance activity) since it was planned but did not take place?

Answer — If the activity is cancelled by the customer, then it would not be reported in OTS. If it is postponed by the customer, then it would be reported in OTS using the new date. If it is postponed or cancelled by the organization, then it would be reported as a late delivery in OTS for the month it was originally due in. Any problem reports against the activity would be counted in NPR.

Question 12776 — In OTD & SQ for 7.3.1 DVd is termed to be “All maintenance activities due to be closed in the month”. Dva is termed to be “All maintenance activities closed on time”. SQt is termed to be “All maintenance activities that occurred during the month”. SQd is termed to be “All maintenance activities that failed in the month”. We would like to understand a bit more. In a scenario where we have a fault with a device not functioning, (for the sake of this example) let’s say the team in charge states that the device should be rebooted as an attempt to restore the device to functionality. Next a maintenance activity/window is scheduled in which the device will be rebooted. At the time for the maintenance, steps are initiated on time and the device is rebooted as planned and powered back on within the maintenance window specified. However it is observed that this maintenance did not fix the problem and the device is still not functioning as it should.

1. Will the activity be counted within DVa as a maintenance activity delivered on time because: a. The maintenance was scheduled for the specific action of rebooting the device and the reboot was executed according to schedule, or
2. Will the activity be counted within SQd as a failed maintenance activity: a. Since it did not resolve the problem that led to the activity for which the maintenance was scheduled, or
3. Will it be counted in both DVa and SQd. The above example applies to two scenarios: A. The malfunctioning device and the maintenance activity are both service affecting B. Neither the malfunctioning device nor the maintenance activity is service affecting.

Answer — One thing that is important to do with regards to the TL 9000 Measurements is to evaluate each one independently. So first we will look at the scenario you describe from the standpoint of OTD. The maintenance activity to be included in OTD here is the restoration of function to the device that is not functioning. It is completion of that activity within the set time frames for such activity that should be included in OTD. The scheduling of a maintenance window is just a part of that activity and would be a step in the overall process of function restoration. The maintenance window would not be included in OTD reporting; only the overall restoration of function would be.

Looking at SQ, since the reboot did not correct the problem and there will need to be a second visit to the site, then there would be maintenance call back event to include in SQ.

Question 12856 — OTD: An order is originally accepted based on the given forecast. That forecast subsequently changes, but no PO changes are processed (original PO was "per attached forecast"). Is OTD measured against the revised forecast or the originally accepted forecast?

Answer — If the change to the forecast was initiated by the customer, then the revised forecast can be used to measure OTD. If the change was initiated by the organization, then the original forecast must be used to measure OTD. This is as per rule 5.4.4 b) 6).