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

Development en custom code, een belangrijk onderwerp rondom een voorgenomen transitie naar S/4HANA. Dat onderwerp staat centraal in deel 2 van deze serie. 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 delen we in een serie van 3 blogs ervaringen 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.

In deze editie gaan we verder in op de discipline ‘Development’. Hierbij een belangrijk onderwerp de migratie, ook wel conversie, van maatwerk (custom code en enhancements). Het is een onderdeel uit de SAP Readiness Check, gebruik makend van de ‘Custom Code Migration Worklist’.

SAP Development en custom code

Maatwerk, customer enhancements, SAP development of custom code, allemaal zeer bekende termen in een SAP systeem landschap. We willen allemaal graag dicht bij de SAP standaard blijven, maar door de jaren heen is er telkens toch behoefte aan aanpassingen, uitbreidingen, programma’s, slimme rapporten, apps en nog veel meer. Een nadeel hiervan is wel dat maatwerk bij iedere SAP upgrade een rol speelt (nabewerking, fixes en veel testen), maar bij de database migratie naar HANA of de conversie naar S/4HANA is dit een nog grotere uitdaging.

Bij de transitie naar S/4HANA is het belangrijk om vooraf je landschap op de juiste manier geprepareerd te hebben (‘Readiness’).

Een belangrijke controle, waarbij klantorganisaties waarschijnlijk het meeste werk uit gaat voortvloeien is de ‘Custom Code Check’. Deze check loopt door je maatwerk code heen en signaleert zaken die na een upgrade naar S/4HANA mogelijk problemen op gaan leveren. Je kunt hierbij denken aan data types die veranderen of veranderende tabel structuren.

Het liefste zouden we deze code check natuurlijk vóór de migratie al uitvoeren zodat we alvast weten hoeveel werk er ongeveer uit gaat komen. Vervolgens dan op voorhand het benodigde ontwikkelwerk te verzetten om al het (relevante) maatwerk weer werkend te krijgen nadat de upgrade is gedaan. Dit is natuurlijk lastig gezien we in de huidige situatie niet de database structuur en andere gewijzigde zaken hebben om deze checks op uit te voeren. Hier heeft SAP iets op bedacht. Je kunt in de zogenaamde ‘Code Inspector’ een model inladen van de nieuwe S/4HANA database en hier tegenaan de checks uitvoeren.

Je moet dan al wel dezelfde NetWeaver stack versie hebben als die van je doelsysteem. In ons geval versie 7.51 omdat we naar S/4 1610 wilden (pre-requisite). In een dergelijke voorbereidende fase in het project is de kans dan ook nog aanwezig dat het huidige productieve systeem nog niet deze stack versie heeft. In ons geval was dat helaas ook nog niet zo, dus we konden de checks niet op ons ‘oude’ systeem uitvoeren. Ook daar is wat op gevonden. Je kunt de checks remote uitvoeren vanuit een ander systeem dat wél de juiste NW versie heeft. Je zou hier een “leeg” systeem voor kunnen optuigen of, zoals in ons geval, een ander systeem uit je landschap gebruiken dat al wel deze hogere versie heeft. Dit systeem noemen we het Evaluatiesysteem.

De werkelijke stappen ten uitvoer brengen

