De migratie van SAP ECC naar S/4 is een reis die veel bedrijven aan het maken zijn of zullen maken. Terwijl die reis voor sommigen een makkie is, stuiten de meesten onderweg op obstakels of hindernissen. In deze serie artikelen laten we zien waar je rekening mee moet houden en hoe je je moet voorbereiden op de rit.

In onze 2 eerdere blogs hebben we elementen besproken zoals de redenen om over te stappen naar S4, de verschillende migratieaanpakken en het team/de capaciteiten die je aan boord moet hebben voor de reis. Laten we nu wat dieper ingaan op de inhoud van wat er moet gebeuren, te beginnen met enterprise architectuur.

Architectuure – niet enkel tech

Het kan verleidelijk zijn om deze migratie te versimpelen tot het verwisselen van het ECC-systeem met S/4. Als je je “voor” en “na” applicatielandschap op een hoog niveau tekent, is dat inderdaad de meest opvallende verandering: het vakje in het midden krijgt een nieuwe naam. Maar omdat we zijn begonnen met het “waarom” van de migratie, zijn daar ook doelen aan verbonden, en dat betekent meestal dat alle 6 lagen van enterprise architectuur die we onderscheiden op zijn minst een beetje aandacht nodig hebben: KPI, organisatie, proces, data, applicaties en infrastructuur.

Waarom zijn we hieraan begonnen en wat betekent dat?

Zoals eerder gezegd, doen we dit project om een goede reden. Ja, we kennen allemaal wel mensen die gewoon gek zijn op technische dingen, het geven van workshops of het uitvoeren van projectmanagement, gewoon al op zichzelf. Maar we verwachten (en dringen er op aan!) dat dat niet de reden is waarom je aan deze migratie begint: er moet echt toegevoegde waarde zijn, bij voorkeur goed meetbaar ook.

Het vertalen van de gestelde doelen naar concrete KPI’s begint met het verduidelijken wat die P voor “performance” betekent en hoe goed eruit ziet.

We zien organisaties vaak worstelen met het vaststellen – en opvolgen –  van de juiste KPI’s op elk niveau. Het lijkt erop dat deze organisaties zich er niet van bewust zijn dat de migratie meer zou kunnen (moeten?) veranderen dan alleen de stand van de bekende KPI’s. De migratie biedt de mogelijkheid om het bestaande KPI-model om te vormen tot een nieuw, meer toekomstgericht duurzaam model. Vragen zoals:

Krijgen we betere bedrijfsresultaten met de nieuwe opzet en hoe zorgen we daarvoor? Veranderen de soorten bedrijfsresultaten als onderdeel van de transformatie? Als we bereiken wat we voor ogen hebben met dit project, hoe definiëren we dit succes dan? Aangezien we dit voor de komende zoveel jaar doen: hoe nemen we doelstellingen op voor nieuwe (en blijvende) bedrijfsthema’s, zoals ESG, verdere digitalisering of het creëren van een wendbare organisatie?

Dit zijn allemaal elementen van de KPI-architectuur die we nodig hebben om te begrijpen en overeenstemming te bereiken over hoe goed eruit ziet en hoe we solide beslissingen kunnen nemen binnen het project, maar nog belangrijker binnen het bedrijf nadat we klaar zijn.

Uiteraard moeten er ook voor het project zelf KPI’s zijn, en niet alleen voor de scope van de projectmanager (op tijd, binnen budget), maar ook voor de oplossing zelf. Hoe goed passen we “fit to standard” toe en hebben we solide regels (architectuurprincipes) voor wanneer we dat niet doen. Meten en houden we de afwijkingen bij, welke “score” op onze complianceprestaties vinden we daar acceptabel?  En natuurlijk alle meer technische KPI’s: beschikbaarheid, latency, responstijden – zowel voor de systemen als voor de organisatie rondom IT.

Als je niet weet waar je naar streeft, wordt het moeilijk om dat te bereiken.

Het vakje in het midden

Het feit dat ECC (S/4) voor veel organisaties dat vakje in het midden is, betekent dat het het kloppend hart van het systeemlandschap is. Als je dat vervangt, is het verstandig om er veel zorg en aandacht aan te besteden. Maar het hart moet wel verbonden blijven met de rest van het lichaam. Elke applicatie in de applicatie-architectuur heeft een specifieke functie voor de organisatie. Hoewel veel interfaces met deze andere applicaties niet veranderen qua structuur of frequentie, moet je opletten waar je wijzigingen aanbrengt in de data-structuur of -inhoud als onderdeel van de migratie.

