MCTL - Managing Computer Technology Library

Transcriptie

1 17. TAAKGEBIED TRANSITIE Het laatste taakgebied in het taakcluster Change control is Transitie. Transitie betekent letterlijk overgang en dat is in dit kader een goed getroffen term. In dit taakgebied gaat het om de overgang in productie van de huidige werkwijze (bedrijfsproces) + huidige systeem naar een gewijzigde werkwijze (bedrijfsproces) + gewijzigd systeem. ACHTERGROND Wijzigingen zijn op zichzelf niet bijzonder. Wat in het kader van Transitie wel een aandachtspunt kan zijn is dat key-users en functioneel specialisten veel meer en intensiever met wijzigingen te maken hebben dan een gemiddelde eindgebruiker. Voor een eindgebruiker is een tamelijk stabiele werkwijze samen met een tamelijk stabiel systeem de standaard, en een wijziging op dat systeem feitelijk een uitzonderlijke situatie. Het is dus zaak de gebruikers, inclusief het bijbehorende lijnmanagement, enigszins aan de hand te nemen om een wijziging zowel technisch als functioneel te laten slagen. Wijzigingen hebben daarnaast veelal ook een technische component. Er dient daarom vanuit functionele support afstemming te zijn met infra en applicatiesupport en evt. leveranciers van de computertechnologie. In dit taakgebied wordt verder ingezoomd op de functionele aspecten van de invoering van een wijziging in de productieomgeving. DOEL VAN DIT TAAKGEBIED Het doel van transitie is het in de productieomgeving daadwerkelijk effectueren van de wijzigingen in het bedrijfsproces en de bijbehorende computertechnologie ( het systeem ). De wijzingen zijn daarmee voor alle gebruikers beschikbaar gekomen. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: De doelstellingen van de aanpassingen zijn aantoonbaar bereikt De productieomgeving is zowel op het vlak van het bedrijfsproces als systeem aangepast conform requirements, en gebruikers kunnen hier werkelijk gebruik van maken Het aantal functionele vragen en fouten is in de maand na de inproductiename niet meer dan 100% hoger dan gemiddeld in de afgelopen zes maanden De afrondende activiteiten zoals het bijwerken en opslaan van documentatie, archivering c.q. verwijdering van niet meer relevante spullen zijn uitgevoerd De nazorgactiviteiten zijn beëindigd en het systeem is geheel in beheer genomen Gebruikers zijn tevreden over het verloop van de wijzigingen De eigenaar van bedrijfsproces en systeem heeft akkoord gegeven (systeem- of proceseigenaar) (Genoemde percentages zijn uiteraard indicatief) V1.0 Pagina 1

2 INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn als volgt schematisch weer te geven: Hierna worden de activiteiten nader besproken. ACTIVITEIT: OPSTELLEN / BIJWERKEN TRANSITIEPLAN In deze activiteit wordt het transitieplan opgesteld, of als het al bestaat, bijgewerkt. Het is erg aan te bevelen dit plan zodanig op te stellen dat het kan worden hergebruikt. In principe wordt hier dus uitgegaan van het bijwerken van het transitieplan, en niet het (steeds opnieuw) opstellen ervan. Het transitieplan omvat: 1. Detailplanning van zowel de voorbereidende activiteiten als de activiteiten die tijdens de transitie zelf moeten worden uitgevoerd 2. Tijdsplanning 3. Afstemming met infra en applicatie support en waar nodig met leveranciers (taken/ bevoegdheden / verantwoordelijkheden) 4. Go no go moment(en) 5. Risico s en maatregelen om risico s te voorkomen of de gevolgen te beperken Een transitieplan kan afhankelijk van de omvang en aard van de wijziging klein tot zeer omvangrijk zijn. Soms volstaat een simpele checklist, soms is een fors document nodig. Het is geen gekke suggestie enkele verschillende versies te maken en afhankelijk van de situatie op basis van een van deze versies een uitwerking te maken. Op die wijze kan tegen minimale tijdsinspanning een plan worden gecreëerd dat tijdens de werkelijke transitie voldoende houvast biedt. V1.0 Pagina 2

