How Micius checks an equipment maker’s part numbers, field by field

A semiconductor equipment maker with a wide range of parts checks every new part number before the part is set up. A master-data engineer used to work down each list against the company’s coding rules, one code at a time, and a wrong code that slipped through ended up in BOMs, purchasing and inventory. Working with the company, Zhiman handed that first pass to Micius, its model. Engineers still decide what changes.

Challenge

A trip back to the rules for every code

The company’s part-numbering scheme lives in a set of spreadsheets: prefixes, what they mean, and the forms each category allows. Whenever a part was added or its master data changed, someone checked the new code against those sheets by hand. Each code needs five checks: category, form, field length, separators, and whether it repeats another code. The more categories a company has, the longer the rules get, and the more often a line is missed or misjudged. A wrong code becomes an error in BOMs, purchasing and inventory, and eventually rework on the master data itself.

The rules also keep moving. Categories are added and rules revised, and a checker who misses a change ends up checking codes against rules that no longer apply.

Rules

Reading the rules before checking anything

Micius works from two inputs: the company’s coding rules, which go into a knowledge base first, and each batch of part numbers to check. Here the rules set out four fields joined by hyphens, a category list, and a table of the materials each category allows.

The engineer asks Micius to read the rules, list them with sources, and then check a batch of 47 new part numbers. Micius pulls out which prefix maps to which category, which forms each category allows, and how long each field is and how fields are separated. It lists five rules, each citing where it came from: the code-structure section, the category list or the materials table. It also lays out which materials each of the five categories allows. Where the table has no row for a category yet, Micius flags the gap instead of guessing.

MiciusCoding rules · listing the checksKnowledge base

What are the coding rules in this spec? Cite where each comes from.

Reading the coding rules…

Read: part-number coding rules · 4 sections

From the coding rules, five rules apply to every part number. Each one cites the section it comes from:

Rules extracted

Each cites its source in the spec

1. 01Four fields joined by “-”: category-material-spec-serial⁠1
2. 02Category: two capital letters, from the category list⁠2
3. 03Material: one the category allows⁠3
4. 04Spec: exactly four letters or digits⁠1
5. 05Serial: four digits, no repeats within a batch⁠1

⁠1 §1 Code structure⁠2 §2 Category list⁠3 §3 Category-material table

Which materials each category allows

From the category-material table (no HT row yet)⁠3

SSALCUPKCE

VCVacuum

GSGas line

MCMachined

ELElectrical

FXFasteners

SS stainless · AL aluminium · CU copper · PK PEEK · CE ceramic

Done5 rules, each traceable to its source in the spec.

An engineer checks the five rules against the original, and only then are they used on a batch. Engineers can also ask what a prefix stands for, or have rules scattered across several sheets rebuilt as one table. Micius runs inside the company’s own network, so the rules and the part data stay there.

Check

47 codes, each failure explained

When new parts are added or master data changes, the engineer uploads the list or pastes the codes into the chat. Micius splits each code into its fields, checks each field against the rules, then checks the batch for repeats.

Its answer opens with a summary. Of the 47 codes, 41 pass, 5 fail and 1 is undecided. Two failures use a material their category doesn’t allow, one spec is a character short, one code is missing a separator, and one serial repeats an earlier line. Row 36 belongs to a category with no row in the materials table yet, so Micius sets it aside for a person.

The engineer can ask about any line. Take row 07: category, spec and serial are fine, but the material isn’t one that vacuum parts allow. Micius shows which rule each field was checked against and where that rule is written, and suggests confirming what the part actually is before deciding which field to change. It then suggests which of the five failures to fix first, starting with structural errors, since nothing else can be checked until a code splits cleanly into its fields. If the list already carries a person’s verdicts, Micius compares them line by line and flags any disagreement.

MiciusRow 07 · why it failsField by field

Row 07 · field by field

Why it fails

VCcategory-PKmaterial-K040spec-0213serial

• Category VC: vacuum parts; on the category list⁠2
• Material PK: vacuum parts allow only SS, AL or CU⁠3
• Spec K040: four characters⁠1
• Serial 0213: no repeat in this batch⁠1

ConclusionOnly the material field fails. First confirm the part really is a vacuum part, then decide whether the material or the category should change.

Suggested order of fixes

5 failing lines in this batch

1. 01Structure1 · row 23Add the missing “-” first: until the code splits, nothing else can be checked⁠1
2. 02Material vs category2 · rows 07, 40Confirm what each part is before changing the code⁠3
3. 03Spec length1 · row 19Make the spec four characters⁠1
4. 04Repeated serial1 · row 31Give it a new serial⁠1

For you to confirm

Row 36: HT is on the category list, but the category-material table has no row for it. Is CE allowed? Please confirm, or add HT to the table first.

Which category a part belongs to, and how its code should change, depends on what the part is, so that decision stays with an engineer. Micius can be wrong too, which is why every finding cites its rule. When a finding looks off, the engineer can follow the source to see why.

Results

Engineers start from the summary

With Micius doing the first pass, master-data engineers can start from its summary instead of the rules and spend their time on the few codes that fail or that it couldn’t decide. Zhiman estimates that routine work for material master-data engineers can be cut by more than 55%. Zhiman puts the check accuracy of Micius at 98% or higher.

When a rule is revised or added, the check runs against the current rules as long as the spec itself is kept up to date. Keeping up takes no development project each time. Next, the two teams plan to move the check upstream, to the point where codes are created in PLM and ERP. A failing code would then be stopped before it reaches BOMs, purchasing or inventory.

What stays with people are the questions only they can answer: which category a part really belongs to, and where the rules have a gap that needs writing.