DEV Community: Venkat London26

SAP, Master Data and AI: A Practical Guide to Modernising Enterprise IT

Venkat London26 — Mon, 05 Oct 2026 11:34:00 +0000

title: SAP, Master Data and AI: A Real-World Approach to Modernising Enterprise IT

description: A no-nonsense guide to SAP support, management of master data, AI readiness, and software development for growing businesses.

Most businesses aim to transform digitally, with a focus on AI readiness. In reality, most enterprise IT issues stem from poor data management and insufficient support. Lack of clarity on priorities creates its own set of problems.

In my 25+ years of experience in enterprise IT, I've learned the most important lesson: if the foundations aren't established properly, everything built on top becomes problematic.

The following outlines the most important lessons learned in an easy-to-understand format.

1. Support your ERP systems: SAP and Oracle

Your ERP systems (SAP or Oracle E-Business Suite or similar) are the backbone of your finance, supply chain, and operations. Poor support can cause issues such as wasted reporting time, workarounds, and a lack of faith in the system among end users.

An effective support system usually includes:

A clear plan on how your system will be
Support staff that are onsite or nearby to quickly resolve issues
Continuous improvements and upgrades to the system
A support system that is flexible and can scale with the business

Organisations also use a mix of onshore consultants and offshore support centres to keep costs reasonable while still providing 24/7 support. Infoplus Technologies UK uses this model, having SAP-certified support staff in offshore centres and leadership staff in the UK.

Treat master data as an asset.

Master data refers to essential business data such as materials, suppliers, customers, and assets. Data duplication, inconsistency, and incompleteness present risks at multiple levels of a business. For instance, the reports and automation tools built on master data carry the same defects.

This is particularly problematic in asset-heavy industries such as manufacturing, utilities and energy, where MRO (maintenance, repair and operations) master data impacts purchase and maintenance decisions. Good data practice includes:

Data cleansing
Standardised cataloguing
Data governance
Inspection of plant and equipment to ensure records are up to date.

Better data helps eliminate stockouts, duplicative purchasing, and improves reporting.

Build custom applications only when required.

There are many packaged applications, and it is worth evaluating off-the-shelf applications for the processes you want to develop a custom application for. Custom application development is required when:

-There are no packaged applications to suit your business processes

Integrating multiple applications is the real problem

-You want to differentiate your business from competitors

Custom applications should be small in scope. Testing and documentation should occur early and continuously and support for the application should be planned for. Outsourcing product development and testing can help deliver applications faster.

3. Get AI-ready (without the hype)

AIs are only as powerful as the data and systems that back them. Before investing in AI, you should consider:

Is our data accurate and structured?
Are our core systems integrated?
What specific problem are we solving with AI?

If the answer to the first two is “no”, then the best AI investment is to improve the basics from sections 1 and 2.

The chatbot phase is finished. What's going to replace it isn't a chatbot.

Venkat London26 — Thu, 20 Aug 2026 15:12:11 +0000

