RISE TCO and shadow IT detection.

The shadow SAP estate is the most consistent source of TCO surprise on a RISE engagement. The visible SAP footprint sits in a known set of ECC modules, a known set of named users, and a known set of integrations. The invisible footprint sits in custom add ons, Fiori extensions, niche modules deployed by business units, satellite systems that integrate quietly, and consumption patterns that have grown without governance. The visible footprint is what the SAP account team sizes against. The invisible footprint is what the RISE invoice eventually surfaces, often as a Digital Access true up in year three. A shadow IT scan run before signature is the cheapest way to bring the invisible footprint into the negotiation while the buyer still has leverage.

Why shadow SAP is bigger than the architecture team thinks

The architecture team holds a map of the SAP estate. The map is accurate for the systems that were built by the architecture team. The systems that were built outside the team, including the regional finance tools, the local procurement add ons, the line of business Fiori apps, the analytics flows that read SAP tables directly, and the integrations that move data through middleware the architecture team does not own, do not appear on the map.

Across 500 plus engagements, the shadow SAP estate is rarely below 20 per cent of the visible estate and is often above 40 per cent. The shadow estate consumes API calls that count toward Digital Access. It accesses tables that count toward indirect access. It carries users that should map to higher FUE categories. The shadow estate is invisible to the SAP account team during the proposal phase and becomes visible during the year three true up phase, at which point the price is no longer negotiable.

Where shadow SAP usually hides

The first hiding place is the integration layer. Middleware systems that move data into and out of SAP tables count as document creators under the Digital Access framework. The middleware that the architecture team owns is usually counted. The middleware deployed by business units, including the Boomi tenants set up for regional initiatives, the Mulesoft flows built for partner onboarding, and the ETL pipelines built into the data warehouse, is usually not counted in the SAP sizing.

The second hiding place is the satellite systems. Procurement add ons, expense management tools, treasury workstation extensions, EDI translators, and field service applications often read or write SAP data through API patterns that count as Digital Access. The satellite map is held by the line of business that owns the system, not by the architecture team that owns the SAP core.

The third hiding place is the analytics flow. Direct connections from Power BI, Tableau, and the corporate data lake to SAP tables count under the indirect access rules. The connection is usually invisible from the SAP side because it does not appear in the named user list. It is visible on the analytics side, but the analytics side rarely speaks to the SAP licensing side until a true up notice arrives.

The fourth hiding place is the custom Fiori app estate. The custom apps built by line of business developers on top of SAP, including the regional approval workflows, the local reporting dashboards, and the niche operational tools, often carry users who should map to higher weighted FUE categories. The mapping is rarely revisited unless a sizing exercise forces the conversation.

How to run a structured shadow SAP scan

The scan runs in five steps. The first step is the access log analysis on the SAP core. The log shows every system that called SAP across the prior twelve months, with the volume, the table, and the access pattern. The log is the most reliable source of truth on the shadow footprint, because it captures every integration regardless of who built it.

The second step is the integration platform inventory. The buyer maps every middleware system in the estate, including the platforms owned outside the architecture team. The inventory records the SAP touchpoints for each platform, with the document volume estimated against the platform's own logs.

The third step is the satellite system survey. The buyer asks every line of business owner to list the systems that read or write SAP data, with the integration pattern named for each. The survey usually surfaces five to fifteen systems that the architecture team did not have on the map.

The fourth step is the analytics connection audit. The buyer asks the analytics team to list every direct connection to SAP, with the connection method named for each. The audit usually surfaces three to seven connections that count under the indirect access rules.

The fifth step is the FUE category re mapping. The buyer walks the named user list against the actual usage pattern of each user, with the category corrected where the usage warrants. The exercise usually reveals a 10 to 18 per cent under classification, with the under classification concentrated in the developer, the analyst, and the operational user populations.

Pricing the shadow estate against the RISE proposal

The scan produces a shadow inventory. The inventory is priced against the RISE proposal in three places. The first place is the Digital Access volume. The shadow integration footprint adds to the document count, which adds to the Digital Access cost across the term. The second place is the FUE count. The re mapping adds to the weighted user count, which adds to the subscription cost. The third place is the BTP allocation. The shadow integration footprint, once it is brought onto the BTP layer, consumes BTP capacity at a rate the bundled allocation does not cover.

The pricing exercise typically reveals between 12 and 28 per cent of incremental cost relative to the SAP proposal at signature. On a 25 million dollar deal, the incremental cost runs to three to seven million dollars. The exercise also reveals the true ups that would have landed in year three under the un scanned proposal. The true ups are larger than the negotiated price on the same volume at signature, because the true up mechanism does not carry the discount that the original deal carries.

How the scan changes the negotiation

The scan changes the negotiation in three ways. The first change is that the proposal is now sized against the real footprint, not the visible footprint. The conversation with the SAP account team is no longer about the document count in the proposal but about the document count in reality. The reality is harder to dispute because it comes from the SAP access log.

The second change is that the buyer has visibility into the year three true up that would otherwise have landed without warning. The visibility lets the buyer negotiate a true up cap into the contract, with a defined ceiling on the year over year change in Digital Access volume and a defined price per document beyond the ceiling.

The third change is that the buyer can choose which shadow systems to retire before signature, which to migrate onto the BTP layer, and which to keep outside. The choice changes the BTP allocation conversation, the integration architecture, and the overall TCO. The choice is informed by the scan and is not available to a buyer that has not run the scan.

The cost of skipping the scan

The buyer that skips the scan signs a contract priced against the visible footprint. The contract holds for the first two years, while the visible and invisible footprints diverge quietly. At the year three true up, the SAP team produces an invoice that prices the divergence at the rate inside the contract for true ups, which is rarely the discounted rate from signature. The invoice surprises the buyer, surprises the finance team, and surprises the board.

The cost of the surprise on a typical mid sized deal runs to four to nine million dollars across the term, depending on the size of the shadow estate. The cost is rarely recoverable because the contract has been signed and the leverage has moved. The shadow scan, by contrast, costs a fraction of a percent of the contract value and brings the surprise into the negotiation while the buyer still has the lever to act on it.

Conclusion: the scan is the cheapest insurance on the contract

The shadow SAP scan is the cheapest piece of insurance the buyer can run before a RISE signature. The scan surfaces the integration footprint, the satellite system map, the analytics connections, and the FUE classification drift that the SAP account team is not motivated to discover before pricing the deal. The scan moves the negotiation from the visible footprint to the real footprint, which moves the price from the discounted signature rate to the realistic seven year cost. The buyer that signs without the scan pays the difference at the year three true up. The buyer that signs after the scan pays a smaller difference at the year three true up, with the larger share already negotiated into the contract. The scan is the buyer side equivalent of a survey before a building purchase, and the survey is rarely the place to economise.