De kwaliteit van een informatiesysteem wordt niet alleen bepaald door de vraag of het systeem doet wat het zou moeten doen, het zal het ook snel moeten doen. Of in ieder geval zo snel, dat de eindgebruikers de snelheid niet als een negatief aspect van het systeem gaan zien. Daarom is het belangrijk dat de uiteindelijke prestaties van een te ontwerpen systeem een integraal onderdeel uitmaken van het ontwerpproces. Voor standaard-softwarepakketten, zoals het erp-pakket van SAP, is dat niet anders, stelt een adviseur van Magnus Management Consultants.
Een automatiseringstraject is in verschillende fases op te delen. Bij grote projecten is dit zelfs noodzakelijk om het overzicht niet te verliezen en adequaat te kunnen plannen.
Project-planning is bijvoorbeeld in vier fases onder te verdelen.
Conceptueel ontwerp – Bepaald wordt welke functies het nieuwe systeem zal moeten gaan vervullen en waar deze functies in elkaar grijpen.
Detail-ontwerp – Voor elk van de te ontwikkelen functies zal een functionele beschrijving moeten komen, waarin exact aangegeven staat op welk moment welke output van de applicatie verwacht wordt en welke inputs daarvoor vereist zijn.
Realisatie – In deze fase worden de in het detail-ontwerp gemaakte beschrijvingen uitgewerkt tot draaiende programma’s.
Productie en nazorg – Het nieuwe systeem wordt in productie genomen. Eventuele kleine foutjes worden hersteld en de prestaties van het systeem worden geoptimaliseerd.
Ontwerpen en testen
De rol die performance of de prestatie van het systeem heeft, of zou moeten hebben, verschilt sterk per fase. Vaak wordt er over ‘performance’ gesproken in termen van ’tuning’, het instellen van het systeem. Het daadwerkelijke tunen van de performance gebeurt echter alleen in de laatste fase, indien de applicatie productief gebruikt wordt. In de aanloopfase naar het productief gebruiken van het systeem zal de uiteindelijke performance echter wel een belangrijke rol dienen te spelen.
Er zal bekend moeten zijn welke programmamodules vaak uitgevoerd worden, welke responstijd voor deze modules acceptabel is (zowel vanuit het perspectief van de functie van het informatiesysteem als vanuit het perspectief van de gebruikers van het systeem). Deze informatie over de gewenste responstijden dient een belangrijke rol te spelen bij het ontwerpen en testen van de applicatie. Voor erg tijd-kritische modules zal veel tijd gespendeerd moeten worden aan het zo optimaal mogelijk schrijven van de modules en het inbouwen van wegen en mogelijkheden waardoor elke module een zo kort mogelijke responstijd heeft.
De prestaties
SAP R/3 is een standaard software-pakket. Door het zogenoemde ‘customisen’ ervan worden vele parameters ingesteld die bepalen hoe de uiteindelijke werking van de erp-software zal zijn. Om een goede performance van dit ‘enterprise resource planning‘-pakket te garanderen is – in vergelijking met een regulier software-ontwikkelingstraject – een heel andere werkwijze vereist.
Om dit te verduidelijken nogmaals het overzicht van de vier verschillende fases in de project-planning; ditmaal echter, zijn per fase de activiteiten gegeven die onderdeel uitmaken van de implementatie van SAP R/3.
Conceptueel ontwerp – Bedrijfsprocessen inventariseren, veranderingsbehoefte ten aanzien van processen in kaart brengen, huidige en gewenste informatiebehoefte beschrijven, beschrijving benodigd maatwerk
Detail-ontwerp – Uitwerken van de informatie uit het conceptueel ontwerp naar een werkend prototype in SAP R/3, een integratietest.
Realisatie – Maken van procedures en handboeken, acceptatietest, trainingen geven, conversies.
Productie en nazorg – Ondersteuning leveren aan eindgebruikers, de evaluatie.
Welke specifieke problemen zijn er nu bij het integreren van de ‘performance’ in het totale systeemontwerp? Enkele belangrijke factoren bij het implementeren van SAP R/3 komen hieronder aan de orde. Steeds zal worden aangegeven waarom dit een belemmerende factor is bij het integreren van de prestaties; als probleem bij het ontwerp en bij de realisatie van het systeem.
Gewenste functionaliteit
Meestal is bij de aanvang van een project de gewenste functionaliteit nog niet bekend. Wel moet er al gekozen worden voor een server, een besturingssysteem en een database-platform om het systeem te kunnen ontwikkelen. Deze keuzes kunnen belangrijke consequenties hebben voor de uiteindelijke prestaties van het systeem; het migreren van het ene platform naar het andere is niet erg eenvoudig.
Veelal wordt om deze reden meestal een initiële sizing (raming van de hoeveelheid werk) van het systeem gedaan op basis van een te verwachten aantal gebruikers per module. Dat dit vaak niet voldoende is, zal uit het vervolg van het artikel blijken.
Functionele ontwikkelaars
Vrijwel alle door een klant gewenste functionaliteit wordt standaard aangeboden. Bij een implementatie zijn de feitelijke ontwikkelaars daarom functioneel georiënteerd en kan men het ontwikkelwerk ‘customisen’ op basis van de gewenste inrichting van de bedrijfsprocessen.
Wat er systeem-technisch gebeurt tijdens dit customisen, is dat de modules geparametriseerd worden. De instelling van deze parameters bepaalt de afloop van de processen binnen SAP en kan grote gevolgen hebben voor de belasting van het systeem. Aangezien de ontwikkelaars hierbij dus een functionele bril op hebben, en met name geïnteresseerd zijn in de correcte afhandeling van een bedrijfsproces, blijven de consequenties van de gekozen parameter-instellingen op de prestaties van het uiteindelijke systeem op de achtergrond.
Conversies
Het ‘customisen’ van SAP gebeurt veelal in een ‘lege’ omgeving waarin voor testdoeleinden enige masterdata worden aangemaakt. Masterdata zijn in dit verband gegevens over leveranciers, klanten, producten, etcetera. Voor het testen van de flow van een levering door een systeem is slechts een beperkte set van masterdata nodig.
In het latere productiesysteem zullen echter veel meer masterdata zitten. Deze gegevens worden aan het eind van een implementatie, bij de zogenaamde ‘conversie’ in het systeem gebracht. Dit kan echter op het laatst onverwachte prestatie-problemen aan het licht brengen. Waar tot op het moment van de conversie hooguit enkele tientallen leveranciers in het systeem waren ingebracht en dit aantal na de conversie opgelopen kan zijn tot vele tienduizenden, dient rekening gehouden te worden met merkbaar langere zoektijden. In sommige gevallen resulteert dit in onacceptabel lange zoektijden.
Individuele transacties
Het komt regelmatig voor dat enkele transacties te traag verlopen. Een voorbeeld van een relatief traag onderdeel van SAP is de zogenaamde ‘product-configurator’. Hierin wordt veelal een zeer groot aantal checks gedaan op een gekozen set van product-eigenschappen.
Individuele transacties die een slechte responstijd laten zien, behoren tot de moeilijkst op te lossen performance-problemen in deze omgeving. Op het moment namelijk, dat de trage responstijd wordt geconstateerd, is het (functionele) ontwikkelwerk reeds goeddeels ten einde. De consequenties voor het op een andere wijze parametriseren van de modules of, in het uiterste geval, het op een andere wijze inrichten van de bedrijfsprocessen, zijn dan ook erg groot. In een dergelijk geval zal het erg veel tijd kosten om goed te analyseren wat er tijdens het uitvoeren van de transactie systeem-technisch gebeurt: welke tabellen worden op welke wijze benaderd, welke programma’s worden uitgevoerd, hoe vaak gebeurt dat, enzovoorts? Op basis van deze analyse moet bekeken worden hoe de bewuste transactie optimaal is te versnellen. In een uitzonderlijk geval kan het aanmaken van een enkele index voldoende zijn. Veelal echter zal een complexere oplossing nodig blijken te zijn.
Maatwerk
Hoewel bij de meeste SAP-implementaties de voorkeur uitgaat naar het gebruik van de standaard modules, blijkt in veel gevallen een beperkte hoeveelheid maatwerk niet te vermijden. Meestal blijkt juist dit maatwerk in de praktijk prestatieproblemen op te leveren.
Om programma’s (de zogenoemde ‘Abap’s) te schrijven die goed presteren, dient de programmeur uitgebreide kennis te hebben over de onderliggende technische inrichting van dit erp-pakket en over de interactie met de database en het besturingssysteem. Door je slechts te concentreren op een programma dat werkt (en pas over de prestaties na te denken als dit een probleem blijkt te zijn) kan veel kostbare tijd verloren gaan. Om programmacode te versnellen kan het dan namelijk nodig blijken om de hele structuur van het programma te veranderen (dit is ook een veelgemaakte fout bij reguliere software-ontwikkelingstrajecten).
Weinig ervaringsgegevens
Ondanks het feit dat R/3 een standaard software-pakket is, is elke SAP-omgeving anders. Om te beginnen zijn er bijzonder veel manieren om een dergelijk systeem te ‘customisen’. Daarnaast kan, zelfs bij twee systemen met identieke ‘customising’-instellingen, het gebruik van het systeem een bepalende rol spelen bij de prestaties van het systeem.
Een voorbeeld van zo’n situatie is de grootte van een order. Het maakt erg veel uit of elke order uit hooguit enkele orderregels bestaat of dat er per order tientallen of zelfs honderden orderregels zijn.
Aangezien elke specifieke situatie dus steeds weer anders is, zijn er veelal geen ‘bewezen’ standaardoplossingen die bruikbaar zijn.
Een andere aanpak
Inmiddels zal duidelijk zijn dat voor het garanderen van een goede performance van SAP R/3 een andere werkwijze benodigd is dan gebruikelijk is bij reguliere systeemontwikkeling.
Om tot een goede performance te komen zijn vijf activiteiten noodzakelijk: sizing van het productiesysteem, een infrastructuur-test, een piekbelasting-test, transactie-optimalisatie en performance tuning. Van elk van deze vijf activiteiten volgt hieronder een uiteenzetting, wat deze inhoudt en welke rol deze activiteit speelt in het bereiken van een goede performance. Opnieuw worden de eerder gehanteerde vier fasen vermeld, waarbij dit keer is aangegeven welke activiteit op welk moment plaats zou moeten vinden.
Conceptueel ontwerp – Keuze voor besturingssysteem en database-platform, vervolgens het ‘sizen’ van het ontwikkelsysteem.
Detail-ontwerp – ‘Sizing’ van het productie-systeem, de infrastructuur-test en dan transactie-optimalisatie.
Realisatie – Piekbelasting-test.
Productie en nazorg – Performance tuning.
‘Sizing’ productie-systeem
Zoals eerder aangegeven zal een initiële ‘sizing’ van het systeem moeten plaats vinden, nog voordat ook maar enig ontwikkelwerk gedaan is. Voor een productieserver is dit eigenlijk onmogelijk. Zeker gezien de eerdere constatering dat veelal pas tijdens het project duidelijk wordt welke functionaliteit gebruikt zal worden en hoe de modules ‘gecustomised’ zullen worden.
Vaak wordt daarom eerst een ontwikkelserver aangeschaft, waar in eerste instantie SAP op aangepast wordt. Hierdoor wordt tijd gewonnen voor de ‘sizing’ van het productiesysteem. Tegen de tijd dat echt vast dient te staan welke server-configuratie gebruikt wordt voor het productieve systeem, is het implementatietraject reeds aanzienlijk gevorderd. Bovendien is beduidend meer informatie beschikbaar om een onderbouwde ‘sizing’ van het systeem uit te voeren.
Infrastructuur-test
Een SAP-systeem bestaat uit vele onderdelen die gezamenlijk de responstijd van een transactie bepalen. Een beperkte greep uit het totaal aantal ’tunables’ staat opgesomd in de bij dit artikel afgebeelde tabel.
Bij de installatie wordt slechts een minimale poging gedaan om al deze aspecten op elkaar af te stemmen: op basis van de hoeveelheid beschikbaar werkgeheugen (RAM) wordt een initiële grootte van de SAP-buffers en het initiële aantal, en de verdeling van SAP-werkprocessen bepaald. Er is daarom vaak nog een aanzienlijke hoeveelheid additionele optimalisatie vereist. Dit is de infrastructure performance test. Tijdens deze test wordt het systeem maximaal belast. Aan de hand hiervan wordt bekeken welke bottleneck er in het systeem aan te wijzen is. Na het herconfigureren van het systeem wordt de test opnieuw uitgevoerd om te beoordelen of de bottleneck is verdwenen en om te zien welke bottleneck vervolgens optreedt.
Deze test zal op het (toekomstige) productiesysteem uitgevoerd moeten worden. De configuratie van het systeem waarmee men in productie wil gaan dient dan ook beschikbaar te zijn.
Transactie-optimalisatie
Zodra duidelijk is welke functionaliteit ingezet wordt en er een prototype van deze functionaliteit beschikbaar is, moet opgelet worden welke transacties structureel een te langzame responstijd hebben. Hoe eerder dit geconstateerd wordt, des te meer tijd er is om een oplossing te zoeken.
In dit stadium van het project is het al zinvol om voor transacties, waarvoor via het Online Service Systeem (OSS) van SAP performance-patches beschikbaar zijn, deze op te nemen in het ontwikkelsysteem en hier testen mee uit te voeren. Nog steeds kan na de conversie blijken dat een transactie, waar je dat niet van verwacht had, te traag is. Het is zaak zoveel mogelijk werk met betrekking tot de optimalisering van de prestaties in de tijd naar voren te halen. Probeer te voorkomen dat performance-problemen pas geconstateerd, of opgelost, worden wanneer eindgebruikers hierover al opmerkingen hebben gemaakt. In dat geval zal de acceptatie van het systeem door de eindgebruikers wel eens kunnen tegenvallen.
Piekbelasting-test
Op het moment dat alle functionaliteit beschikbaar is en dat bij voorkeur ook alle conversies zijn uitgevoerd, maar nog vóór het in productie nemen van het nieuwe R/3-systeem, moet het projectteam zich er van vergewissen dat ook straks, als de functionaliteit in productie genomen wordt, er een goede prestatie te verwachten is.
Tijdens een ontwikkeltraject zijn er meestal tot maximaal tien mensen tegelijk op het systeem bezig. Op dat moment is dus nog steeds niet bekend hoe de productieserver zal reageren als daar straks bijvoorbeeld 150 gebruikers tegelijkertijd op aan het werk zijn. Niets is zo vervelend als een nieuw informatiesysteem dat tijdens de eerste dag van ingebruikname al negatief ervaren wordt vanwege de slechte prestaties. Daarom is het zaak voor het nieuwe systeem voor de wolven wordt gegooid een zogenaamde ‘Customer Peak Performance Test’ uit te voeren. Een dergelijke test simuleert de maximaal te verwachten systeembelasting. Alle transacties die in een productieve situatie tijdens het drukste uur van de dag uitgevoerd worden, zullen tijdens deze test ook in een uur uitgevoerd worden. Door een dergelijke simulatie uit te voeren voor het live gaan, weet je van tevoren welke systeembelasting op het drukste moment van de dag te verwachten is. Bovendien kunnen bij een tegenvallende prestatie nog maatregelen genomen worden.
‘Performance tuning’
Pas als het systeem productief gebruikt wordt, kan met de zogenaamde ‘performance tuning’ begonnen worden. Dan pas zijn problemen te constateren die het gevolg zijn van langduriger productieve operatie (Er zijn buffers, zoals de single record buffer, die dagen nodig kunnen hebben om hun optimale hitratio te bereiken).
Bij het instellen van de performance is het belangrijk om in eerste instantie veel informatie te verzamelen over alle aspecten van de omgeving: het besturingssysteem, de database en SAP. Waar bottlenecks blijken te zitten of hitratio’s niet optimaal zijn, zal een van de te tunen parameters veranderd moeten worden om vervolgens het effect te bekijken. Het is nooit verstandig om meerdere parameters tegelijk te veranderen, aangezien deze veelal interacteren (tabellen worden bijvoorbeeld zowel op filesysteem-niveau, in de database als in SAP gebufferd).
Acceptatie en succes
Er zijn twee redenen waarom een goede performance belangrijk is voor het slagen van een automatiseringsproject. Ten eerste zal de functionaliteit van de applicatie gegarandeerd moeten worden. Dit geldt met name in omgevingen waar een snelle afhandeling van een transactie onderdeel is van de bedrijfsvoering. Een voorbeeld hiervan is de aandelenhandel, waar het heel evident is dat een te langzame transactie-afwikkeling geld kost.
De tweede reden om te streven naar een goede applicatie-performance is acceptatie door eindgebruikers. Net als bij elk ander pakket bepaalt bij de implementatie van SAP de acceptatie door de eindgebruikers voor een belangrijk gedeelte het succes van de implementatie. Om deze reden is een goede performance een niet te onderschatten factor voor een succesvolle implementatie. Het is dus uitermate belangrijk prestatie-problemen zoveel mogelijk in een vroeg stadium op te lossen. Nog te vaak gebeurt het, dat prestaties pas aan de kaak gesteld worden als de eindgebruikers hierover opmerkingen beginnen te maken. Maar dan is het al te laat.
Ruud Nijhuis is senior consultant bij Magnus Management Consultants
HARDWARE, OS | DATABASE | SAP |
Aantal CPU’s | Aantal database-processen | Aantal applicatie-servers |
Hoeveelheid geheugen | Aantal locks | Aantal werkprocessen |
Disk-snelheid | Verdeling van data over disks | Grootte van OS-files: roll-file, page-file |
Kernel-settings | Type SQL-optimizer | Werkproces-verdeling |
Grootte OS-buffercache | Grootte database-buffers | Grootte SAP-buffers |