The Software Is the Last Decision,
Not the First
Most PLM projects run into trouble long before anything is installed, because the process was never defined and the requirements were written by whoever happened to be in the room. We work the other way around: process first, requirements second, software last.
These documents are yours. You can implement with us, with another partner, or decide the project is not worth doing yet. All three are legitimate outcomes.
Most PLM Projects Fail on Paper
Long Before They Fail in Production
By the time the problems show up during rollout, the decisions that caused them were made months earlier, usually in a meeting where nobody had mapped the process first.
Why PLM Consulting?
Digitalization has compressed product life cycles and raised what customers expect. Companies now have to innovate faster while cutting cost and holding risk down, and the systems that support that have to be chosen well the first time.
The usual failure is not technical. It is that the software gets selected before anyone agrees how the work should actually flow. Requirements are written from the vendor's feature list rather than from the process, and the gap only becomes visible once users are in the system.
Our consultants bring the methodology and the domain experience that internal teams either do not have or cannot free up at the moment it matters. Not to produce a strategy document, but to make the decisions defensible before money is committed.
"The cheapest change you will ever make to a PLM system is the one you make on a process map, before anything is configured."
Cross-Domain Expertise
We work across product data management, production execution, warehouse operations, and enterprise IT. That range is what lets us design a process that holds together past the engineering department, which is exactly where most digital thread projects break.
In-House Development Team
Integrations, API extensions, and workflow customizations are built by our own engineers, without outsourcing or generic middleware. When we say something is feasible, it is because we would be the ones building it.
Advice We Have to Live With
Most consultancies hand over a report and move on. We also implement and run the systems we recommend, which means every recommendation is constrained by what we would have to deliver ourselves. That tends to keep proposals honest.
Authorized Vendor Partnerships
As a partner of PTC and Dassault Systèmes, we have direct access to the platforms and to the people who build them. Where the answer is that you do not need more software yet, we say that too.
Four Phases, and Each One
Ends With a Document
Consulting that produces only opinions is hard to act on. Every phase here closes with something written, reviewed, and signed off, so you can stop at any point and still have something usable.
Assess
Current state and where the value is leaking- Interviews across engineering, production, planning, and IT
- End-to-end process walkthrough and value stream mapping
- Review of existing systems, data quality, and integrations
- Baseline measurement of how long things actually take today
- Assessment report with findings ranked by impact
- Process map of the current state, as it really works
- Quick wins list, things worth fixing before any project starts
Design
How the work should flow, before choosing a tool- Design the future-state process with the people who will run it
- Define the digital thread: what data moves where, and when
- Agree BOM structures, revision rules, and change workflow
- Establish master data governance and ownership
- Future state process design, agreed by the departments involved
- Data model and digital thread map
- Governance rules for who owns which data and decision
Specify
Requirements and architecture a vendor can be held to- Write requirements derived from the process, not from a feature list
- Define the integration architecture with your ERP and other systems
- Assess whether your current platform can carry the design
- Model licensing scenarios against real usage patterns
- Requirements specification, usable in a tender or a contract
- Integration architecture with interfaces and directions defined
- Licensing and TCO analysis for the options on the table
Plan
A roadmap and a business case you can take to the board- Break the work into phases, sequenced by dependency and payback
- Estimate effort, cost, and internal resource load per phase
- Define the KPIs the project will be measured against
- Identify the risks and what would have to be true for each phase to work
- Phased implementation roadmap with what to do first and what to skip
- Business case with cost, effort, and expected return
- KPI framework agreed before the project starts, not after
Consulting ends here, deliberately
What comes next is building and running the system, and those are separate engagements with their own scope and pricing. If you decide to continue with us, that work is covered by System Implementation and Managed Services. If you decide to continue with someone else, the documents from these four phases are written so that they can.
Five Problems Companies Bring Us
More Often Than Any Others
An engagement rarely covers all five. Most start with one that has become urgent, and the others surface during the assessment.
Process Design & Digital Thread
Mapping how information should actually move from concept to delivery, and removing the manual handovers that break it along the way.
Architecture & System Integration
Deciding which system owns which data, and designing the interfaces that keep the rest of the business in step with engineering.
Master Data Governance & Migration
Getting decades of accumulated files into a structure that holds, and agreeing the rules that keep it clean afterwards.
Licensing Strategy & Cost of Ownership
Matching what you pay for to what is actually being used, and to where the operation is heading rather than where it was.
Adoption & Change Planning
Planning for the part that sinks most projects: people continuing to work the old way in a new system.
Not sure which of these is your actual problem?
That is a common starting point, and it is what the assessment phase is for. Frequently the issue a company arrives with turns out to be a symptom of a different one on this list.
What Consulting Actually Looks Like
on Each System
The four platforms we implement, and the decisions that have to be made correctly on each one before configuration starts.
Windchill PLM
Product data and lifecycle
3DEXPERIENCE Platform
Unified collaboration
InfoBiro WMS
Warehouse operations
DigiPro System MES
Production monitoring
Consulting does not require you to buy any of these. If the assessment shows that your current platform can carry the design, or that the process fix alone is enough, that is what the report will say. Several engagements have ended with a recommendation to change nothing about the software and everything about the process.
What Companies Ask For,
and What the Assessment Usually Finds
The request a company arrives with is almost always a symptom. Part of the value of an assessment is separating the two before anyone spends money on the wrong problem.
We need a new PLM system. This one is not working for us.
Often the platform is fine, the configuration never matched the process
The system was set up during implementation years ago, around how the company worked then. Nobody revisited it as the business changed. Replacing it usually reproduces the same problem on a newer version.
We want to integrate PLM with our ERP so BOMs transfer automatically.
The BOM structure has to be fixed before it can be automated
Engineering and production hold different views of the same product, and the manual re-entry has been quietly correcting for that difference all along. Automating it first would just move the errors downstream faster.
We need to migrate twenty years of CAD data into the new system.
Much of it should not be migrated at all
Obsolete revisions, abandoned variants, and duplicates of the same part under different numbers. Deciding what to leave behind is the harder half of the job, and it determines whether the new system stays clean or inherits the old mess.
The system is too slow. We think we need better hardware.
The bottleneck is usually the data model or how the system is used
Assemblies structured in ways that force the system to load far more than the user needs, or searches running without the attributes that would narrow them. Hardware rarely fixes a structural problem, it just raises the cost of having one.
Our engineers spend too much time on administration. We need more people.
The work is real, but most of it does not need an engineer
Approvals routed to people who never had grounds to refuse, data entered twice because two systems both claim ownership, documents assembled by hand. Adding headcount scales the problem rather than removing it.
Adoption is poor. Our people need more training on the system.
Users are rarely confused about the buttons
They are working around a process that was never agreed between departments, and the workaround is often the more sensible option given how the system is set up. More training on an unclear process produces better-informed workarounds.
Recognize your own question on the left?
Then the useful next step is not a proposal, it is an assessment. You get the findings in writing, and you decide what to do with them.
PLM Consulting,
Answered Plainly
The questions companies ask before committing to an assessment, including the awkward ones.
Consulting decides what should be built and why. Implementation builds it. They are separate engagements with separate scope and pricing, deliberately.
Consulting ends with a roadmap, a requirements specification, and a business case. At that point you have everything needed to start a project, and the decision of who executes it is still entirely open.
If you continue with us, the work is covered by System Implementation, and once the system is live, by Managed Services.
A fair question, and it deserves a direct answer rather than a reassuring one. We are authorized partners of PTC and Dassault Systèmes. That is a commercial relationship and we are not going to pretend otherwise.
What we can state is how the process is structured to keep it honest. Requirements are written from your process before any platform is discussed, and they are written so that any vendor can be measured against them, including us.
In practice, a significant share of assessments conclude that the platform is not the problem. If that is what we find, the report will say so, because a project sold on the wrong premise ends up being our problem too.
Documents, not slide decks. Depending on the phases in scope:
- Assessment report with findings ranked by impact
- Current and future state process maps
- Requirements specification usable in a tender or a contract
- Integration architecture with interfaces and directions defined
- Phased roadmap covering what to do first and what to skip
- Business case with cost, effort, and expected return
They are yours. Nothing in them is written in a way that only we could execute.
This is the constraint most companies underestimate, so it is worth being specific. We cannot design a process without the people who run it, and that time cannot be outsourced.
Typically:
- Assess: interviews of one to two hours with eight to fifteen people, plus a few half-day process walkthroughs
- Design: the heaviest phase, with workshops involving a core group of four to six people
- Specify and Plan: mostly our work, with review sessions on your side
We schedule around production and release cycles wherever possible. A company that cannot free up that time is usually not ready for the project either, and that is worth knowing early rather than late.
More often than for companies starting from nothing. An existing system carries years of decisions that made sense at the time and were never revisited.
The usual triggers:
- The system was configured for how the company worked five years ago
- An acquisition or a second site introduced a parallel way of working
- Users have built workarounds that now carry real process logic
- An upgrade is due and it is unclear what should be carried forward
In these cases consulting usually produces more value per day than it does on a greenfield project, because the constraints are already known.
We can write the requirements specification and the evaluation criteria, which is the part most tenders get wrong. A specification derived from your process rather than from a feature list is what makes vendor answers comparable.
Where the tender includes platforms we represent, we will say so plainly and can step out of the evaluation itself. If you need a fully independent evaluator for that stage, we will tell you rather than take the work.
Then that is what the report says, and it is a legitimate result. A recommendation to delay, to reduce scope, or to fix the process first is frequently the most valuable output of an assessment.
A failed PLM project costs several times what an assessment costs, and it usually takes two or three years before anyone in the organization is willing to try again. Knowing that the timing is wrong is worth paying for.
A full engagement across all four phases typically runs eight to eleven weeks. Many companies start with the assessment alone, which is three weeks, and decide afterwards whether to continue.
What moves the timeline:
- Number of sites and departments in scope
- Whether integration architecture is included
- How quickly your side can free up people for workshops
- Whether decisions need board approval between phases
As a fixed fee per phase, agreed before the phase starts. Each phase has a defined deliverable, so what you are paying for is a document rather than a number of days.
That structure exists for a specific reason: you can stop after any phase. If the assessment tells you what you needed to know, there is no obligation to continue into design.
The variables are the number of sites, departments, and systems in scope. We quote after a short scoping conversation, which costs nothing.
You describe the problem in your own terms. Not as a specification, but as the thing that keeps coming up: the handover that always goes wrong, the data nobody trusts, the upgrade that keeps getting postponed.
From there we tell you honestly whether an assessment would help, and roughly what it would involve. If we think the issue is smaller than a consulting engagement, we will say so and point you at the shorter route.
Question not covered here?
Describe your situation and we will answer against it, not against a generic case.
The Cheapest Version of This Project
Is the One You Plan Properly
Every change is cheaper on a process map than in a configured system, and cheaper in a configured system than in production. The assessment is three weeks and ends with a written report, which is yours regardless of what you decide next.