For the last few years, the majority of "[AI in the enterprise]
(https://www.infoplusltd.co.uk/)" conversations revolved around the same issue: a chatbot grafted onto a support website or a copilot that creates an email that a human is required to send. Effective, but not enough -it waits for an event, then does one thing, and then ceases.

The phase that was closed is over. What's coming in its place is software that doesn't need to be contacted. It analyses a goal and breaks it down into steps, and then uses the APIs and tools it requires, and only calls an individual when something goes outside its permission boundaries. This is the change people mean when they talk about "agentic AI," and it's not just a research demonstration—it's appearing in core enterprise applications at a rate most IT teams didn't anticipate.

If you design, manage or protect enterprise systems, it's not a trend that you can observe from a distance. It affects how you create integrations, the way you think about access control and the way you define a "feature" in the first place.

What is the reason this is happening right now? It was not even two years ago
Three elements had to mature before agents could be able to move beyond demos:

Orchestration became standardised. Protocols like MCP (Model Context Protocol) provided agents with a uniform way to find and use external tools instead of each team rolling out brittle integrations. This one change took away large chunks of plumbing that was used to create multi-step automation that was expensive to develop and impossible to maintain.

Models have become sufficiently reliable to allow chaining. A single bad output from a five-step chain could turn into chaos. The quality of reasoning across models of the current generation has improved to the point that multi-step task execution has become sufficient for specific and well-bounded workflows -not for general autonomy, but more specific ones such as reconciling invoices or triaging tickets and updating data across different systems.

Governance is no longer an add-on feature. Early pilots failed not so much due to the quality of models and more due to the inability of anyone to determine "what is this agent allowed to touch, and can we prove it after the fact?" Permission scoping, action logs and approval checkpoints are included in the architecture of agents beginning from day one, instead of being retrofitted following an incident.

In the end, it's because analysts are coming to the same issue from various perspectives this year: agent-integrated applications are growing from a tiny fraction to a significant portion of enterprise software and the gap that exists between "we tried an agent" and "we run one in production" is slowly beginning to close; however, it's much larger than the marketing claims.

The place it's actually going to land (not where the hype claims it's)
The pattern in real deployments is more granular and boring than the demos that are used for the keynotes:

Finance and operations reconciling, detection of anomalies and reporting, which used to take days to complete, operates as a bounded agents workflow, with a sign-off by a human step.
Customer service - resolution and triage of tickets for clearly defined categories, with clear pathways to escalate any ambiguity.
Delivery of software -- updates to dependencies, routine quality checks for code, and PR triage where the impact radius of a mistake is very small and can be reversed.
Industries that are regulated -Banking and insurance outshine healthcare and public administration in this area because the workflows can be more standardised, and conformity tools are more advanced.
Note the common theme: each one of them is a specific, well-defined job with a clearly defined boundary and not an all-purpose "AI employee." The businesses that are gaining value are those that resist the urge to create an AI that is broad, and instead offer something that is specific enough to effectively test, monitor and then roll back.

What does this mean for the way you design
If you're designing for this, a few attainable changes are more important than choosing the right model.

Design to allow access to tools that goes beyond the prompts. An agent is only as secure as the permissions it's given. Consider every connection to a tool as an API key with the lowest privilege, expiring credentials as well as the audit trail.
Create a human-controlled checkpoint when the price of error is significant. Full autonomy isn't the ultimate goal of most businesses at the moment. A pause-and-approve process for any process that involves customers' data, financial transactions, as well as production equipment is cheap insurance.
Test every aspect before you take it to scale. Decision logs and observation aren't just optional extras; they're what differentiates an operation you can defend against a pilot that you must stop.
Begin by defining a workflow that you are able to evaluate. Time saved, error rate and costs per transaction. Agent projects that are cancelled are typically the ones that no one can tie to a specific number.
A multi-vendor plan for reality. Locking into one orchestration layer or model provider can be a more serious danger with agents than basic chat functions, as your business logic is being embedded into the way that agents communicate with tools and not only in an interface that you could change out.
The real caveat
It's not likely that every agent initiative is likely to succeed. It's important to state that out loud. A substantial portion of the pilots that are currently in production fail, and not due to bad designs, but rather from a lack of clarity on control, ownership or ROI or insufficient risk control after a product is in production. Think of "agentic AI" as an architecture decision that comes with real operational costs, not just as a checkbox option. The teams that reap the most value are those that have a clear scope while also establishing early instrumentation and being transparent about what a particular workflow actually requires autonomy to.

This is the less thrilling and more practical version of the story, which is the one worth constructing around.

Infoplus Technologies UK Limited is a specialist across AI automation, automation, and enterprise IT delivery, from the design of agentic workflows as well as RPA up to cybersecurity and cloud. If you're planning an agentic AI pilot project and require a second set of eyes to examine the architecture, contact us.