3 ACTIVITEIT: INFORMEREN / OPLEIDEN GEBRUIKERS Gebruikers moeten vooraf volledig en juist op de hoogte worden gebracht van de aanstaande wijzigingen. Te denken hierbij is: 1. Een overzicht van de wijzigingen in de taal van de gebruikers, inclusief de aanleiding en het belang van de wijzigingen en de consequenties indien met het gewijzigde systeem de oude werkwijze gehanteerd blijft worden 2. Wanneer gaan de wijzigingen in productie 3. Wat gebeurt er indien de inproductiename onverhoopt niet goed verloopt (terug naar het oude systeem en oude werkwijze?, of eenvoudigweg afwachten, of?) Afhankelijk van de behoefte en mogelijkheden kan een en ander worden gedaan in mondelinge sessies, via of social media, een videoboodschap, een e-learning omgeving, faq s op het intranet, wiki s, in een nieuwsbrief en natuurlijk via gewijzigde werkinstructies en gebruikershandleidingen. Op het moment dat gebruikers worden geïnformeerd over de wijzigingen is er een natuurlijke neiging dit zo compact mogelijk te doen. Immers, de gebruikers moeten daarvoor hun gewone werk onderbreken, en het is niet uitzonderlijk dat gebruikers simpelweg niet op de wijzigingen zitten te wachten. Toch is het juist zaak hier functioneel behoorlijk op in te zetten. Dit is immers dé gelegenheid om gebruikers de wijzigingen, maar vooral ook het nut en belang ervan, tussen de oren te krijgen. Een mooi principe is hierbij om gebruikers te leren om het zelf te doen. Zoals ook al eerder is betoogd moet worden voorkomen dat gebruikers aan het functionele infuus gaan hangen, en dus elk wissewasje een beroep doen op de key-user of functioneel specialist. Wat ook wel wordt getracht is om slechts enkele gebruikers van een afdeling in te lichten, en die moeten vervolgens het hun collega s maar vertellen. Voordeel is natuurlijk dat de Keyusers en functioneel specialisten worden ontlast. Maar hoe groot is de kans dat de betreffende gebruikers dit inhoudelijke stokje volledig en correct doorgeven? En bovendien, de key-users en functioneel specialisten worden weliswaar ontlast, het werk is daarmee echt niet verdwenen (maar verschoven). Tot slot is dit ook bij uitstek een moment om niet-gewijzigde onderdelen van een bedrijfsproces of systeem waar gebruikers opvallend vaak problemen mee hebben voor het voetlicht te brengen. In sommige organisaties is een interne afdeling opleidingen aanwezig. Indien dit het geval is, kunnen genoemde activiteiten daar worden uitgevoerd. Tot slot nog een aardig voorbeeld van hoe gebruikers al snel in de war kunnen raken in een wijzigingstraject dat gefaseerd wordt uitgevoerd: Vanwege een softwarewijziging moet ook allerlei hardware worden vervangen. Omdat dat bij V1.0 Pagina 3

4 elkaar een behoorlijke belasting vormt voor de uitvoerende afdeling, wordt ervoor gekozen de nieuwe hardware al eerder te plaatsen. Tot verbazing van de technische crew raken gebruikers geheel in de war. Zij krijgen immers wel de nieuwe hardware, maar na het opstarten zien ze nog de oude software verschijnen. Het vereist de nodige functionele inzet om alle gebruikers duidelijk te maken hoe het totale traject eruit ziet en wanneer de volledige eindsituatie zal zijn bereikt. ACTIVITEIT: INFORMEREN EXTERNE KLANTEN Indien externe klanten ook direct met het gewijzigde systeem te maken krijgen, dan moeten zij ook worden geïnformeerd. Het verdient aanbeveling vooral de voordelen van de wijzigingen te benadrukken, omdat doorgaans wijzigingen van systemen ook wel overlast veroorzaken waar de meeste klanten niet bepaald op zitten te wachten. ACTIVITEIT: VOORBEREIDEN FUNCTIONEEL SUPPORT / SERVICE DESK Naast de gebruikers moet ook functioneel support en de service desk zichzelf voorbereiden op de komende wijzigingen. Veelal zijn slechts één of een paar mensen binnen Functioneel support echt inhoudelijk op de hoogte van de wijzigingen tijdens alle activiteiten voorafgaand aan transitie. Hier wordt de nodige informatie onder de eigen collega s van functioneel support en de service desk verspreid, zodat ook zij goed op de hoogte zijn van de in productie komende wijzigingen. Mochten er dan toch heel onverwachte gebeurtenissen zijn in niet gewijzigde systemen, dan is in ieder geval bekend waar mogelijkerwijs de oorzaak ligt. Ook in de functionele ondersteuning na transitie kunnen collega s en de service desk een rol spelen mits zij van de laatste stand van zaken op de hoogte zijn. Met andere woorden: net zoals bij infra en applicatie support kennis over wijzigingen intern wordt verspreid, moet dat aan de functionele kant precies zo gebeuren. ACTIVITEIT: UITVOEREN TRANSITIE(PLAN) Hierna worden de activiteiten op functioneel terrein verder uitgewerkt. Controle op technisch volledige inproductiename Infra en applicatie support, evt. samen met leveranciers, zullen zorgen voor de technische inproductiename. Vanuit de functionele kant is een controle nuttig. In de praktijk kan dat worden vormgegeven door, voor de wijzigingen worden uitgevoerd, voor iedereen de toegang tot het systeem in productie te blokkeren. Nadat de wijzigingen aan de technische zijde zijn uitgevoerd, en daar gecontroleerd, wordt het systeem in productie alleen vrijgegeven voor de functioneel specialisten en key-users. Zij kunnen dan, met een functionele bril op, een laatste check doen of er inderdaad geen elementen zijn vergeten. Aanpassingen parameters / configuratie V1.0 Pagina 4

