Wat ik doe voor en na een systeemupdate

Een systeemupdate is voor de meeste MKB-bedrijven geen project. Er komt een aankondiging, er wordt een datum gekozen, en op die datum staat de nieuwe versie er. Dat werkt ook prima, tot het een keer niet werkt en niemand weet waar hij moet beginnen.

Wat mij opvalt is dat het bijna nooit de standaardfunctionaliteit is die omvalt. Dat deel is bij duizenden klanten getest voordat het bij jullie langskomt. Wat wel omvalt is het maatwerk eromheen: de koppeling die iemand ooit heeft gebouwd, de rapportage waar de directie op stuurt, de autorisatie die net iets te specifiek is ingericht.

Dit is de volgorde die ik aanhoud.

Vooraf: bepaal eerst wat je eigenlijk gebruikt

Voordat je aan testen begint, moet je weten wat er getest moet worden. Dat klinkt vanzelfsprekend en is het in de praktijk niet, want bij de meeste organisaties heeft niemand een compleet beeld van wat er in de omgeving zit.

Ik maak daarom eerst een lijst van vier dingen:

• De processen die dagelijks lopen. Verlof aanvragen, uren boeken, declaraties, in- en uitdienst, facturatie. Alles wat stilstaat als het niet werkt.
• De koppelingen naar buiten. Elk systeem dat gegevens uit je ERP-systeem haalt of erin zet. Denk aan een roosterpakket, een tijdregistratie, een webshop of een rapportagetool.
• De rapportages waar iemand op stuurt. Niet alle rapportages, alleen die waar op gestuurd wordt. Dat zijn er meestal minder dan tien.
• Het maatwerk dat je kunt aanwijzen. Eigen velden, eigen weergaven, workflows die van de standaard afwijken.

Deze lijst maak je een keer en onderhoud je daarna. Bij elke volgende update is het een halfuur werk in plaats van een dag.

Testen: met je eigen gegevens, niet met voorbeelddata

Een testomgeving met verzonnen medewerkers vertelt je of de knoppen het doen. Dat is niet waar het misgaat. Het gaat mis bij de medewerker met twee dienstverbanden, bij de afdeling waar de goedkeuring twee stappen heeft, bij het contract dat halverwege de maand ingaat.

Loop daarom je lijst van dagelijkse processen langs met echte situaties uit je eigen organisatie. Laat dat ook doen door de mensen die het werk normaal doen. Een functioneel beheerder klikt een proces anders door dan een salarisadministrateur, en de administrateur ziet in drie seconden dat er een kolom mist.

De vier dingen die het vaakst stuk gaan

Koppelingen

Als een koppeling gegevens ophaalt via een vaste definitie, en die definitie verandert of verdwijnt, dan stopt de koppeling. Vaak zonder foutmelding aan de kant waar iemand kijkt. Controleer na de update per koppeling of er nog gegevens doorkomen, en of het nog de goede gegevens zijn.

Autorisaties

Nieuwe functionaliteit komt met nieuwe rechten. Die staan standaard uit of standaard aan, en beide kan bij jullie verkeerd uitpakken. Het scenario dat ik het liefst voorkom is dat iemand plotseling bij salarisgegevens kan die hij eerder niet zag.

Rapportages en weergaven

Aangepaste weergaven en analyses zijn kwetsbaar, want ze verwijzen naar velden die van naam of plek kunnen veranderen. Als de maandrapportage voor de directie een dag na de update leeg is, ben je een vervelend gesprek verder.

Workflows

Meestal blijven die gewoon staan. Maar als er in dezelfde periode ook iets in de organisatie is veranderd, is de update wel het moment waarop het opvalt. Kijk daarom of er aanvragen zijn blijven hangen die er voor de update nog niet stonden.

De week erna: kijk of het echt goed ging

De meeste updates worden op de dag zelf gecontroleerd en daarna niet meer. Terwijl een deel van de problemen pas zichtbaar wordt als de eerstvolgende salarisverwerking draait, als de maandafsluiting komt, of als iemand de eerste declaratie van die maand indient.

Zet daarom een moment in je agenda, een week erna. Loop dan opnieuw je lijst langs en vraag de mensen die er dagelijks in werken of ze iets geks hebben gezien. Die vraag levert meer op dan welke controle dan ook, en hij kost vijf minuten.

Wat je vastlegt

Schrijf per update op wat je hebt getest, wat er is opgevallen en wat je hebt aangepast. Dat is saai werk en het betaalt zich terug op het moment dat er iets misgaat en iemand vraagt sinds wanneer dat zo is.

Bij mijn beheerklanten leg ik dat vast in hun eigen omgeving, zodat het bij de rest van de documentatie staat en niet in een map op mijn laptop. Als ik ooit vertrek, blijft het gewoon staan.

Tot slot

Een update is geen risico als je weet wat je hebt. Het overgrote deel van de paniek na een update komt voort uit het feit dat niemand meer precies wist wat er in de omgeving zat.

Wil je die lijst een keer samen opstellen? Dat is precies wat ik in de gratis quickscan doe. Een half uur bellen, daarna mijn bevindingen op papier.