ONDERZOEK

<----- Hoofdstuk 11, eerste deel

11.2: Voorwaarden voor de IS/IT kampioen en troubleshooter

Uit de theorie is gebleken dat elke verandering een veranderingsagent nodig heeft. Met de opkomst van IT is die rol veranderd. Zo stellen bijvoorbeeld Markus en Benjamin in paragraaf 8.3 dat de IS specialist de nieuwe veranderingsagent hoort te worden. Uit de case study is gebleken dat dit hier niet het geval is. Sterker nog, door het ‘taalverschil’ is er een grote afstand tussen de IS specialist (de afvaardiging van de IT-afdeling) en de eindgebruiker ontstaan. De IS-specialist is weliswaar geïnteresseerd in een verbetering van het systeem en het gebruik daarvan, maar uit dat in technische zin en heeft niet de noodzakelijke eigenschappen om ook de sociale kant van de implementatie te begeleiden. De stap naar een veelzijdiger implementatie blijkt lastiger dan voorgesteld in de theorie.

De IS/IT kampioen kan dit gat vullen. Uit de theorie zijn echter een aantal vragen opgekomen over het ontstaan en de inzetbaarheid van deze kampioen. Uit het vorige hoofdstuk bleek dat de rol van troubleshooter in dit geval behoorlijk dicht bij de IS/IT kampioen komt. Aan de voorwaarden en eigenschappen zoals deze uit de theorie naar voren komen blijken in redelijke mate voldaan te zijn. Howel en Higgins vragen zich af of de rol van kampioen geformaliseerd kan worden. Heng et al. hebben de formele kampioenen onderzocht, maar hebben ze wel moeten zoeken. De kampioen daar is niet als kampioen aangesteld, maar heeft een aangesteld persoon zich tot kampioen ontwikkeld. Dit samen met het standpunt dat een opinieleider of informal advocate een grote invloed bij veranderingen kan hebben leidt tot de vraag hoe een kampioen kan worden ingezet en of dit inderdaad formeel kan gebeuren. De rest van deze paragraaf zal een kader schetsen waarbinnen de functie van troubleshooter of kampioen kan worden ingezet.

De kampioen blijkt vooral bij de implementatie een rol te spelen. In principe zou bij een optimale gebruikersparticipatie, met inachtname van de overige factoren van het model van Keen et al., gecombineerd met een IS specialist als veranderingsagent de rol van troubleshooter overbodig zijn. De IS specialist zou de rol van kampioen op zich moeten nemen. In de door mij meegemaak-te praktijk blijkt dit echter niet zo te zijn. Wel is het goed te beseffen dat troubleshooting pas bij implementatie van belang wordt.

Bij de initiatie van een verandering hoort de gebruiker overtuigd te worden van het nut van de verandering en daardoor te participeren in de verandering. De theorie geeft aan dat gebruikersparticipatie leidt tot systeemsucces en de implementatie van een IS vergemakkelijkt. Het nadeel van participatie bestaat vooral uit tijdverlies. Door participatie wordt het gehele veranderingsproces vertraagd. Als participatie niet plaatsvindt, komt die vertraging bij de implementatie naar voren. Voor de uitvoering van een project dient derhalve een balans gevonden te worden tussen participatie en geboekte voortgang.

Een mogelijkheid om deze balans te vinden zou in dit geval kunnen betekenen dat participatierondes worden gehouden. Bij elke fase van het project kan de gebruiker participeren, maar slechts tot een bepaald punt, waarna de participatie wordt afgesloten, de naar voren gebrachte punten worden verwerkt en naar de volgende fase wordt gegaan, waar een nieuwe ronde plaatsvindt. Deze tijdelijke participatie is een compromis tussen de voordelen van participatie en de afremming die daardoor ontstaat. Dit betekent verder gaan dan het testen en experimenteren zoals ik dat ben tegengekomen, maar meer actief denken tot een bepaald punt. In de case study is dat op een bepaald moment gebeurd door een einddatum voor wijzigingsaanvragen te stellen. In dit geval opende dat de ogen voor wijzigingen in plaats van een afsluiting omdat men niet zozeer participeerde maar testte.

In dit proces dient de gebruiker bijgestaan te worden door een IS specialist die de mogelijkheden en onmogelijkheden van applicaties kan uitleggen en als tussenpersoon tussen de technische kant en de gebruiker kan dienen. De IS specialist als veranderingsagent door te faciliteren en op actieve wijze met de gebruiker om te gaan. Als deze specialist de juiste persoonskenmerken heeft, kan deze uitgroeien tot kampioen. In de case study blijkt dat het functionaliteitenbeheer wel bij een IS specialist lag, maar dat deze niet de kenmerken had om tot kampioen uit te groeien. Hierbij speelt ook een dimensie geschiedenis mee. Door de functieverschillen tussen gebruiker en specialist is er geen objectieve en frisse blik. In de eerdere fasen van de verandering is dat probleem niet onoverkomelijk, maar bij de implementatie kan dit tot problemen leiden, zoals uit de case study bleek, waar bij de constructie- en testfase van het systeem al problemen kwamen. Dit kan mijns inziens toegeschreven worden aan gebrek aan participatiemogelijkheden en hoeft niet representatief te zijn.

