Op weg naar de ‘Digital Enterprise’: transitie naar S/4HANA (Digital Core) – deel 1

In ons nieuwsbericht van de maand juli hebben we melding gemaakt van de succesvolle afronding van de transitie naar S/4HANA binnen ons SUPlabs innovatieplatform. Daarin werd ook aangekondigd dat we in een drietal opvolgende blogs, meer inkijk geven in de aanpak die hierbij is gehanteerd. Vanuit de mogelijke transitiepaden naar S/4HANA hebben we het volledige pad bewandeld vanuit de ‘System Conversion’ aanpak. Deze aanpak is vrij simpel omschreven in de basis, maar kan in het systeemlandschap van de  klantorganisatie nogal wat voeten in de aarde hebben.

Er kan worden gekozen voor een ‘Big-Bang’ conversie, of een meer gefaseerde aanpak waarin er ook in de tussenliggende periodes waarde gecreëerd kan worden in de organisatie door het goed gebruiken van de mogelijkheden die ter beschikking komen in het vernieuwde landschap.

Binnen SUPlabs hebben we bovenstaande gefaseerde aanpak gekozen zodat we alle facetten en mogelijkheden onderweg benutten. De kennis die hieruit voortvloeit is weer een toegevoegde waarde richting klantorganisaties die met dezelfde vraagstukken stoeien.

Nu we fase 2 succesvol hebben afgerond gaan we in een serie van 3 blogs ervaringen delen vanuit 3 disciplines:

• Deel 1: SAP basis en architectuur
• Deel 2: Development en custom code
• Deel 3: Functionele readiness en impact

We behandelen daarin primair de ‘SAP Readiness Check’ wat een cruciaal onderdeel is voor een succesvolle transitie. Verder gaan we ook in op de daadwerkelijke upgrade, data conversie en nabewerking.

SAP Basis en architectuur

Vanuit de keuze om het ‘System Conversion’ scenario uit te voeren richting S/4HANA 1610 SP02, krijgen we al gauw het gevoel dat het hier om een werkelijke upgrade gaat van het ERP systeem. Dat hebben we uiteraard al veel vaker gedaan, maar wat maakt deze upgrade dan anders? Deze upgrade behelst primair het ERP systeem naar een nieuwe generatie te brengen, maar daarbij is de naadloze integratie met zowel het DB platform als de Frontend server (GW voor Fiori) een zeer belangrijk aspect.

We stonden dus voor de taak om ons ERP systeem te upgraden naar S4/HANA 1610 SP02. Fysiek hield dat in dat zowel de ERP omgeving als de Frontend Server (Gateway) omgeving moest worden geüpgraded. Beide omgevingen krijgen dan een Netweaver 7.51 basis én een SAP database. Dit is een pre-requisite van SAP, vanaf S/4HANA wordt er alleen gewerkt met SAP databases. Zo zijn er meer pre-requisites voor het (aanpalende) landschap, voor je kunt upgraden naar S/4HANA. Voor ons SAP basis team dan ook de uitdaging om zorg te dragen voor alle zogenaamde ‘technical tasks’ uit onderstaand model, met een zwaartepunt op de ‘readiness check’ vanuit de Maintenance Planner.

Aangezien de HANA database migratie van de ERP omgeving al een jaar eerder was gedaan zou de upgrade naar S/4HANA zelf meevallen. Simpelweg omdat de DMO optie (Database Migration Option) in SUM al eerder gedaan was. We kwamen van het ERPonHANA scenario, waarbij we al een jaar stabiel draaiden.

Readiness acties landschap

