TL 9000 Situation Explanations

The following paragraphs are explanations of various situations encountered by TL 9000 registrants. The explanations are supplied by the Subject Matter Experts in the QuEST Forum IGQ work group that produces the TL 9000 standard. Please also see the FAQ for experienced users.

General Questions

Installation Audits in 7.1.1

Service Level Agreement (SLA) and FRT measurement

Applicability of Requirements 7.1.C.1, 7.1.V.1, and 7.1.C.3 in Installation Services, Produce Category 7.1.1

Explanation of OTD in Release 4.0

Reporting of the SQ Measurement

 

Installation Audits in 7.1.1

Situation: The customer performs an installation audit and finds that there are enough problems to classify the audit as non-conforming. How does this customer audit impact the reporting of SQ and NPR data by the organization?

Answer: It’s a general practice in auditing installations to have a set of criteria that will be inspected. It’s not necessary to meet 100% of these criteria to have a conforming audit but there is a point where the accumulation of missed criteria makes the audit non-conforming.

The organization has a set of audit criteria and a set of rules to determine if the audit is conforming to requirements or not. The customer may also have a set of audit criteria and set of rules to determine if the audit performed by the customer is conforming to requirements or not. The organization audit requirements and the customer audit requirements may or may not be the same.

Relative to reporting the SQ measurement only the organization audits are counted. It doesn't matter what the customer audit outcome is relative to the SQ measurement.

The customer audit may find missed criteria which they can report as problems to the organization. The organization would then be obliged to include these reports in their NPR measurement. It really doesn't matter whether the customer audit is conforming or not relative to the NPR measurement. What matters is if the customer reports a problem to the organization as a result of the audit, conforming or not-conforming.

The purpose of the organization audit is to find missed criteria and then correct them before the customer does an audit. This is just part of the organization’s quality process for producing an installation that meets customer requirements. They would normally not report these missed criteria to the customer unless obliged to do so by contract. If the organization misses the CRD as a result of having to fix things found in their audit, then that impacts their OTD measurement. If they choose not to fix things found in their audit in order to meet the CRD date, the chances are the customer will find the same problems and report them to the customer as problems, thus impacting their NPR. Their SQ measurement is already impacted because of the organization’s non-conforming audit. So either way, their numbers are going to be impacted because of shoddy work that led to their non-conforming audit. Thus, they have the incentive to improve their processes so that their audits are conforming and thus any negative impact on the customer is minimized.

Finally a customer audit and its being either conforming or non-conforming is an issue between the customer and the organization. The customer audit does not play a role in the SQ measurement and does not directly enter the organization’s NPR and OTD measurements. However, the impact of the customer audit does potentially impact the organization’s NPR and OTD measurements indirectly if problems found are reported (impacting NPR) or fixing problems causes them to miss the CRD (impacting OTD).

top

Service Level Agreement (SLA) and FRT measurement

Situation: The organization has a contractual agreement with the customer to provide fixes to problems within 20 days, which is shorter than the default 30 fix response period specified in TL 9000. Release 4.0 of TL 9000 permits changing the 30 day fix response period through a service level agreement (SLA). Is a separate SLA required in this case?

Answer: There is no need for a separate service level agreement. The contact requirements are the same as an SLA.

 

top

Applicability of Requirements 7.1.C.1, 7.1.V.1, and 7.1.C.3 in Installation Services, Produce Category 7.1.1

Situation: Requirement 7.1.C.1 — Life Cycle Model, 7.1.V.1 — Service Delivery Plan, and 7.1.C.3 — End of Life Planning don't seem to readily apply to Product Category 7.1.1, Installation Services. Can they be excluded?

Answer: No. They can't. In fact they do apply to Installation Services. All of these requirements can be applied to an installation contractor and already are at the organizations registered in this TL 9000 product category. It can be difficult to see exactly how they are to be applied at first. It requires remembering the product being delivered is the installation itself. From that standpoint the following advice is offered.

7.1.C.1 Life Cycle Model — Life cycle is harder to define for services than it is for hardware software products. For most services the lifecycle starts with requirements and not product “concept”. Customers provide requirements through RFQ’s, the service company responds to the request, a contract or purchase order ensues defining requirements and the organization then executes through its delivery processes, and then warranty/sustaining, if any, is included and end of life. The requirement can be addressed it the quality manual by simply analyzing the cycle and defining it for what is. An example for an installation company could be a life cycle model that goes — request for quote, quote response, site engineering, material procurement, installation, removal, and sustaining, along with end of life.

7.1.V.1 Service Delivery Plan and the related 7.3.1.C.1 Project Plan — Most installation companies deal with many short projects and do not develop a project plan specifically for each one. This can be handled by a general project plan applicable to “typical” projects. Typical would have to be defined or the plan could simply start with a decision point to determine if the standard plan applies to the project or a project specific plan would have to be developed.

