Ask your SAP.Get an answer,
not a ticket.
dodo Sage is an AI platform that connects to the SAP system you are running right now — reads the tables it needs, writes the code, ships the app, and forecasts what comes next. No data pipeline. No warehouse. No four-week queue.
“Why did unit cost jump in Plant B last week?”
Plant B unit cost rose +8.4% week over week.
Driver: scrap rate on line 2 moved 3.1% → 7.6% after material lot MLT-2291 switched supplier on 24 Jul.
4 tables · 11,204 rows · full query available on request
Representative session. Table names and figures are illustrative.
Measured in proof-of-concept
The same SAP work,
at a different speed.
Observed across proof-of-concept engagements with three enterprise SAP landscapes.
The gap
ERP was built for systems. People were not.
One question travels through four people and comes back after the decision has already been made.
- Day 1The question becomes a report request in the IT queue.
- Day 3A consultant rewrites it as a functional spec.
- Day 8An ABAP developer builds and tests the extract.
- Day 14A BI analyst turns it into a dashboard nobody opens twice.
Two languages, one system
The loop
Analysis to implementation.
One loop, one product.
Not an analysis tool. Not a coding tool. dodo Sage owns the whole cycle from decision to execution.
The empty seat on the map
BI tools serve the business side only. Dev tools serve IT only. SI consultants run this loop by hand — in about two weeks per turn. No product owns the whole loop.
Champion and gatekeeper, both on board
Business teams become the champion; IT stays the validator. That matches how enterprise purchases actually get made.
Why users are unlimited
The loop only completes when both sides are in it — so we never charge per seat. One product, unlimited users per SAP instance.
The loop closes, but people hold the keys — every transition is approved by a human.
Six commands
One prompt line.
Six things it can do to your SAP.
Pick a command to see a real exchange. Every step is yours to approve — this is delegation, not autonomy.
Showing /sap · 1 of 6
Ask the running system in any language. dodo Sage reads the data dictionary, picks the right tables and CDS views, and answers with its sources attached.
Your IMG configuration, custom Z-tables and existing ABAP are embedded first — so answers follow your business rules, not generic SAP defaults.
“Which customers are past due more than 60 days, and how much is at risk?”
$184M across 17 customers is past 60 days.
Top exposure: Atlas Industrial Supply — $31M, 143 days, credit limit exceeded twice this quarter.
Several agents argue the same decision from different seats — operations, finance, supply chain — each grounded in your live numbers rather than opinion.
It is most useful when one answer looks right but nobody can articulate why the other one is wrong.
“Should we switch material MLT-2291 back to the previous supplier?”
3 perspectives · 5 tables · assumptions listed in full report
Turns a business goal into an SAP technical specification: which configuration points move, which objects are touched, what custom code is affected, and how much effort it really is.
Written in the format your consultants already review, so it drops straight into your existing change process.
“Block sales orders when a customer's credit exposure passes 80% of limit.”
Spec exported to Word · ready for your change board
Writes Clean ABAP against your real objects and naming conventions — not textbook examples. Development systems only, never your production core.
Every change moves through your own CTS transport process, is versioned, and can be rolled back. dodo Sage works inside your governance rather than around it.
“Implement the credit exposure check from the spec above.”
" Credit exposure check — generated from spec ZSPEC-0412 METHOD check_credit_exposure. DATA(lo_limit) = zcl_credit_limit=>get_instance( iv_kunnr = is_order-kunnr ). DATA(lv_ratio) = lo_limit->exposure_ratio( iv_horizon_days = 30 ). IF lv_ratio >= zif_credit=>c_threshold_block. rs_result-status = zif_credit=>c_status_blocked. RETURN. ENDIF. ENDMETHOD.
Unit test generated · 7 cases · all passing. Ready for review in DEVK903118 — nothing has moved to QA or production.
A complete app, not a snippet. dodo Sage writes the CDS view, defines the RAP behaviour, exposes the OData V4 service and generates the Fiori Elements application — annotations included.
What normally takes a Fiori developer two weeks lands in your development system the same afternoon, ready to review.
“Build an approval app for sales orders blocked by credit.”
4 objects generated · transport DEVK903121 · rollback available
Pulls the time series straight out of SAP — movements, orders, postings — engineers the features, then runs AutoML across candidate models and keeps the one that actually validates.
No export to a data science team, no separate platform. The history is already in your system; the forecast comes back into it.
“Forecast demand for MLT-2291 over the next six months.”
Demand rises +14% into Q1, peaking in March. Current reorder point covers 11 of 26 weeks.
Watch
See dodo Sage run against a live SAP system.
A short walkthrough of the six commands — asking the running system, generating ABAP, and shipping a Fiori app without a data pipeline.
/fiori in depth
From a sentence
to a working Fiori app.
Most AI coding tools stop at a snippet. A Fiori app is not a snippet — it is a data model, a behaviour definition, a service, and a UI layer that all have to agree with each other. dodo Sage generates the whole chain.
- 01
CDS view
Derives the data model from your real tables, including custom fields and the associations your consultants already use. Annotations for labels, value helps and semantics are written in.
- 02
RAP behaviour definition
Defines what the app can actually do — draft handling, validations, determinations, and the actions your process needs, mapped to your authorisation objects.
- 03
OData V4 service
Service definition and binding generated and activated, so the app talks to the system through the standard channel rather than a bespoke integration.
- 04
Fiori Elements application
List Report and Object Page generated from the annotations — meaning it stays consistent with SAP's own design system, and future changes regenerate cleanly.
@AccessControl.authorizationCheck: #CHECK @EndUserText.label: 'Credit-blocked sales orders' define root view entity ZC_CreditBlockedOrder as select from vbak association [0..1] to I_Customer as _Customer on $projection.Customer = _Customer.Customer { key vbeln as SalesOrder, kunnr as Customer, netwr as NetValue, zcredit_status as CreditStatus, _Customer } where zcredit_status = 'B';
/forecast in depth
Your history is already in SAP.
So is the forecast.
Forecasting projects usually die in the export step — extract the data, hand it to analysts, wait, then find nobody can put the result back into planning. dodo Sage never leaves the system.
Extraction, not export
Material movements, order history and postings are read in place. Nothing is copied to a warehouse and nothing leaves your network.
Features from your own calendar
Seasonality, promotion periods, plant shutdowns and lead-time shifts are derived from your configuration — not assumed from a generic template.
AutoML with honest validation
Candidate models are compared under walk-forward validation. dodo Sage reports the error rate and the runner-up, so you can judge whether to trust it.
A result you can act on
The forecast connects back to planning parameters — reorder points, safety stock, MRP settings — through /plan, inside your normal change process.
AutoML run · MLT-2291
Where your data stays
Your infrastructure. Your keys.
Your vector store.
This is the first question every SAP team asks, so it belongs on the front page rather than buried in a security questionnaire.
No dodo servers
dodo Sage is deployed inside your network. We do not host a copy of your system and we never receive your data.
Your model account
Model calls route through your own Vertex AI or Bedrock credentials. You see every request and you own the bill.
Context stays yours
The vector store built from your configuration and custom code is your asset. It stays on your side and leaves with you.
Auditable by default
Every answer can show the tables read, the code generated and the rows returned. Turn on trace and watch the whole path.
Bring one real question. We will answer it on your system.
A PoC runs two to four weeks on a sandbox or development instance, and starts with success criteria we agree on before anything is installed.