Stop defaulting to Excel: iterate your hardware in Koddex, then release it to your PLM

In a recent article on Beyond PLM, Oleg Shilovitsky gave a name to a habit every hardware engineer knows: "usualing", choosing a tool because it is the usual one rather than the right one (read his article). His example is Excel for the bill of materials, and his question is worth asking in every engineering team: am I choosing this because it is the best tool for the job, or because it is what we always do?

We agree with the diagnosis. This article looks at where the habit comes from in hardware teams, and at the phase where it costs the most: iteration, the weeks and months before a design is mature enough to go into the PLM.

Excel is not the problem everywhere

Excel is a good tool for some jobs, and it is fair to say so:

• —A small, simple BOM that will not change much.
• —A one-off analysis or report.
• —Collecting data quickly before it goes into a proper system.

The trouble starts when the spreadsheet becomes the place where the product is designed: when several teams change it every day, when each change has effects on requirements, mass, cost and tests, and when the product must later prove its compliance in aerospace, medical or automotive.

Why teams fall back to Excel during iteration

Most hardware companies have a PLM, or plan to. So why does the BOM live in a spreadsheet for months?

Because a PLM is built for released data. It is very good at managing what has been decided: controlled parts, approved revisions, change orders, the configuration that goes to production and to the supplier. It is not built for the phase where the design changes ten times a week. Putting every early change through a formal change process slows the team down, so engineers do the iteration elsewhere, in the tool they already have open.

The result is a familiar pattern:

• —Copies everywhere. "BOM_v12_final_JD.xlsx" travels by email. Nobody is sure which version is the right one.
• —One person at a time. Design, certification and purchasing wait for each other instead of working in parallel.
• —No impact view. When a part changes, finding the requirements, tests and assemblies it touches means meetings and manual searches.
• —A painful hand-off. When the design is finally ready, someone re-types or re-imports the spreadsheet into the PLM, and the history of why each decision was made stays behind in the files.

The habit is not irrational. It fills a real gap between the whiteboard and the PLM. The question is whether a spreadsheet is the right tool to fill it.

What iteration actually needs

Iterating fast on a regulated hardware product needs a few things that neither a spreadsheet nor a release-oriented PLM gives you on its own:

1. 1.Structure from day one. The BOM is a tree of parts with attributes, linked to requirements and tests, not a flat list of rows.
2. 2.Live collaboration. Several teams change the same product at the same time, and everyone sees the same data.
3. 3.The impact of every change. When someone changes a part, the team sees right away which requirements, assemblies, mass and cost budgets are affected.
4. 4.Cheap revisions. Trying an option, comparing it and going back must not cost a change order.
5. 5.A clean exit. When the design is ready, the team freezes a baseline and hands it to the PLM with its history and its links.

Iterate in Koddex, release to your PLM

This is the role Koddex plays next to the PLM. Koddex is the AI engineering system for regulated hardware: the place where the team designs and iterates the product on structured, traced data. The PLM stays the system of record for released data. Koddex connects to it, and to your CAD and ERP, during integration through its API (integrations), so nothing is typed twice.

In practice, the iteration phase looks like this:

1. Start from your spreadsheet. Import the existing BOM into Koddex and give it a real structure: the product tree, the attributes that matter to you (mass, cost, supplier, status) and the links to requirements. At our reference customer, assembling a complex product structure takes 15 minutes in Koddex, instead of 2 to 3 days in Excel.

2. Iterate together, and see the impact of every change. Design, certification and purchasing work on the same data at the same time. When a part changes, Koddex shows what it affects (impact analysis): the requirements, the tests, the assemblies and the budgets that roll up from it. At our reference customer, an impact analysis takes one day instead of two weeks of meetings and spreadsheets, and the whole team sees it live.

3. Hand repetitive work to AI agents. Agents work as teammates inside your permissions: you assign them a task, such as checking requirement coverage or updating a test plan after a change, they propose the update and an engineer approves it. Every action is traced. On guided deployments, teams spend up to 50% less time on repetitive engineering tasks.

4. Freeze a baseline and release it to the PLM. When the design is ready, the team locks a baseline in Koddex: a frozen state of the product, with its revisions, its links and the reason for each decision. That baseline is what goes to the PLM for release. The PLM receives a clean, consistent configuration instead of a spreadsheet to re-type.

The two tools do what they are good at. Koddex covers the fast, collaborative and traced iteration. The PLM covers controlled release and production.

Five questions to ask your team

Before the next project starts in a spreadsheet, it is worth asking:

1. 1.How many copies of the BOM exist right now, and which one is the reference?
2. 2.When a part changes, how long does it take to know which requirements and tests it affects?
3. 3.Can design, certification and purchasing work on the product at the same time?
4. 4.When the design goes into the PLM, how much is re-typed by hand?
5. 5.If an auditor asks why a decision was made six months ago, where is the answer?

If the answers are uncomfortable, the team is probably "usualing", in Oleg Shilovitsky's word.

Conclusion

Excel is not going away, and it does not need to. But the iteration phase of a regulated hardware product is too important to live in files that nobody can trust. Iterating on structured, traced data, with the impact of every change visible and AI agents taking the repetitive work, and then releasing a clean baseline to the PLM, is how teams cut time to market without giving up control.

If you want to see it on a product like yours, book a 20-minute demo: we show one use case in Koddex, and your first use case is live within a month.