SAP FUE by Design: så styr du aktivt licensklassificeringen i ett SAP S/4HANA-projekt

En SAP S/4HANA-implementation genererar dussintals, ofta hundratals designbeslut: nya Fiori-applikationer, processutökningar, rollförändringar, nya behörighetsobjekt, ytterligare aktiviteter eller åtkomst till fler organisationsenheter. Var och en av dessa ändringar kan potentiellt påverka användarklassificeringen i FUE-modellen.

Den naturliga reflexen är därför att försöka utvärdera varje Change Request ur ett licensperspektiv. Ett sådant tillvägagångssätt är möjligt, men vid större projektskala blir det snabbt dyrt, inkonsekvent och svårt att underhålla. Å andra sidan betyder mätning av FUE först efter go-live att vi inte styr risken - vi mäter bara dess resultat.

Rätt mål är därför inte "räkna FUE så tidigt som möjligt", utan styr FUE iterativt medan lösningen mognar.

1. Problemet: FUE dyker upp i projektet mycket tidigare än vid revision

I ett typiskt projekt dyker frågan om FUE-påverkan upp med efterföljande CR:er. Teamet vill till exempel rulla ut en ny applikation för massorderskapande, eller utöka Purchaser-rollen med funktioner relaterade till RFQ:er, leverantörsoffert eller kontrakt. På affärsnivå kan ändringen se oskyldig ut, men tekniskt kan den innebära en ny Fiori-katalog, nya behörighetsobjekt och ytterligare aktiviteter.

Problemet är att i konceptfasen finns de slutgiltiga rollerna och kompletta behörigheterna ofta inte ännu. Det är därför omöjligt att utföra en full teknisk klassificering av användare. Det betyder dock inte att FUE-ämnet ska skjutas upp till projektets slut.

1a. Varför denna utmaning är strukturell, inte personlig

Det är värt att stanna upp en stund och förstå varför denna utmaning är så svår att lösa i den klassiska arbetsmodellen. Det handlar inte om god vilja - det är ett strukturellt informationsproblem, där båda sidor arbetar med begränsad kunskap.

Kundens perspektiv

SAP:s licenspolicy för RISE with SAP och S/4HANA-miljöer är komplex och utvecklas. FUE-modellen ersatte klassiska Named User-licenser - istället för att räkna användare efter nominella licenstyper mäter den den effektiva behörighetsomfattningen. Samma användare kan klassificeras som Core Use eller Advanced Use beroende på en enda aktivitet i ett behörighetsobjekt.

Under projektet lär sig kunden funktionaliteten just nu - vad en specifik Fiori-applikation gör, hur en ny process fungerar, vilka varianter utökningar har och vilka behörigheter som kommer att krävas. Samtidigt är de medvetna om att varje beslut om en utökning har licenskonsekvenser. Det ansvarsfulla beteendet är att fråga om påverkan innan man beslutar. Men för att fråga vettigt behöver man ett verktyg - och kunden har inte ett ännu.

Konsultens perspektiv

Funktionskonsultens mål är systemkonfiguration och leverans av en affärslösning. Kunskap om FUE-måttet, de 7 licensklasserna, kombinatoriken av Auth Object + Field + Value är en specifik teknisk-licensmässig kompetens som bara en relativt liten grupp specialister besitter. Inte varje funktionskonsult bär den i sitt naturliga kompetenspaket - och det är rätt, eftersom deras primära uppgift är att leverera en fungerande affärsprocess, inte en licenskalkylator.

Utan ett verktyg som omedelbart visar effekten av en ändring på användarklassificeringen skulle konsulten behöva: lära sig FUE-rulesetet (v1.69, 3 100+ regler), köra en användarpopulationsanalys, utföra en kombinatorisk beräkning - allt för varje enskild CR. Detta är extra specialisering och extra arbete som inte får plats i det klassiska implementeringsomfånget.

Informationsparadoxen

Kunden vet att de borde känna till FUE-påverkan före beslut - men de har inget verktyg ännu som skulle visa det. Konsulten vet hur man implementerar funktionaliteten, men har ingen naturlig kunskap om hur det kommer att översättas till licensklassificering. Resultat: båda sidor gör sitt bästa, men räkningen dyker upp först vid projektets slut.

I SAP FUE-sammanhang innebär det ett verktyg som:

