Hur ECC-användarbehörigheter påverkar kostnaden för S/4 HANA-licenser i Rise with SAP-modellen

Inledning

Till att börja med en handfull bakgrundsinformation om varför ämnet i titeln på detta blogginlägg bör vara av intresse för alla företag som för närvarande kör ett SAP ECC-system, som hittills har har inte migrerat till S/4:

• Gartner rapporterar att från och med 2026 (klockan tickar) kommer 90% av de nya installationer som SAP erbjuder att vara Rise with SAP (nedan kallad „RWS”),
• Rise with SAP-modellen är en molntjänst som, även om den inte är som „vanlig S/4” (bara det i molnet), ändrar sättet du faktureras med SAP,
• I RWS-modellen ändras både typerna av namngivna användarlicenser och (viktigast av allt) sättet att licensiera,
• om rollerna i ECC inte är optimala, då med RWS-funktionen - kan du förvänta dig en ökning av licenskostnaderna från 50-150% (enligt USU-forskning)
• Det finns verktyg som avsevärt kan optimera både licenskostnader (USU Optimisation for SAP) och, så smärtfritt som möjligt, genomföra ett projekt för optimering av arbetsroller (Pathlock Role Management).

FUE Full användningsekvivalent

Förändringen från ECC till RWS omfattar införandet av konceptet FUE.
Detta är ett nytt sätt att redovisa namngivna användarlicenser med flexibiliteten att välja licenser enligt nyckeln nedan:

• Developer Access (1 användare = 2 FUE),
• Advance Use (1 användare = 1 FUE)
• Kärnanvändning (1 användare = 1/5 FUE)
• Självbetjäning Användning (1 användare = 1/30 FUE).

 

Och för att ge ett snabbt exempel, lite mer enkel matematik.

• 1 FUE = 5 kärnor används,
• 2 FUE = 1 tillgång för utvecklare,
• 1 FUE = 30 Självbetjäning Användning,
• 4 FUE = (1 Developer Access) + (5 Core Use) + (30 Self-service Use)

Jag noterar att Advance Use är inte riktigt den Professional User som man känner till från ECC, a Core Use är inte samma sak som Limited Professional User med ECC.

Varför då?

Tänk på de förändringar som rör definitionen av vad varje användartyp innebär. Om en ECC-användare hittills har tilldelats en Professional User-licens, på grund av att de utför försäljningsprocesser i SD-modulen, behöver de inte ha Advanced i RWS alls. Om du skulle göra en enkel licensöverföring för den här användaren utan att ta hänsyn till S/4-definitionen kan det hända att du betalar för mycket för licenserna.

Varför då?

Därför att licenser i S/4 (både S/4 onprem och Rise) definierar försäljningsaktiviteter för licenstyper som är lägre än Professional.

Och så för Core Use:

• Fakturering av försäljning,
• Hantering av försäljningskontrakt,
• Hantering av försäljningsleads.

Detta innebär att om du överför användaren (enligt exemplet ovan) - kommer du att betala mycket för mycket.
Det är därför värt att titta på kontextuella förändringar av vilka specifika licenser en viss användare kommer att behöva baserat på vilka aktiviteter de använder (eller mer exakt, vad de har tillgång till).

Trap - ändring från „användningsbaserad” till „behörighetsbaserad”.

Detta är nu det viktigaste - hittills har varje användarlicens i ECC fakturerats utifrån vilka transaktioner som användaren har använt.

I RWS är förändringen kolossal, titta på definitionen:

„Med "Full Usage Equivalent (FUE)" avses det antal som motsvarar antalet individer bemyndigad att tillgång till specificerade lösningsmöjligheter.”

Jag har lyft fram de viktigaste - I RWS är det inte viktigt om användaren har utfört en åtgärd. Det som är viktigt är om han eller hon har tillgång till den.

Ja, det Tillstånd är nyckeln till licensfrihet. Vad innebär detta? Om behörigheterna (rollerna) är för stora - då är det uppenbart att vi betalar för mycket för licenser.

SAP STAR-tjänst

SAP erbjuder att mappa licenser från ECC till RWS med hjälp av SAP STAR-tjänsten.
Låt oss titta på en enkel driftsalgoritm:

