ONDERZOEK

<----- Hoofdstuk 10, vierde deel

Dit hoofdstuk gaat in op de bevindingen zoals deze uit hoofdstuk 10 naar voren kwamen. De eerste paragraaf gaat in op de tekortkomingen van de implementatie uit de case study, waarna in de tweede paragraaf dieper wordt ingegaan op de voorwaarden van de IS/IT kampioen en troubleshooting vanuit de theorie en de ervaren praktijk. De eerste paragraaf beantwoord derhalve als uitvloeisel van de toetsing uit hoofdstuk 10 de deelvraag: 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 tweede paragraaf gaat dieper in op de gebeurtenissen rond de troubleshooter door een additioneel theoretisch kader op te zetten over het gebruik van deze functie.

11.1: Conclusies

Bij de implementatie van het in de case study beschreven informatiesysteem is veel gebeurd. Ik heb gepoogd dit zo objectief mogelijk weer te geven. Als daar vanuit de theorie naar wordt gekeken, valt op dat veel problemen zijn ontstaan vanuit een klein aantal tekortkomingen. Het management trad niet direct en daadkrachtig op, de projectleden van de motorafdeling pasten niet in het beeld van een goede projectmanagementvorm en vanuit de projectgroep is gebruikers-participatie vrijwel achterwege gelaten en vervangen door een passief hulpsysteem.

Het management van de verzekeraar mag het zich aanrekenen dat het niet daadkrachtig heeft opgetreden. Uit de praktijk blijkt dat zij het project geïnitieerd had, maar verder slechts een passieve rol vertegenwoordigde. Het gebrek aan actief overtuigen, sturen, steunen en communiceren zorgde ervoor dat het projectteam geen steun in de rug had en dat de vertegenwoordigers van de motorafdeling vrij spel hadden.

De vertegenwoordigers van de motorafdeling bleken niet de juiste eigenschappen te bezitten om waardevol te zijn voor het projectteam. Dit blijkt uit de volgende feiten. De managers hebben geen actieve rol vervuld tegenover de eindgebruikers. Deze managers hadden moeten communiceren over wat er gebeurde in het projectteam, vragen moeten beantwoorden van de gebruiker, deze moeten doorspelen aan het projectteam en in het algemeen als verbinding tussen het projectteam en de eindgebruiker moeten fungeren. Dit is niet gebeurd, waardoor de eindgebruiker niet overtuigd werd van het nut van het systeem, weerstand ging vertonen en een passieve houding tegenover het systeem ontwikkelde, wat zich uitte in een lage acceptatie van het systeem. De nadelen van het systeem kwamen, door het niet omvormen van de taken, heviger dan bedoeld naar voren. Het takenpakket dat aan het systeem voldeed riep tevredenheid op, het takenpakket dat niet voldeed, hetzelfde werk in een complexer jasje, riep weerstand op.

De managers van de motorafdeling waren niet geschikt voor het project. Op zich is dat niet funest voor het slagen van het project, als om deze ‘misslag’ heen kan worden gewerkt. Dat is niet gebeurd, aangezien het projectteam wel aandacht had voor de gebruiker, maar deze benaderde vanuit een passieve invalshoek. Dit betekent dat een functionaliteit die in algemene lijnen is aangegeven in een workshop slechts getest wordt op de werking. Het eerder inmengen van de gebruiker bij het experimenteren of evaluatie van de functionaliteit (aangegeven door het management van de afdeling) had veel problemen kunnen voorkomen en ook de gebruiker het idee gegeven dat er inspraak mogelijk was, wat tot commitment leidt.

De slechte werking van het management van de motorafdeling, gecombineerd met de passieve houding van het projectteam zorgde voor veel problemen. Een voorbeeld is de slechte responstijden, die slechts laat werden ontdekt door het projectteam. De motorafdeling kreeg het idee dat het systeem niet werkte en begon ernstige (groeps)weerstand te vertonen. Op dat moment is de troubleshootersfunctie in het leven geroepen.

Het bestaansrecht van de troubleshooter wordt in dit geval niet bepaald door technische of onderhandelingskwaliteiten, maar meer door de open geest en het feit dat ik als medewerker nieuw was en als objectief werd gezien. Ik had geen geschiedenis binnen het bedrijf. De verdere ontwikkeling tot algemeen tussenpersoon tussen de afdeling en de overige organisatie is daarop voortgeborduurd. Door deze karakteristieken werd een vertrouwen gewonnen en werden meer contacten tussen verschillende partijen gelegd. De troubleshooter participeerde namelijk in alle aspecten van het systeem en heeft door overtuiging de acceptatie verhoogd. Door deze rol kwam het idee dat er controle bestond over het systeem vanuit de gebruiker. Het gebrek aan participatie werd in ieder geval deels goedgemaakt door de troubleshooter.

Hoofdstuk 11, tweede deel  ------>