Case study: How a chemical company achieved a double-digit reduction in SAP license costs through FUE analysis before migration

Project work meeting questions raised by the project team, before the initiative?

• How many FUEs will we realistically need in the new S/4HANA environment?
• How do our current roles and authorizations affect future FUE classifications — and costs?
• Can we use the S/4HANA migration as an opportunity to reduce Segregation of Duties (SoD) risks?
• Should role redesign be treated as a separate initiative, or integrated into the S/4HANA transition?
• Which users, roles, or departments are likely to drive the highest licensing costs?
• What access cleanups or adjustments can we make now, before signing a new agreement?
• How can we proactively manage the FUE model long-term — especially as licensing costs often rise after year 3? (most organizations only plan with a 3-year horizon, but FUE contracts typically become more expensive beyond that.)
• Can we use a standard SLIM*USER report and how does it surf our purpose?

Introduction: Why FUE Matters

Transitioning to SAP S/4HANA is a major milestone, yet licensing is often overlooked. With the shift from Named User to Full Use Equivalent (FUE) licensing — especially in RISE with SAP contracts — licensing is no longer tied to user identity but to the authorizations granted. This means your access design directly affects your future costs. FUE licensing, which prices access based on assigned authorizations (not actual usage), can be 50–150% more expensive than usage-based models. Without strategic preparation, costs can soar

Read First:   SAP RISE FUE – Is it just a new metric, or a whole new pricing model?

This article takes the discussion further based on our case-study results.

We present a real-world case study of a large chemical manufacturing company that conducted a structured FUE analysis before migrating to S/4HANA. The outcome? A double-digit reduction in projected FUE consumption, leading to measurable savings and a stronger position in licensing negotiations with SAP.  Before starting the project we searched extensively for official SAP materials comparing licensing models but found none official comparison, authorized by SAP (or either we couldn’t found or there is no one). Based on discussion with industry experts and SAP consultants have noted that applying a straightforward “lift-and-shift” approach — transferring existing user roles and authorizations from SAP ECC to S/4HANA without modification — can lead to higher licensing costs under the FUE model, especially in longer than 3 years period of time. This is because the FUE model assigns license costs based on the activities users are authorized to perform, rather than their job titles or departments. Consequently, roles that were cost-effective under the Named User model may incur higher costs if not re-evaluated for FUE compliance.

Kill two birds with one stone

However, this challenge also presents an opportunity. By conducting a thorough analysis of user roles and aligning them with actual business needs, organizations can identify areas where not only security can be improved,  access can be streamlined or reclassified, but it can deliver significant cost savings. This requires however not only applying a reasonable Named User to FUE model transition, but also by leveraging the new model as a driver for authorization access reduction, limiting access to only the transactions actually used. This proactive approach ensures that licensing expenditures are optimized and aligned with the organization’s operational requirements.

1. Initial situation – the Client story

The client in this case is a large chemical manufacturing company operating across several European countries. Their SAP ERP system, based on ECC, had been in place for over a decade. Over that time, user roles had been created and modified organically—often through copying, expanding, or assigning authorizations “just in case.” By the time the company started planning their migration to SAP S/4HANA, their environment included:

• Over 2,500 active SAP users,
• Hundreds of thousands roles — many of which were overlapping or outdated,
• Overall extensive authorizations with segregation of duties risks in many business areas
• Numerous “power users” with broad access due to copied roles from admin or test environments,
• A license model based on Named Users, with categories like Professional, Limited Professional, and Employee.

The organization was aware that with the move to RISE with SAP, they would be forced to adopt the new Full Use Equivalent (FUE) licensing model. What they didn’t know was how many FUEs they really needed, or how their current role design would translate into this new cost model.

Key questions raised by the project team:

• How many FUEs will we realistically need in the new S/4HANA environment?
• How do our current roles and authorizations affect future FUE classifications — and costs?
• Can we use the S/4HANA migration as an opportunity to reduce Segregation of Duties (SoD) risks?
• Should role redesign be treated as a separate initiative, or integrated into the S/4HANA transition?
• Which users, roles, or departments are likely to drive the highest licensing costs?
• What access cleanups or adjustments can we make now, before signing a new agreement?
• How can we proactively manage the FUE model long-term — especially as licensing costs often rise after year 3? (most organizations only plan with a 3-year horizon, but FUE contracts typically become more expensive beyond that.)

Before the project the team only suspected that a simple one-to-one migration of current roles (the so-called “lift-and-shift”) might cause a sharp increase in license costs.