• Har aktuella data om roller och behörigheter över alla kundens SAP-instanser,
• Har det aktuella FUE-rulesetet laddat (för närvarande v1.69) och en mekanism för att uppdatera till framtida versioner,
• Vet vad som finns i rollerna idag och vad användarna faktiskt använder,
• Kan simulera hur det kommer att förändras när vi lägger till ny funktionalitet - med konkret effekt på användarpopulationen,
• Presenterar resultatet i ett format som kund och konsult tillsammans kan diskutera före projektkommitténs beslut.

Endast med ett sådant verktyg kan kunden besluta ansvarsfullt, och konsulten kan tillhandahålla komplett information utan behov av manuell analys per CR. Marknadsutmaningen som beskrivs i början blir genomförbar - inte genom teamhjältemod, utan genom att ge teamet rätt verktyg.

2. Tre mognadsnivåer av FUE-analys

FUE by Design - konceptfas

I början analyserar vi inte roller, utan planerade affärsfunktioner. Målet är ännu inte en slutlig användarklassificering, utan att identifiera scenarier som kan vara drivare av en högre FUE.

• Scenario A: användaren skapar bara en inköpsrekvisition.
• Scenario B: användaren kör RFQ:er och jämför offerter.
• Scenario C: användaren väljer dessutom en offert och skapar ett kontrakt eller en inköpsorder.

I denna fas är det scenarioanalyser och "vad om"-frågor som är meningsfulla: vad händer med klassificeringen om vi utökar processomfånget med ytterligare en affärsfunktion?

FUE by Authorization - byggfas

När roller, kataloger, applikationer och behörighetsobjekt börjar konfigureras kan analysen göras mer detaljerad. Istället för att bedöma en allmän processbeskrivning kan vi peka på specifika element som påverkar klassificeringen.

Till exempel definierar objektet M_BEST_EKO omfattningen av inköpsorganisationer, men antalet värden som tilldelas en användare ändrar inte FUE i sig. Vad som spelar roll är kombinationen av objekt, aktivitet, affärsfunktion och hela den effektiva behörighetsomfattningen.

I denna fas kan what-if-analysen svara på en mycket mer praktisk fråga: "vad händer med användarklassificeringen om vi lägger till denna applikation, katalog, objekt eller aktivitet till rollen?"

FUE by Usage - efter go-live

Efter go-live dyker ett ytterligare datalager upp: faktisk systemanvändning. Vi kan då jämföra vad användaren har tilldelat med vad de faktiskt använder. Detta skapar möjligheten att optimera roller och identifiera enskilda behörigheter som i onödan höjer klassificeringen.

FUE-mätning efter go-live är därför nödvändig, men i sig är det inte styrning. Styrning börjar när effekterna av beslut kan bedömas innan de rullas ut.

3. Varför manuell analys per CR inte skalar

Teoretiskt kan GRC-teamet granska varje CR separat: analysera funktionen, rollerna, objekten, aktiviteterna och potentiell FUE-påverkan. I praktiken fungerar denna modell bara med ett litet antal ändringar.

• CR:er dyker upp snabbare än de kan analyseras manuellt.
• Roller ändras efter den ursprungliga bedömningen och slutsatsen blir snabbt föråldrad.
• I konceptfasen saknas ofta tekniska data.
• Samma funktion kan implementeras av olika applikationer och roller.
• Manuell bedömning beror på några få personers kunskap och är svår att reproducera konsekvent.
• Excel, möten och punktvisa analyser skapar en kontrollprocess, men inte en mekanism för kontinuerlig styrning.

3a. Hur FUE-påverkananalys faktiskt ser ut - SAP:s riktlinjer

För att förstå problemets skala hjälper det att se hur den officiella mappningen av behörigheter till licensklassificering ser ut. SAP tillhandahåller ett FUE-ruleset för RISE with SAP Private Cloud Edition (aktuell version: 1.69), som mappar kombinationer av behörighetsobjekt till 7 huvudsakliga licensklasser.

Varje regel är en kombination: Auth Object + Auth Field + Auth Value. Exempel - en regel som klassificerar en användare som Advanced Use (GB):

Rule Description: GB Advanced Use
Auth Object:      F_ACES_PER
Auth Field:       ACTVT
Auth Value:       02, 30, 39, F1, UL

Om en användare har behörighetsobjektet F_ACES_PER med aktivitet 30 i sina roller klassificeras de som Advanced Use.

En klassisk dold fälla - transaktion BP (Business Partner):