Bijvoorbeeld aanpassingen aan je grootboekschema of organisatiestructuur die je hebt besloten te combineren met de migratie (zoals besproken in het vorige artikel). De keuze moet dan worden gemaakt of je diezelfde veranderingen in de rest van het landschap (tegelijkertijd) doorvoert of om met mappings te gaan werken. Dit laatste is een gemakkelijk ontkoppelingsmechanisme, maar je wilt waarschijnlijk ook geen verwijzingen naar verouderde structuren op hun plaats houden tot het einde der tijden…

Een evenwichtsoefening tussen: “wat verander ik als onderdeel van de migratie” en “wat houd ik op mijn to do list (schuld) omwille van de beheersbaarheid”. Goed architectuurwerk zal op zijn minst de afwegingen zichtbaar maken en de organisatie blijven herinneren aan de “to do’s”.

Het onderwerp van de data-uitwisseling brengt ons bij een volgend element in de bedrijfsarchitectuur: processen, omdat die uitwisseling meestal gebeurt om iets te laten gebeuren.

“End-to-end is a joy forever”

Ah, de zaligheid van goede, toegankelijke documentatie over hoe alles werkt… en het project van de migratie naar S/4 is vaak een moment waarop je je realiseert dat dat niet aanwezig is.

Het meest gedetailleerde beeld dat beschikbaar is, is vaak een domeinoverzicht of een andere functionele decompositie van welk deel van de bedrijfsvoering door wat en hoe wordt ondersteund. En hoewel zeker niet elke organisatie het niveau van documentatie nodig heeft dat het handboek van een ruimteschip heeft, is een goed begrip van welke processen zullen worden geraakt door de overstap naar S/4 van meer nut dan de meeste mensen denken.

Denken in end-to-end (E2E) processen en dit vastleggen in een model levert verschillende voordelen op. Ten eerste geeft het inzicht in hand-overs: interfaces ja, maar ook tussen afdelingen. Dat zijn de gebieden die je wilt afdekken bij het beheersen van projectafhankelijkheden, integratie- en gebruikersacceptatietests. Het doorlopen van scenario’s over de end-to-end processen helpt ook om de impact en risico’s te begrijpen en maakt het mogelijk om uitwijkmaatregelen te nemen.

Ten tweede helpt end-to-end bij het voorkomen van suboptimalisatie – het stimuleren van effectiviteit en efficiëntie in de héle organisatie in plaats van in één functie of proces. Vooral als er meer echt transformatieve veranderingen deel uitmaken van het programma, is er vaak een voordeel op het ene gebied, met wat meer inspanning op een ander gebied. Als mensen dan het plaatje van de gehele keten en de totale KPI’s zien, begrijpen ze beter wat hun bijdrage is en ontstaat er draagvlak. We kunnen het belang van het meenemen van de gebruikersgemeenschap (zelfs ook die buiten je eigen organisatie) voor succes niet genoeg benadrukken.

En de mensen dan?

Dit sluit ook aan bij een ander element van de enterprisearchitectuur: organisatie. Duidelijk hebben wie wat doet, waarom, en waar er kieren waar dingen in vallen of belangenconflicten kunnen ontstaan als gevolg van niet op elkaar afgestemde KPI’s. Ook waar is een tweede paar ogen nodig (en een extra processtap) om voor compliance zorg te dragen. Door “organisatie” te koppelen aan de E2E-procesarchitectuur en -aanpak, verzeker je je meer van consistentie en volledigheid: als je dit duidelijk hebt, profiteer je er later van bij alle onderwerpen waarbij “de mensen” betrokken zijn: training, OCM, autorisaties, testen…

Beginnen met E2E procesmodellering kan een afschrikwekkende taak lijken (we krijgen dat vaak te horen). Dat hoeft echt niet, vooral als je niet probeert het wiel opnieuw uit te vinden, maar gebruik maakt van wat er al is en je concentreert op het begrijpen en het je eigen maken van de mindset. De moeilijkheid ligt dan meestal in “waar is het gerechtvaardigd dat ik het standaardproces niet volg” – en dat komt weer terug bij “stick to standard” en alleen differentiëren waar het echte waarde toevoegt waarover we het eerder hebben gehad.

