Query scheduling and caching layer for SAP OData connectors

The moment a data analyst at a mid-size manufacturer realizes the SAP stock report they need every morning takes 40 minutes to run — and they have no idea why, or when it will finish — is when they start emailing IT to 'just pull the data for me.' That workaround costs both people time every single day and creates a bottleneck that compounds as the team grows.

The gap persists because SAP's own connector ecosystem is enormous and the vendors building connectors on top of OData — like the one in these complaints — are focused on breadth of coverage, not query performance. Optimizing extraction timing and caching intermediate results would require deep investment in infrastructure that doesn't show up in a feature comparison chart, so nobody does it. The buyer (an IT manager or BI lead) often isn't the person suffering through the slow extractions (the analyst), so the complaint doesn't get loud enough to move the roadmap.

What's concretely broken: users report not knowing 'the exact time of SAP stock table extraction for example MARD,' which means they can't schedule downstream work reliably. The OData interaction is described as 'not sometimes that easy to use' on-premise, and the lack of native querying means analysts pay for additional tools just to do retrieval. This isn't a one-time setup cost — every new report, every new table, every schema change forces the same slow cycle again.

The business case is straightforward: a manufacturer with 10 analysts each losing 30 minutes a day to extraction waits is losing real labor hours, and that scales directly with headcount. The need recurs every time data refreshes — daily, weekly, per shift — which means the pain never goes away without a structural fix.

What to build

Build a scheduling and incremental-cache proxy that sits between SAP OData endpoints and BI tools, learns extraction timing patterns per table (including MARD and similar stock tables), pre-fetches on a configurable schedule, and surfaces a status dashboard so analysts know exactly when fresh data is available without triggering a live extraction.

Where to start

Start with MARD and a handful of the most-extracted logistics tables (MARC, MARA, MKPF) — the tables that every manufacturing customer hits and that have predictable, documentable extraction quirks — so you can promise a specific, demonstrable speedup before touching anything custom.

The hard part

SAP environments are deeply heterogeneous — authorization models, custom tables, and OData service configurations vary enough between customers that a caching layer that works out of the box for one customer may silently return stale or incomplete data for another, making the first few enterprise pilots extremely high-touch.

How it makes money

Annual subscription per SAP instance, tiered by number of OData services cached and frequency of refresh cycles, with a one-time onboarding fee for initial table mapping.