Attachment 0021 - Warranty SIC Parameter Requirements.docx

Distribution A- Unlimited; Distribution Approved for Public Release

Warranty Specific Issue Classification (SIC) Parameter Summary & Requirements

Overview:

In order to effectively leverage warranty data, a number of parameters must be logged and maintained in separate database fields, so that they can be parsed during trend analysis. The most important of these from a quality perspective (and crucial from other perspectives, as well) is the SIC parameter. This parameter provides an accurate and concise description of a given failure and is therefore absolutely vital for sorting warranty data.

Life Cycle of the SIC Parameter:

The SIC parameter, by nature, evolves. When an issue is first discovered, it is often known only by symptom. Throughout the root cause analysis phase of an issue’s life cycle, its classification can progresses from symptom through increasingly refined levels of intermediate cause, until the actual root cause has been isolated. The root cause has been reached when the problem can be turned on and off with a change in product or process.

Characteristic Requirements of the SIC Parameter:

Since the SIC parameter will be widely leveraged during data parsing to identify trends, the parameter must be sufficiently descriptive to support differentiation of one failure from the next, even when they are quite similar. For instance, one issue could involve A/C system failure due to a loss of refrigerant, caused by a burst hose. Another could also represent A/C system failure due to loss of refrigerant, but be driven by a leak in the high pressure switch. Though these share A/C system failure and loss of refrigerant, they diverge at the cause of the refrigerant loss. Early in their investigation, they would appear to be the same. So, they might share a common SIC. Further into problem solving, they would be proven different. Thus, their SICs would diverge.

A conflicting requirement of the SIC parameter is that it must be brief, in order to support effective charting and alternate data presentation. The bar chart serves as an effective example. If a given SIC is too long, the space consumed by the bar labels would be extreme and the space remaining for the bars themselves could become sufficiently small so as to reduce the visual resolution of their values.

Operational and Maintenance Requirements of the SIC Parameter:

Given the necessity for clear, accurate, and consistent SIC names, these names must be established at the origin of an issue and be maintained throughout the life cycle of each issue. When a warranty claim is initiated, all available information pertaining to the claim must be reviewed in order to assign an SIC. As root cause analysis of the issue progresses, the name must be updated each time the root cause is refined.

When naming or renaming an SIC, the chosen name must be compared to existing names, in order to standardize across analogous issues. Periodically (at least once per calendar quarter), a review of the overall collection of names must be performed, standardizing across the spectrum of SICs for the given program.

Ineffective Alternatives to the SIC Parameter:

Various ineffective alternatives have been attempted and/or proposed in lieu of the SIC parameter. e.g.:

Originator’s (open text field) Problem Description. This approach is faulty for a number of reasons. In particular, since an open text field is used for capturing the originator’s observations, inherent differentiation in verbiage between originators makes it impossible to sort by this parameter. A single character difference in descriptions (even an extra space, which is easily overlooked) causes two identical incidences to sort separately. Additionally, it is beneficial to encourage originators to log as much detail as possible regarding symptoms, attempted diagnosis and related information. Thus, attempting to constrain entries is counterproductive.

Causal Part. The causal part field has been attempted, as a substitute for the SIC. There are at least two primary deficiencies with using causal part. First of all, it is typically based on the part replaced. However, the part replaced is not always the cause. It can, instead, be the effect (i.e., a victim part). Additionally, causal part does not communicate the issue experienced by the part. The more complex a part is, the more failure modes it may possess. Causal part also suffers from poor readability and description, as well as excessive name length.

Drop Down Menu for Originator Problem Description. This approach has been proposed frequently, as a solution to the open field problem description format. It would be, however, impossible to list all the potential issue descriptions for the vehicle. Since a truck has thousands of different parts and each part can have multiple failure modes, the list supporting this approach would have an exorbitant number of entries. Once an initial list was constructed, it would still require maintenance as new issues are encountered. Even if a comprehensive list was constructed and maintained, the list owner would still need to read through the originator’s open text, in order to determine if the specific issue was properly assigned by the originator. Also, since a given originator has only a limited view of the spectrum of issues which have been encountered across the entire fleet of trucks and trailers, they are at a distinct disadvantage for properly naming various issues. As an additional obstacle, naming of an issue evolves with time, during root cause analysis. Thus, construction and maintenance of a drop down list would be impractical.

Naming Convention Requirements of the SIC Parameter:

In order to meet all associated functional requirements, it is imperative that SIC naming follow an established, consistent set of criteria. Experience has led to the criteria below, which shall be followed until such time as PdM MTV approves an alternate approach:

· Naming Structure. The name of a given SIC shall be composed of a sequential list of segments, which begins with the effected system (if applicable) and progresses through increasingly refined levels of cause.

· In most cases, a SIC name can be conveyed appropriately with just 2 segments, the system effected and the finest available level of cause (optimally, the root cause).

· These segments shall be delineated by a space, a hyphen, and another space (e.g., A/C - Hi Press Sens Leak).

· Capitalization shall be applied the same as to a title (i.e., each non-trivial word is capitalized), except that additional capitals may be applied as a means of abbreviation (ref. Abbreviations, below).

· Abbreviations. All portions of the name shall be abbreviated to the maximum extent possible, while still retaining an intuitive presentation of the item of interest.

· Acronyms and abbreviations (periods left out) are encouraged

· Industry conventions and well-known slang (such as “Trans” for Transmission) are allowed

· Creative forms of abbreviations are also allowed, as long as they enhance communication

· If the name begins to grow to excess, more severe abbreviation approaches may be incorporated, including adding capital letters and deleting spaces in unconventional manners; e.g.:

· A/C – High Pressure Sensor Leak

· A/C – Hi Press Sens Leak

· A/C – HPSens Leak

· Note that an acceptable length of naming for a given SIC is generally determined by the length of other SICs. For instance, if the maximum number of characters in the full collection of SIC names is 36, then there is no reason to sacrifice clarity on an SIC less than this to make it even shorter.

· On a specific case basis, if a given SIC is much longer than others being used as labels on the same bar chart, motivation is high to shorten that SIC, in order to directly increase the amount of display space available for chart graphics.

· First Naming Segment. The name of a given SIC shall begin with an indication of the effected system.

· Generic terms such as “Inop”, “Faulty”, or “Not Working” (which are already implied) shall not be associated with the system name, unless nothing more is known about the cause of the issue. Thus, “A/C Inop” would only be allowed if no level of cause were presently available.

· Descriptors conveying useful information are allowed. e.g., “Engine No Start - ...” or “Engine Rough Idle - ...” initially add a degree of value (reference Intermediate Naming Segments, below).

· Last Naming Segment. The name of the given SIC shall end with an indication of the most refined level of cause, to date. When root cause has been achieved, this portion of the name shall represent the root cause.

· Intermediate Naming Segment(s). Due to case-by-case variation, it is left to the discretion of the person managing the SICs whether intermediate levels of cause are removed from the name, once a more refined level of cause (or the root cause) have been achieved. Following are considerations to be evaluated:

· The shorter the name, the better, since long names consume more chart/display space.

· In most cases, intermediate causes add little, once a more refined level of cause has been identified.

· Examples of naming abbreviation without loss of information:

· A/C Not Working - Low Charge - Faulty Hose Crimp becomes A/C - Hose Crimp Leak

· ABS Faulty - Light On - ECU Inop - Connection Loose @ P184 becomes ABS - P184 Conn Loose

Warranty SIC Parameter Requirements - 150819d Page 3 of 3 Ronald J. Thomas