Change support is het taakcluster waarin alle functionele aanpassingen aan de computertechnologie (software, hardware, databases) en gerelateerde werkprocessen (instelling parameters, configuratie van software) gestructureerd worden uitgevoerd. Veel taken hiervan liggen op het terrein van de techniek. Hier wordt nadrukkelijk de functionele invalshoek genomen, maar vanzelfsprekend wel afgestemd met de in de techniek uit te voeren werkzaamheden.
Introductie
Het aanpassen van computertechnologie is geen bijzonderheid. De stroom wijzigingen in de eigen organisatie, van buiten komende wijzigingen zoals bijvoorbeeld wetswijzigingen of wijzigingen in organisaties waar zaken mee worden gedaan, en tot slot aanpassingen die vanuit leveranciers van computertechnologie op de organisatie afkomen, zijn aan de orde van de dag. Wijzigingen dienen over het algemeen eerst op hun functionele aspecten te worden beoordeeld, en met name in het licht van de bedrijfsprocessen in de organisatie te worden bezien. Met andere woorden: elke wijziging wordt eerst uitgewerkt in de consequenties voor het bedrijfsproces, en pas daarna volgt de uitwerking in de noodzakelijke aanpassingen in de computertechnologie.
Rollen die hier de hoofdrol spelen, zijn met name die van de Functioneel beheerder. Ook de Business Analist of Requirements Engineer, indien aanwezig, zijn hier aan het werk. In verband met realisatie en testen kunnen de Key-users en (indien aanwezig) Testers aanhaken.
Indeling taakcluster
Schematisch ziet het taakcluster Change support er als volgt uit:
Korte beschrijving van de taakgebieden
Hieronder worden de vijf taakgebieden van het taakcluster Change support kort toegelicht:
1. Requirements management
In het taakgebied Requirements management worden de (nog niet gerealiseerde) behoeften van gebruikers geïdentificeerd, gespecificeerd, gevalideerd en onderhouden.
2. Ontwerp
In het taakgebied Ontwerp worden de requirements uitgewerkt tot een beschrijving die de basis is voor zowel het aanbrengen van wijzigingen op functioneel als technisch (niet-functioneel) gebied.
3. Realisatie
Het taakgebied Realisatie draag zorg voor de daadwerkelijke aanpassingen. Deze vallen uiteen in functionele aanpassingen in bijv. de parameterinstellingen, configuratie en gebruik van vrije velden in een systeem en de bijbehorende documentatie in de vorm van gebruikershandleidingen en werkinstructies. Aan de technische zijde vinden tegelijkertijd ook de nodige acties plaats. Deze twee groepen activiteiten worden op elkaar afgestemd.
4. Testen
In het taakgebied Testen worden de tests op functioneel gebied uitgevoerd. Met name gaat het hierbij om de functionele en gebruikers acceptatietest.
5. Transitie
In transitie wordt de in productie name van de wijzigingen voorbereid, uitgevoerd en afgerond. Ook hier is weer sprake van een samenspel van de functionele aspecten, waar binnen MCTL de nadruk op ligt, en de technische aspecten, waarmee wordt afgestemd.
Algemene activiteiten in taakcluster Change support
Binnen Change support zijn een aantal taken te vinden die niet specifiek voor een taakgebied gelden. Het betreft de navolgende algemene activiteiten:
1. Verzamelen / intake
Het doel van deze activiteit is het creëren en bijhouden van een volledig overzicht van alle wensen en wijzigingsvoorstellen. Hier is nog in het geheel niet relevant of de wens noodzakelijk, nuttig, etc. is. Integendeel; het is juist de bedoeling dat ook ideeën / wensen /voorstellen waarvan op het eerste gezicht het nut niet zo duidelijk is, gewoon op de lijst worden opgenomen. Ten eerste omdat op deze wijze het signaal wordt afgegeven dat elke wens serieus wordt genomen. Ten tweede is het zeker niet uitgesloten dat pas bij uitwerking van de wens het echte nut duidelijk wordt. En tot slot is het ook zo dat sommige wensen herhaaldelijk worden ingediend, maar uiteindelijk om allerlei redenen niet worden gerealiseerd. Indien dit soort wensen helemaal niet worden geregistreerd, verdwijnt een kennelijk herhaaldelijk opborrelende behoefte uit beeld. Het is beter een wens op te nemen, wat grondiger te bekijken en vervolgens beargumenteerd toe- of af te wijzen, dan al voor opname een inschatting van nut en haalbaarheid te doen.
Wensen hebben als oorsprong onder andere:
• De gebruikersorganisatie (eindgebruikers en management)
• Eigen ideeën binnen de functioneel beheerorganisatie
• Eigen ideeën binnen de technisch en applicatiebeheer organisatie
• Externe bronnen (overheid, toeleveranciers, klanten, leveranciers van computertechnologie)
Van een wens moeten worden vastgelegd:
• Gegevens indiener (naam + contactgegevens)
• Datum indiening
• Aanleiding
• Doelgroep
• Doel
• Omschrijving (evt. voorzien van Proof of Concept)
• Schatting prioriteit / gewenste datum gereed
• Schatting kosten / baten (inclusief technische en functionele impactanalyse)
• Schatting kosten / gevolgen wanneer wens niet wordt uitgevoerd
• Evt. relaties met andere wens(en)
Deels zullen deze elementen bij de intake worden vastgelegd, maar deels kan dat ook in een later stadium. De elementen dienen ervoor te zorgen dat de wens zoveel mogelijk SMART (Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdsgebonden) wordt gedefinieerd. Het detailleringsniveau hoeft hier nog niet heel hoog te zijn, dat wordt in het taakgebied Requirements management verder aangevuld. De detaillering moet zodanig zijn dat er in de volgende activiteit een weloverwogen besluit kan worden genomen. Mocht het nodig zijn om i.v.m. de vereiste detaillering vanuit deze activiteit een beroep te doen op het taakgebied Requirements management of Ontwerp, dan is dat geen probleem. De activiteiten binnen het taakcluster Change support kennen wel een volgorde die gewoonlijk wordt gevolgd, maar het is geen probleem daarvan in voorkomende situaties af te wijken.
Achteraf is vrij eenvoudig te meten hoeveel / wie / welke afdeling over welke bedrijfsprocessen / welke systemen de meeste succesvolle wijzigingsvoorstellen heeft ingediend.
2. Beoordelen
Het doel van deze activiteit is het komen tot een besluit over het al dan niet uitvoeren van een uitgewerkt wijzigingsvoorstel. Hierbij bestaat de mogelijkheid aanvullende voorwaarden te stellen. Indien een wijzigingsvoorstel wordt goedgekeurd en een externe leverancier bij de uitvoering betrokken, kan op basis van dit besluit een opdracht aan de externe leverancier worden verstrekt.
De beoordeling is in eerste instantie een bedrijfseconomische afweging: kosten versus baten. Hierbij moet worden opgemerkt dat niet alle kosten, en zeker niet alle baten, in geld zijn uit te drukken. Bijvoorbeeld een wijzigingsvoorstel om een wetswijziging of nieuw veiligheidsvoorschrift in het bedrijfsproces en bijbehorende systeem te verwerken, zal doorgaans heel duidelijke kosten met zich meebrengen. De bate, “voldoen aan de wet”, is echter niet direct in geld uit te drukken. Ook een element wat meespeelt met het nemen van een beslissing is welke kosten en baten worden meegenomen. Zijn dat alleen de initiële kosten en baten, of ook de operationele? Het meest juist is doorgaans de operationele kosten en baten mee te nemen, maar dan doemt het probleem weer op over welke periode zich dit dan moet uitstrekken. Feitelijk hebben we het dan over de TCO (Total Cost of Ownership) versus TBO (Total Benefits of Ownership). Verdere aandachtspunten bij de kosten/baten afweging kunnen zijn dat de initiële kosten zo hoog zijn dat zij niet of nauwelijks door de organisatie zijn te dragen, de risico’s van tussentijdse wijzigingen in omstandigheden (interne managementvisie, leveranciers, klanten, overheid) zo groot dat er een reële kans bestaat dat door deze tussentijdse wijzigingen de kosten / baten balans negatief uitslaat en tot slot dat de uiteindelijk verwachte baten zeer ver in de toekomst liggen.
Voorkomen moet worden dat per wijziging moet worden nagedacht over deze elementen. Bovendien is er het gevaar dat naar een bepaalde beslissing wordt “toegerekend”. Daarom is het verstandig vooraf op dit vlak criteria vast te stellen; op basis waarvan worden de kosten / baten berekend en op basis van welke criteria wordt een besluit genomen?
Omdat er veelal meer wensen zijn dan kunnen worden uitgevoerd, kan MoSCoW worden gebruikt om een ordening aan te brengen. Waarbij MoSCoW staat voor:
• M – Must haves (wijzigingen die moeten worden ingewilligd)
• S – Should haves (wijzigingen die zeer gewenst zijn, maar niet absoluut noodzakelijk)
• C – Could haves (wijzigingen die kunnen worden ingewilligd indien er ruimte in tijd en budget is)
• W – Would haves (wijzigingen die wel interessant zijn, maar worden geparkeerd voor later)
Aldus kan een afgewogen besluit worden genomen. Overigens kan het zeker zo zijn dat tijdens de verdere planning en uitvoering nieuwe feiten boven water komen die de beoordeling beïnvloeden. Dat wordt in de activiteit “Bewaken / bijstellen” verder afgehandeld.
3. Plannen
Het doel van deze activiteit is het inplannen van alle goedgekeurde wijzigingen. In deze planning moeten de activiteiten binnen functioneel, technisch en applicatiebeheer, de gebruikersorganisatie en eventueel betrokken leveranciers worden afgestemd. Ook hier is het aan te bevelen een totaalplaatje te maken, hoewel de mate van detail kan verschillen: zo zal een externe leverancier vaak de door haar uit te voeren activiteiten samenvatten in één of enkele termen + tijdspad, terwijl bij de leverancier intern een gedetailleerder planning wordt gehanteerd. Dezelfde werkwijze kan ook nuttig zijn voor functioneel, technisch en applicatiebeheer en de gebruikersorganisatie. De verantwoordelijkheid voor een juiste planning kan worden belegd bij de Change manager of Change coördinator. Deze rollen kunnen overigens door verschillende personen uit de beheerorganisatie worden vervuld, of door personen uit een speciale groep die zich uitsluitend bezig houdt met wijzigingen.
Elke wijziging beïnvloed de planning, maar andersom is dat ook het geval. Indien er slechts heel weinig tijd beschikbaar blijkt te zijn, kan een wijziging functioneel worden uitgekleed, of het kwaliteitsniveau worden verlaagd. Is er daarentegen juist veel tijd beschikbaar, dan kan een wijziging worden verrijkt. Het gevaar van het laatste is uiteraard de beruchte “scope creep” waarbij gaandeweg de uitvoering van een wijziging de inhoud sterk wijzigt. Beter is indien de planning krap of ruim is toch vast te houden aan de oorspronkelijke wijziging en eventueel terug te gaan naar de eerste activiteit om eventueel de wijziging inhoudelijk aan te passen, opnieuw een besluit te nemen en dan eventueel de aangepaste wijziging opnieuw in te plannen.
Wijzigingen kunnen stuk voor stuk worden ingepland en uitgevoerd, maar zeker op softwaregebied is het heel gebruikelijk wijzigingen te groeperen. Traditioneel waren dit op softwaregebied releases of projecten, steeds meer wordt er ook gewerkt met sprints (vanuit scrum). Een groepering van wijzigingen, ook op hardware of functioneel gebied, kan tot efficiencyvoordelen leiden. Ook kan groepering meer eenduidigheid in de productieomgeving tot gevolg hebben; bijvoorbeeld de vervanging van alle werkplekapparatuur tegelijkertijd geeft meer eenduidigheid op de werkvloer dan het stuk voor stuk vervangen. Groepering van wijzigingen leidt over het algemeen wel tot een complexere planning, die ook moeilijker is te realiseren. Vanuit de gebruikers is het vaak plezierig indien wijzigingen worden gegroepeerd rondom vaste tijdstippen, bijvoorbeeld per maand. Ook dit leidt tot complexere afstemming bij de interne beheerorganisatie en externe leveranciers, maar de voordelen zijn evident.
Achteraf is vast te stellen of de planning voldoende goed was door te bezien of de werkzaamheden in het kader van de wijzigingen op het juiste tijdstip zijn uitgevoerd en of er niet bovenmatig veel aanpassingen in de planning zijn gemaakt; ook hiervoor zijn kwaliteitsnormen noodzakelijk.
4. Bewaken / bijstellen
Het doel van deze activiteit is het bewaken van de uitvoering van de wijziging en het eventueel bijstellen van de wijziging. Elke wijziging dient binnen tijd, budget en geldende kwaliteitsnormen te worden uitgevoerd. Verstandig is om op alle drie de aspecten een bepaalde bandbreedte af te spreken. Dus niet een wijziging in 115 uur uitvoeren, maar in 115 uur + / – 5%. Of 10%. Op deze wijze is een goed besluit over een wijziging te nemen en hoeft als het goed is alleen in uitzonderlijke gevallen de wijziging te worden bijgesteld. Bijstelling van wijzigingen hoeft uitsluitend te gebeuren indien de uitvoering of inhoud van een wijziging buiten de vooraf vastgestelde afspraken terecht komt.
Een wijziging kan in elke fase van uitvoering buiten de afspraken terecht komen. Het is hier de bedoeling dat dan niet binnen die fase iets wordt gedaan aan bijsturing, maar dat dat altijd via de hier beschreven activiteit plaatsvindt. Met andere woorden: indien een wijziging bijvoorbeeld al in testfase is, maar zich daar allerlei problemen voordoen waardoor de wijziging uit de tijd gaat lopen, wordt niet door een tester of testcoördinator actie ondernomen, maar door degene die verantwoordelijk is voor de bewaking en bijstelling van de wijziging. Doorgaans is dat de change manager of change coördinator. Deze zal de bijstelling voor zijn rekening nemen, en afhankelijk van de aard van de gewenste bijstelling vooraf nog wel contact hebben met andere betrokkenen.
In zeer uitzonderlijke situaties loopt een wijziging niet conform afspraken en kan ook hier niet worden bijgestuurd. Er volgt dan escalatie; de situatie wordt voorgelegd aan een groep (inhoudelijk deskundigen + management) die de situatie kan beoordelen en vooral, uiteindelijk een besluit kan nemen.
5. Communicatie
Het doel van deze activiteit is het op de hoogte houden van alle actoren die bij de wijziging zijn betrokken. Gebrekkige communicatie, onevenwichtige, onjuiste, te weinig of juist teveel, op het gebied van communicatie kan veel mis gaan.
Hier zijn de volgende richtlijnen van toepassing:
– Er wordt alleen over relevante zaken gecommuniceerd, dus bijv. niet alles naar iedereen, niet steeds communiceren dat “alles op planning loopt”
– Er wordt tijdig gecommuniceerd, dus niet alleen voldongen feiten. Maar er wordt zo tijdig gecommuniceerd dat betrokkenen nog invloed kunnen uitoefenen
– Er wordt gelijkmatig gecommuniceerd; dus niet soms heel veel, soms heel weinig
– Er wordt feitelijk juist en volledig gecommuniceerd; nogal een open deur. Maar toch, de neiging bestaat om slecht nieuws een beetje te “verpakken”, of slecht nieuws maar weg te laten uit de communicatie, of in ieder geval een minimale plek te geven
En bovenal wordt ook afgesproken of er een informatie-breng of informatie-haal plicht bestaat. In het geval van de informatie-breng plicht zal de change coördinator of change manager vaak het voortouw nemen om iedereen conform bovenstaande richtlijnen actief te informeren. In het geval van een informatie-haal plicht zal de change coördinator of change manager op een afgesproken plaats, vaak ergens op een intranet, alle relevante informatie tijdig plaatsen. Zodat iedere betrokkene zichzelf op die wijze kan informeren.
Ondersteunende tooling
Om aanpassingen van bedrijfsprocessen en de bijbehorende computertechnologie efficiënt uit te voeren, kan gebruik worden gemaakt van tooling. Er kan dan worden gedacht aan tooling om bedrijfsprocessen goed en voldoende gedetailleerd te beschrijven en ook de gewenste aanpassingen daarin te verwerken. Op het gebied van Ontwerp kan een beroep worden gedaan op tooling die ook aan de CT-zijde wordt gebruikt, zoals bijvoorbeeld voor ontwerp van het datamodel. Testen kan worden ondersteund door faciliteiten zoals goede testomgevingen en ook tools specifiek gericht op het uitvoeren van (functionele) tests. Tot slot geldt hier, net zoals aan de CT-zijde, dat alle elementen onder versiebeheer moeten vallen, en ook op het gebied van versiebeheer zijn diverse tools voorhanden.