Engineering First: How we think about PLM implementation
There's a question we ask every organization we work with before we touch a single configuration setting in Teamcenter: How does a product actually get made here?
Not how it gets sold. Not how it gets invoiced. How does an idea become a design, a design become a released part, and a released part become something a customer can hold in their hands?
That question, along with the time we spend truly answering it, forms the foundation of everything we do.
The system should follow the process
We believe that enterprise software exists to support the way people work, not to define or over-constrain it. This sounds obvious, but in practice it's easy to get backwards. When implementation begins before the underlying process is understood, the software starts making decisions that belong to the organization. Data structures get locked in. Workflow assumptions get baked into configuration. Those decisions, made early and often without full context, become constraints that are expensive to undo.
Teamcenter is where your product comes into existence. It's where parts are created, designs are validated, changes are approved, and released data flows downstream into every other system that touches your product. When that environment is configured thoughtfully, it is built around how your engineering organization works on a daily basis. This results in everything downstream getting cleaner. BOMs are accurate. Changes move through the right hands. Integrations with ERP and manufacturing systems have something solid to connect to.
When these decisions are made too early or without full context, the impact isn’t felt right away. Instead, it shows up later as rework, manual intervention, and constrained options when the business needs to respond. This friction compounds quietly for years.
The sequence determines what the systems inherit.
A common sequence worth examining
Many organizations establish their ERP or MES environment before their PLM system is fully in place. There are understandable reasons for this. Financial systems carry compliance obligations, manufacturing execution has immediate operational urgency, and the pressure to get those systems running is real and legitimate.
What we've observed, though, is that those implementations inevitably make assumptions about product data. An ERP system needs to know how parts are numbered, how BOMs are structured, how changes get communicated. An MES needs to know what a work order looks like and where released manufacturing data comes from.
When the engineering definition isn’t yet fully articulated, those assumptions still have to be made in order to keep programs moving, and they are often folded into configuration decisions.
By the time Teamcenter enters the picture, it's often inheriting a product data model that someone else designed, for a different purpose, under different constraints. The engineering system then has to conform rather than lead. The result isn't usually a failure; the systems work, but there's a persistent friction that is difficult to trace back to its source and expensive to fully resolve.
We don't think there's always a way to avoid this sequence. But we do think it's worth naming clearly, so that organizations going through it can be deliberate about which decisions get made where, and by whom.
Engineering-first defines structure, performance, and constraints before design decisions lock in risk.
What We Start With
For us, “Engineering First” is less a doctrine than a risk-management approach: making sure the most consequential product decisions are made with enough context before they become difficult to change.
Who creates parts in your organization, and what information do they need to capture? What does a change order represent, and who has authority over it? How do you manage product configuration across a family of variants? What does "Released", “Approved” or “Prototype” mean, and what happens the moment something achieves a specified status?
These aren't questions with universal answers. Every organization has developed their own logic, usually over many years, often with good reasons that aren't written down anywhere. Our job is to understand that logic before we recommend anything.
Once we have that picture, the Teamcenter implementation follows from it. Vault structure, workflow configuration, BOM management, and integration architecture are all tailored to the engineering process we mapped out together, rather than a one-size-fits-all approach.
The Rodin Cars Teamcenter engagement is a good illustration of this in practice. Rodin builds safety-critical, high-performance race cars where a single bracket may interface with suspension geometry, aerodynamic loads, and carbon manufacturing constraints. Before any configuration began, Sherpa conducted a series of workshops to understand exactly how Rodin's engineering organization operated (their processes, data, team structure, and what they needed Teamcenter to accomplish). That foundation shaped everything: a custom data model, an intelligent part numbering system built around how Rodin's engineers think about vehicle architecture, and an NX environment standardized across every workstation. The result wasn't a generic PLM deployment. It was a system that reflected the way Rodin works.
A Rodin Cars assembly technician under the hood of the Sintura prototype race car.
Read the full case study Building Rodin Cars’ Digital Engineering Backbone
Notably, the ERP integration took place once the engineering foundation was established, rather than beforehand. That sequence was intentional, and it's exactly what made the expansion possible on Rodin's terms rather than the systems.
That foundation also has a practical benefit that extends well beyond PLM. When enterprise systems connect to each other, the quality of those connections depends on the quality of the data and logic at the source. Engineering data that's structured well from the beginning becomes an asset for every other system in the organization.
Why it matters who does this work
Teamcenter implementations, upgrades, and migrations require deep technical knowledge. But they also require something harder to hire for: genuine understanding of how engineering organizations function, what they need from their tools, and where the real complexity lives. That understanding reduces integration surprises that can increase implementation timelines, inflate budgets, and require custom exceptions to keep systems aligned.
An engineering first starting point is not at odds with financial or operational goals. In practice, it supports them. ERP systems configured on top of a stable, well understood product model generate cleaner transactions, fewer exceptions, and more reliable reporting. The upfront investment in clarity reduces downstream intervention.
At Sherpa, we come from that world. We've worked inside engineering organizations, not just alongside them. That background shapes how we listen, what questions we ask, and where we focus when the work gets complicated.
Teamcenter provides system of record that carries engineering decisions through the product lifecycle.
We're based in Portland, Oregon and work with manufacturers across the region and beyond — companies that are serious about getting their PLM environment right, and who want a partner that treats implementation as an engineering problem, not just a software project.
Whether you're working through an existing environment or planning a deployment from the ground up, the natural starting point is a Teamcenter Site Assessment. A site assessment is a two-day engagement where we examine your current environment, understand your process, and deliver a prioritized roadmap. You can use that plan with us or take it elsewhere. Either way, you leave with clarity.
Looking to get Teamcenter PLM? Learn more about our engineering first approach and see we might be a good fit for your team.