2. False Start: Why SLIM report failed

The customer’s initial approach was to use the standard SAP-provided report included in SAP Note 3113382, designed to help organizations estimate licensing needs under the Full Use Equivalent (FUE) model. While it seemed like a reasonable starting point, this technical tool quickly revealed its limitations and proved insufficient for building a cost-optimized license strategy. The report (SLIM_USER_CLF_HELP) calculates licensing needs based on current ECC authorizations for user or role. On paper, it promises clarity. In practice, it often generates confusion and requires extensive manual interpretation.

Why the Initial Approach Failed:

❌A. Not Designed for Flexibility or Strategic Decisions

The report assumes the current state of role assignments is correct, relevant, and reflective of actual business needs. In reality, years of overprovisioning and role drift mean this assumption is often invalid — leading to overestimated license needs.

❌B. Complex and Rigid Data Structure

The tool relies on a ruleset of 700+ authorization objects and over 2,000 value-based conditions to determine license type. This includes nuanced mappings like:

• ACTVT=03 (display) → Self-Service
• ACTVT=01 (create) → Core or Advanced

But even one mistakenly included object (e.g. M_RECH_BUK with create rights) can upgrade a user from Core to Advanced licensing — regardless of actual usage.

In the client’s case, trying to analyze the raw output became a burden. The interface (as shown in the role details report) demands painstaking manual investigation: “First, I see the user and what license they supposedly need. Then I check which roles they have — and which license each role pushes them into. Next, I click into each role to investigate the specific authorization objects triggering the classification. It’s extremely time-consuming” was a customer feedback.

The report does not offer perspectives by business process, user type, or application, making it hard to spot optimization potential. It presents technical detail without context — forcing security or license teams to reverse-engineer relevance role by role. What’s missing is prioritization. Ideally, the tool would help identify “low-hanging fruit” — users who only need 10–20% of their current authorizations adjusted to qualify for a lower license tier. Instead, it treats all users equally, often starting with those whose profiles would require 80%+ redesign, which is much less cost-effective to tackle first. Even more critically, it would be extremely helpful to combine the license-driving objects with actual usage data. Knowing whether a transaction or object is actually used — and by whom — would turn this from a theoretical classification tool into a practical, strategic decision aid. A particularly valuable output from these sessions was the ability to pinpoint exactly which role was responsible for upgrading a user to a higher license tier. In many cases, it was just one role. By checking whether the user actually used any transactions from that role — and finding out they often didn’t — the team was able to remove the unnecessary assignment. This simple step resulted in immediate FUE reduction without impacting business operations.

❌ C. No Simulation, No What-If Scenarios

The report does not support simulation. You cannot answer simple, strategic questions like:

• “What if I remove this object?”
• “What if I split this role into display and edit variants?”
• “How does usage affect classification?”

This is especially limiting when roles are shared across users. You may want to downgrade one user’s license, but the tool does not account for shared role impact or suggest how to adjust roles safely.

❌D. Manual, Siloed Execution Flow

Running the tool requires uploading and managing rulesets manually via file import. There’s no central governance or integration with the role design process, provisioning flows, or user activity monitoring. Additionally:

• Background execution is unavailable in some systems,
• There’s no real-time integration with actual usage data,
• It doesn’t consider custom authorization objects, which many companies rely on heavily.

❌ E. SAP’s Own Recommendation: Use STAR Service

Even SAP acknowledges that the report is limited. The documentation explicitly recommends supplementing it with the SAP Trusted Authorization Review (STAR) — an expert service for interpreting and validating results. That alone indicates the tool is not sufficient for licensing strategy without significant manual effort and external support.

3. Revised Approach: GRC and Business-Led Optimization

Recognizing the limitations of their initial methodology, the client pivoted to leverage their existing GRC Access Control solution — specifically the Access Risk Analysis (ARA) and Business Role Management (BRM) modules. As an alternative, they could have used an alternatives tools like smartGRC, which offers comparable — and in some cases enhanced — capabilities.

The adoption of GRC tooling brought measurable improvements, thanks to features such as:

• License simulation – instantly testing how changes to roles or objects would affect FUE classification,
• Ruleset flexibility – quickly adapting license classification logic in response to SAP criteria changes,
• Usage integration – identifying unused transactions or roles over the past 6 or 12 months,
• License visibility – directly linking required license types to roles, users, and access requests.