5 Indien technisch gezien het systeem goed is opgeleverd, kan worden vervolgd met het aanpassen van de functionele parameters en configuratie in de productieomgeving. Dit is al eerder gedaan in de verschillende ontwikkel- en testomgevingen, en zou hier verder geen bijzonderheden mogen opleveren. Zie ook de eerdere beschrijving van de activiteiten in de taakgebieden Ontwerp en Realisatie. Aanpassingen autorisaties + controle op de aanpassingen Het aanpassen van autorisaties vanwege wijzigingen in functieprofielen dient hier nu in de productieomgeving te worden uitgevoerd en gecontroleerd. Praktijkprobleem is dat te weinig / ontbrekende autorisaties snel opvallen, maar teveel autorisaties niet. En als ze al opvallen, dan zijn gebruikers vaak weinig geneigd om dit te melden. Het is immers vaak wel fijn om iets meer te mogen dan eigenlijk de bedoeling is. Ook hier ligt dus een controlerende taak voor key-users en functioneel specialisten. Controle gegevensconversie Zoals al eerder in het taakgebied Gegevensbeheer besproken is de inhoudelijke juistheid van databases geheel een verantwoordelijkheid van de gebruikersorganisatie. Veelal is het uitvoeren van een conversie een taak die door applicatie support wordt uitgevoerd of begeleid. Vanuit functioneel support kan assistentie worden verleend bij de inhoudelijke controle. Soms kunnen key-users en functioneel specialisten zelf de juistheid vaststellen, en is de verantwoordelijkheid vanuit de gebruikersorganisatie aan hen gedelegeerd. In andere gevallen zullen gebruikers zelf moeten opdraven om de juistheid vast te stellen. Ook in dat laatste geval zullen functioneel specialisten handen spandiensten verlenen om het in goede banen te leiden. Uitvoeren handmatige gegevensconversie Indien de conversie van gegevens niet geheel via het systeem wordt uitgevoerd, via software / scripts, moeten gegevens met de hand worden geconverteerd. Indien dit het geval is ligt deze taak op het bordje van de gebruikersorganisatie. Deze voeren dit uit met begeleiding van functioneel support. Soms kan een externe partij voor de nodige extra menscapaciteit zorgen, die dan ook vanuit Functioneel support wordt begeleid. Daadwerkelijk doorvoeren documentatiewijzigingen De gewijzigde werkinstructies, gebruikershandleidingen en formulieren moeten op de juiste plaats worden neergezet, en oudere versies gearchiveerd. Ook documentatie die een service desk gebruikt (faq s, interne database met oplossingen, wiki), en documentatie die binnen functioneel support zelf wordt gebruikt, wordt hier vervangen. Bijhouden afwijkingen t.o.v. transitieplan en de requirements / specificaties Alle afwijkingen ten opzichte van het transitieplan en de eerder opgestelde requirements / specificaties worden genoteerd. Deze vormen input om hierna een go / no go beslissing te nemen. Indien het een go wordt, vormt de lijst met afwijkingen input om achteraf te bezien of alsnog aanpassingen moeten worden gedaan. Vaak zijn bijvoorbeeld cosmetische foutjes geen reden om een inproductiename af te blazen, maar ook dergelijke foutjes zijn niet helemaal juist. Deze kunnen dan in een volgende ronde van aanpassingen worden meegenomen. V1.0 Pagina 5