• ACTVT=03 (Visa) → användaren klassificeras som Self-Service Use (lägsta kostnad)
• ACTVT=01/02 (Skapa/Ändra) → automatiskt Core eller Advanced Use (tiotals gånger dyrare)

En skenbar "liten skillnad" mellan Visa och Ändra i en enda transaktion kan flytta hundratals användare från Self-Service (0,033 FUE) till Advanced Use (5-10× mer FUE). Vid en genomsnittlig taxa på ~2 000 € per FUE per år är en sådan förändring i en oskyldigt utseende CR konkret tiotusentals, till och med hundratusentals euro i extra licenskostnad.

SAP tillhandahåller rapporten SLIM_USER_CLF_HELP (Note 3113382) som utför en initial FUE-klassificering - men SAP själv noterar i dokumentationen att resultatet kräver expertvalidering (STAR Review-tjänsten) och inte tar hänsyn till anpassade behörighetsobjekt eller faktisk systemanvändning.

Varför detta är svårt i praktiken

• Regelvolym - 3 100+ poster att analysera. En funktionskonsult kan inte detta ruleset utantill och känner inte ens till alla behörighetsobjekt.
• Kombinatorik - användaren får MAX av sina behörigheter, inte SUMMAN. Om användare X redan har Advanced Use från FI förändrar inte tillägg av Core Use från MM någonting. Men om användare Y är i Self-Service Use "uppgraderar" samma Core Use dem. Utan populationsanalys kan man inte förutsäga detta per CR.
• Rulesetet utvecklas - v1.69 är ännu en SAP-uppdatering. En konsult som analyserar en CR på v1.65 kan felklassificera under v1.69.
• Anpassade Z-behörigheter - SAP täcker dem inte i det officiella rulesetet. Kunden måste mappa dem själv och underhålla den mappningen.
• Branschspecifika ruleset - Retail (73 regler), IS-H Healthcare (74), Real Estate (83), GTS (31), HR (35), Utilities (48) - varje bransch har ytterligare regler som kan överlappa.
• Dynamiska ändringar - CR:er uppdaterar roller flera gånger i veckan, nya användare tillkommer, nya funktioner dyker upp. En snapshotanalys från förra månaden är redan föråldrad.
• Miljöskala - en typisk enterprise-implementation är flera SAP-instanser (ECC + S/4HANA + BW + dev/test/prod-landskap) och många tusen användare. Varje tillagd CR måste analyseras i kontexten av hela populationen över alla system samtidigt. Att göra detta manuellt i Excel vid den skalan är hundratals analytikertimmar per projektkommitté.

Åter till utmaningen som beskrivs i början - båda perspektiven är meningsfulla. Klassisk manuell analys per CR skalar verkligen inte vid denna komplexitet, men att lämna det till slutet av Explore är också för sent för styrning. Svaret ligger inte i att välja mellan "manuellt per CR" och "i grupp vid slutet", utan i att bygga ett automatiskt analytiskt lager som matas med aktuella SAP-data och det officiella rulesetet.

4. Där smartGRC kan tillföra värde

I en sådan modell bör smartGRC inte behandlas enbart som en FUE-kalkylator. Det största värdet uppstår när verktyget blir ett analytiskt lager mellan rolldesign och licensmodellen.

Som ett resultat är frågan inte längre "är denna roll Core eller Advanced?", utan: "vilken specifik behörighet eller funktion orsakar klassificeringsförändringen och hur många användare påverkas?"

4a. Fyra FUE-medvetna processer i åtkomstens livscykel

Aktiv FUE-styrning är inte bara what-if-analys per CR i konceptfasen. Det innebär att bädda in licensmedvetenhet i fyra viktiga operativa processer som redan finns i en organisation med SAP GRC:

1. Rolldesign med FUE-begränsning (designtid)

Klassisk rolldesign tittar främst på två axlar: funktionalitet (låter rollen dig göra de nödvändiga uppgifterna) och SoD (skapar den en segregation of duties-konflikt). En tredje axel som borde vara lika synlig: FUE-klassificering.

Ett konkret scenario: en "Display Only"-roll för finansteamet bör ge Self-Service Use. Men för skenbar bekvämlighet lades objektet M_RECH_BUK med Skapa-aktiviteten till - och plötsligt klassificerar rollen alla sina användare som Advanced Use. Utan FUE-medvetenhet vid designtiden är sådana situationer normala - och dyra. Rolldesignern bör se licensklassificeringen vid byggtiden, inte månader senare vid en revision.

