Insights van een platformmigratie

HELP, WAAR ZIJN MIJN KEY-USERS!

Door de grote hoeveelheid aan applicaties en directe betrokkenheid van de professionals op de afdelingen ben ik gedurende een dergelijke migratie inhoudelijk afhankelijk van (key-)users. Het formele akkoord op de migratie-readiness van de applicatie lag in de meeste gevallen bij functioneel beheer. In veel gevallen wordt kwaliteitsbewaking en testen pas vrij laat in het project geborgd. Ook in dit traject was dat het geval. Hierdoor ben ik tegen een aantal uitdagingen aangelopen, te beginnen bij de planning van de uit te voeren gebruikerstest.

Bij iedere applicatie ging een reeks vragen vooraf. Allereerst: wie kunnen de gebruikerstesten uitvoeren? Verdere vragen volgden vanzelf. Zijn er key-users aangewezen? Zo niet: heeft de applicatie een functioneel -/applicatiebeheerder? Sommige applicaties hebben echter geen key-user én worden niet formeel beheerd. Wie zijn dan de gebruikers van de applicatie? En als je deze hebt weten te lokaliseren, zijn zij formeel bevoegd om akkoord te geven? Het is een zoektocht, maar essentieel voor goede communicatie en uiteindelijk een goede migratie. En met migraties is het ook zo: deze hebben vaak een lange doorlooptijd, ze worden gewoon over vakantieperiodes heen gepland. Hierbij wordt vrijwel geen rekening te houden met de aanwezigheid van key-users of functioneel beheer.

Een van de belangrijkste zaken die uitgezocht moeten worden in de voorbereidingsfase is: Op welke client draaien de applicaties en moet dus getest worden? Fat-client, thin-client, Computer On Wheels (verder: COW)? Er zit een hoop verschil in. Een thin client is doorgaans makkelijk te regelen, een fat-client moet speciaal ingericht worden, de beschikbaarheid van een COW moet afgestemd worden met de gebruikers.

KAN IK NOG MEER AANPASSEN NU IK TOCH BEZIG BEN?

Een migratie is veel werk, maar het uitgelezen moment om veel aan te pakken. Tijdens een platform migratie komt het gehele IT-landschap onder een vergrootglas te liggen. De applicaties vallen dan in een aantal categorieën uiteen.

• Te migreren applicaties
• Standalone applicaties die niet gemigreerd hoeven te worden
• Uit te faseren applicaties:
  • Applicaties die niet meer gebruikt worden
  • Die slechts door 1 of enkele gebruikers gebruikt worden
  • Applicaties die vervangen dienen te worden
• Applicaties die niet compatible zijn met het nieuwe platform.
  • Kunnen deze vervangen worden door een compatible systeem?
  • Als hier geen geld/tijd voor beschikbaar is, dan moet het blijven draaien op oude systeem (fat-client, niet ideaal – extra onderhoud)

Zoals je kunt begrijpen vindt op deze manier naast een migratie vaak een efficiëntie-/opruimingsslag plaats. Soms betekent dit dat eerst geprobeerd wordt een applicatie te migreren. Pas als dit niet succesvol lukt, wordt besloten om er anders mee om te gaan. Testen van de gemigreerde applicatie geeft dit inzicht.

ACH, ER ZIJN VAST NOG WEL AFHANKELIJKHEDEN

De kans dat tijdens de migratie waar ik verantwoordelijk voor ben de tijd voor andere projecten stil staat is nihil, dus naast dat de werkzaamheden binnen de ziekenhuizen gewoon door gingen, waren we ook afhankelijk van enkele andere projecten.

• Gelijktijdige implementatie van een nieuw EPD-systeem (in dit geval EPIC). Dit was een groot project dat veel tijd van key-users vergde, waardoor zij minder tijd aan het migratieproject konden besteden. Hiervan bewust zijn hielp mij om zo efficiënt mogelijk om te gaan met de beschikbare tijd.
• De migratie Office 2010 naar Office 2017. Een pakket waar veel systemen een koppeling mee hebben. Helaas was het niet altijd mogelijk de applicaties die een koppeling met Office hadden later te migreren. Doordat deze overgang gelijktijdig plaatsvond, moesten sommige (reeds succesvol gemigreerde) applicaties nu dubbel getest worden. Hier werd extra tijd voor gepland.
• Terugbrengen van het aantal fatclients door meerdere thinclients in gebruik te nemen, tenzij dit echt niet mogelijk was. Of een applicatie enkel op een fatclient kon draaien was van tevoren niet altijd duidelijk bij het migratieteam; hier was explorerend testen een manier om dit uit te vinden.

INKOPPER OF NIET, GOED OM REKENING MEE TE HOUDEN

1. Voer eerst een basale pre-test uit voordat je gebruikers naar de applicatie laat kijken. Hiermee voorkom je dat de gebruiker voor niets komt, motivatie verliest en de test herpland moet worden.
2. Gebruikers dienen input te leveren; zij weten als geen ander wat belangrijke scenario’s zijn en wat het verwachte gedrag van de applicaties is. Zorg dat je de (key) users in voldoende mate betrekt.
3. Waak voor de scope van het project; voor gebruikers het is aanlokkelijk om reeds bestaande fouten in de applicatie aan te geven bij het migratieproject. (“..wie weet; kunnen ze dit even meepakken..”). Dit soort known errors vallen doorgaans buiten de scope van het project en discussie hierover of zelfs het oplossen hiervan kan tot vertraging leiden.
4. Naast de meest voorkomende scenario’s is het bij een platform-migratie belangrijk te testen of alle koppelingen nog werken. Interne koppelingen natuurlijk, maar vooral koppelingen met andere systemen, randapparatuur, etc.
5. Een inkopper, maar beperk de bewegende vlakken. Het tegelijkertijd migreren naar Office 2017 had als gevolg dat sommige, reeds gemigreerde applicaties opnieuw aangepast moesten worden om goed te functioneren met Office 2017.

EN NU: OP NAAR DE VOLGENDE!

 Deze migratie was een behoorlijk complex project waar ikzelf na afloop zeker wijzer uit ben gekomen. Bij een volgend project ongetwijfeld weer genoeg uitdagingen!