REFORGESAPRetail

The AI-native retail stack: what replacing SAP IS-Retail looks like in practice

Sumeet Goenkasaasinator AI9 min read

The map before the build

SAP IS-Retail is rarely one system. At a Middle East retailer of any meaningful size, it is six or seven modules running in the same instance, with the integrator's customisations stacked on top of each. Materials Management for purchasing and supplier handling. Sales and Distribution for the inbound and outbound flows. Warehouse Management for the DC operations. POS Data Management to receive transactions from the till estate. The Customer Activity Repository sitting underneath the loyalty programme. The CRM module that the marketing team uses without ever logging into SAP itself.

A REFORGE engagement against this estate is not a re-platforming project. It is a module-by-module replacement that starts at the workflow furthest from the ERP backbone and works inward. The eight-week pilot retires one workflow cleanly. The next eight weeks retire the next one. The SAP licences shrink at each renewal in proportion to the surface area that has retired. That is the shape of the work.

This piece is the working map we use at kickoff. It is not theoretical. We have run versions of it.

Sprint one — the till

The till is almost always the first workflow we move. The reasons are operational, not theoretical. The store associate population is the largest user community in the estate, the per-terminal SAP cost is one of the most visible lines on the licence bill, the integration surface back to SAP is narrow, and the in-store user experience has had no real product investment in five years. Every store manager who has tried to onboard a seasonal hire knows it.

The new transaction surface is a tablet-first React application. Pricing rules and promotion logic move to a rules engine the commercial team can edit. Receipts and payment-terminal integrations move to direct connections that no longer depend on the SAP-vended middleware. The offline-first queue handles network drops at the store and reconciles cleanly when the connection returns. The single boundary back to SAP carries the goods movements, the financial postings, and the daily reconciliation in the same shape SAP receives them today. To the central finance team, nothing changes.

The pilot store goes live at week eight. The next store cohort goes live on a fixed cadence behind it.

Sprint two — the promotion engine

The promotion engine is where the SAP system most actively punishes the business. Every promotion the commercial team wants to run gets translated into an SAP configuration request, billed by the integrator, and held in a queue. The team that should be designing the next campaign is instead waiting on the integrator's release window.

Moving this to owned software is a clean two-week pilot. The promotion authoring surface, the eligibility logic, the redemption rules, the stacking and exclusion logic — all of it moves to a transparent ruleset the commercial team edits. The output back to the till is a feed the new transaction surface already understands. The SAP-side promotion configuration retires in proportion to the campaigns that have moved.

The integrator retainer that funded the promotion work was a meaningful line on the annual bill. That line shrinks in the first renewal after this sprint.

Sprint three — Customer Activity Repository and the loyalty engine

The Customer Activity Repository is the surface SAP has positioned as the customer-360 layer. In practice it is the storage layer underneath the loyalty programme, the marketing automation, and the personalisation engine. Every system that reads from it carries an indirect-access exposure the licensing team is increasingly attentive to.

Moving the loyalty engine off CAR is the highest-leverage sprint in the sequence. The tier rules, the redemption mechanics, the lifecycle communication, the member-facing surfaces — all of these are workflows the retailer's team can own. The data the loyalty engine reads moves to the warehouse the retailer already operates. The marketing engine reads from the warehouse rather than from CAR. The personalisation engine reads from the warehouse rather than from CAR. The CAR licence retires when the last system that depends on it has moved.

This is the sprint that changes the renewal trajectory.

Sprint four — Warehouse Management and the DC operations

Warehouse Management is the module Middle East retailers most commonly leave on SAP for the longest. The DC operations are mission-critical. The RF-gun integration is brittle in any environment. The 3PL relationships are configured against the SAP boundary. None of that is wrong. The question is whether the workflow on top of the DC is being held back by the WM surface.

The pattern we run here is additive, not replacement. The WM module stays. An agentic layer sits in front of it for the workflows the WM surface does not handle — the receiving exception triage, the cycle-count optimisation, the slotting recommendations, the carrier-selection logic on outbound. The agentic layer reads from SAP through a defined contract and writes back through the existing approval workflow. The auditor's view of the warehouse does not change. The enterprise's productivity does.

The WM licence stays where it is. The integrator's WM retainer shrinks because the agentic layer absorbs the workflow extensions the integrator was billing for.

Sprint five — Materials Management and supplier handling

By the time the engagement reaches MM, the retailer has retired three or four workflows from the SAP surface. The team operating the new systems is the retailer's own. The institutional default has shifted. The MM sprint is a conversation about which supplier workflows are differentiating and which are commodity.

Differentiating workflows — supplier scorecarding, lead-time forecasting, category-specific terms, the negotiation rhythms that the buying team actually run — move to owned software with an agentic layer. Commodity workflows — purchase order issuance, goods receipt confirmation, invoice three-way match — stay on SAP MM. The line between the two is the architectural question. We have an opinion on where to draw it for a Middle East retailer; the buying team has the final say.

What the retainer looks like at the end

The full sequence above takes 12 to 18 months for a mid-sized Middle East retailer. The licence bill at the end is materially smaller than the starting point. The integrator retainer is a fraction of what it was. The platform team operating the replacement is the retailer's own. The 2027 renewal conversation with SAP is a different conversation from the 2024 one, because the surface area being renewed is smaller and the dependency on SAP is no longer load-bearing.

Each sprint is independent. Each sprint pays for itself within the first quarter of operation. The CIO who runs the first one has not committed to the full sequence; she has bought herself the option to run the second one if the first goes well.

The saasinator perspective

The retail CIOs who run this work successfully share two traits. The first is that they ran the first pilot before they understood the full sequence. The second is that they ran the first pilot with their own platform team in the room, not as observers but as the receiving team. The handover is not a phase. It is the architecture.

The vendor's account team is highly invested in framing replacement as a binary all-or-nothing decision. The work above is the proof that it is not. Each sprint is a decision in its own right. Each sprint is reversible if it has to be. None of them require the CIO to commit to a multi-year programme she has not yet validated against her own estate.

How to start

The decision to make this quarter is which workflow flips first. The answer depends on your renewal cycle, your integrator's quarterly billing rhythm, and which workflow your store managers complain about most consistently. Bring those three inputs to a diagnostic and we will tell you which sprint we would run if it were our estate.

Book a diagnostic. Ten working days. Bring the IS-Retail module breakdown, the integrator retainer schedule, and the per-store cost split. We will tell you the order to run the sprints in and what the first eight weeks would contain.


Share this insight