6 Go / no go Op een zeker moment, vooraf afgesproken en opgenomen in het transitieplan, is er sprake van een go / no go. Aan de functionele zijde (en tegelijkertijd aan de technische zijde) zal een besluit moeten worden genomen of de situatie zodanig is dat doorgegaan kan worden, of dat de wijzigingen moeten worden teruggedraaid ( fall back ). In het geval van een teruggang naar de oude situatie moeten gebruikers daarvan op de hoogte worden gesteld. Het kan ook dat in geval van een no go niet naar de oude situatie wordt teruggegaan (bijvoorbeeld omdat dat onmogelijk is), maar dat een ander noodscenario in gang wordt gezet. In dat laatste geval is een strakke begeleiding van gebruikers hierin absolute noodzaak. Bij een verzekeringsmaatschappij wordt in een weekend een forse update op het systeem doorgevoerd. Gebruikers zijn netjes vooraf op de hoogte gesteld, en tijdens de update is gebruik van het systeem geblokkeerd. Maandagochtend vanaf 07:00 is het systeem weer beschikbaar. En inderdaad; de vroege vogels die al rond die tijd inloggen krijgen een werkend systeem voor hun neus. Alleen wel het oude. Omdat verdere mededelingen ontbreken raken gebruikers geheel in de war; kan er nu gewerkt worden of niet? En stel dat ze aan het werk gaan, is het werk dan over enige tijd niet verloren omdat opeens toch het nieuwe systeem beschikbaar is, en de gegevens niet worden meegenomen? Of moeten ze misschien toch anders inloggen? Met de groei van het aantal gebruikers die ochtend neemt de verwarring hand over hand toe en de key-users en functioneel specialisten worden overspoeld met vragen. Uiteindelijk blijkt dat de update in het weekend helaas niet goed is gegaan, en conform plan het oude is teruggezet. Dat is technisch perfect verlopen. Helaas is functioneel verzuimd de gebruikers in te lichten. Met als gevolg dat een keurig uitgevoerd scenario toch tot veel onnodige onrust en tijdverlies op de werkvloer heeft geleid. En in dit geval volkomen ten onrechte de technische crew de schuld in de schoenen krijgen geschoven. ACTIVITEIT: NAZORG Aanpassingen zijn pas geheel af indien gebruikers goed overweg kunnen met de aanpassingen in het aangepaste bedrijfsproces, en alle daarom heen spelende zaken op het gebied van documentatie zijn afgerond. Daarnaast kan het zijn dat vanuit leveranciers de dienstverlening is gewijzigd. Ook dit zal dan moeten worden gemonitord: worden de nieuwe afspraken nagekomen? De historie van nazorg In het verleden was nazorg een non-existente activiteit. Wijzigingen werden simpelweg over de muur gegooid waarna de gebruikers er maar het beste van moesten zien te maken, samen met Service Desk medewerkers die vaak ook nauwelijks inhoudelijk op de hoogte waren van wijzigingen. Degenen die de wijzigingen hadden gemaakt en getest waren alweer bezig met de V1.0 Pagina 6

7 volgende wijziging en niet aanspreekbaar voor ook maar de minste nazorg. De negatieve effecten van bovengeschetste werkwijze waren overduidelijk. In de daarop volgende fase werd ervoor gezorgd dat in een afgesproken tijdsperiode degenen die bij de wijziging waren betrokken, nog konden worden aangesproken op de wijzigingen en daarin ondersteuning konden verlenen. Bijvoorbeeld na afloop van een release of project waren de medewerkers nog twee weken beschikbaar voor nazorgpunten. In deze fase zitten veel organisaties nog steeds. Toch is ook een vastgestelde periode ook nog niet ideaal: stel dat aan het eind van de nazorgperiode de wijzigingen nog steeds niet goed zijn geland, of nog steeds bovenmatig veel issues veroorzaken? De echte invulling van nazorg kan via twee wegen geschieden: 1. Er kunnen criteria worden vastgesteld aan de hand waarvan kan worden bepaald of de wijzigingen geheel operationeel beheerd kunnen worden of niet. Bijvoorbeeld: indien er per week niet meer dan 10 vragen wordt gesteld of 1 nieuwe fout wordt gemeld over het gewijzigde onderdeel, dan wordt de wijziging vanuit beheer geaccepteerd en zijn degenen die de wijziging hebben uitgevoerd ontslagen van verdere nazorgverplichtingen 2. In het geval met sprints wordt gewerkt, waarin tamelijk kort cyclisch nieuwe wijzigingen in productie worden genomen, kan ook het systeem worden gehanteerd dat in principe alle issues van een vorige sprint in de eerstvolgende sprint worden opgelost. Aldus ontstaat ook een natuurlijke druk om zoveel mogelijk werkzaamheden in één keer goed op te leveren. Voor nazorg dient altijd wat extra capaciteit, zowel aan de functionele als aan de technische kant, beschikbaar te zijn. Ook kan het in voorkomende gevallen nuttig zijn extra capaciteit bij de betrokken leveranciers te regelen. In het geval van ongemakken/fouten in de productieomgeving die via een workaround tijdelijk zijn op te vangen dient de service desk daarvan op de hoogte te worden gebracht en kan dat daar worden gebruikt om gebruikers te helpen tijdelijk deze issues te omzeilen. OPMERKINGEN De volgende opmerkingen zijn te maken in het kader van transitie. 1. GEFASEERDE INPRODUCTIENAME De transitie is pas afgerond indien de gehele gebruikersgroep van alle wijzigingen gebruik kan maken. Het is soms te verantwoorden, of zelfs noodzakelijk, om de transitie gefaseerd in de productieomgeving uit te voeren. Een kenmerkende situatie die is die waarin er sprake is van meerdere productieomgevingen. Vroeger was dat geografisch het geval; bijvoorbeeld was er dan een productieomgeving in Groningen, Amsterdam, Den Haag, Goes, Eindhoven, Maastricht en Arnhem. In dat geval kon er voor worden gekozen eerst de wijzigingen in bijvoorbeeld Groningen uit te voeren, omdat dat de meest representatieve omgeving was voor alle andere omgevingen. Technisch geeft dat soms complicaties vanwege ongelijke productieomgevingen, maar steeds vaker geeft dit ook functionele effecten omdat tijdelijk bedrijfsprocessen van elkaar gaan afwijken. Een moderne variant V1.0 Pagina 7

