PLM analysis written to be used.
Working papers on the parts of PLM that decide whether a programme succeeds — sequencing a roadmap, computing ROI you can defend to a CFO, choosing between platforms and designing for the decade after go-live. Each piece is structured to be worked through, with the assumptions and the arithmetic left visible so you can substitute your own numbers.
- 25 min readWhite Paper
Released is permanent and the reasons for it are not
A transition is an event, so once it has happened it cannot become untrue. An approval is not an event — it is a conditional commitment whose conditions are almost never written down, so when one of them changes the item stays Released while the grounds for releasing it have gone. A state machine can hold only the first of those two facts. A white paper on the primitive PLM never had, with counts from a vendor-shipped configuration, a mechanism borrowed from 1979 and a short story about a Thursday.
- 8 min readWhite Paper
Your PLM already knows what to test
PLM test suites are written by hand from memory, go stale the moment the configuration changes and are the first thing cut when an upgrade runs late. But the configuration is the specification — item types, lifecycles, workflows and permissions already describe every behaviour the system promises. A white paper on deriving the regression suite from the system itself rather than writing it.
- 8 min readWhite Paper
The attribution gap: your database cannot tell you who did it
A PLM connects to its database under one service account, so every user in the system arrives at SQL wearing the same name. The application layer knows who you are and the database layer does not, which makes every database-level diagnostic — deadlocks, blocking, runaway queries — anonymous by construction. A white paper on the identity that is lost at the connection boundary and how to get it back.
- 9 min readWhite Paper
Your backup restores a PLM that never existed
A PLM is not one system. It is a database, one or more file vaults and a configuration and they are almost always backed up by different tools on different schedules. Restore them and you get a system in a state that never existed in production: records pointing at files that are not there and files belonging to records that do not. A white paper on restore consistency, why backup success says nothing about it and how to test the only thing that matters.
- 7 min readWhite Paper
Your vault replica crossed a border and nobody filed anything
Vault replication is specified by infrastructure teams as a performance and availability feature. But a replica in another country is a copy of controlled technical data in another jurisdiction, created automatically, with no human decision and no record. A white paper on replication as a disclosure event, why the controls that exist do not see it and what a defensible design looks like.
- 16 min readWhite Paper
Who downloaded that drawing? Why PLM audits the item and loses the file
Every PLM platform advertises a full audit trail and every one of them means change history — who approved which revision. Almost none of them can reliably tell you who took a copy of the file. That gap is architectural: a download is not a server event, it is a file-server transaction outside the business layer. A white paper on why file egress is hard to audit, a mind map of the paths a file actually leaves by, how the major platforms implement it and what a defensible log must contain.
- 12 min readWhite Paper
The code boundary: what an AI agent can and cannot change in your PLM
Every PLM platform is configurable. The question nobody asks is configurable to what depth — and every platform has a line past which change stops being data and becomes code that must be compiled, deployed and restarted. That line decides whether an AI agent can extend your PLM or only decorate it. On one major platform the line does not exist and this paper is about what that makes possible.
- 13 min readWhite Paper
The missing dimension: PLM records what changed and when, never why
Every PLM platform stores the what (parts, revisions, structures) and the when (effectivity). None of them stores the why. Design-rationale capture was tried thirty years ago and failed, because it cost engineers effort and nothing could use the result. Both of those constraints have just disappeared. A white paper proposing intent as a first-class PLM object, the data model, what it enables and the honest reasons it might not work.
- 6 min readCAD Data Management
CAD data management: the problem is the references, not the files
Managing CAD in PLM looks like a file-storage problem and is actually a graph-integrity problem. Why check-in/check-out is the easy part, where CAD-PLM integrations really break and how to tie a CAD revision to a part revision without creating two versions of the truth.
- 7 min readEffectivity
Effectivity and variants: where PLM stops being a filing cabinet
A BOM is not one thing. It changes over time and across variants and effectivity is how you say which version applies when, where and to which unit — without cloning the structure. The choice between date, serial and option effectivity and the clone-and-edit trap that quietly destroys traceability.
- 11 min readAccess Control
Access control across Aras, Windchill, Teamcenter and 3DEXPERIENCE: one question explains it
Supplier access to part of an assembly, two projects sharing a sub-assembly, external IAM, state-dependent permissions — four hard scenarios, four platforms. They all reduce to one question: does access attach to the item or to the container the item lives in? The answer predicts which scenarios are native and which need a module.
- 6 min readAras Innovator
Running an Aras upgrade: what the subscription does and the half that is still yours
Aras performs the upgrade for you — all the labour, your customisations carried forward, as part of the subscription. That is a genuine structural advantage. It is also not the same as zero effort. A practitioner playbook for the half of an Aras upgrade you still own and the one thing that quietly derails it.
- 6 min readData Migration
PLM data migration: the estimate is wrong and here is why
Data migration is the line item most often underestimated in a PLM programme and the one that sinks it. What the public record shows about how badly estimates miss, the four decisions that determine the real cost and a method for finding out before you commit.
- 5 min readAdoption
Why people bypass your PLM and what the workarounds are telling you
Every PLM deployment has a shadow system: spreadsheets, shared folders, a chat group where the real decisions happen. Treating that as an adoption problem is the standard mistake. It is a specification, written by your users, of what the system fails to do.
- 4 min readBOM
Your BOM and your ERP disagree. Here is how to find out which one is wrong
Every manufacturer discovers their engineering BOM and their ERP BOM have drifted apart. The instinct is to reconcile the differences. The better move is to find out why they drift, because the mechanism tells you which system is lying and what to fix so it stops.
- 4 min readEngineering Change
The engineering change process, minus the theatre
Most change workflows are modelled on the org chart rather than on who holds the decision, which is why they stall. How to tell a real approval from a ceremonial one and how to design a process people follow instead of route around.
- 4 min readPLM Administration
You have inherited someone else's PLM. What to do in the first 90 days
Taking over a PLM implementation you did not build is a specific job with a specific failure mode: changing things before you understand why they are that way. A 90-day sequence for working out what you have, what is load-bearing and what to fix first.
- 5 min readPermissions
Designing PLM permissions people do not route around
Access control fails in one of two directions: too loose and it protects nothing, too tight and people email the file instead. A method for designing permissions from the questions the business actually asks and the four rules that keep a model maintainable after the consultants leave.
- 5 min readPlatform Selection
What a PLM proof of concept should actually test
Vendor demos are optimised and prove nothing about your situation. A proof of concept run on your own worst data, with a fixed pass mark agreed in advance, is the only selection instrument that cannot be gamed — and most organisations run it wrong in three specific ways.
- 4 min readPart Numbering
Part numbering: have the argument once, then never again
Intelligent or non-significant numbering is the cheapest argument in PLM to have early and the most expensive to reopen late. A short case for non-significant numbers, the three objections that always come up and what to do when you have inherited a scheme you cannot change.
- 14 min readAras
Why Aras has the stronger mid-market case than Windchill
For a discrete manufacturer of 200–300 users with modest CAD complexity and a lean IT function, Aras Innovator offers stronger lifecycle economics than PTC Windchill across change, upgrades, administration and access control. The case becomes stronger when Aras is already the incumbent.
- 6 min readPlatform Selection
Comparing Aras, Teamcenter, Windchill and 3DEXPERIENCE without the vendor deck
The four major platforms differ less in features than in the shape of the commitment they ask for. A comparison on architecture, upgrade cost, customisation model and exit — with the questions each vendor would rather you did not ask.
- 5 min readRoadmap
Sequencing a PLM roadmap: what to do first and what to refuse
Most PLM programmes fail on ordering, not on tooling. A dependency-first sequencing method, the four phases that survive contact with reality and the three requests you should decline in year one.
- 5 min readROI
The PLM business case your CFO will actually sign
Most PLM business cases die because they promise productivity. Finance does not buy productivity. Here is the arithmetic that survives a CFO review and the three numbers you already have but are not using.