De constructiefase blijkt een kritieke fase te zijn. De verschillende partijen moeten waarmaken wat beloofd is, wat spanning op de groep zet. De gebruiker is afhankelijk van het uitvoeren van deze fase van de IT-afdeling. Op het moment dat die steken laat vallen, wordt het vertrouwen beschadigd. Als de IS specialist lid is van de IT-afdeling, verliest deze een deel van het vertrouwen. In dit geval lijkt een kampioen die niet verbonden is aan de IT-afdeling een betere keus.

Een kampioen is volgens Howell en Higgins iemand die informeel opkomt in de organisatie. Als de IS specialist de kwaliteiten mist om tot kampioen uit te groeien of de geschiedenis voor problemen zorgt, kan het goed zijn om een troubleshooter aan te stellen, zoals in de case study is gebeurd.

Dit levert een interessante stelling. In hoeverre is het zinvol om bij de constructiefase een fris iemand die geen geschiedenis heeft binnen de organisatie te halen en deze formeel tot kampioen aan te stellen? Uit de case study blijkt dit gebeurd te zijn. Maar wat bepaalt het succes en kan dit algemeen gesteld ook gebeuren?

Formeel gezien heeft de troubleshooter of kampioen geloofwaardigheid nodig. De kampioen moet, zodra binnengehaald, het vertrouwen van alle partijen hebben dat deze objectief is. Er mag geen verdenking zijn van collaboreren met een afdeling of het management. Dit dient te geschieden door de kampioen vrijheid te geven om eigen werkwijzen te ontwikkelen en kennis te maken met de organisatie en het systeem. Het is van belang de kampioen te laten zien wat de voordelen van het systeem zijn en de werking daarvan te leren, zodat deze overgebracht kunnen worden naar de gebruiker. Dit laatste dient spontaan te gebeuren en persoonlijk.

Daarbij is het van belang de troubleshooter de ruimte te geven om de gebruiker te overtuigen. In vergelijking met het weerstandstrategiemodel hoort dit in dat de eerste fasen, tot en met faciliteren, te gebeuren. Voor de overige fasen dient het lijnmanagement te worden ingeschakeld. Als de troubleshooter de manipulatie- of dwangfase gaat uitvoeren, verliest deze het opgebouwde vertrouwen. In die zin is het managen van de troubleshooter belangrijk en dienen goede afspraken te worden gemaakt.

Het moeilijke in het formeel aanstellen is de geschiktheid te bepalen. Howell en Higgins geven aan dat de kampioen via psychologische tests moet worden gezocht. Het valt buiten mij expertise om daar uitspraken over te doen. In mijn opinie dient de kampioen onbevooroordeeld te zijn, goed met mensen kunnen omgaan, geduldig te zijn en zowel van de operationele kant als van IT kennis hebben om tussen de gebruiker en de IT-afdeling in te kunnen staan.

De voordelen van het aanstellen van een kampioen bij de constructiefase kunnen aanzienlijk zijn als er een behoorlijke participatie heeft plaatsgevonden in de eerdere fasen van een project en de IS specialist geen goed veranderingsagent blijkt te zijn. Als participatie niet heeft plaatsgevonden dient de troubleshooting eerder plaats te vinden. Als de IS specialist een goed veranderingsagent is, is de rol van troubleshooter overbodig, aangezien de IS specialist dan ook kampioen is.

Tenslotte blijkt dat een veranderingsagent onontbeerlijk is in een organisatie. De case study laat zien wat gebeurt als de sociale kant van een verandering wordt onderbelicht. De noodzaak om een veranderingsagent aan te stellen had veel sneller gesignaleerd moeten worden. De organisatie had het geluk dat ik geschikt bleek voor de functie, anders had de implementatie nog groter schade opgelopen. Daarbij dient binnen de organisatie bestudeerd te worden wie de opinieleiders zijn en deze te overtuigen van het nut van de innovatie. Daarmee wordt aan een voorwaarde voldaan, zodat ze de kans en de ruimte krijgen om tot kampioen uit te groeien. Er mag niet gerekend worden op spontane opkomst van een kampioen. De sociale kant van een implementatie vergt veel werk, maar geeft ook veel voldoening. Mensen zijn moeilijk te veranderen dan een technisch systeem, maar mensen zijn wel de spil van een organisatie. En het onderschatten van de effecten van verandering op het personeel kan veel kosten.

Literatuuropgave  ------>