Analyzing Quality Inspection Failures with Failure Analysis

The Failure Analysis tool in Quality Inspector helps identify patterns across failed quality inspections. It summarizes historical failures by factors such as vendor, item, measurement, production work center, item attributes, BOM components, and when the failure occurred.

This can help answer questions such as:

• Are failures occurring more frequently for a particular vendor?
• Is one item responsible for a disproportionate number of failures?
• Is the same measurement repeatedly causing tests to fail?
• Do production failures have a common work center?
• Do failing manufactured items share particular components or item attributes?
• Are failures more common on a particular day or production shift?

Failure Analysis is intended as a simple investigative tool. It can be useful when investigating nonconformances or determining possible cause and consequence patterns, but it does not itself perform root-cause analysis or establish that one of these relationships caused the failure.

What Tests Are Included?

Failure Analysis analyzes failed tests.

A test is considered failed for analysis when its Grade Category is Not Acceptable. Tests with acceptable grades are not included in the failure counts.

You can further restrict which tests are analyzed using the filters at the top of the Failure Analysis page.

Running Failure Analysis

Search for and open Failure Analysis in Business Central.

1. Select the tests to analyze

Configure the filters at the top of the page.

Template Code

Select a Quality Inspector template to limit the analysis to tests created from that template.

When you select a Template Code, Quality Inspector updates the underlying Test Filter accordingly.

Only Finished

Enable Only Finished when you want to analyze completed inspections only.

This adds a Status=Finished filter to the Test Filter.

For most historical failure analysis, enabling Only Finished is recommended so incomplete tests do not become part of the analysis population.

Test Filter

Use Test Filter when you need more precise control over the tests included in the analysis.

The Test Filter is a Business Central table view filter applied directly to the Quality Inspector Test records. Use the assist-edit button beside the field to build the filter rather than manually entering the view syntax.

You can use this to restrict the analysis by criteria such as a date range or other fields available on the Quality Inspector Test.

If you select a Template Code or Finished status through the filter builder, Quality Inspector also updates the corresponding Template Code and Only Finished fields where applicable.

2. Set the Failure Threshold

The Failure Threshold determines the minimum number of occurrences required before a pattern is displayed.

For example:

• A threshold of 1 shows patterns that occurred at least once.
• A threshold of 2 hides patterns that occurred only once.
• A higher threshold can be useful when analyzing a large history where isolated failures would otherwise create excessive noise.

The threshold is applied before the final results and Pareto classifications are calculated.

3. Choose what to analyze

Select the relationships that are useful for your investigation.

Depending on the type of test and source record, Failure Analysis can analyze:

• Vendor – identifies failures associated with a vendor, such as inspections generated from purchasing activity.
• Item – groups failures by the item being received or produced.
• Measurement – identifies the individual Quality Inspector measurement associated with the failure.
• Date – groups failures by day of the week and, where production shifts are configured, by shift.
• Work Center – identifies production failures associated with a common work center.
• Item Attributes – identifies attributes shared by items involved in failures.
• BOM Components – identifies common components used by manufactured items involved in failures.

Not every relationship is available for every type of inspection. For example, vendor analysis is most useful for purchasing-related inspections, while work center and BOM analysis apply to production scenarios.

4. Choose Analyze

Select Analyze to rebuild the Failure Analysis results using the current filters and analysis options.

Understanding the Results

Each result represents a pattern found among the failed tests.

Category

The Category identifies the type of relationship found, such as Vendor, Item, Measurement, Attribute, or Day Details.

Summary

The Summary identifies the value responsible for that row.

Examples include:

• A vendor
• An item and variant
• A measurement description
• Color = Blue for an item attribute
• Monday
• Monday (Night Shift) when production shifts are available

Failure Count

Failure Count shows how many analyzed failed tests matched that pattern.

For example, if three failed inspections were all associated with the same vendor, the vendor row has a Failure Count of 3.

% of Total Failures

% of Total Failures compares the Failure Count with the total number of failed tests being analyzed.

For example, suppose there are three failed tests:

• Vendor A appears in all 3: 100%
• Measurement A failed in 2: 66.67%
• Measurement B failed in 1: 33.33%

This percentage should be interpreted independently for each pattern. It is not expected that all rows or all categories add up to 100%.

A single failed test can contribute to several analysis rows. It might simultaneously be associated with a vendor, item, weekday, attribute, and measurement.

A test can also contribute to more than one Measurement result when multiple measurements contribute to the failure. Because the percentage still uses failed tests as its denominator, measurement percentages can collectively exceed 100%.

