ERP PLM integration with an AI agent needs two MCP servers, one on the PLM such as Windchill or Teamcenter and one on SAP, plus a comparison tool that fixes revision rule, plant and effective date before reading either BOM. Pexon's design keeps it read-only beside the existing transfer interface, because the failures sit in configuration, not in the protocol.
Where it breaks
01 · Configuration
A PLM structure is not one BOM. Windchill resolves it through a configuration specification, Teamcenter through a revision rule plus effectivity, and the same top-level part returns different children as released and as working. A tool that reads without naming the rule compares SAP against whatever configuration the session happened to use.
02 · Plant
SAP keeps BOMs per plant and allows alternatives; SAP's own PLM System Integration add-on creates plant-specific BOMs and BOM alternatives from one structure version. A difference is only a defect if plant, alternative or a manufacturing-only item does not explain it, and a naive diff cannot tell which.
03 · Change
Engineering releases through a change notice in the PLM. SAP records the same change as a change master or change record with a valid-from date. The two dates rarely match to the day, so a comparison run on the wrong date reports as a gap what is a change still in flight.
04 · Identity
If both servers authenticate a technical account, the agent will show a designer the costed mBOM of a plant they have no rights in, or an export-controlled eBOM to a buyer. Each server has to run as the person asking, and each system has to decide on its own what that person may read.
The first answer is the transfer interface you already have. A manufacturer that runs a PLM next to SAP moves released structures with a vendor connector, a middleware flow or SAP's own PLM System Integration add-on, which receives structure versions from an external PLM and creates classic or plant-specific BOMs without additional middleware. That interface is the right tool for moving a released structure into manufacturing. It is the wrong tool for the question a planner or a change engineer asks on an ordinary Tuesday: does the BOM we build to still match what engineering released, and what does this pending change touch? The interface answers whether something was transferred. After transfer, plants edit the manufacturing BOM for good reasons, and the interface was never asked to notice.
The second answer is newer. Give the agent one MCP server per system and let the model do the join.
It demos well: ask for both BOMs of a part and the model lays them side by side and names the differences in fluent sentences. It fails without noise. The model cannot know that the PLM server returned the working structure while SAP returned a BOM valid from last month, and it describes the difference with the same confidence either way. The join also happens inside a context window, where a missing item and an item that belongs to another plant look identical.
Our position is that a join which decides whether a production BOM is wrong does not belong in a model's reasoning. It belongs in code that a PLM owner can read, test and sign, with the model reduced to explaining a result it did not compute. That is a stronger constraint than most agent demos accept, and it is the one that survives the first review by the people who own the BOM. We have not yet run this comparison for a customer; the argument rests on what both systems document and on what a BOM owner will ask.
What gets built
01
Named read operations only: get_structure, where_used, get_change_notice. Every operation takes the configuration explicitly, a Windchill config spec or a Teamcenter revision rule with effectivity, and returns the configuration it used alongside the data. It is built against Windchill REST Services or Teamcenter Services, whichever your instance exposes, and it never opens a generic query endpoint.
02
Read operations on the material BOM and on change objects: get_material_bom by material, plant and valid-from date, and get_change_record. It is built on the released OData services such as API_BILL_OF_MATERIAL_SRV and API_CHANGEMASTER where your S/4HANA release provides them, and on RFC where it does not. Plant and date are required inputs, never defaults.
03
compare_ebom_mbom calls both servers for the same effective date, applies your mapping rules (which items are manufacturing-only, which plant builds which alternative) and returns each difference classified as explained, unexplained or change in flight. The model summarises that result for the person who asked. It does not produce it.
The configuration as argument
This is the definition the comparison server publishes over MCP. The required list is the design: a call without a configuration, a plant or a date is rejected before either system is touched, and the fourth failure, identity, is handled by who is allowed to call it.
# compare_ebom_mbom: MCP tool definition on the comparison server.
# Every input is required. None has a default, on purpose.
{
"name": "compare_ebom_mbom",
"description": "Compare the engineering BOM of one part in the PLM with the SAP material BOM of one plant, both resolved for one date. Read-only.",
"inputSchema": {
"type": "object",
"required": ["part_number", "plm_config", "plant", "effective_date"],
"properties": {
"part_number": { "type": "string" },
"plm_config": { "type": "string", "description": "Named revision rule or config spec the plant builds to" },
"plant": { "type": "string", "description": "SAP plant; one mBOM per plant" },
"effective_date": { "type": "string", "format": "date" }
}
}
}
# The result echoes what was actually used, so it can be checked later:
# { "plm_config_used": "...", "sap_valid_from": "...",
# "differences": [ { "item": "...", "class": "explained | unexplained | change_in_flight", "reason": "..." } ] }If a result does not echo plm_config_used and sap_valid_from, nobody can check it afterwards, and an unexplained difference becomes an opinion.
Covered and not covered
| Question | Covered by the PLM-to-SAP transfer | Additionally needed for the agent |
|---|---|---|
| Move a released structure into SAP | Yes. SAP's PLM System Integration add-on creates classic or plant-specific BOMs from a structure version | Nothing. Keep the interface; the agent never writes a BOM |
| Does the mBOM still match the released eBOM? | No. After transfer, plants edit the mBOM in SAP | A comparison tool with configuration, plant and date fixed per call |
| What does this pending change touch? | Partly: the change master links objects once the change has been transferred | where_used in the PLM plus open change records in SAP, read before release |
| Who may see which BOM? | Typically a technical user moves the data | The person's identity on both servers, checked by each system |
| Why was a difference accepted last time? | Not recorded in the transfer | Mapping rules as code and a log of every comparison |
Rows describe the interface class, not one product. Check your connector's own documentation for what it monitors and logs.
When not to build this
If your manufacturing BOM is generated from the engineering BOM and nobody edits it in SAP, the transfer interface already answers the question, and an agent only adds a second place to look. The same holds when one team owns both structures and reconciles them by hand without incident. The build pays off when plants edit their BOMs independently and change notices arrive faster than planners can check them. Where the PLM side is PTC, the connector is described under Windchill integration.
No, and it should not try. The transfer interface moves released structures into SAP under change control and has its own monitoring. The agent reads both sides afterwards to answer the questions that interface was never built for: does the manufacturing BOM still match what engineering released, and what does a pending change touch. Keeping the agent read-only is what lets it sit next to a controlled process without becoming part of it.
Not in the architecture we propose. Every tool on both servers is a read operation, and the comparison tool returns classified differences rather than corrections. When a difference is a real defect, a person raises the change in the PLM or SAP through the process that already exists. An agent that edits a production BOM would need the same validation as any other system that does, and at that point it is a different project.
The entry is a fixed-price Readiness Blueprint at €4,900 over two weeks: one part family, one plant, the mapping rules written down and a costed build plan for both servers. A first production use case is typically a pilot from €15,000. API access for technical or per-user calls into SAP and the PLM can carry licence terms of its own, so check them with your vendors before the build. All prices are net and exclude VAT.
It does not work where nobody can say why the manufacturing BOM differs from the engineering BOM. The comparison tool is only as good as the mapping rules behind it, and if plants have edited their BOMs for years without recording why, the first output is a list of thousands of differences nobody can classify. In that case the useful first project is writing the rules down, with or without an agent. It also does not help when the PLM holds no reliable released state.
Then we run them, inside your environment rather than ours. The servers are your code in your repository, deployed where your PLM and SAP already sit, and the handover includes the tool definitions, the mapping rules and the tests. If you want us to operate them afterwards, monitoring starts at €3,000 per month. A hosted gateway outside your network is possible in principle, but for engineering data under export control it is usually the harder conversation.
Next step
Two weeks, fixed price: we pick one part family with your PLM and SAP owners, write down why its manufacturing BOM differs from the engineering BOM, test whether both systems can carry the person's identity, and hand back a costed plan for the two servers.