Detta innebär följande - vi tar behörigheterna för en viss användare från ECC och mappar detta till RWS. Med den här tjänsten får vi en lista över mållicenser (och slutligen antalet FUE:er som ska köpas).

Erfarenhet av auktorisation

Enligt vår erfarenhet står det genomsnittliga företaget, som hittills inte har tagit itu med auktorisationsprojekt, inför problemet med alltför många auktorisationer. Värdet av transaktioner i bruk är cirka 10%.
Resten är onödiga åtkomster som kan generera rättighetskonflikter eller bara en ökning av (onödiga) kostnader för mål-SAP-licenserna.

Vad som är värt att betona igen - om du har suboptimala behörigheter i ECC idag kommer detta med största sannolikhet att leda till en ökning av kostnaden för Rise with SAP-erbjudandet. Det är alltså viktigt att få ordning på sina behörigheter INNAN man påbörjar målanalysen av licensbOM:en från SAP.

Delprojekt - Automatisering av projektet för omorganisation av förmåner

En mardröm för alla organisationer som arbetar med SAP är omorganisationsprojekt.
Oftast handlar det om den långa tid det tar att driva ett projekt (snarare hundratals dagar för konsulter + resurser på företagssidan). Dessutom behovet av att tillhandahålla aktuell information om de processer och transaktioner som används i företagen - vi måste utse personer från företaget som måste sluta att hantera nuvarande uppgifter under en tid. Och så har vi den känsliga perioden - testning av nya roller (detta är det ögonblick som, om det fanns fel i de tidigare stegen, kan leda till att användarna inte kan utföra sina affärsprocesser).

Därför är det värt att hjälpa till med lösningar som optimerar konstruktionen till dess yttersta gränser.
Enligt vår erfarenhet - med så mycket som 80% tid jämfört med omorganisationsprojekt med manuella behörigheter.

Vi genomför omorganisationsprojekt med hjälp av Pathlocks verktyg för rollhantering.
Verktyget används för att optimera och automatisera varje steg i skapandet av ett nytt år. Kort sagt har vi kontroll över behörighetskonceptet (underhåll av dokumentation, arbetsflöde för godkännande, namngivningskonvention, befattningar och ansvar).

Vad är målet?

Nya arbetsroller som är skräddarsydda efter användarnas faktiska affärsbehov, baserat på historiska data.

Process på hög nivå:

• logisk representation av organisationsstrukturen,
• analys av användaraktivitet,
• Automatiskt förslag på huvudroller för jobb,
• arbetsflöde för godkännande med SoD-analys,
• tester,
• dokumentation,
• livscykeln för en roll - förändringar

Projektcykeln ser ut så här:

Och ett exempel på format med höga arbetsroller ser ut så här:

Delprojekt - licensoptimering

Med hjälp av USU-optimering för SAP och dedikerade regler (i verktyget) får vi styra tilldelningen av motsvarande licenser i SAP (det spelar ingen roll om ECC eller S/4)

USU Optimisation for SAP-verktyget levereras med definitionsbibliotek för specifika licenstyper i förhållande till de transaktioner och auktoriseringsobjekt som tilldelats en specifik licens. Om du har anpassade transaktioner (det finns ingen SAP utan Z*) lägger vi naturligtvis till definitionerna de parametrar för T-koder eller auktoriseringsobjekt som är lämpliga för licenstypen.

Till exempel, vad en specifik Licensdefinition för exempel på Core Use (1/5 FUE):

På den andra raden - definitionen av de transaktioner som en specifik användare har tillgång till. En detaljerad lista öppnas med innehåll som beskriver de nödvändiga åtkomsterna:

Vi har också ett simuleringslager:

Besparingar - även före migreringsbudet

Detta tillvägagångssätt sparar licenskostnader i Rise med SAP från 50% till och med 150%. Eftersom vi optimerar licenserna innan migrering (även innan budgivning) och vet exakt vilka licenser vi kommer att behöva.

Vad händer nu, hur ska jag leva?

Det finns flera möjligheter. Vi inbjuder dig att:

• ladda ner vår e-bok, där ovanstående kommer att beskrivas mer i detalj,
• deltagande i dedikerade webbinarier,
• kontakt via formulär och ansikte mot ansikte med våra experter.