• 1. Installeer in je Business Suite systeem SAP Note 2270689. Deze installeert een extractor die remote vanuit het Evaluatiesysteem kan worden aangeroepen om de code te bekijken.
• 2. Download van de SAP Service Market Place de laatste versie van de Simplification Database als ZIP. Hierin staan alle datastructuren van het toekomstige S/4 systeem beschreven. Je code zal hiertegen worden gecheckt.
• 3. Importeer de ZIP in je Evaluatiesysteem. Dit doe je door rapport SYCM_UPLOAD_SIMPLIFIC_INFO te draaien.
• 4. We gaan naar de SAP Code Inspector op het Evaluatiesysteem: Transactie SCI. Definieer een object set om te controleren. Gezien we objecten uit een remote systeem willen controleren voeren we niet direct de selectie in, maar gaan we naar het tabje Object Collectors en selecteren we middels F4 de collector “Remote Objects (RFC)”. Wanneer we dit gedaan hebben kunnen we daaronder de objecten filteren. Bijvoorbeeld door bij Package iets in te vullen als Z*, Y* of /SUPERP/*.

• 5. We willen de controles nu daadwerkelijk gaan uitvoeren. In de Code Inspector maken we een ‘Inspection’ aan. Hierin vullen we als Object Set de set in die we net hebben aangemaakt en als Check Variant S4HANA_READINESS_REMOTE. Nu kunnen we hem opslaan en uitvoeren. Tip: Doe dit in de achtergrond, want voor een grote set maatwerk kan dit wel even duren.

• 6. Als hij klaar is met al zijn checks kun je onder jouw Inspection de Logs opvragen.

De resultaten zien er hetzelfde uit als alle andere Code Inspector resultaten. Zaken die in deze resultaten terug zullen komen zijn bijvoorbeeld:

• Plekken waar het MATNR veld wordt gebruikt. Deze wordt namelijk van 18 naar 40 karakters opgerekt. Als de waarde dus naar een ander veld wordt gekopieerd kan het voorkomen dat je de laatste 22 karakters gaat missen. Ook plekken waar BAPI’s worden aangeroepen of (IDOC) interfaces die dit veld bevatten worden getoond omdat hier zaken aan gewijzigd zijn.
• Referenties naar tabellen die gewijzigd zijn of die niet meer gebruikt dienen te worden.

De error meldingen uit de Code Inspector verwijzen vaak weer naar SAP Notes, waarin staat beschreven wat er in bepaalde situaties gedaan moet worden om het probleem op te lossen. In sommige gevallen heeft SAP setjes met methodes opgeleverd om je te helpen. Bijvoorbeeld om bij interfaces en BAPI’s het vullen van input velden altijd goed te laten verlopen na het langer maken van het MATNR veld (één van de vereiste aanpassingen voor S/4HANA is de lengte van het MATNR).

In ons geval is deze controle uitgevoerd op een beperkte set uit een demo systeem. In klantsystemen kan hier echt een hele flinke lijst uitkomen die geanalyseerd moet worden en waar het grootste gedeelte ook werkelijk leidt tot noodzakelijke aanpassingen om de functionaliteit werkend te houden na de conversie naar S/4HANA.

De meeste van deze zaken kun je vóór de migratie nog niet aanpassen, aangezien je de code dan niet meer kunt compileren omdat de gewijzigde tabellen en data types nog niet bestaan. We hebben het bij de klant immers nog steeds over een productief systeem dat we ‘Ready’ willen maken voor de conversie. De wijzigingen wil je natuurlijk niet pas gaan ontwikkelen na de conversie, dus dit zul je in de huidige ontwikkelstraat (OTAP) moeten doen zodat het tijdens de Go-Live puur een kwestie is van transporteren en activeren. In langer durende projecten, of programma’s, kan er ook nagedacht worden over het tijdelijk neerzetten van een parallelle ontwikkelstraat om al het maatwerk aan te pakken. 

Dit is bij uitstek ook een mooi moment om bepaalde stukken code die eigenlijk toch niet meer gebruikt worden uit te faseren, dat scheelt later weer bij het migreren van de code. We maken namelijk heel vaak maatwerk, maar het wordt niet altijd actief opgeruimd. Hier zijn ook allerlei tools voor om je maatwerk actief te managen en prioriteren op basis van gebruik (CCLM). Maar dit is weer een apart onderwerp an sich.

Onze conclusie is dat rondom dit onderwerp de juiste tools voorhanden zijn vanuit SAP. Qua landschap moet je uiteraard wel aan wat randvoorwaarden voldoen zoals de juiste stack versies. Daarnaast dient dit onderwerp absoluut niet onderschat te worden door klanten in de voorbereiding naar S/4HANA. Indien de keuze is gemaakt voor de transitie en het doelscenario duidelijk is, raden we aan deze controles al direct tijdens de ‘Plan’ fase uit te voeren zodat inzichtelijk is wat de daadwerkelijke workload gaat worden, daarmee ook de doorlooptijden en complexiteit inzichtelijk wordt. Het zou namelijk vervelend zijn als je daar tijdens de bouwfase pas achter komt, dan wel dat er programma’s omvallen na de conversie die ‘O-zo’ belangrijk zijn.