2. Taggning av "dyra" roller i BRM / smartArchitect

Roller som bär en hög FUE-klassificering (Advanced, Developer) bör märkas i rollhanteringsverktyget - i SAP GRC Access Control BRM, i smartArchitect, eller i något annat system som hanterar rollmetadata. En etikett som "Licens: Advanced (+3,5 FUE / användare)" synlig på varje sådan roll förändrar downstream-dynamiken.

En linjechef som begär åtkomst för en ny anställd ser direkt att roll A är mer än tio gånger dyrare än roll B - och frågar funktionellt: "Behöver de verkligen allt från A, eller räcker den slankare B?". Det är ett samtal som inte hände tidigare, eftersom ingen såg priset.

3. FUE-medveten provisionering (workflow)

Nästa steg: att bädda in synlighet av FUE-kostnad direkt i åtkomstansökningens workflow. När en chef godkänner underordnads åtkomst ser de inte bara om den bär SoD-risk, utan också:

• vilken FUE-klassificering som kommer att tilldelas användaren,
• om den ändras från den nuvarande (t.ex. Core → Advanced),
• hur mycket det kostar per år inom avdelningens budget.

Effekten: chefen slutar vara bara en "SoD-godkännare" och blir en "kostnads-och-riskgodkännare". Ansvarigheten för licenskostnad fördelas till dem som fattar åtkomstbeslut - inte bara till ekonomiavdelningen, som ser SAP-räkningen vid årsskiftet.

4. Regelbundna åtkomstgranskningar från ett FUE-perspektiv

Traditionell User Access Review (UAR) kontrollerar "ska denna användare fortfarande ha denna åtkomst ur ett funktionellt perspektiv". Det är värt att utöka detta med en kostnadsfråga: "använder denna användare åtkomsten tillräckligt intensivt för att motivera Advanced/Developer-klassificering?".

Praktiskt resultat från riktiga projekt: granskningar baserade på faktisk användning (användningsdata från senaste 6-12 månaderna) kan identifiera 15-30 % av användarna som är tilldelade en högre FUE-klass än deras faktiska arbete i systemet skulle motivera. Att nedgradera dessa användare till en lägre licensklass ger omedelbara besparingar utan att förlora affärsfunktionalitet.

5. Det kritiska villkoret: aktuella data

Enbart what-if-funktionen löser inte problemet om analysdata uppdateras manuellt. Att exportera från SAP, förbereda filen, importera till verktyget och upprepa hela processen för varje större CR skalar inte i ett intensivt projekt.

Aktiv FUE-styrning kräver därför inte bara en analytisk modell, utan även en smidig och helst automatisk matning av aktuella data från projektet och SAP-miljön.

Först då kan en praktisk cykel byggas:

projektändring → rolluppdatering → what-if-analys → påverkansbedömning på användare → beslut → återkontroll efter utrullning.

6. Målmodell: FUE som en designbegränsning

Det mognaste tillvägagångssättet behandlar FUE som SoD eller säkerhetsarkitektur: inte som en kontroll som utförs efter projektets slut, utan som en av de begränsningar som beaktas under designen.

Detta betyder inte att vi vid första skedet måste veta den slutgiltiga licensen för varje användare. Analysens noggrannhet växer med projektets mognad:

• koncept → scenariobedömning och potentiella FUE-drivare,
• bygg → analys av slutliga roller och behörigheter,
• test/go-live → simulering av påverkan på användarpopulationen,
• run → jämförelse av behörigheter med faktisk användning och optimering.

7. Slutsats

Poängen är inte att räkna FUE exakt så tidigt som möjligt. Poängen är att förstå konsekvenserna av designbeslut allt noggrannare medan projektet mognar.

Manuell analys per CR kan vara en bra kontrollmekanism, men skalar inte som en styrningsmodell. En mätning som görs först vid slutet visar resultatet, men tillåter inte längre effektiv påverkan på projektet.

Ett verktyg som smartGRC kan fylla denna lucka när det används inte bara för slutlig FUE-mätning, utan för scenario- och what-if-analys under projektet och senare jämförelse av behörigheter med faktisk användning. Villkoret är dock regelbunden tillgång till aktuella data - utan det förvandlas även bra analytics snabbt till ännu en manuell process.

Den viktigaste frågan är inte: "vilken licens har denna roll?", utan "vilket designbeslut ändrar användarklassificeringen, och behövs det verkligen?"