AI across multiple business systems

Ask most organisations where a given answer lives and you will get a pause, then a list. Part of it is in the ERP. Part is in the procurement platform. Part is in a reporting tool. And the bit that actually settles the argument is in an application somebody wrote in 2014 that two people still understand.

Users have learned to route around their own architecture. That knowledge is a tax, and they pay it every day.

The tax users pay

People have quietly absorbed an enormous amount of institutional knowledge that has nothing to do with their actual job: which system to open for which question, who to ask when they are not sure, which route is quickest, and which one is merely official.

Nobody put that in a process document, because it is not a process. It is compensation for a landscape that grew one acquisition and one project at a time. The people who are best at it are usually the ones who have been there longest — which should worry you, because it means the knowledge leaves when they do.

Why single-system AI disappoints

This is the quiet reason a lot of AI pilots underwhelm. The assistant is connected to one system, and it answers questions confined to that system beautifully. But those were never the questions that hurt.

The painful question is the one that crosses a boundary: can we ship this? — which depends on stock, on a credit position, on whether a supplier is approved, and on something a planner knows. Ask a single-system assistant and you get a confident, partial answer, which is worse than none, because now somebody has to work out which part is missing.

One answer, from wherever the truth lives

A capability is not obliged to respect your system boundaries. It can be created for JD Edwards EnterpriseOne, JD Edwards World, SAP, Ariba, reporting platforms, internal and bespoke applications, partner systems — one source or several — and present as a single, coherent thing.

One system or many. One source or several. One answer, assembled from wherever the truth lives.

The user stops needing to know where anything is. They ask for the outcome. And the tax quietly stops being collected.

Governance gets harder, not easier

Now the uncomfortable part, because it is the part that gets skipped.

Reaching across systems multiplies what an AI could touch, and therefore multiplies the governance burden. A capability that spans four systems is exactly as useful as it sounds, and exactly as alarming to your security team — unless the question “who approved this, and who may use it?” has a crisp answer.

So cross-system reach only works if it comes with a boundary that is centrally owned: one identity, one place where groups are decided, one act that publishes a capability to an audience, and one act that takes it back. Bolt cross-system reach onto a deployment that lacks that, and you have not built a capability layer. You have built a very fast way to make a mistake in four systems at once.

Where to start

Not with the landscape. Start with one system — usually the one everybody complains about — and a small number of capabilities that people actually ask for by name. Prove the governance model works when the stakes are low and the blast radius is small.

Then add reach, deliberately, as the value proves itself. Cross-system capability is a destination worth reaching. It is a terrible place to begin.