Centric-release installeren bij een gemeente: de checklist
Releases van Key2Burgerzaken, Key2Financiën en andere Centric-applicaties blijven vaak liggen. Met deze checklist plant, test en installeert u ze zonder verrassingen.
Bij veel gemeenten stapelen Centric-releases zich op. Niet omdat niemand ze kan installeren, maar omdat een release altijd net iets meer is dan "op installeren klikken". Er hangen koppelingen aan, er draaien werkprocessen op en als het misgaat staat de balie stil. Deze checklist is de volgorde die wij zelf aanhouden, van planning tot nazorg.
Voor de installatie
Lees de releasenotes helemaal, niet alleen de samenvatting. Let vooral op drie dingen:
- Welke onderdelen wijzigen: de applicatie zelf, de database, koppelingen of berichtdefinities?
- Stelt de release nieuwe eisen aan de omgeving, zoals een nieuwere database- of frameworkversie, of een vernieuwd certificaat?
- Zijn er handmatige stappen na de installatie, zoals conversies, het opnieuw inlezen van tabellen of het aanpassen van instellingen?
Breng de koppelingen in kaart. Een release raakt bijna altijd het berichtenverkeer: de aansluiting op de BRP, de datadistributie (DDS), de koppeling met het zaaksysteem of met de financiële administratie. Noteer per koppeling wie de eigenaar is, hoe u die test en wat de gevolgen zijn als hij een dag uitvalt.
Test eerst in de testomgeving, en zorg dat die klopt. Een testomgeving die drie releases achterloopt op productie test iets anders dan wat u straks installeert. Werk hem eerst bij of ververs hem met een kopie van productie.
Plan een servicewindow en communiceer het. Buiten kantoortijden waar nodig. Laat balie, backoffice en de servicedesk weten wanneer de applicatie niet beschikbaar is en hoelang. Een verrassing op maandagochtend kost meer goodwill dan een geplande avond.
Regel de terugvaloptie. Maak vlak voor de installatie een back-up of snapshot van de applicatie- en databaseserver, en controleer dat u weet hoe u die terugzet. Een release zonder hersteloptie is geen risico, het is een gok.
Zet een lijn naar de leverancier open. Meld vooraf aan dat u installeert, of zorg dat u weet wie u belt. Zo begint u niet onderaan de wachtrij als er iets misgaat.
Tijdens de installatie
- Houd de volgorde uit de releasenotes aan. Meestal: database, dan applicatie, dan koppelingen.
- Log elke stap met tijdstip en resultaat. Bij een storing, ook weken later, is dat logboek goud waard.
- Doe direct een rooktest: inloggen, een dossier of zaak openen, een bericht versturen en controleren of het aankomt.
- Stop bij een foutmelding die u niet begrijpt. Doorklikken maakt een klein probleem groot.
Na de installatie
- Laat key-users hun eigen processen doorlopen. De beheerder ziet of de applicatie draait, de gebruiker ziet of het werk kan doorgaan.
- Controleer het berichtenverkeer expliciet: worden berichten aangemaakt, verstuurd én verwerkt aan de andere kant?
- Houd de eerste dagen de logboeken en foutmeldingen in de gaten. Veel problemen tonen zich pas bij het eerste maandeinde of de eerste batchverwerking.
- Werk de documentatie bij: versienummer, datum, afwijkingen van de standaardprocedure en openstaande punten.
- Zet de volgende release meteen in de kalender.
Het echte geheim: ritme
Eén release per kwartaal installeren is makkelijker dan drie in één keer. Hoe langer u wacht, hoe groter de sprong, hoe meer koppelingen tegelijk veranderen en hoe lastiger het wordt om te achterhalen waar een fout vandaan komt. Een vaste releasekalender, met een vast moment om te testen en een vast servicewindow, haalt de spanning uit het proces. Het wordt dan gewoon werk in plaats van een project.
Loopt uw gemeente achter en weet u niet precies hoeveel? Begin met inventariseren: welke versies draaien er, welke releases staan open en welke koppelingen zijn geraakt. Dat overzicht is precies wat onze quickscan oplevert.