top of page

Reliable Performance Data

⏤measure what matters

 

Enterprise Reporting and Strategic KPI Thresholds

KPI thresholds are strategically established by leadership for each department. When performance is below the KPI threshold value, an alert is submitted to the improvement portfolio manager for consideration to launch an improvement project. Strategic KPIs launch improvement initiatives to take actionengaging people at all levels in solving problems, improving processes and achieving measurable business value.

Mm_pillar_1_data.png

 

Structured Problem Code Lists

Problem codes are critical for accurately measuring internal and external problems to assess product and process performance. A strategic, structured approach to Problem Code Lists includes:

  • Problem Code Naming Convention

    • Aligned

      • Internal:

        • Design/customer terminology (attribute measured, specification)

        • BOM (assembly, component)

        • Reporting requirements (problem, defect, failure)

      • External: Industry terminology (e.g., IMDRF Adverse Event Terminology > problem codes, component codes)

    • Component-levelto identify specific components that fail

    • Discrete Values

      • eliminate "synonym data fragmentation"

      • avoid: crack, cracked, cracking, etc.

    • Concisefor intuitive simplicity

Alignment with Engineering Design & Customer Reporting Terminology

Problem codes and terms for products should be aligned with engineering design and customer requirements. By establishing alignment, communication of problems is simplified throughout the product lifecycle. Additionally, reports that rely upon Problem Code Lists can be automated in compliance with customer reporting formats and requirements.

80-20 "Pareto Principle" Approach

The 80-20 “Pareto Principle” approach produces a more concise Problem Code List to improve data entry reliability while keeping the focus on high impact problems.

  • Named Problem CodesProblems that contribute to the top 80% of problem quantities. These are the "top problems" that need visibility and consideration for appropriate corrective action. To promote data integrity and reliable reporting, Named Problem Codes are captured using a drop-down selection field in the data entry form.

  • OTHER (Add description)Problems that do not have a listed "Named Problem Code" are entered as "OTHER (Add description)" and require a description to be entered. OTHER (Add description) captures the lower 20% of problem quantities. OTHER (Add description) also provided better tracking and visibility of "new" problem types discovered during new product design releases.

"Today, organizations need to use the Pareto Principle to help them separate

the “vital few” problems from the “useful many.”"Dr. Joseph M. Juran

Eliminate "Synonym Data Fragmentation"

Synonyms in Problem Code Lists cause data fragmentation that results in poor data integrity, including:

  • Data Entry

    • Confusing Choices

      • Problem code synonyms > Data Entry Representative: “Wow, several of these problem codes are similar…which similar code should I select?"

    • Too Many Choices

      • Data Entry Representative: “Wow, this is a long list of problem codes…how do they expect me to enter this accurately?"

  • Reporting

    • Problem quantities are understated—Problem quantities are understated since failures for a specific issue are fragmented across multiple synonymous failure codes rather than one code for the specific failure. Synonym data fragmentation leads to poor visibility and inaccurate measurement of internal and external failures.​

      • Avoid multiple synonymous codes for same problem: crack, cracked, splintered, fractured, broken, etc.

    • Corrective Action—Assessing “appropriate” corrective actions is unreliable…problems that adversely impact customer and company can easily go unnoticed. (Quality Engineer: “Wow, I just noticed our problem codes are loaded with synonyms…I wonder how many of these components actually failed for this issue?)

    • Design Engineering Feedback—Design Engineering receives unreliable feedback regarding product performance. (Design Engineer: “Wow, I just noticed our problem codes are loaded with synonyms…It seems our designs haven’t been performing as well as we thought they were?)​​

Problem Origination Source| Strategy for Continuous Process Monitoring 

Once a reliable Structured Problem Code List is established, each unique Problem Code can be assigned a Problem Origination Source. The Failure Origination Source is the most likely process where the failure may have originated. Each department (Problem Origination Source) can view reports on their specific problem performance. Examples include:

Administration of Problem Code Lists

Each product type should have an associated "Problem Code List" which is centrally administered (typically by the Quality department). Business is dynamic—new products, new suppliers, process changes, old problems solved. To sustain optimal data integrity, Problem Code Lists should be periodically reviewed and updated to reflect current products/processes and sustain the 80-20 "Pareto Principle" approach.

  • Data captured in the "OTHER" category—look for:

    • Named Problem Codes incorrectly assigned as "OTHER".

    • High risk problems that should be "promoted" to a Named Problem Code.

    • Problems that should immediately be considered for appropriate corrective action (e.g., a single significant incident).

  • Training for Data Entry

    • Data entry representatives should be trained when updates to Problem Code Lists are rolled out.​ Most all employees are involved (directly or indirectly) in customer-facing roles that involve problem capture and resolution—customer service, sales, social media, complaint handling, problem solving—this can be a large group of data entry representatives!

Business Benefits

Structured Problem Code Lists enable accurate measurement of internal and external failures—critical information for assessing business impact (financial and risk). Organizations guided by accurate and timely failure code data are better positioned to focus resources on high-value strategic improvements aligned with customer and business priorities.

  • Cost Reduction | Accurate performance data to quantify problems facilitates reliable measurement of the cost of problems (Actual# of failure occurrences x Cost per occurrence). Visualizing the cost of each type of problem provides an informed, data-driven basis to establish a business case for assigning resources to fix the problem, prevent/reduce occurrences and achieve cost reduction.

  • Risk Reduction | Discrete and intuitive problem codes improve performance data accuracy to improve ability to detect problems. Risk is reduced when problems are easier to detect.

  • Design and Process Optimization | Accurate performance data feedback identifying the likely Problem Origination Source can assist business process owners to drive timely and effective continuous process improvement.

Digital Architecture

Your IT framework should not be a black box—data architecture should be structured in a way to make data flow effectively and efficiently to meet business needs.

  • Is your data managed in a way that enables visibility for informed and proactive decision making?

  • Have you performed a 5S lean analysis of your IT framework & business dataflow architecture?

80-20 Pareto-Failure Codes.png
Component Code
Problem Code
Problem Origination Source
Notes
Mechanical-Wire Harness
Connection Failure
Assembly
Identify root cause of connection failures.
Raw Material-Stainless Steel-Grade 304
Hardness
Supply Chain
Supplier material did not meet required hardness specifications.
Software-Keypad
Calculation Error
Design
Design can investigate/resolve root cause of software error.
Shipping
Wrong Address
Order Entry
Identify order entry problems
Mechanical-Bushing
Excessive Wearing
Design
Design can consider improvements (new material, lubricants, etc.)
bottom of page