De utopie van het professioneel beheer Een nieuw informatiesysteem dat eenmaal in de lucht direct en perfect werkt? Het is een utopie. Toch verwachten betrokkenen vaak wel dat dit gebeurt. De realiteit is anders: bij centralisering van bedrijfsprocessen kan het soms meer dan een jaar duren voordat een nieuw centraal informatiesysteem optimaal werkt. Zelfs wanneer aan alle kernvoorwaarden is voldaan. Centralisatie van bedrijfsprocessen is aan de orde van de dag. Veel organisaties reorganiseren momenteel hun administratieve, financiële, logistieke en HRM-processen. Vaak worden hierbij informatiesystemen gebruikt die de bestaande ondersteunen. Initiële inrichting gebeurt projectmatig. Is het moment van lancering van centrale informatiesystemen daar, dan liegen de verwachtingen er vaak niet om. Het systeem moet meteen voor 98% in de lucht zijn, verstoringen mogen hooguit een dag duren en aanpassingen moeten razendsnel kunnen worden doorgevoerd. Dat lijkt meer op droom dan werkelijkheid. Er is al veel gewonnen voor een organisatie wanneer de beheersorganisatie een jaar na invoering weet wat ze aan het doen is en waarin ze het volgende jaar moet gaan investeren. Hoe krijg je dat voor elkaar? Van project- naar beheersorganisatie: De praktijk En dan is het zover, het informatiesysteem is door de projectorganisatie ontwikkeld en de centraliserende processen zijn ingebouwd. Het voldoet bovendien aan de eisen van de gebruikers en de verantwoordelijken hebben het systeem geaccepteerd. Het werk van de beheersorganisatie is nu begonnen; die moet ervoor zorgen dat het systeem blijft voldoen aan de wensen van de gebruikers, die er vanaf nu mee gaan werken. En dan blijkt: • De beheersorganisatie krijgt een aantal zogenaamde ´restpunten’ mee om af te ronden; • Een groot aantal gegevens is niet juist door de conversie gekomen, de digitale omzetting is daarmee

deels mislukt; • Gegevens uit het oude systeem zijn toch anders geïnterpreteerd dan verwacht; • In de praktijk blijkt het werken met de (nieuwe) gecentraliseerde bedrijfsprocessen, toch niet helemaal

overeen te komen met de verwachting; • De voordelen van de gecentraliseerde broninformatie, wordt ook door anderen opgemerkt. Andere

toepassingen willen graag gebruikmaken van deze gecentraliseerde informatie, middels interfaces. Chaos breekt nu uit voor de beheersorganisatie. Haar medewerkers proberen de vloedgolf aan vragen zo snel en goed mogelijk te beantwoorden, maar met elke oplossing ontstaat weer een nieuw probleem. De vaak gefrustreerde gebruikers misbruiken ongewild de hiërarchie binnen de organisatie en het aantal escalaties evenaart het aantal gebruikersvragen. Niemand weet onderhand nog wat er nu precies moet gebeuren. Keuze voor procesorganisatie Maar overzicht is een absolute noodzaak. Om die dus terug te krijgen wordt de organisatiestructuur gewijzigd. Het management kan besluiten om de hiërarchische structuur in de beheersorganisatie te kantelen naar een matrixstructuur. Daarbij neemt een stafafdeling het procesmanagement op zich en maakt men onderscheid in diverse dagelijkse beheeractiviteiten (controle back-ups, nachtverwerking etc.). Daarnaast staan het incident management en het change management. Er worden medewerkers aangesteld om dat allemaal in te richten en te coördineren. Aan hen wordt duidelijk gemaakt dat: • de incidentcoördinator verantwoordelijk is voor prioritering van de incidenten; hij rangschikt incidenten

dus naar belangrijkheid • de wijzigingscoördinator verantwoordelijk is voor de voorspelbaarheid van het onderhoud.

Hoe richt je Change Management in? Om het change management binnen de beheersorganisatie succesvol in te richten, is het essentieel om onderstaande drie modellen gelijktijdig in te richten: • Communicatiemodel • Procesmodel • Besturingsmodel Het communicatiemodel voorziet de aangewezen aanvragers van informatie over de voortgang van ingediende wijzigingsverzoeken. Die informatie dient gestructureerd te worden verstrekt, wat neerkomt op aanmaak van registratienummers en heldere omschrijving. Ook belangrijk is het de status van een wijzigingsverzoek (mate van prioriteit en verwachte datum van verwerking) aan te geven. Door zo helder en open te communiceren ontstaat voor de beheer organisatie de rust om belangrijke zaken snel en blijvend te realiseren. In het procesmodel vind je de structuur voor professioneel onderhoud. Doordat alle verzoeken er centraal in staan geregistreerd krijg je een overzicht van de totale werkvoorraad. De prioriteitenlijst van de opdrachtgever is vervolgens bepalend voor de planning van onderhoudsupdates. Voor verschijning van elke update wordt een individuele analyse gemaakt van de impact van de in die update opgenomen wijzigingen. Daarbij is belangrijk dat er voor elke competentie en elk kennisgebied een nauwkeurig overzicht komt van wat moet gebeuren en hoeveel tijd dat gaat kosten. Dit creëert draagvlak onder de uitvoerenden, die door samenvoeging van deze gegevens met een helder plan van aanpak kunnen werken. In dat plan staan de uitvoeringsactiviteiten beschreven en de tijd die hiervoor nodig is. Het lijkt eigenlijk op een offerte, want het reikt de klant (business- en/of de gebruikersorganisatie) een oplossing voor zijn probleem aan en becijfert tevens de kosten daarvan. Het besturingsmodel is misschien wel het belangrijkste onderdeel van Change Management. Belangrijke partijen zijn: • Klant • Informatiemanagers binnen de functionele

