Eén op de drie werknemers is ontevreden is over de snelheid van ICT systemen op het werk. Elke IT manager krijgt dan ook wel eens te horen dat het systeem erg traag is en dat hij daar iets aan moet doen. Zijn antwoord is dan meestal redelijk voorspelbaar: Wat is er traag en wanneer vind je het traag?
Traagheid is een subjectief begrip. Kijk maar eens naar je eigen PC of laptop, start die niet veel langzamer op dan toen je hem net kreeg? Of lijkt dat maar zo? Traagheid is vooral ook een relatief begrip. Traagheid kan immers uitsluitend worden geconstateerd als de huidige prestaties van het ICT systeem worden vergeleken met de prestaties van dat systeem op een eerder tijdstip. Alleen dan kan er onderbouwd een uitspraak gedaan worden over het al of niet trager worden van het ICT systeem.
Het moet dus om de feiten gaan en die kun je alleen weten door te meten!
Begin zo snel mogelijk, liefst als het ERP systeem net in gebruik is genomen, met een nulmeting. Stel met een aantal gebruikers een top 3 vast van veel gebruikte schermen of batches. Doe dit zowel met gebruikers van de financiële module van het pakket, als met gebruikers van de modulen inkoop, verkoop, voorraadbeheer en productie. Meet vervolgens met deze gebruikers de tijdsduur vanaf het opstarten van het scherm tot het moment dat alle gegevens op het scherm worden getoond. Meet ook de tijd dat het duurt om een transactie af te handelen, bijvoorbeeld de verwerking van een verkooporder.
Maak van alle meet resultaten een duidelijk verslag, waarbij ook rekening moet worden gehouden met de omstandigheden waaronder de test is uitgevoerd. Denk daarbij bijvoorbeeld aan de dag in de week, het tijdstip, het aantal gelijktijdige gebruikers in het systeem, de eventuele batchverwerking die op dat moment werd uitgevoerd, etc.
Bewaar het verslag met de meetresultaten en herhaal de meting bijvoorbeeld één keer per half jaar. Bij een opmerking van een gebruiker dat het systeem traag is haal je de resultaten van de vorige meting erbij, doe je eventueel een nieuwe meting en vergelijk je de resultaten. Als blijkt dat het systeem wel degelijk trager is, dan moet de oorzaak daarvan worden achterhaald.
Traagheid van het systeem kan verschillende oorzaken hebben. Ik noem er vier:
Het ligt aan de capaciteit van de hardware. Dit is de meest eenvoudig op te sporen oorzaak. Er is te weinig intern geheugen. Het extern geheugen is te traag toegankelijk. Er is te weinig processor capaciteit.
Het ligt aan de parameterinstelling van de SQL-Server. Ook dit is redelijk eenvoudig na te gaan.
Het ligt aan de als maar toenemende groei van data, waarbij wordt nagelaten om overtollige data te archiveren. Los van het feit dat rapportages daardoor in toenemende mate beslag leggen op de capaciteit van de hardware, komt er daardoor ook een enorme druk te staan op de dagelijkse back-up van het systeem. Overweeg daarom om data die operationeel niet meer belangrijk is te archiveren naar een archief database die niet elke dag meegenomen hoeft te worden in de backup. Zorg er dan wel voor dat de archief database goed te benaderen blijft voor het opvragen van historische informatie. Dat bent u ook door wettelijke regelingen verplicht. Denk bijvoorbeeld hierbij aan de bewaarplicht van 7 jaar voor de fiscus.
Het ligt aan het maatwerk. Traagheid dat veroorzaakt wordt door de aanwezigheid van maatwerk is vaak lastig te achterhalen. Goed programmeren is een vak en zoals in veel andere beroepen ook het geval is: er zijn meer mensen die het vak uitoefenen dan vakmensen. Te vaak wordt vanuit budgettaire redenen of gewoon vanuit een gebrek aan professionaliteit de binnenbocht gekozen. Met als gevolg onnodige belasting van het systeem. Zorg er dus voor dat in een opdrachtverstrekking voor maatwerk het performance aspect ook een punt van aandacht is. Test de nieuwe functionaliteit dan ook, ten behoeve van de acceptatie van het geleverde maatwerk, op een representatieve database en vergeet dan de performance van het maatwerk niet te testen.
Zie voor meer informatie: performance check en archivering Microsoft Dynamics AX