Everything a business runs on is already in HANA. The problem is getting it out. Every non-trivial question — which customers slipped from last quarter, where stock is sitting against orders that will not ship, which plants are carrying cover they do not need — turns into a ticket for whoever writes the SQL, and comes back days later as a spreadsheet that answers the question you asked on Monday.
HANA Intelligence removes that round trip. You ask the question in ordinary business language. It queries the live database, and gives you the answer as a table and a chart you can read immediately. Then, when the answer implies something should be done, it carries you through to doing it — under the same approval and audit controls as the rest of our platform.
Ask it the way you would ask a colleague
There is no report to pick, no cube to understand, no field names to learn. You ask what you actually want to know, and follow up the way you would in conversation — 'now split that by plant', 'only the ones above fifty thousand', 'compare it to last year'. Each follow-up keeps the thread of what you were looking at.
What comes back is the data, not a paragraph about the data. A table you can read down, and a chart chosen to suit the shape of the answer. The figures are the database's, retrieved on that request.
Questions cannot become changes
Asking a question is a read. That is enforced by the platform, not by asking the model nicely: a generated query that is anything other than a read is rejected before it reaches the database, and the connection it runs on has no authority to write. Nobody can phrase a question in a way that deletes a row.
This matters more than it sounds. The usual objection to letting a language model near a production database is exactly this scenario, and it is the reason most of these projects never leave the demo. We closed it structurally so the product can actually be pointed at live data.
End to end: the answer leads to the action
An analytics tool stops at the chart. The gap between seeing a problem and fixing it is where the time really goes — you find the shortfall, then start a separate process with separate people in a separate system to do anything about it.
Here the agent continues. From the same conversation it proposes the action the data implies, states exactly what will change, and sends it for approval. Nothing commits on the agent’s say-so.
- Whoever proposed an action cannot approve it — segregation of duties is enforced by the platform.
- Approval routing follows your own thresholds: value bands, risk, and who is allowed to sign off on what.
- The data behind a decision is re-read at the moment of commit; if it has moved since you looked, the action stops rather than posting against stale figures.
- Every step — question, query, result, proposal, approver, outcome — lands in an append-only audit trail you can verify has not been altered.
It says when it does not know
If a question is ambiguous, the agent asks which reading you meant instead of picking one. If the data needed to answer it is not there, it says so. We treat both as correct outcomes, because a confident wrong answer about your own business is worse than no answer — it gets acted on.
Who it helps
Operations and planning people get answers in the moment they need them, instead of a queue. Analysts stop being a lookup service for other people’s questions and get their time back for the work that needs their judgment. And leadership gets something a BI dashboard cannot give: a path from the number on the screen to the decision taken on it, with the entire chain recorded.