Skip to content
AnrilX

IT & SAP teams

Every report request is a question nobody could ask

Every custom report request is a question somebody could not ask. The backlog never clears because the underlying need is unbounded, and each report you build is a new object to maintain, test and eventually retire.

What gets in the way

Each report is a permanent liability

It is built once and maintained for years. It ages against master data changes, it embeds assumptions nobody wrote down, and it is impossible to retire because you cannot tell who still relies on it.

Self-service BI moved the problem, it did not solve it

An extract layer becomes a second source of truth that disagrees with SAP at month end, and the reconciliation lands back on your team.

An AI that writes SQL is a governance problem

A language model writing queries against production ERP is a plausible-wrong-number generator and an audit finding waiting to happen.

Where you start, and what you get

Questions you can ask on day one

  • “Which entity sets does a given question actually read?”
  • “What did every user ask this month, and what did it cost?”
  • “Which write attempts were refused, and by which policy?”
  • “How long did this turn take, and how many SAP calls did it make?”
  • “Which saved dashboards would break if we renamed this field?”
  • “Which users are near their token budget this week?”

What you get back

  • A model that is structurally unable to write a filter, a date or an entity name
  • Fail-closed policy on every governed call, with your SAP authorisations enforced underneath
  • A complete trace of every model call, tool call and SAP read, including the refused ones
  • On-premise deployment, in your landscape, with no bulk copy of your ERP

What we did instead of letting a model write queries

The whole platform is built around one decision: the model reasons, and code queries.

A question is compiled into a typed specification (which entity, which measure, which grouping, which period token) and code executes it. The model picks an entity from a candidate list the platform assembled from your own catalogue. It never writes a filter string. It never writes a date. A field name it gets slightly wrong is repaired against the live catalogue and the repair is shown, or the question escalates.

That is not a prompt instruction. Those shapes have no representation in the query format, so they are not available to be got wrong.

Everything you can audit

Every model call, every tool call and every SAP read is recorded: the prompt as sent, the response as received, the arguments, the result, the duration, and the reason for anything refused. A refused call is as visible as a successful one, which matters, because a governance layer nobody can see the output of is a governance layer nobody can verify.

The cost of running it

A saved dashboard or report costs zero model calls to render: the view stores a compiled query, so opening it is a database read plus an SAP call. The model is paid for once, when the question was asked. Per-user and per-window token budgets are enforced before a run starts, and what each turn cost is visible to the person who ran it.

One of these questions, answered

Which write attempts were refused, and by which policy?

Eleven refusals this month, none of which reached SAP. Nine were the same policy (pricing conditions are read-only for everyone outside the pricing team), and two were a person acting outside their own SAP authorisations, which the platform does not widen. A refused call is recorded exactly like a successful one.

Policy Refused
Pricing conditions are read-only 9
Outside the user's SAP authorisation 2
Reached SAP 0

Source: Platform audit trail · every tool call, model call and SAP read, with what was asked, what came back, and what was refused and why

A refusal is as visible as a success, and carries the policy that produced it. An audit that only records what happened cannot answer the question an auditor actually asks.

Before a pilot

What it will not do for this role

The limits that bear on these questions specifically.

  • It does not tune your SAP. A slow answer to a heavy question is a signal about the system underneath, and the platform reports what it waited on rather than fixing it.

  • Every question it answers is one that stops reaching your team, which is the point, and it also means your ticket queue stops being a measure of demand. What people ask is visible in the platform's own record instead.

  • A change to your SAP is a change here. Add a field, rename a view or move a service and the catalogue has to be read again; that step is your team's, and the platform says when what it knows has gone stale.

Questions people ask us

What stops a language model writing a bad query against production?

It cannot write one. The query is built in code from a typed specification: the model picks an entity from a candidate list the platform assembled, and there is no slot anywhere in that format for a filter string, a date or an entity name it invented.

What can we audit?

Every model call, tool call and SAP read: the prompt as sent, the response as received, the arguments, the result, the duration, and the reason for anything refused. A refused call is as visible as a successful one.

What does it cost to run once it is in?

A saved dashboard or report costs zero model calls to render: the view stores a compiled query, so opening it is a database read plus an SAP read. The model is paid for once, when the question is asked.

Bring the question your reports cannot answer

Thirty minutes against a live SAP system we provide: no access to yours, nothing to set up. If it cannot answer, you find that out in half an hour rather than three months into a pilot.