ONDERZOEK

<----- Voorwoord

Deze scriptie gaat in op de implementatie van informatiesystemen. Tijdens mijn stage bij een middelgrote verzekeraar ben ik in aanraking gekomen met deze materie. Daar heb ik als troubleshooter gewerkt bij de implementatie van een organisatiebreed informatiesysteem op de motorafdeling van deze verzekeraar.

De probleemstelling voor deze scriptie luidt: in hoeverre is de opzet van de implementatie van het informatiesysteem zoals meegemaakt tijdens de stage volgens de theoretische standaards verlopen en welke theoretische oorzaken kunnen worden gevonden voor de gevonden weerstand tijdens deze implementatie?

Om deze probleemstelling te beantwoorden is deze opgedeeld in de volgende deelvragen, die elk in een apart deel worden behandeld. Het eerste deel behandelt de deelvraag welke gebeurtenissen hebben een duidelijk zichtbare rol gespeeld bij de vordering van het project dat tot doel had een organisatiebreed informatiesysteem te implementeren, waarna deel twee de volgende deelvraag beschrijft: het weergeven van een theoretisch kader waarin de gebeurtenissen van de case study getoets kunnen worden en de oorzaken van de ervaren weerstand kunnen worden opgespoord. In deel drie wordt onder de volgende deelvraag de case study aan de theorie getoetst: in welke opzichten zijn er verschillen waar te nemen tussen de theorie en de praktijk en wat was hun invloed op de gebeurtenissen zoals deze in de case study zijn beschreven?

De implementatie van het informatiesysteem blijkt technisch goed verlopen te zijn, maar sociaal ondermaats afgehandeld te zijn. Het management van de verzekeraar heeft zich passief opgesteld door niet goed te sturen en de verandering die door het systeem ontstaat niet door te communiceren door de juiste personen te overtuigen. De juiste personen zijn in dit geval het management van de betrokken afdelingen. Daardoor is de eindgebruiker ook niet overtuigd geraakt van het nut van de verandering.

Het projectteam blijkt verkeerd te zijn samengesteld door hiėrarchie boven kwaliteiten te stellen, waardoor de afvaardiging van de motorafdeling inadequaat was. Deze hoorde de taken voor de afdeling bij te stellen, zodat deze bij het systeem pasten, maar hebben dit nagelaten. Tevens communiceerden zij de voortgang niet met de gebruiker en stonden niet open voor suggesties van de afdeling. Daarbij is de uit de theorie waardevol gebleken gebruikersparticipatie passief opgezet. Ook de uit de theorie waardevol gebleken functie van IS specialist als veranderingsagent is in deze organisatie niet aanwezig. Door dit alles werd de gebruiker niet op de hoogte gehouden van de ontwikkelingen en kreeg geen support. De weerstand liep dientengevolge hoog op. Daardoor is men op een gegeven moment gaan zoeken naar een troubleshooter. Deze functie werd door mij ingevuld omdat ik objectief en onafhankelijk was en geen geschiedenis binnen het bedrijf had.

Hoewel deze functie formeel inhield dat ik als brug tussen het projectteam en de afdeling zou fungeren, ontwikkelde zich dit al snel tot vertegenwoordiger van de afdeling op alle systeemgebonden fronten. In vergelijking met de literatuur blijkt dat de voorwaarden en karakteristieken van de IS/IT kampioen goed overeenkomen met de functie zoals ik deze feitelijk had.

Ten slotte is gepoogd een theoretisch kader op te zetten over de formele inzetbaarheid van de functie zoals ik deze bekleedde. Daaruit blijkt dat het bestaan van deze functie alleen mogelijk is bij een niet als veranderingsagent functionerende IS specialist. De gebruikersparticipatie dient op een redelijk niveau te zijn, waarbij een balans gevonden dient te worden tussen participatie en te boeken voortgang.

Verder dient naast de in de literatuur beschreven voorwaarden en karakteristieken aan een aantal organisatorische voorwaarden te zijn voldaan. De troubleshooter mag het liefst geen geschiedenis binnen het bedrijf hebben, waardoor deze objectief en onafhankelijk is, wat de acceptatie bij de gebruiker begunstigt. Ook moet de troubleshooter de vrije hand hebben in het oplossen van problemen om deze onafhankelijkheid te bewijzen. Ten slotte is het bij een redelijke mate van gebruikersparticipatie zinvol om de troubleshooter pas in te zetten vanaf de constructiefase, als de participatie zich meer gaat richten op testen en experimenteren.

Inleiding  ------>