Selecting an AI implementation partner for a PTC Windchill environment requires evidence of both PLM delivery and AI implementation capability. Manufacturers need to understand how the proposed solution will use controlled product information, work across engineering systems and support decisions for which engineers remain responsible.
TT PSC, a Global System Integrator listed by PTC, has published project references covering Windchill migrations at Liebherr and connected engineering at Schaeffler. Alongside PTC’s description of ProductAscentAI, these examples provide a practical basis for examining the capabilities manufacturers should look for in a partner.
What useful AI requires from the engineering environment
Consider an engineer assessing a proposed component change. The relevant information may include a particular component revision, its product configuration, linked requirements and verification evidence. Before evaluating an AI-generated assessment, the engineer needs to know which of those sources were considered and where the evidence is incomplete.
An implementation partner should be able to explain how that context reaches the AI application. Which system holds the authoritative information? How are conflicting records handled? How does the solution respect the user’s access permissions? These questions turn a broad discussion about AI capability into an assessment of a specific engineering workflow.
They also establish the boundaries of the solution. If information is missing from the connected systems, the workflow needs a way to identify the gap and refer it to the responsible engineer.
Choosing between PTC AI capabilities and additional development
The proposal should explain which capabilities come from PTC products and which require configuration, integration or additional development. PTC describes Windchill AI Assistant as supporting natural-language access to document knowledge and summarisation, with references to source information and enforcement of access controls.
A workflow involving several engineering systems needs a separate assessment of the information and connections required. For example, reviewing requirements and preparing an architecture proposal may involve ALM or systems engineering tools alongside Windchill. The partner should identify where each task takes place and how validated results enter the relevant engineering processes.
PTC’s ProductAscentAI description assigns TT PSC a role in data readiness assessment, PLM consolidation where needed, implementation of PTC AI and the connection of customer-specific agents to existing infrastructure. This distinction helps a manufacturer examine the implementation scope and identify who will maintain each part of the solution.
Ask candidates to document dependencies on product versions, deployment arrangements and licensing, together with the cost and ownership of any additional components.
What TT PSC projects reveal about AI readiness
Preparing product data at Liebherr
TT PSC’s Liebherr case study describes migrations into Windchill PLM across more than 14 locations and more than 10 sub-projects. The work included normalising, synchronising and correcting data from different source systems, together with Windchill customisations for change management, CAD data and bills of materials.
This experience is relevant when an AI use case depends on information brought together from several sources. Before asking AI to interpret that information, the implementation team must establish consistent records and the relationships needed by the selected workflow. The Liebherr reference provides evidence of the underlying PLM migration and data preparation work.
Connecting engineering information at Schaeffler
The Schaeffler story describes TT PSC’s development of process-oriented Digital Thread solutions using PTC technologies. The work supports cross-system traceability, transparency and access to information according to user roles.
For AI partner selection, the relevant capability is the ability to connect engineering information while preserving its context. A manufacturer can use this reference to discuss the systems involved, the relationships maintained between them and the responsibilities TT PSC held in delivery. Those details help establish how the experience relates to the manufacturer’s own environment.
Supporting requirements and architecture analysis with AI
TT PSC’s AI framework analyses requirements and specifications to propose a functional breakdown, candidate system blocks and interfaces for engineering review. In its ProductAscentAI article, PTC reports a 60–80% reduction in early-phase requirements and architecture analysis effort in one engagement using the described approach. Engineers review and validate the generated proposals.
The reported improvement concerns that analysis stage. A comparable pilot should establish its own baseline and include the effort required for engineering review and correction when evaluating the result.
Determining how much PLM modernisation is needed
The scope of modernisation should follow the needs of the selected use case. A readiness assessment should establish whether the current Windchill environment provides the required information and access mechanisms, and identify any specific gaps.
Ask the partner to explain why each proposed change is necessary. A wider consolidation programme may be justified when fragmented systems prevent consistent access to the product information required. A narrower workflow may need targeted data preparation or integration. The recommendation should connect each investment to an observable limitation and the expected improvement.
For a European rollout, also establish how the proposed delivery model supports the actual sites involved. Confirm working languages, data processing locations, access arrangements and responsibilities for support after launch.
Testing the proposed solution on a real engineering task
Ask each shortlisted partner to demonstrate a representative workflow using an agreed set of documents and user roles. Include situations that could produce an incomplete or misleading answer during daily work.
| Test situation | What the demonstration should establish |
| Documents contain conflicting information | Whether the solution identifies the conflict, shows its sources and refers unresolved questions for engineering review. |
| A user cannot access part of the documentation | How access restrictions affect retrieval and the generated response, including references and summaries. |
| Available information does not support an answer | How the solution signals insufficient evidence and avoids presenting an unsupported conclusion as an established fact. |
| A task depends on a specific revision or configuration | How the workflow selects the relevant information and makes that selection visible to the reviewing engineer. |
These are proposed acceptance tests. Their implementation will depend on the chosen products and architecture. The demonstration should explain how each requirement will be met in the manufacturer’s environment.
Measuring the pilot before committing to scale
Agree a baseline and acceptance criteria before development begins. For requirements analysis, measure the time needed to prepare a reviewable result, the proportion of findings accepted by engineers and the effort required to correct the output. For information retrieval, evaluate answer accuracy and source relevance alongside search time.
Use representative tasks and include difficult cases. Faster preparation has limited value if reviewers spend the saved time resolving errors. The evaluation should therefore cover the complete task, including human review, and record how failures are handled.
A pilot should also establish operational responsibilities. Identify who approves engineering results, who monitors the solution and who maintains integrations as the source systems evolve. This gives the manufacturer a basis for assessing both the measured improvement and the ongoing cost of using the solution.