Release-updates SAP S/4HANA Cloud: adoptie in vier stappen
In het kort
- SAP S/4HANA Cloud, Public Edition wordt tweemaal per jaar bijgewerkt; de upgrade zelf is geen project, de adoptie van nieuwe functies wel.
- Beperk uw beoordeling tot de functies die uw eigen processcope raken, in plaats van de volledige release-informatie door te nemen.
- Test gericht op uw kritieke end-to-end processen in de kwaliteitsomgeving vóórdat de productieomgeving wordt bijgewerkt.
- Kies per release één of twee functies die u daadwerkelijk invoert, met een eigenaar en een datum.
- Houd extensies en integraties clean-core-vast, zodat een upgrade geen herstelwerk oplevert.
SAP S/4HANA Cloud, Public Edition krijgt twee keer per jaar een release-update, en die upgrade komt hoe dan ook: u bepaalt niet óf u meegaat, maar wat u ermee doet. Dat verschuift de vraag van "hoe voeren wij een upgrade uit" naar "welke nieuwe functies zetten wij deze ronde in, en wat laten wij bewust liggen". In dit artikel leest u hoe u die keuze in vier stappen structureert: van het filteren van de release-informatie tot het beleggen van eigenaarschap, inclusief de testinspanning die daar realistisch bij hoort.
Wij zien bij middelgrote organisaties dezelfde twee uitersten. In het eerste uiterste leest niemand de release-informatie en blijft de omgeving jarenlang functioneel gelijk, terwijl de licentie wél alle nieuwe mogelijkheden bevat. In het tweede uiterste wil men alles tegelijk oppakken, waarna de release-ronde vastloopt op gebrek aan testcapaciteit bij de key users. De werkbare middenweg is een vaste, lichte cyclus die twee keer per jaar terugkomt.
Wat een halfjaarlijkse release-update precies inhoudt
Een release-update van SAP S/4HANA Cloud, Public Edition is een door SAP uitgevoerde upgrade van uw systeem naar een nieuwe versie, waarbij functionele vernieuwingen, aangepaste applicaties en nieuwe configuratie-opties beschikbaar komen. SAP werkt daarbij eerst uw kwaliteits- of testomgeving bij en pas daarna de productieomgeving, zodat u een periode heeft om de effecten te beoordelen. De upgrade is technisch een gegeven: u kunt hem plannen en voorbereiden, maar niet overslaan zoals u dat bij een on-premise ERP jarenlang kon uitstellen.
Dat is precies het verschil met het upgradedenken uit SAP ECC. Daar was een upgrade een project met een business case, een budget en een stuurgroep. In de Public Edition is de upgrade onderdeel van de dienst en verschuift de inspanning naar twee andere activiteiten: het regressietesten van uw eigen kritieke processen, en het beoordelen van nieuwe functionaliteit op bruikbaarheid. Beide activiteiten zijn te plannen, omdat de cyclus vast is.
De releases worden aangeduid met een jaar-maandnotatie, zoals 2302 voor de release van februari 2023. Die notatie is handig in uw eigen documentatie: leg per proceswijziging vast vanaf welke release u een functie gebruikt, zodat u later kunt herleiden waarom een instelling er staat. In onze managed services voor SAP S/4HANA Cloud is het analyseren en voorbereiden van die halfjaarlijkse updates een vast onderdeel van de dienstverlening, juist omdat het anders tussen de dagelijkse supportvragen verdwijnt.
Stap 1: filter de release-informatie op uw eigen processcope
De eerste stap is het terugbrengen van een omvangrijke release-documentatie tot een lijst die voor uw organisatie relevant is. Dat doet u door de aangekondigde wijzigingen te leggen naast de scope-items en processen die u daadwerkelijk in gebruik heeft, in plaats van naast het volledige functionele aanbod. Een organisatie die uitsluitend administratieve en financiële processen draait, kan het overgrote deel van een release binnen een half uur terzijde leggen.
Werk daarbij met drie categorieën. Categorie één zijn wijzigingen in processen die u gebruikt: die moeten hoe dan ook langs een key user. Categorie twee zijn nieuwe functies binnen uw scope die u nu níet gebruikt maar die een bestaande workaround kunnen vervangen; dit is de categorie met de meeste waarde. Categorie drie is alles buiten uw scope: registreren en laten liggen.
Praktisch levert die driedeling per release een lijst van hooguit tien tot vijftien punten op. Dat is een lijst waarover u een gesprek van een uur kunt voeren met de proceseigenaren, en dat is precies de bedoeling. Wie de volledige release-informatie rondstuurt, krijgt geen reactie terug.
Stap 2: test gericht, niet uitputtend
Regressietesten bij een release-update betekent dat u aantoont dat uw kritieke end-to-end processen na de upgrade nog steeds doorlopen zoals afgesproken. Het betekent niet dat u elke transactie opnieuw doorloopt. De testinspanning hoort te schalen met het risico: een order-to-cash-proces dat dagelijks honderden orders verwerkt verdient een volledige doorloop, een zelden gebruikte rapportage niet.
Een werkbare testset voor een middelgrote organisatie ziet er als volgt uit.
| Procesketen | Wat u minimaal doorloopt | Wie bevestigt |
|---|---|---|
| Order to cash | Verkooporder, levering, facturatie en de financiële boeking | Key user verkoop en finance |
| Purchase to pay | Inkooporder, ontvangst, factuurcontrole en betaling | Key user inkoop en crediteurenadministratie |
| Record to report | Periodeafsluiting, kernrapportages en de financiële dashboards | Controller |
| Productie of service | Een representatieve productieorder of serviceorder inclusief nacalculatie | Key user productie of service |
| Integraties | De koppelingen met externe systemen via het platform | IT en de functioneel beheerder |
Plan het testvenster op het moment dat uw kwaliteitsomgeving is bijgewerkt en de productieomgeving nog niet. Leg de uitkomsten per keten vast met datum en naam, zodat u bij een latere vraag kunt aantonen wat er is getest. Die vastlegging is ook waardevol richting uw accountant en, in gereguleerde sectoren, richting een auditor.
Stap 3: voer per release één of twee functies daadwerkelijk in
Adoptie mislukt zelden op techniek en bijna altijd op eigenaarschap. Een functie die "interessant" wordt gevonden maar geen eigenaar en geen datum heeft, staat bij de volgende release nog steeds op de lijst. Kies daarom per release maximaal twee verbeteringen, wijs per verbetering één proceseigenaar aan en spreek af in welke periode de wijziging live gaat.
Financiële processen
In de financiële kolom zit doorgaans de snelste winst, omdat SAP S/4HANA Cloud financieel volledig geïntegreerd is opgezet en nieuwe rapportage- en afsluitfuncties zonder maatwerk beschikbaar komen. Denk aan het vervangen van een spreadsheet in de periodeafsluiting of het inrichten van een standaarddashboard voor marge-inzicht. Deze verbeteringen raken één afdeling en zijn daardoor binnen één release-ronde af te ronden. Deze Finance-Led opzet is ook de basis waarmee veel organisaties starten voordat productie- of servicegerichte processen worden toegevoegd.
Productie- en magazijnprocessen
Voor productie- en magazijnprocessen geldt dat nieuwe functionaliteit vaker een organisatorische component heeft: andere handelingen op de werkvloer, andere scanmomenten, andere afspraken over datakwaliteit. Reserveer hier dus meer doorlooptijd dan de configuratie zelf suggereert. Onze ervaringen uit productiegerichte trajecten leest u terug bij de referenties van productiegerichte implementaties.
Assistentie en automatisering
Functies rond SAP Business AI, procesautomatisering en voorstelgedrag in schermen komen beschikbaar binnen de standaard en vragen geen apart platformtraject. De beoordelingsvraag is hier niet of de techniek werkt, maar of uw stamdata en procesafspraken goed genoeg zijn om een voorstel te vertrouwen. Begin daarom met een proces waarin fouten zichtbaar en corrigeerbaar zijn, niet met een proces dat direct financiële consequenties heeft.
Stap 4: houd extensies en integraties releasevast
Een clean core betekent dat u de standaard niet aanpast maar uitbreidt via de daarvoor bedoelde, door SAP ondersteunde mechanismen. In de praktijk gaat het om in-app extensibility voor velden en logica binnen de applicatie, developer extensibility voor zwaardere uitbreidingen, en side-by-side extensies op het SAP Business Technology Platform voor functionaliteit die naast het ERP leeft. Wie zich aan die mechanismen houdt, houdt zijn uitbreidingen upgradevast; wie eromheen werkt, verplaatst de kosten naar iedere volgende release.
Dat principe is het makkelijkst te begrijpen aan een concreet voorbeeld: in onze blog over clean core in de praktijk met scanner-API's is uitgewerkt hoe magazijnprocessen via API's flexibel worden uitgebreid zonder de kern te raken. De achterliggende ontwerpprincipes en de integratiemogelijkheden staan beschreven bij uitbreidingen, innovaties en integraties binnen SAP Cloud ERP.
Neem uw extensielijst één keer per jaar door, bij voorkeur bij de eerste release van het jaar. Controleer per extensie of hij nog wordt gebruikt, of de standaard inmiddels dezelfde functionaliteit biedt, en of de gebruikte API's nog actueel zijn. Extensies die de standaard inhaalt, kunt u opruimen; dat verlaagt uw testinspanning bij elke volgende upgrade.
Wie doet wat in de release-cyclus
De release-cyclus vraagt drie rollen, en die hoeven niet alle drie intern belegd te zijn. De key user beoordeelt de wijzigingen binnen zijn proces en voert de test uit; deze rol is per definitie intern, omdat alleen de gebruiker weet hoe het proces echt loopt. Een Center of Expertise bewaakt de samenhang tussen processen en houdt de documentatie bij. De derde rol is de functionele en technische verdieping: het beoordelen van configuratie-opties, het inschatten van de impact op extensies en integraties, en het bewaken van systeemhealth en integratiemonitoring.
Bij organisaties zonder eigen SAP-team wordt die derde rol doorgaans extern belegd. Onze consultants zijn gecertificeerd in de betreffende modules en volgen per release de stay-current training, waardoor zij de nieuwe functionaliteit al kennen op het moment dat uw kwaliteitsomgeving wordt bijgewerkt. Voor organisaties die nog aan het begin van de transitie staan, komt dezelfde vraag eerder in beeld: in een Discovery Assessment voor SAP Cloud ERP wordt onder meer bepaald hoeveel van uw processen op de standaard passen, en dat percentage voorspelt direct hoe zwaar uw latere release-cyclus wordt.
Hoe die opbouw er in een volledig traject uitziet, van assessment via implementatie naar beheer, staat beschreven bij onze aanpak voor implementaties van SAP S/4HANA Cloud. De rode draad is steeds dezelfde: hoe dichter u bij de standaard blijft, hoe lichter elke volgende release-ronde wordt.
Veelgestelde vragen over release-updates in SAP S/4HANA Cloud
Hoe vaak krijgt SAP S/4HANA Cloud, Public Edition een release-update?
De Public Edition wordt tweemaal per jaar bijgewerkt. SAP werkt eerst de kwaliteits- of testomgeving bij en daarna de productieomgeving, zodat er een periode is waarin u de wijzigingen in uw eigen inrichting kunt beoordelen en testen. Naast deze halfjaarlijkse functionele releases worden er tussentijds correctieve updates doorgevoerd, die geen functionele beoordeling vragen.
Kunnen wij een release-update overslaan?
Nee. De upgrade van de Public Edition is onderdeel van de dienst en wordt door SAP uitgevoerd; u kunt de planning kennen en u erop voorbereiden, maar niet afzien van de nieuwe versie. Wat u wél bepaalt, is welke nieuwe functionaliteit u activeert: nieuwe functies komen beschikbaar, maar worden niet automatisch in uw processen ingevoerd.
Hoeveel testinspanning kost een release-update?
Dat hangt af van het aantal actieve procesketens en van de mate waarin u binnen de standaard bent gebleven. Een organisatie met een administratieve scope en weinig extensies komt doorgaans uit op een gerichte doorloop van de kernketens door de key users. Zodra er productie-, magazijn- of integratieprocessen bijkomen, groeit de testset mee; het bijhouden van een vaste testset per keten houdt die inspanning voorspelbaar.
Wat gebeurt er bij een upgrade met onze extensies?
Uitbreidingen die zijn gebouwd met in-app extensibility, developer extensibility of als side-by-side extensie op het SAP Business Technology Platform zijn ontworpen om upgrades te doorstaan. Het risico zit in koppelingen die gebruikmaken van interfaces die SAP vervangt of uitfaseert. Een jaarlijkse controle van uw extensie- en integratielijst is daarom onderdeel van een gezonde release-cyclus.
Hoe weten wij welke nieuwe functies voor ons relevant zijn?
Door de release-informatie niet integraal te lezen, maar te leggen naast de scope-items en processen die u daadwerkelijk gebruikt. Alles buiten die scope registreert u en legt u terzijde. Wat overblijft zijn wijzigingen in uw eigen processen, die langs een key user moeten, en nieuwe functies die een bestaande workaround of spreadsheet kunnen vervangen.
Wat is het verschil met een upgrade in SAP ECC?
In SAP ECC was een upgrade een afzonderlijk project met eigen budget, doorlooptijd en risico, mede doordat maatwerk in de kern meegenomen moest worden. In de Public Edition is de upgrade onderdeel van de dienst en verschuift de inspanning naar regressietesten en functionele adoptie. Organisaties die vanuit ECC overstappen, merken dat vooral als een verandering in ritme: kleinere stappen, twee keer per jaar, in plaats van één grote stap per meerdere jaren.