First Occurrence and Last Occurrence

These fields show the earliest and most recent occurrence of the pattern within the analyzed failures.

They can help distinguish between an isolated historical problem and something that is continuing to occur.

Days Since Last

Days Since Last shows how many days have passed between the most recent occurrence and the current Business Central Work Date.

For example, if the last occurrence was seven days before the Work Date, Days Since Last displays 7.

This can be useful for determining whether a recurring problem has happened recently.

Using Pareto Results

Failure Analysis also applies a Pareto classification to the remaining results after the Failure Threshold has been applied.

Pareto analysis can help focus attention on the relatively small number of recurring patterns responsible for much of the observed failure activity.

Use it as an investigative prioritization tool rather than an indication of causation.

Results are sorted by Failure Count, from highest to lowest, when determining the Pareto grouping.

Note: When multiple patterns have exactly the same Failure Count, their relative ordering is not guaranteed. As a result, patterns tied at the point where the Top 80% boundary is reached may not always receive the same Pareto classification between analyses.

Investigating the Tests Behind a Result

Failure Analysis is most useful when you move from the summarized pattern back to the individual inspections.

Select a result and either:

• Drill down on Failure Count, or
• Select Show Details.

Quality Inspector opens the Analyze Fail Details page showing the failed tests contributing to that specific result.

You can then review information such as:

• Test number
• Retest number
• Source item
• Lot number
• Other information from the originating inspection

For example, if a Measurement row shows 18 failures, Show Details lets you examine those 18 inspections and determine whether they have other characteristics in common.

Opening the Related Record

For analysis categories associated with a Business Central or Quality Inspector record, select Open Related Record.

Examples include:

• A Vendor result opens the related Vendor.
• An Item result opens the related Item.
• A Measurement result opens the related Quality Inspector Field.

Some analytical categories, such as a day-of-week result, do not have a related master record and therefore do not have a meaningful record to open.

Example: Investigating Receiving Failures

Suppose you receive the same item from multiple vendors and have noticed an increasing number of inspection failures.

Configure Failure Analysis with:

• Only Finished enabled
• The appropriate Template Code
• A suitable date filter
• Analyze Vendor
• Analyze Item
• Analyze Measure
• Analyze Date

After selecting Analyze, you might see results similar to:

Category	Summary	Failure Count	% of Total Failures
Vendor	Vendor B	12	80%
Item	ITEM-1000	15	100%
Measurement	Surface Finish	9	60%
Measurement	Diameter	4	26.67%
Day Details	Monday	7	46.67%

These results do not prove that Vendor B caused the Surface Finish failures. They do, however, give the quality team a useful starting point.

You could drill into Vendor B, Surface Finish, and Monday to determine whether the same tests occur in several of those groups and whether another common factor explains the failures.

Analyzing Item Attributes

Item attributes can be particularly useful when different item numbers share a meaningful characteristic.

For example, several items may have:

• Material = Stainless Steel
• Product Family = Outdoor
• Color = Blue

Enable Analyze Item Attributes to include these relationships.

If three failed tests involve items with the attribute Color = Blue, Failure Analysis creates a result similar to:

Attribute: Color = Blue – Failure Count: 3

You can then drill into the result to review the contributing failed tests.

This can reveal patterns that would be difficult to notice when examining individual item numbers.

Using Failure Analysis with Nonconformances

Failure Analysis can complement Quality Inspector’s nonconformance processes.

A nonconformance typically records and manages a specific quality problem. Failure Analysis instead looks across multiple historical failed inspections to identify recurring relationships.

For example, an NCR investigation may indicate repeated dimensional failures. Failure Analysis can help determine whether those failures commonly involve:

• The same vendor
• The same item
• The same measurement
• A common item attribute
• A particular production work center
• A common BOM component
• A particular weekday or production shift

These patterns can provide additional evidence when investigating the cause, consequences, and corrective action associated with a nonconformance.

Recommended Practices

When first using Failure Analysis:

1. Start with Only Finished enabled.
2. Select a specific Template Code or otherwise restrict the Test Filter to a meaningful population of tests.
3. Begin with a Failure Threshold of 1 to understand the available data.
4. Select only the analysis categories relevant to the business process being investigated.
5. Increase the Failure Threshold when isolated failures create too much noise.
6. Use Show Details to verify the individual tests behind an interesting pattern.
7. Treat correlations as investigation leads rather than proof of root cause.

Failure Analysis is intentionally a simple pattern-detection tool. Its value is in quickly turning a collection of individual inspection failures into a manageable set of relationships that quality teams can investigate further.