Bij standaardsoftware heeft u geen invloed op wanneer er een update komt, alleen op wat u ermee doet. In de praktijk ontstaan er twee patronen, en allebei kosten ze u geld. Het eerste is uitstellen: updates worden overgeslagen tot u zo ver achterloopt dat bijwerken een project wordt en de leverancier geen ondersteuning meer geeft. Het tweede is klakkeloos installeren, waarna op maandagochtend blijkt dat een koppeling niet meer werkt. Wij zitten ertussenin: beoordelen wat een update voor úw inrichting betekent, testen wat risico loopt en pas dan doorvoeren.

Wat wij in uw releasemanagement oppakken

  • Aankondigingen volgen. Bijhouden wat uw leveranciers uitbrengen en beoordelen wat u werkelijk raakt, in plaats van elke releasenote doorspitten.
  • Testen wat risico loopt. Vooral uw koppelingen en maatwerk, want daar breekt het, niet in de standaardfunctionaliteit.
  • Een planning die past. Updates inplannen op momenten die uw organisatie uitkomen, niet midden in een maandafsluiting of een examenperiode.
  • Terugvalscenario. Vooraf weten wat u doet als het misgaat, want dat bedenken tijdens een verstoring gaat altijd fout.
  • Terugkoppeling. Uw gebruikers vooraf laten weten wat er verandert, zodat de servicedesk niet overspoeld wordt met vragen.

Waarom testen er structureel bij inschiet

Testen kost tijd op een moment dat er niets aan de hand is, en de opbrengst is onzichtbaar: als het goed gaat, merkt niemand dat u het gedaan heeft. Daardoor verliest het altijd van werk dat wel urgent voelt. Het tweede probleem is dat vaak niet duidelijk is wát er getest moet worden. Alles doorlopen is niet haalbaar, dus wordt er in de praktijk niets gedaan. De oplossing is niet meer testen maar gerichter: bij standaardsoftware breekt het bijna nooit in de standaardfunctionaliteit, maar in de koppelingen, het maatwerk en de rapportages die u zelf heeft gebouwd. Dat is een korte lijst, en die is wel elke keer te doorlopen.

Hoe wij het aanpakken

We beginnen met vaststellen wat er bij u kwetsbaar is: welke koppelingen bestaan er, welk maatwerk zit erin en welke rapportages zijn gebouwd op velden die kunnen wijzigen. Dat levert de testlijst op die we bij elke release doorlopen. Daarna richten we het ritme in: wanneer beoordelen we een aankondiging, wanneer testen we, wanneer gaat het live. Bij leveranciers met een vast releaseritme, zoals drie keer per jaar, plannen we die momenten vooruit zodat ze niet samenvallen met uw drukke periodes. Wat we testen en bevinden, leggen we vast, zodat u kunt zien waarom een update wel of niet is doorgevoerd.

Wat het u oplevert

Het meest merkbare is dat maandagochtend rustig blijft. Storingen na een update zijn vervelend omdat ze iedereen tegelijk raken en omdat de oorzaak vaak pas laat gevonden wordt. Wie vooraf test, vangt het merendeel daarvan af. Het tweede is dat u bij blijft: organisaties die updates uitstellen, komen op een punt waar ze meerdere versies achterlopen en de leverancier geen ondersteuning meer geeft, en dan wordt bijwerken ineens een project met een projectbudget. Het derde is rust bij uw mensen, omdat ze weten wat eraan komt in plaats van het te ontdekken.

U beslist wat er live gaat

Wij testen, adviseren en voeren uit, maar de beslissing om iets door te voeren blijft bij u. Wat we hebben getest en gevonden, leggen we vast, zodat u die keuze onderbouwd kunt maken en later kunt terugzien waarom er iets is besloten. De testlijst en het ritme zijn van u en gaan mee als u het beheer terugneemt of elders belegt.

Veelgestelde vragen over releasemanagement

Wij lopen meerdere versies achter. Kunnen jullie dat inhalen?

Ja, maar dat is een traject op zich en geen reguliere update. We brengen eerst in kaart wat er tussen uw versie en de huidige is veranderd en kiezen dan of we in stappen of in één keer bijwerken.

Wat testen jullie precies?

Vooral uw koppelingen, maatwerk en zelfgebouwde rapportages, want daar breekt het. De standaardfunctionaliteit test de leverancier zelf al uitgebreid.

Hebben wij een testomgeving nodig?

Bij voorkeur wel. Is die er niet, dan kijken we naar wat de leverancier biedt of naar een tijdelijke omgeving. Testen in productie raden we af.

Kunnen jullie updates buiten kantoortijd doorvoeren?

Ja, en bij kritische applicaties is dat meestal ook het verstandigst. We spreken vooraf een moment af dat uw organisatie uitkomt.

Wat als een update toch een probleem geeft?

Dan valt u terug op het scenario dat we vooraf hebben afgesproken. Dat vooraf bedenken is het halve werk; tijdens een verstoring is er geen tijd om het te verzinnen.

Hoe snel kunnen jullie beginnen?

Meestal binnen 1 tot 2 weken. We starten met het vaststellen van wat er bij u kwetsbaar is, want dat is de basis onder elke test.

Geef ons in twee zinnen uw situatie: om welke applicaties het gaat, hoe ver u achterloopt en of er een testomgeving is. U krijgt binnen een werkdag een onderbouwd antwoord. Verwant: Applicatiebeheer uitbesteden en Applicatiebeheerder Salesforce inhuren.