Wat betreft tooling voor procesmodellering: aangezien we het hier over SAP hebben, is Signavio een voor de hand liggende keuze, omdat dit vaak wordt “meegeleverd” in de deal. Nogmaals, denk na over hoe dit past bij de rest van je set-up, wees slim maar maak je keuzes ook niet té ingewikkeld. Begrijp wat de tools kunnen en koppel dit aan je eigen ambities en mogelijkheden. De volgende stap, die uiteraard vereist dat je het goed hebt opgezet, is om de tools te gaan gebruiken om ook de naleving en performance van je processen te meten en optimalisatie te stimuleren.

Wat er onder schuilt

Oké, infrastructuur is dus de voor de hand liggende volgende, en we nemen hier een beetje een brede definitie, omdat er altijd een grijs gebied is tussen “technisch” en “functioneel”, hard- en software.

De basis voor S/4 wordt gevormd door de HANA database en het HANA platform, wat vaak nieuwe vaardigheden op technisch (architectuur) gebied betekent. Dit hangt natuurlijk ook af van je hostingstrategie en SAP zet graag in op “Rise”. We weten allemaal dat de “cloud” nog steeds een datacenter is, alleen eentje waarvan jij, aan de ontvangende kant, de individuele servers niet kent. Aangezien ERP meestal niet het enige systeem in je omgeving is, betekent dit dat je nog steeds de knappe koppen nodig hebt die begrijpen hoe A met B praat en wat er moet gebeuren om dat veilig, robuust en consistent te laten werken. En wat te doen als het dat niet doet…

Een ander deel van de infrastructuur zijn de end-points van de gebruikers. In S/4 zijn de meeste “SAPGui-transacties” vervangen door Fiori-apps, en veel van deze apps zijn ontworpen om mobiel te zijn. Super natuurlijk om onderweg dingen te kunnen controleren, of op een portable apparaat in een operationele omgeving, maar het betekent veel voor zaken als beveiliging, connectiviteit (en replicatie).

En dan hebben we het nog niet eens gehad over de infrastructuureisen tijdens het project zelf: hoe schakel ik mijn omgevingen in, wanneer moeten ze beschikbaar zijn en wanneer “frozen”. Vooral als je kiest voor goldfield in plaats van greenfield, moeten de afhankelijkheden met “reguliere changes” worden beheerd. Het project zal enige tijd lopen, hoe ga ik om met service packs, heb ik een n-1 beleid voor de versies en hoe houd ik dat vol tijdens het project.

Conclusie

Waar de projectmanager zich bezighoudt met het projectproces, tijdlijnen, budget en middelen – en dat is wat over het algemeen naar voren wordt gebracht bij de stuurgroep, pleiten wij daarbij voor een sterke architectuursturing op de inhoud van het project – in lijn met het grotere plaatje van de organisatie.  Wie is “de eigenaar” van het eindresultaat (en wat is dat)?

Ervoor zorgdragend dat je alle 6 lagen goed hebt ingevuld. Dit betekent niet dat je een heleboel mensen moet toevoegen aan je project (apart onderwerp: doe dat alsjeblieft niet). De competenties en capaciteiten om ervoor te zorgen dat het geheel ook echt samenwerkt, moeten aanwezig zijn – en moeten ook vertegenwoordigd zijn aan de tafel waar de beslissingen worden genomen. Zorg ervoor dat je een “design autority” hebt die het project inhoudelijk controleert.

En ja, veel van het architectuurwerk moet aan het begin van het project worden gedaan. Het is echter net zo belangrijk om ervoor te zorgen dat de uitvoering ook in lijn hiermee plaatsvindt en/of om weloverwogen wijzigingen aan te brengen als dingen tóch anders uitpakken. Geen achterover leunen voor de architecten, mouwen opstropen!

Wat is het volgende?

Nog zo veel meer om te delen! Dus dat zullen we doen.

Stel ook gerust je vragen of deel dingen waar je tegenaan loopt, we gaan ook graag in op “verzoeknummers”! In een volgend artikel of bij een kopje koffie/thee…

Neem contact met ons op, al is het maar om ‘hallo’ te zeggen.