Driving value cost effectively: promote the people you already have

Most enterprise AI budgets begin with the same question: what will it cost to hire someone who can build this?

It's the wrong first question — not because the number is small, but because it assumes the scarce skill is the one you're missing.

It usually isn't. The scarce skill is already on your payroll.

The expertise that actually gates the project

Safely connecting an AI assistant to an SAP system takes two different kinds of knowledge, and they are not equally hard to obtain.

Protocol and infrastructure knowledge — how to implement an MCP server, host it, secure the transport, handle SAP CSRF tokens, wire OAuth, and keep pace with spec revisions. This work is real, and it is almost entirely generic. It looks nearly identical at every company that does it.

Domain knowledge — which OData service holds the data that matters. Which entity is authoritative and which is a stale copy. Which field is personally identifiable. Which write will quietly break a downstream process at month-end. Which approval genuinely needs a human in the loop.

Only one of those is scarce inside your organization, and it isn't the one you were about to recruit for. A newly hired gen-AI engineer arrives with the first set and spends six months acquiring the second — mostly by interrupting the people who already have it.

Your Basis admin, your ABAP developer, and your functional consultant have been accumulating that second set for years. They are the real constraint on a safe deployment, and they are already here.

Two knowledge sets: generic protocol and infrastructure skills versus scarce in-house domain knowledge

So what was actually blocking them?

If your SAP team already knows what should and shouldn't be exposed to an AI assistant, why haven't they done it?

Because until recently, acting on that knowledge meant becoming a different kind of engineer. Exposing a single OData service to Claude required writing an MCP server, provisioning hosting, building a deployment pipeline, writing a test suite, and then maintaining all of it against a protocol that is still moving. We've written before about the full bill behind a "simple" custom MCP server — it is not a weekend project, and it never stops arriving.

That barrier is what quietly converted "our SAP experts should own this" into "we need to hire someone."

DataTether removes the barrier instead of the people. Point it at a service URL and it reads $metadata, discovers every entity, navigation property, and function import, and generates typed MCP tools — list, get, create, update, delete, search, count. SAP CSRF handling, OData v2 and v4, Basic Auth, OAuth 2.0, and cookie auth are a step in a wizard, not a codebase you inherit.

What's left over is precisely the part your people are uniquely good at: deciding which entities to expose, which fields to hide, which operations stay read-only, and which writes pause for a named approver.

That isn't a smaller job. It's the important one — and this is the first time it has been separable from the plumbing.

The cost side of the same decision

The two paths don't just differ in price. They differ in who ends up holding the knowledge.

The last row is the one that tends to get overlooked. A custom MCP server usually leaves exactly one person who understands it, and that person is expensive and mobile. A configured connection leaves the understanding with the team that already owns the system of record.

What "promotion" actually looks like, by role

This is the part worth being concrete about, because "empowering your team" means nothing on its own.

The SAP Basis admin stops being the ticket queue for data access and becomes the person who defines what AI is allowed to touch across the landscape. Scoping entities, enforcing read-only mode at the platform level, and deciding which operations require confirmation is governance authorship — not provisioning.

The ABAP developer stops writing throwaway extraction reports. No-code enrichment rules cover the routine reshaping, and the sandboxed JavaScript transformation editor is there when the logic is genuinely custom. Composite tools chain calls across several OData services without a glue-code project attached to each request.

The functional consultant stops filing frontend tickets and waiting a quarter. The drag-and-drop UI builder produces working dashboards and cards without a frontend developer, which means the person who understands the process is also the person shaping how it's presented.

The IT leader stops defending a stalled proof of concept. Scope, approval gates, and audit trails are properties of the platform, so the security review has something concrete to examine instead of a promise — the difference between a pilot and something that ships.

How each role moves from routine execution work up to ownership and governance

Don't put a tax on the people you just promoted

Per-seat pricing punishes exactly the behavior you want. If every additional person costs more, adoption becomes a budget negotiation, and the tool stays with the two people who could justify a licence.

DataTether charges for connections, not seats. Every plan includes unlimited users — Free, Pro at $49/mo, Team at $199/mo, and Enterprise alike. You pay for the ERP connections your team needs, not for the number of people who benefit from them. Every plan includes every feature, so a wider rollout is a decision about value rather than a line-item fight.

That matters for the argument in this post specifically: promoting your people only pays off if you can afford to promote all of them.

Governance is what makes delegation affordable

There's a fair objection here. Giving more people the ability to connect AI to systems of record sounds like it increases risk, not value.

It would — without bounded blast radius. That's why the controls sit under the delegation:

• Confirmation-gated writes. The AI prepares the action; a human sees the entity, the operation, and the exact field values, and can edit or cancel before anything executes.
• Read-only enforcement at the platform level, not by instructing the model. The AI cannot write unless a human explicitly permitted it.
• A credential vault. Secrets are encrypted at rest, injected at execution time, and never appear in tool responses or logs — the AI client never holds them.
• Scoped exposure. Only the entities, fields, and operations someone deliberately approved are visible at all.
• An audit trail, with live session tracking and pending-confirmation history.

Together these are what let you hand real capability to more people without handing over more risk. The security and governance documentation covers the mechanics in full.

The cheaper path was never the smaller one

Driving value cost effectively isn't about spending less on a thinner version of the project. It's about not paying to import expertise you already employ.

The generic half of this work — servers, pipelines, protocol churn, transport security — is worth outsourcing precisely because it's generic. The valuable half was never the code. It's the judgment about what an AI should be allowed to do with your ERP, and the people holding that judgment are already sitting in your SAP team, waiting for the barrier to come down.

Ready to hand them the keys? The getting started guide walks through connecting a first service, and the pricing page has the honest side-by-side comparison.