8 op deze gefaseerde invoering is in web omgevingen te vinden. Bezoekers van websites komen vaak in een cluster terecht waarin meerdere servers de interactie afhandelen en achterliggend meerdere databases beschikbaar zijn. In geval van een inproductiename kan een gedeelte van deze complete omgeving worden afgeschakeld, waarbij de bezoekers naar het overblijvende deel worden gerouteerd. In het afgeschakelde deel wordt de update uitgevoerd en dit wordt vervolgens weer bijgeschakeld. Aldus is ook tijdens de update de website beschikbaar, en kan heel goed worden gemonitord hoe het reeds geupdate deel van het systeem zich gedraagt met de bezoekers die daar terecht komen. Tot slot kan ook worden gewerkt met bèta-versies waarvan gebruikers zichzelf al realiseren dat, hoewel productie, daar wellicht niet alles perfect werkt. Ook daarvan zijn vooral voorbeelden op internet te vinden. Duidelijk zal zijn dat een gefaseerde inproductiename ook op functioneel vlak de nodige perikelen veroorzaakt. Indien de omvang of complexiteit van de wijzigingen te groot wordt, kan er daarom beter voor worden gekozen de wijzigingen in de tijd op te knippen en in meerdere cycli de wijzigingen naar productie te brengen. Scrum, met tamelijk kort cyclische sprints van 2, 3 of 4 weken, is daar een mooi voorbeeld van. Functioneel is er dan meer grip te houden op de uitvoering, maar zeker ook op de inproductiename die dan veel minder omvangrijk is. En bij een inproductiename van wijzigingen elke drie weken ontstaat op heel natuurlijke wijze ook een schat aan ervaring. 2. GEBRUIKERSTEVREDENHEID TRANSITIE Los van de andere tevredenheidsonderzoeken die kunnen worden uitgevoerd, is het mogelijk specifiek voor transitie een tevredenheidsonderzoek onder gebruikers uit te voeren. Het zal duidelijk zijn dat het niet is aan te raden dit bij elke transitie te doen. Hierna volgen wat suggesties van vragen die in een dergelijk onderzoek kunnen worden gesteld: 1. Zijn de wijzigingen conform de afgesproken tijd in productie genomen? 2. Zijn de wijzigingen precies zoals u had verwacht? 3. Bent u vooraf inhoudelijk voldoende geïnformeerd over de wijzigingen? 4. Bent u tijdig geïnformeerd over de wijzigingen? 5. Bent u zelf tevreden over inhoud van de wijzigingen (vindt u ze nuttig in uw eigen werk?) 6. Bent u zelf tevreden over de kwaliteit van de uitvoering (weinig tot geen fouten tijdens en na de wijziging)? 7. Heeft u opmerkingen waardoor in de toekomst een volgende wijziging (nog) beter kan verlopen? En ook zonder gebruikerstevredenheidsonderzoek is functioneel vaak makkelijk te constateren dat de transitie is geslaagd: Als gebruikers de gewijzigde werkwijze en het gewijzigde systeem soepel gebruiken, nauwelijks vragen hebben en nauwelijks fouten melden..dan zit het meestal wel goed. V1.0 Pagina 8