Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 57 views

    TL 9000 Quality Management System Measurements Handbook FRT Examples

    Uploaded by

    محمود علي الخطيب
    FRT deals only with reported problems from customers and the responsiveness of the supplier to fixing the problem. Since problem reports in Product Categories 1, 2, 3, 4, 5, 6, and 9 are classified by severity, FRT is also reported by severity. Critical problem reports are those problem reports that must be addressed immediately and continuously until resolved.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    TL 9000 Quality Management System Measurements Handbook FRT Examples

    Uploaded by

    محمود علي الخطيب
    57 views5 pages
    FRT deals only with reported problems from customers and the responsiveness of the supplier to fixing the problem. Since problem reports in Product Categories 1, 2, 3, 4, 5, 6, and 9 are classified by severity, FRT is also reported by severity. Critical problem reports are those problem reports that must be addressed immediately and continuously until resolved.

    Original Title

    meas-ex-5-2

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    FRT deals only with reported problems from customers and the responsiveness of the supplier to fixing the problem. Since problem reports in Product Categories 1, 2, 3, 4, 5, 6, and 9 are classified by severity, FRT is also reported by severity. Critical problem reports are those problem reports that must be addressed immediately and continuously until resolved.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    57 views5 pages

    TL 9000 Quality Management System Measurements Handbook FRT Examples

    Uploaded by

    محمود علي الخطيب
    FRT deals only with reported problems from customers and the responsiveness of the supplier to fixing the problem. Since problem reports in Product Categories 1, 2, 3, 4, 5, 6, and 9 are classified by severity, FRT is also reported by severity. Critical problem reports are those problem reports that must be addressed immediately and continuously until resolved.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 5

    Quality Excellence for Suppliers of Telecommunications Forum (QuEST Forum)

    TL 9000 Quality Management System Measurements Handbook FRT Examples

    Copyright 2011 QuEST Forum

    Fix Response Time (FRT) Examples

    5.2

    FRT Examples

    Problem reports from customers are expected to produce an action by the supplier to fix or alleviate the problem (see definition of Problem Report in the Glossary). The problem fix is to be delivered in a time frame determined the rules in 5.2.4 d) 1). Since FRT deals only with reported problems from customers and the responsiveness of the supplier to fixing the problem, the FRT measurement is not normalized but reported as a percentage of problems fixed on time. It may be that an organization has no problems to fix in a particular month. In that case 0 is reported for the number of problems fixed and also for the number of problems due to be fixed, which results in an FRT of 100%.

    5.2.1 FRT for Product Categories 1, 2, 3, 4, 5, 6, and 9


    Since problem reports in product categories 1, 2, 3, 4, 5, 6, and 9 are classified by severity, FRT is also reported by severity. Critical problem reports are those problem reports that must be addressed immediately and continuously until resolved. Since the fix for critical problem reports cannot be scheduled there is no measure of FRT for critical problem reports. FRT in these product categories applies only to major and minor problem reports. 1) Consider one months data for one product category for one TL 9000 registration. There are five major problem reports due to be closed during the month and all five were closed on time. There are 25 minor problem reports due and 20 were closed on time. 2) The data reported is shown in Table 5.2.1-1.

    Table 5.2.1-1 FRT Data Table Report for Product Categories 1, 2, 3, 4, 5, 6, and 9
    Identifier MeasurementID Fr2c Fr2d Fr3c Fr3d Value FRT 5 5 20 25

    3) The measurement calculation result is shown in Table 5.2.1-2.

    Table 5.2.1-2 FRT Source Data and Measurement Calculation for Product Categories 1, 2, 3, 4, 5, 6, and 9
    Fixes Available On Time Fr2c = 5 Fr3c = 20 Severity Fixes Due FRT Measurement Results Problem Reports Closed On Time FRT2 = 100% FRT3 = 80%

    Major Minor

    Fr2d = 5 Fr3d = 25

    The calculation of FRT2 is 100 * 5 / 5 = 100%. The calculation of FRT3 is 100 * 20 / 25 = 80%.

    Copyright 2011 QuEST Forum Version 1.1

    FRT Examples 5.2-1

    Fix Response Time (FRT) Examples

    5.2.2 FRT for Product Category 7 and 8


    Problem reports in product categories 7 and 8 are not classified by severity. All problem reports are considered equally weighted. 1) Consider one months data for an organization of a particular installation service. There are 20 problem reports due to be closed during the month and 16 were closed on time. 2) The data reported is shown in Table 5.2.2-1.

    Table 5.2.2-1 FRT Data Table Report for Product Categories 7 and 8
    Identifier Product Category MeasurementID Fr4c Fr4d Value 7.1 FRT 16 20

    3) The calculation of the measurement is shown in Table 5.2.2-2.

    Table 5.2.2-2 FRT Source Data and Measurement Calculation for Product Categories 7 and 8
    Fixes Available On Time Fr4c = 16 Fixes Due Fr4d = 20 FRT Measurement Results Problem Reports Closed On Time FRT4 = 80%

    The calculation of FRT4 is 100 * 16 / 20 = 80%.

    5.2.3 Effect of Customer Delay


    According to counting rule 5.2.4 b) 7) there are certain situations where delays can be excluded from the overall closure time and fix date can be adjusted. For example, if access to a site to fix a problem is denied for a certain period of time then the time the access is denied can be excluded. Suppose a major problem report is received on March 1 and that there is no service level agreement in place with the customer. In this case, according to 5.2.4 d) 1), the due date for fixing this major problem is March 31. On March 10, the supplier determines that they need access to the customers site to be able to fix the problem. On March 12, the customer tells them that they cant gain access to site until April 1. This is summarized in Table 5.2.3-1.

    Table 5.2.3-1 Effect of Customer Delay


    Event Major Problem Report Received Need for site access identified Customer informs site not available until April 1 Site Available Event Date March 1 March 10 March 12 April 1 Problem Closure Due Date March 31 March 31 Due date suspended April 18

    Copyright 2011 QuEST Forum Version 1.1

    FRT Examples 5.2-2

    Fix Response Time (FRT) Examples

    They may exclude the interval that access to the site was denied (March 12 through 31), which has the effect of moving the due date of the problem report from March 31 to April 18. If they fix the problem on or before April 18, then the problem was fixed on time. The problem report is therefore reported with the April data per counting rule 5.2.4 b) 4).

    5.2.4 Effect of Fix Deferral


    If the customer agrees, the delivery of a fix may be deferred such as waiting to deliver the fix in the next software release. In these cases, according to counting rule 5.2.4 b) 9), the interval between the time when the fix is identified and when it is delivered can be excluded for the overall fix response time. For example, suppose a major problem is reported on June 1 with a closure due date of July 1. The supplier fixes the problem on June 20 but the customer wants to defer delivery until the next major release of the software, which occurs on December 15. This situation is summarized in Table 5.2.4-1.

    Table 5.2.4-1 Effect of Fix Deferral


    Event Major Problem Report Received Fix deferred to Release R3.1 Release R3.1 Delivery Event Date June 1 June 20 Dec 15 Problem Closure Due Date July 1 Release R3.1 Delivery Dec 15

    The problem is due to be fixed in December and reported with in the December FRT data submission. It is not considered due nor reported in the preceding months of July through November. If Release R3.1 contains the fix to the problem report and the fix works, then the problem report is counted on time. If Release R3.1 does not fix the problem, then the problem report must be reported as due but not fixed in July. This will require a resubmission of the July data. Furthermore, it is now overdue and according to counting rule 5.3.4 b) 3) must be reported as overdue in all months from July through December and continuing until it is fixed. This also will require resubmission of the August through November data.

    5.2.5 Effect of Incomplete Fix


    A fix was delivered within the time required by an SLA. But at a later point in time if the customer rejects the fix as incomplete because it was ineffective or unusable or had some undesirable side effects caused by installation of the fix, then in these cases, according to counting rule 5.2.4 b) 3) the problem report shall be re-classified as open. All intervening time shall be included in determining on-time problem closures as if the fix had not been delivered. For example, suppose a major problem is reported on June 1 with a closure due date of June 3. The supplier fixes the problem on June 2, but later the customer rejects the fix on August 15. This situation is summarized in Table 5.2.5-1.

    Copyright 2011 QuEST Forum Version 1.1

    FRT Examples 5.2-3

    Fix Response Time (FRT) Examples

    Table 5.2.5-1 Effect of Incomplete Fix


    Event Major Problem Report Received Supplier provides the fix Customer rejects the fix Event Date June 1 June 2 Aug 15 Problem Closure Due Date June 3 June 3 June 3

    The problem is due to be fixed in June and reported in the June FRT data submission. On August 15 Customer finds that the problem is not completely fixed and rejects the fix, then the problem report must be reported as due but not fixed in June. This will require a resubmission of the June data. Furthermore, it is now overdue and according to counting rule 5.3.4 b) 2) must be reported as overdue in all months from June through August and continuing until it is fixed. This also will require OFR data resubmission of the June through August data.

    5.2.6 FRT Counting Aid


    According to counting rule 5.3.4 b) 4), for FRT, problem reports are counted once, ONLY in the month they are due and not in the month they are fixed or closed. Following table serves as a quick check for deciding whether to count a problem report for calculating FRT or not depending on various possible scenarios on timeliness of the fix in a given month (say July).

    Table 5.2.6-1 FRT Counting Summary Table


    Problem Report Scenario To be Counted in current month (July)? Due in the month and Closed before Closed in June, Due only Yes the month (early fix) in July Closed in the month and Due in Closed in July, Due only No future month (early fix) in August Due and Closed in the month on time Closed on July 20, Due Yes on July 20 (timely fix) Closed in the month and Due in Closed in July, Due in No previous month (late fix) June Due and Closed in the month but Closed on July 20, Due Yes after time (late fix) on July 18 Due in the month and still open Due on July 20 and still Yes Open Example

    Copyright 2011 QuEST Forum Version 1.1

    FRT Examples 5.2-4

    You might also like