However, the most impactful shift didn’t come from the tool itself — it came from involving the right people. The real game-changer was the workshops with Business Stakeholders. The breakthrough came with a series of joint workshops that brought together a cross-functional team:

• SAP Security consultants, who understood the technical design of roles and authorizations,
• Functional consultants, who knew which transactions supported specific processes,
• Business stakeholders — including key users, department heads, and process managers — who had insight into process flows, compliance obligations, and real user needs.

These workshops bridged the gap between raw license data and operational reality. They enabled informed, actionable decisions by answering key questions:

• Does this role really need change access, or is display access sufficient?
• Can the role be split into two personas to reduce the license tier?
• Is this transaction still relevant?
• Can a user group be moved to self-service if the process is streamlined?

This collaborative approach enabled the organization to redesign access with both security and cost-efficiency in mind, avoiding reliance on outdated assumptions or legacy role structures.

Workshop Outcomes

By combining technical insights with business context, the organization achieved:

• A clear, transparent view of true licensing exposure,
• Confidence to negotiate their FUE contract with SAP based on data and business rationale,
• A double-digit reduction in projected FUE requirements — even before migrating a single user to S/4HANA.

4. Measurable Results: From Complexity to Clarity

After shifting from a purely technical estimation to a business-aligned licensing strategy, the organization was able to turn complexity into clarity — and projected costs into real savings. By combining GRC tooling with structured business validation, they achieved tangible outcomes across multiple dimensions:

✅ Double-Digit reduction in FUE count

Through simulation, cleanup, and role redesign, the company reduced its projected FUE consumption by over 15% — all without compromising operational needs or user experience.

✅Elimination of unused or inflated access

Roles and transactions assigned to user and unused for 12+ months were flagged for removal. These included:

• Technical/test roles,
• Inherited admin authorizations,
• Copied roles that had no valid business justification.
• No longer valid due to organizational changes access

✅ Role simplification and splitting

High-cost roles were redesigned into distinct variants (e.g., “display-only” vs “editor”). As a result, many users were reclassified from Advanced to Core or Self-Service, drastically reducing licensing cost per user.

✅ Smarter license allocation

Licenses were reassigned based on actual system behavior rather than job titles or outdated mappings. Over licensed users — common under the previous approach — were corrected based on real usage patterns.

Additional Insights: Lessons from the field

Several key learnings emerged that are highly relevant for organizations reviewing their FUE exposure:

• Small changes in activity values (e.g., changing “edit” to “display”) can significantly affect FUE classification.
• Shared roles used across divergent personas distort the true licensing picture.
• Fiori app catalogs often bundle multiple backend transactions — silently inflating license costs.
• GRC tools are most powerful when paired with real usage data and business context.

6. Key Takeaways & Summary

• Start Early- licensing begins with role design – leaving licensing to the final stages of a project is a costly mistake. Access design decisions made early have a direct financial impact on the FUE count.
• Don’t Rely on raw reports alone -tools like SAP Note 3113382 offer a starting point — but lack simulation, clarity, and business context. GRC solutions (SAP GRC AC or alternatives like smartGRC) bring the real value when paired with usage and role redesign.
• Engage the business – context changes everything – The biggest lever for optimization wasn’t the software — it was business engagement. Workshops brought in real-world understanding that no tool alone can provide.
• Combine simulation + usage for control Simulating FUE impact and aligning it with actual usage data enabled confident, data-driven cleanup and license optimization.
• Make licensing part of access culture – embedding FUE awareness into daily provisioning created a culture of continuous cost control — where every access request was a chance to validate cost vs. need.

FUE is not just a metric — it’s a new operating model. Organizations that treat it like a contract checkbox will lock in unnecessary costs. Those that approach it as a design and governance decision will unlock long-term value. This case study shows that with the right tools, data, and people, SAP licensing can shift from a financial risk to a strategic advantage — and stay optimized beyond go-live.

—

Sources:

• E3 Magazine: The publication notes that “entitlement-based licensing is on average 50 to 150 percent more expensive than usage-based licensing,” emphasizing the financial impact of SAP’s authorization-based approach. E3-Magazin
• Redress Compliance: Their analysis indicates that “authorization-based licensing is typically 50–150% more expensive than usage-based licensing,” underscoring the potential for increased costs if licenses are not optimized. com
• SAP Licensing Experts: They mention that such models can be “50–150% more expensive than true usage-based models if they are not optimized,” suggesting that careful license management is crucial to control expenses.