7.1.C.3 End of Life Planning — It is true that end of life is a rare occurrence for a service product, especially installation services. It does apply to the discontinuation of installation activities involving special techniques, knowledge and/or skills, although in most case, those services will fade away from lack of demand instead of actually being stopped. The simple solution is to write a very brief procedure that calls out required tasks to end the life of the product according to the standard, the roles and responsibilities within the organization for doing so, and the method to inform customers such as sending a letter, Service Bulletin, etc.

There are other methods and documentation the organization can implement to comply with these three requirements. The above suggestions are just that, suggestions. The bottom line is the requirements do apply to an installation contractor.

top

Explanation of OTD in Release 4.0

Situation: The OTD measurement changed in Release 4.0 with the elimination of OTIS. What do we do about reporting system orders in the OTD measurement? Are they

  1. one line item per system order, or
  2. decomposed into line items comprising the system order, or
  3. ignored completely?

Answer: The only change in R4.0 is to report the special type of service orders, system installations along with the other installation service orders instead of reporting these service deliveries separately. There are no other changes to the rules. It is exactly as stated in the note following section 5.4.4 d) "Those service deliveries previously reported in on-time installed systems delivery (OTIS) are now included in the OTS measurement." The order for an installed system is to be treated as a service order. So the answer here to the above question is "None of the above" unless the system order is comprised of several service orders with separate customer requested dates for delivery with separate acceptances.

One nuance is that the order for a "system" without any installation service would be treated as any other line item order. The assumption made in all of these answers is that the term "system order" means an installed system.

Situation: How and in what categories do we count service line items, if at all?

Do we

  1. count service items only in OTS, or
  2. count them in product OTI, if product and service items are included in a single order, or
  3. count them in both, if the same order involves both a product and service category?

Answer: In TL terms, there is no such thing as a service line item. An order is either for a line item or for a service. It can not be both. The delivery of material or equipment in association with a service order such as an installation is considered to be a delivery internal to the organization. The only delivery date of concern to the customer is when the installation is complete and ready for acceptance testing. Therefore the delivery of material related to the service is not counted within any TL OTD measure. Again, it should be noted this applies to all prior versions of TL 9000 as well as R4.0.

Situation: At least 2 rules appear to be in conflict that could apply to service orders. Counting Rule 5.4.4.b) 11) says "Compound orders designated by the customer for a single delivery, for example must ship complete orders, shall be treated in aggregate. If one line item is late, then all line items shall be counted as late.", while counting rule 5.4.4.C) 3) says "Material that is part of a service delivery by the organization should not be counted in the line item delivery measurement." In the latter case, do we ignore any product items in an order that includes services, or do we only ignore ancillary items like tools and site prep materials that have nothing to do with a product category?

Answer: First of all, counting rule 5.4.4 b) 11) applies to line items only. It does not apply to service orders.

The delivery of material required for the completion of an installation service order, including the equipment being installed is not reported within any TL OTD measure. An example of an exception to this would be a compound order for the installation of a system along with the separate delivery of spare units to a central warehouse or other location. The system installation would be counted in OTS and the spares delivery would be counted in OTI. In standard industry terms, EF&I, F&I, or I orders are counted in OTS and OTS only. Furnish only orders are counted in OTI. Any E&F order would have a service order to report (the engineering job) and a line item order to report (the furnished equipment). As noted in the exception above, an EF&I order which contains an order for separate equipment not involved in the installation activity would also have a service reported in OTS and items reported in OTI. There are no cases where the delivery of material or equipment associated with the installation service are reported in one of the OTD measures.

top

Reporting of the SQ Measurement

The reporting of the SQ measurement is easier than it might appear. SQ reports the number of transactions completed during the month being reported as the denominator and the number of defective transactions reported in the month being reported as the numerator. The transaction that is being reported as defective could have been completed in the month being reported or in an earlier month.

As an example, consider the month being reported to be April 2007. The company starts a transaction (such as an installation) in February and finishes it in April. This transaction is not reported in the February or March data submission but is reported in the April data submission only since that is the month the transaction was completed. Many of the transaction types are completed very quickly in the same month they are started but if the transaction completes in a month later than the month when the transaction started, then the only month it is reported is the month of completion.

When do you report defective transactions? Answer: Report them in the month they are reported as defective. For example, suppose a company completes 5 transactions in January, 3 in February, 6 in March, and 7 in April. Suppose also that one of the transactions completed in January and two of the transactions completed in March are reported to be defective in April. The company will report SQt, the denominator or (t)total transactions, for April as 7 and will report SQd, the numerator or (d)defective transactions, as 3 for the one defective transaction completed in January plus the two defective transactions completed in March but reported defective in April.

Product Category 7.4 indicates there is a six month period for reporting. Do you add up the transactions over the last six months and report that for the number of transactions? Answer: No. Each month report only the transactions that were completed that month. The comment in product category 7.4 says that any transaction that is reported defective in a month for a transaction that is out of warranty or was completed more than six months earlier is to be ignored and not reported.

top