beheersorganisatie • Materiedeskundigen • Resource managers Door eenduidig te benoemen welke partijen welke verantwoordelijkheid dragen, wordt binnen de hele

keten duidelijk door wie en op basis van welke criteria beslissingen worden genomen. De te nemen beslissingen zijn: • Validiteit van het wijzigingsverzoek (Go of

NoGo) • Prioriteit van de goedgekeurde

wijzigingsverzoeken • Goedkeuren van de plannen van aanpak die

zijn gemaakt tijdens de impact analyse. • Volgorde van realisatie • Beslissingen rond de voortgang • Escalatie over de gehele procesgang

Aanvragers

Registratie

Impact Analyse

Realisatie

Testen

Funct. Ontwerp

Productie

Gebruikers

Klant organisatie

Beheer organisatie

Info

Info

Info

Info

Beslissen & Info

Beslissen & Info

Beslissen & Info

Beslissen & Info

Change Management

Bovenstaande modellen zijn een voorwaarde voor het succes van Change management. Maar dat betekent nog niet dat medewerkers effectief worden ingezet. Daarvoor is namelijk resource management nodig. Het management van de beheersorganisatie zal die competenties moeten aanwijzen, die belangrijk zijn voor uitvoering van wijzigingsverzoeken. Een voorbeeld: de medewerkers van de afdeling applicatiebeheer besteden de helft van hun werktijd aan het realiseren van wijzigingen en de andere helft aan operationele beheertaken en incident management. Naast juiste inzet van medewerkers moet je ook weten welke wijzigingsverzoeken je parallel en welke je integraal kunt realiseren. Ook belangrijk: door Software Control te registreren welke versies onderhanden zijn. Zijn deze zaken helder, dan kan gestart worden met het ‘releasematig’, dus gebundeld, totstandbrengen van die wijzigingen. Op die manier zet je mensen en middelen efficiënt en effectief in. In onderstaande figuur zijn de gevolgen rond de inzet van resources afgebeeld.

Win tijd: ontwikkel parallel

In veel organisaties zijn de competenties gecentraliseerd binnen afdelingen. Degenen die de ‘impact analyses’ opstellen, zijn vaak meewerkend voormannen. Gevolg van dat meewerken is dat zij niet gelijktijdig ook wijzigingsverzoeken kunnen behandelen.

Wat betekent dat in het begin relatief weinig tijd wordt besteed aan “impact analyse” en functioneel ontwerp. Logisch ook, want het loont minder om met meerdere personen één functioneel ontwerp op te stellen. Veel efficiënter is het om meerdere functionele ontwerpen (en dus verschillende wijzigingsverzoeken) gelijktijdig op te stellen. Zo is in de realisatiefase tijd te winnen door parallel te ontwikkelen.

In de ontwikkelingsfase zijn de meeste medewerkers bezig met doorvoer van wijzigingen, wat betekent dat er minder tijd is om incidenten op te lossen. Ergo: incidenten hopen zich op.

Op de realisatie- volgt de testfase. Nu wordt de technische omgeving, waarin wijzigingen worden getest, geblokkeerd voor randzaken. Want incidenten moeten immers getest worden in een omgeving die overeenkomt met de werkelijkheid. Is de onderhoudsrelease, dus de bundel doorgevoerde wijzigingen, klaar voor productie dan komt weer tijd vrij om tussentijds ontstane incidenten op te lossen. De meewerkende voormannen zijn immers pas begonnen met het maken van een nieuwe impact, op het moment dat de release in de testomgeving is geplaatst.

Tijd

Inze

t Res

ourc

es

Onderhoudsreleases Incidenten

ImpactAnalyse

FunctioneelOntw erp

Realisatie

Testen

Realisatie

Testen

ImpactAnalyse

FunctioneelOntw erp

Kamelen aan de riem! De bovenstaande figuur toont wat dat voor de praktijk betekent: er ontstaat een kameel (piek en dal momenten mbt inzet van resources en/of medewerkers) rond de inzet van middelen. Je kunt je tijd immers maar aan één activiteit tegelijk besteden. De klant en de beheersorganisatie doorzien en accepteren dit. Maar je moet wel per ‘kameel’ bepalen wat de doorlooptijd is, hetgeen weer afhangt van de hoeveelheid wijzigingsverzoeken. En daarbij moeten scherpe keuzes gemaakt worden, want tijdens het uitvoeren van een kwalitatief goede test loopt de organisatie risico. De mogelijkheid van een crash maakt een testomgeving nodig. Ook dan moet er nog rekening gehouden worden met valkuilen, zoals politieke beslissingen. Want binnen elke organisatie spelen nu eenmaal verschillende belangen. Bij dit alles geldt: • Ga niet te snel. Niet iedere medewerker is in