Allereerst bleek een upgrade van de Windows versie van de applicatieserver noodzakelijk. De huidige versie was nog Windows server 2008 R2 maar voor Netweaver 7.51 is minimaal Windows Server 2012 vereist. Tevens moest de SAP Frontend Server (GW) geüpgraded worden van SAP-basisrelease 7.50 naar 7.51. Daarbij wordt er, zoals eerder gemeld, eveneens vereist dat er een SAP DB onder de front-end server draait. In ons geval was dit nog Microsoft SQL Server dus ook hier hadden we een rand voorwaardelijke migratie te pakken. Dit betekende in ons geval daarom eerst nog een heterogene DB migratie van MS SQL Server naar een SAP database, in ons geval MaxDB. Dit is vanwege het feit dat de UI-add-on met de nieuwe S/4HANA Fiori Apps alleen maar kunnen “draaien” op een omgeving met een SAP database. Dit was voorheen met Fiori 2.0, op een ERPonHANA systeem, nog niet benodigd. We hebben bewust gekozen voor MaxDB omdat migratie naar HANA DB weer wat extra voeten in aarde zou hebben, inclusief additionele kosten.

Aangezien we in ons innovatieplatform al werken met Fiori 2.0 hadden we al redelijk wat ‘productieve’ Fiori apps draaien. Deze bleken in sommige gevallen al dusdanig ‘verouderd’ waardoor een un-install van enkele Fiori add-ons moest plaats vinden. Dit op zowel de Frontend Server alsook op de ERP backend. Dit houdt in dat die oude Fiori apps (m.n. van MM en SD) écht verdwijnen en worden vervangen door nieuwe. Dit kan nogal wat impact hebben in een productieve klantomgeving. Een serieus punt van aandacht om rekening mee te houden tijdens de transitie en in het draaiboek niet mag ontbreken.

De pre-check fase

Nu alle componenten voldoen aan de randvoorwaarden om te kunnen migreren, is er nóg een belangrijk zwaartepunt. Deze ligt meer op functioneel - en development vlak. Om zonder problemen door de pre-check fase van SUM heen te komen, heeft het functionele en development team vele OSS notes moeten inspelen als gevolg van meldingen uit de readiness check, ook customizing en maatwerk zijn aangepakt. Indien je deze meldingen niet vroegtijdig oplost, dan kom je ze tijdens de online-fase van de upgrade (SUM) weer vanzelf tegen en zullen het proces blokkeren. Daarnaast heb je ook te maken met diverse ‘waarschuwingen’ op basis van de benodigde simplification list activiteiten (hierover meer in deel 2 en deel 3). Na de intensieve voorbereiding de pré-check fase is daadwerkelijk zonder oponthoud verlopen.

De grootste uitdaging tijdens de werkelijke conversie was dat het filesysteem van de HANA database server niet groot genoeg bleek en dus moest worden uitgebreid.

Tijdens het uitvoeren van de uiteindelijke upgrade nog wel een aantal errors ondervonden. Deze zijn door het functionele - en development team opgelost door OSS Notes in te spelen. Op enig moment óók nog de melding "not enough memory", deze kunnen verhelpen door de HANA database opnieuw te starten.

Tevens kwamen we erachter dat het SUM proces een eigenaardigheid vertoonde. De database logging bleek namelijk, onverwacht, weer actief te zijn. Omdat het hier geen productief systeem betreft hadden wij deze eerder al gedeactiveerd. Door de onverwachte SUM-wijziging naar “active logging” werd nu een grotere hoeveelheid storage-ruimte ingenomen. Dit is uiteraard iets wat tijdens een upgrade goed in de gaten moet worden gehouden.

Na niet al teveel problemen was de upgrade een feit en van het uiteindelijke “final screen” wordt natuurlijk elke SAP basis consultant gelukkig!

Los van de SPDD en SPAU, zoals bij elke upgrade, dient nu óók nog de daadwerkelijke datamigratie naar de nieuwe simplified datamodellen plaats te vinden. Dit vindt dus plaats na de upgrade en moet handmatig worden uitgevoerd. Dit bleek geen onderdeel van de upgrade zelf, het systeem is op dit moment dus nog niet beschikbaar voor productief gebruik.

Onze conclusie is dat de upgrade uitvoering, “an sich”, niet veel afwijkt van een andere SAP-upgrade, dit vanuit SAP Basis perspectief bekeken. De voorbereiding en alle randvoorwaarden zijn significant heftiger dan een ‘normale’ upgrade.