Git vs PDM vs PLM: Choosing by Model, Not by Feature List

Comparisons of hardware data tools usually turn into feature lists, which is the least useful way to choose one. Features are easy to add and hard to evaluate. What actually determines whether a system fits is older and simpler: what is the unit it thinks in?

Everything else follows from that. A system organised around files answers file questions well and part questions badly, no matter how many part-shaped features are bolted on.

So here are four models, by their unit.

Four models

Files and folders. The unit is a file. Questions about files are trivial; questions about anything else are a manual search. Every project starts here and many never need to leave.

Git and similar. The unit is still a file, plus a history of states. It adds authorship, exact recovery of past states and parallel work. It remains a file system in its model of the world.

PDM — product data management. The unit is an item: a part, an assembly, a document, each with revisions and relationships. It can answer "where is this part used?" and "what is this assembly made of?" because those are questions about items, which is what it stores.

PLM — product lifecycle management. The unit is still an item, but the system also models processes around it: change requests, approvals, effectivity, sometimes manufacturing and supply chain. It is PDM plus workflow, and the workflow is most of the cost.

The progression is not a ranking. It is an increase in what the system knows about, paid for with setup, administration and rigidity.

Which questions each one answers naturally

"Naturally" means without a manual search or a convention that someone has to remember.

Read the last row with the others. A PLM answers more questions than anything else in the table, and that is exactly why it is the wrong choice for a team that does not have those questions yet.

Cost is not only money

The visible cost is licences. The invisible costs decide whether the thing survives contact with a real team.

Setup. Item numbering, categories, permissions, workflow definitions. An item-based system needs decisions made before it is useful, and those decisions are hard to change later.

Administration. Someone owns the system. In a small company that someone is an engineer who would rather be designing.

Friction per change. If logging a change takes fifteen minutes, people stop logging changes, and the data quietly becomes fiction. This is the most common failure mode of an over-specified system, and it is worse than having no system at all, because people trust it.

Exit cost. How hard is it to get your data out in a usable form? Worth asking before going in, not after.

Of those four, friction is the one that decides outcomes, and it is the one nobody evaluates during a trial. A trial is run by the person who chose the tool, on a clean project, with no deadline. The real test is whether an engineer with a board due on Friday still records a substitution properly at six in the evening, and no demonstration answers that. If you can, ask a company your own size what they stopped doing after the first year.

A decision path

Rather than a matrix, a sequence of questions. Stop at the first one where you recognise yourself.

Are you one person on one product, with releases that are rare? Folders and a written release procedure. Genuinely. Add Git when the history starts to matter.

Do you lose work, or argue about which file is current? Git, for the design source. It solves exactly that, and it costs an afternoon.

Do you reuse components across several boards, and does a part change mean checking every project by hand? You have outgrown file-based tools. The question "where is this used?" cannot be answered by any system whose unit is a file. This is the moment a component-and-BOM system starts paying for itself.

Do you need formal approvals, effectivity dates, and an auditable change process because a customer or a regulator requires it? That is PLM territory, and the workflow engine is the thing you are buying.

Does the change process span purchasing, production planning and costing? Then the question is an ERP question as much as an engineering one, and the engineering tool has to interoperate rather than compete.

Most teams reading this are at step three and reaching for step four, which is the expensive mistake in this field: buying process machinery to solve a data problem.

Where XKEMA sits, and where it does not

XKEMA is in the third band: component, BOM and configuration data with versioning. Being specific about the edges is more useful than a feature list.

What it does. Components as shared records referenced by the boards that use them. Boards, BOMs, documents and PCB data stored as versions with an author, a date and an explicit link to the previous version. A review step before a revision is closed, with a recorded signature. Comparison between two versions of a BOM or a manufacturing package. Once a revision is closed it is closed: changing it means creating a new version.

What it does not do. It does not store native ECAD design files — your schematic and layout sources belong in Git or in your ECAD vendor's own system, and this article is not an argument for moving them. It is not a PLM: there is no change-request workflow engine, no effectivity calendar, no costing, no supply-chain module. It does not track individual manufactured units; it records what a revision contained, not which revision a particular serial-numbered unit was built from.

If you need the things in that second paragraph, a PLM is the honest answer, and it will serve you better than a lighter tool stretched past its design.

The useful question is not which model is best. It is which questions you are currently answering by hand, and how often.

ECAD, ERP and XKEMA Git and KiCad: what to version Hardware configuration management When does a project outgrow a spreadsheet?