staat om te begrijpen waarom zaken gewijzigd worden.

• Geef medewerkers de ruimte om te groeien in hun rol. Een technisch specialist van een toepassing, moet te weten komen wat de afwijkingen van de standaard zijn. Dit kost tijd!

• De tijd die nodig is voor het goedkeuren van zowel plannen van aanpak als van de functionele ontwerpen, is altijd langer dan de beschikbare tijd.

• In de hierboven beschreven aanpak, wordt de beschikbare tijd geclaimd voor wijzigingsverzoeken. Ze worden niet geclaimd voor belangrijke wijzigingen van de beheersorganisatie.

• Intern is men afhankelijkheid van openstelling van de ICT voorzieningen van andere onderdelen binnen het bedrijf. Denk hierbij aan service-windows voor infra-onderhoud en de business cq. eindgebruikers die op momenten absoluut de applicatie ter beschikking dienen te hebben (zondagopenstelling, overwerken, etc).

• Op het moment dat een wijzigingsverzoek in productie wordt genomen, dient in veel gevallen een omzetting van data plaats te vinden. Die conversie kan alleen succesvol verlopen, als dat volledig en gecontroleerd gebeurt.

Alle valkuilen ontweken? Tóch ben je er nog niet! Willen veranderingen echt succesvol zijn moet aan nog een aantal voorwaarden worden voldaan: • Betrokkenen moeten zich bewust zijn van het

“kameeleffect” en benoem dat ook. • Creëer tijdig betrokkenheid van de medewerkers.

Dat kan door ze ook te betrekken op momenten dat beslissingen worden genomen, niet alleen bij de uitvoering.

• Definieer normen (KPI´s) en maak hier op een juiste manier gebruik van. Spreek elkaar elke keer opnieuw aan op gemaakte afspraken. Overigens dienen in deze fase deze normeringen niet als strafmaatregel gehanteerd te worden (ook niet door de klant).

• Maak gebruik van zogenaamde “processimulatie”; technieken om de complexiteit van het veranderingsproces helder te krijgen, bij zowel management als medewerker.

• Vertel de klant wat je van hem verwacht en wijs hem ook op zijn verantwoordelijkheid.

• Om op sommige momenten snelheid te creëren, is dakpansgewijs, dus meerdere mogelijkheden tegelijk, testen een creatieve oplossing. Hiervan kan mogelijk gebruik van worden gemaakt om achterstanden in planningen in te halen.

• Te allen tijde ontstaat voortschrijdend inzicht, sta hiervoor open!

• Wees niet bang om fouten te maken, ook al weet je dat dit waarschijnlijk gezichtsverlies betekent. In de toekomst zal dit zijn vruchten afwerpen, je bent immers niet de enige die moet veranderen.

• Maak gebruik van de drie-lagen structuur: klant, wijzigingscoördinator en functioneel beheerder. Zo creëer je een communicatiestructuur die altijd via het SPOC (single point of contact) verloopt. Ieder heeft in de keten zo dus één aanspreekpunt.

Conclusie: professionaliteit kost tijd Het inrichten van een professionele beheersorganisatie binnen één jaar is een utopie. In mijn bovenstaande uitzetting is alleen de impact van het Change Management aangehaald. Ik wilde daarbij aangeven wat er moet gebeuren om het afgesproken doel, “het voorspelbaar worden”, te realiseren. De complexiteit hiervan geeft een duidelijk beeld. Er komt nogal wat bij kijken, om als organisatie professioneel te acteren. Naast facetten als het inrichten van processtappen, het maken van klantafspraken en de communicatie rondom dit proces, zijn de algemene aspecten van het veranderen naar een centrale organisatie van zeer groot belang. Medewerkers dienen samen te werken en samen hetzelfde doel na te streven, ze moeten inhoudelijk bekwaam zijn. En ze moeten zich bewust zijn van de verantwoordelijkheid die ze dragen. Samenvattend kan ik stellen dat: -als je het binnen een jaar voor elkaar krijgt om de dagelijkse activiteiten in de organisatie uit te voeren -als je de verstoringen oplost binnen een afgesproken kader én -als je voorspelbaar bent in het onderhoud van het informatiesysteem je een zéér grote stap hebt gemaakt. Eentje die een organisatie de kans biedt om in de toekomst verder te groeien naar een professionele beheersorganisatie. Ing. Gert-Jo van der Heijden is Expert in ICT Service Management en werkzaam bij Yacht als Senior Interim Professional. De afgelopen jaren heeft Gert-Jo diverse opdrachten met aansprekende resultaten uitgevoerd op het gebied van inrichting, professionalisering en veranderingen binnen ICT Service Organisaties. Middels zijn enthousiasme, inlevingsvermogen en oog voor kwaliteit weet hij mensen mee te krijgen en te motiveren in veranderingsprocessen. E-mail: gert.jo.van.der.heijden@yacht.nl