PLM Solution Design

Requirements into technical design

Translating business requirements into a Teamcenter design: data model, lifecycle, workflow, access rules and integration points. The useful output is specific enough that two different people would build roughly the same thing from it.

Data model and lifecycle design

Object types, relationships, revision rules and lifecycle states that match how your products are actually developed. Data model decisions are among the most expensive to reverse once there is production data, which is why they deserve disproportionate attention early.

Scalability and design patterns

Designs that still behave at production volumes, across sites, with the number of concurrent users you will actually have. We prefer patterns that have survived contact with real deployments over novel approaches.

Custom tools built around Teamcenter

Some requirements have no configuration answer and no product on the market behind them. Building a purpose-made tool around Teamcenter is often the shortest route there, and we are comfortable doing it in whatever technology the situation calls for — ITK and SOA libraries, REST services, .NET or Java applications, Excel add-ins, scripting and scheduled jobs. The platform gets chosen to fit the problem and the people who will maintain it afterwards, rather than the other way round.

Awkward problems are the interesting ones

The requirements worth building for are usually the ones that look difficult: data spread across systems that were never meant to talk to each other, a process nobody has automated because it sits between two tools, a report that takes someone three days a month. We are happy to take those on. What we care about is that whatever gets built is scalable, efficient, and still legible to whoever maintains it in two years.

Implementation planning

Phasing, dependencies, what has to be true before each stage starts, and where the risk concentrates. A plan that acknowledges uncertainty is more useful than one that assumes none.

Common questions

Can you review a design we already have?

Yes. Yes. A design review before implementation is considerably cheaper than discovering the same issues afterwards.

Do you implement what you design?

We can, but it is not a condition. If you would rather hand the design to your own team or to another implementation partner, that is a perfectly reasonable arrangement.

What if our requirement has no standard Teamcenter solution?

That is usually where a purpose-built tool earns its place. We check whether configuration can cover it first, because configuration survives upgrades better than code does. Where it cannot, we design and build around Teamcenter in whatever technology suits the problem — ITK, SOA, REST, .NET, Java, Excel add-ins or scripting.

How early should solution design start?

Before configuration begins. Design decisions made implicitly during implementation are the ones that tend to need unpicking later.