SAP runs the core.
Everything around it runs on Excel.
Clean core means your custom requirements have to live somewhere. Today that's Excel, Access and Z-tables. dForge is a governed application layer next to SAP — never a replacement: data model, roles, workflows, reports and audit from one definition, on PostgreSQL, in your own environment.
Internal slides hidden. Open with the deck key to show them.
What we'll cover.
- 01The spreadsheet ring around the core
- 02Why clean core pushes custom logic outside
- 03A governed application layer next to SAP
- 04Security, data and where it runs
- 05The first side process
The ring of spreadsheets around the core.
SAP handles the core processes well. It's everything around them — the approvals, requests and exceptions — that ends up in places nobody governs.
- Every custom requirement is a choice between a core modification and another spreadsheet.
- The S/4HANA move forces a decision on years of Z-code — keep it, rewrite it, or drop it.
- Store requests, price approvals and claims run on Excel files emailed between teams.
- Even a small side application still costs a quarter — specs, a project, a transport cycle.
Next to SAP, not instead of it.
SAP keeps the core. dForge takes the side processes that never belonged there — and gives them the governance a spreadsheet never had.
Keep the core clean
Custom requirements move out of Z-tables and core modifications into a separate application layer. SAP stays standard, and your upgrades stop depending on custom code.
Replace the spreadsheet ring
The Excel and Access tools around SAP become governed applications: a real data model, roles, workflows, reports and an audit trail — all from one definition, not a pile of files.
Your perimeter, your database
One PostgreSQL database per customer, row- and column-level security, a full audit trail, and self-hosting in your own environment. Your data doesn't leave the perimeter you control.
What that looks like in practice.
- Custom logic lives beside SAP, not inside it.
- Fewer Z-tables and modifications to carry through every upgrade.
- A clearer answer for the S/4HANA Z-code decision.
- Data model, roles, workflows, reports and audit from one definition.
- Approvals and hand-offs replace files emailed between teams.
- A side application in weeks — not a quarter.
- One PostgreSQL database per customer.
- Row- and column-level security, full audit trail.
- Self-host in your own environment.
Core mods & Excel vs. a governed layer.
Modules worth installing first.
Warehouse Management
Warehouse management: procurement requests, PO workflow, stock operations, inventory tracking. Vendor identity lives in the shared parties module; WMS-specific columns (supplier code, payment terms) are layered as an extension.
Pricing
Product pricing, price lists, discount rules, and cost tracking (WAC)
Finance
Accounts receivable, accounts payable, invoicing, and payments
Sales CRM
Sales CRM: contacts, leads, opportunities, quotes, activities, and product catalog. Customer identity lives in the shared parties module; CRM-specific columns (industry, credit limit, account manager) are layered on as an extension.
The questions people actually ask.
Scroll down for the answers — or jump straight to one.
Is dForge a replacement for SAP?
No. dForge is an application layer next to SAP, for the side processes around the core — requests, approvals, claims, exceptions. SAP keeps finance, logistics and everything else it runs today. The point is to keep the core clean, not to compete with it.
How does dForge connect to SAP?
dForge exposes a JSON-RPC API and webhooks. Your SAP integrator connects the SAP side using the standard SAP interfaces you already run. There is no packaged SAP connector — the integration is built for your landscape, and you control it.
Where does dForge run?
dForge runs as containers on PostgreSQL — hosted by us, or in your own environment, including on Kubernetes such as SAP BTP Kyma. dForge is not SAP-certified.
Which sign-in options are supported?
Today: email and password, and Google sign-in. Enterprise single sign-on via OIDC (for example SAP IAS or Microsoft Entra ID) is designed but not yet available.
How is our data protected?
Each customer gets its own PostgreSQL database. Access is controlled by roles with row- and column-level security, every change lands in an audit trail, and backups are taken per workspace. If your policy requires it, you self-host dForge inside your own perimeter.
Pick the spreadsheet that hurts most.
One side process, beside SAP, with roles and audit from day one. The core stays untouched.
Inventory the ring
List the spreadsheets, Access tools and Z-tables around SAP — who uses them, what they feed, what breaks when they're wrong. Pick the one that hurts most.
Model it and connect it
We model the process as a dForge module. Your SAP integrator connects SAP to our JSON-RPC API and webhooks, using the standard SAP interfaces you already run.
Run beside SAP, then expand
The first process goes live next to SAP with roles and audit in place. Then the next one — on the same model, the same database, the same security.