Onderzoek naar verbeterde implementatie en nazorg van
financiële software.
Een casestudy bij FINAN Financial Analysis.
Hilde Zijlstra
Studentnummer: 1323938
MSc Business Administration - Organizational &
Management Control
Rijksuniversiteit Groningen
1
steafstudeerbegeleider: drs. C.M. Elsenga
2
deafstudeerbegeleider: drs. E.J. Stokking
Voorwoord
Beste belangstellende,
voor u ligt het verslag dat is geschreven naar aanleiding van mijn afstudeeronderzoek bij FINAN Financial Analysis te Zwolle, ter afsluiting van mijn studie Organizational & Management Control (O&MC) van de Faculteiten Economische Wetenschappen en Bedrijfskunde aan de Rijksuniversiteit Groningen.
Ik ben tijdens mijn afstudeerperiode door veel mensen voorzien van advies, hulp en informatie. Er zijn echter een aantal personen in het bijzonder die dit eindresultaat mede mogelijk hebben gemaakt. Ik wil graag van deze gelegenheid gebruik maken om deze personen te bedanken.
Om te beginnen wil ik graag mijn eerste scriptiebegeleider, mevrouw Elsenga, en mijn tweede scriptiebegeleider, de heer Stokking, bedanken voor hun hulp en aanwijzingen gedurende het gehele afstudeertraject. Daarnaast wil ik graag de heer Ter Bogt, de algemene begeleider van het afstudeertraject van de masteropleiding O&MC, bedanken voor zijn deskundige begeleiding in de beginfase van het afstudeertraject.
Officieel zijn mijn respectievelijk eerste en tweede stagebegeleider de heer Baas en de heer Bergmann. Ik wil graag van deze gelegenheid gebruik maken om hen hartelijk te bedanken voor al hun hulp tijdens mijn stageperiode. In de praktijk bleek dat ik hulp kreeg van alle medewerkers van FINAN Financial Analysis. Voor deze, vaak spontaan aangeboden, hulp wil ik hen graag bedanken.
Ter afsluiting wil ik graag mijn vriend, familie, vrienden en (oud)studiegenoten bedanken voor hun steun en geduld gedurende het gehele afstudeertraject. Dankzij deze mensen heb ik genoten van mijn studiejaren in Groningen. Ik zal dan ook altijd met plezier terugdenken aan mijn studietijd.
Samenvatting
Het bedrijf FINAN Financial Analysis (kortweg: Finan) ontwikkelt en verkoopt financiële software, de FINAN Financial Analyzer. Deze software ondersteunt financiële analyses. De FINAN Financial Analyzer is verkrijgbaar in verscheidene configuraties. Medewerkers van Finan vermoeden dat de implementatie van hun producten niet voldoet aan de wensen van de gebruikers. De definitie van implementatie is in deze afstudeeropdracht: de invoering van een systeem in een organisatie. Dit, descriptieve en explorerende, afstudeeronderzoek gaat in op de mogelijke oorzaken van de beperkte implementatie van de software van Finan. Uit wetenschappelijk onderzoek blijkt ook dat veel implementaties niet het gewenste resultaat opleveren. Hiervoor zijn verschillende oorzaken aan te wijzen, waaronder gebrek aan scholing van de (toekomstige) eindgebruikers.
De doelstelling van de afstudeeropdracht is: ‘Te bepalen in hoeverre aandachtspunten uit de wetenschappelijke literatuur een toereikende basis vormen voor de implementatie en nazorg van een financieel product in de praktijk.’ De hieruit volgende onderzoeksvraag is:
‘Welke belangrijke aandachtspunten van de implementatie van een financieel product zijn op basis van een kritische analyse te ontlenen aan de literatuur en in hoeverre vormen deze aandachtspunten een toereikende basis voor de implementatie van zo’n product in de praktijk?’
De definitie van nazorg voor dit afstudeeronderzoek is: de (ondersteunende) activiteiten die door de leverancier van het product aangeboden worden om bij de gebruikers de kennis en het gebruik van het product te verbeteren.Nazorg vindt plaats nádat het product is overgedragen van de ontwikkelaar naar de klant. Dit afstudeeronderzoek is gericht op de kleine accountancykantoren en adviesorganisaties die de software van Finan gebruiken.
Om de onderzoeksvraag te kunnen beantwoorden, zijn de volgende deelvragen geformuleerd: 1. Welke aandachtspunten geeft de literatuur over de wijze waarop financiële
productontwikkelaars nieuwe producten bij hun klanten moeten implementeren?
2. Uit welke activiteiten bestaat de nazorg van financiële producten volgens de literatuur?
4. Hoe verhouden de aandachtspunten uit de literatuur én de praktijk zich tot elkaar? In dit afstudeeronderzoek is gebruik gemaakt van de case study methode. Voor de case study bij Finan zijn de volgende dataverzamelingsmethodes gebruikt: (telefonische en persoonlijke) semi-gestructureerde interviews, documenten en directe observaties. De inhoud van de interviews is gestuurd vanuit het theoretische kader. Tabel S.1 toont het theoretische kader. Implementatie: Nazorg:
Acceptatietest Mate van interactie met klant
Regels en routines implementatietraject Beheersen van veranderingen in software Gebruiksgemak Nazorg Ingeschatte bruikbaarheid Communiceren van veranderingen
Kenmerken van het systeem In hoeverre EUP fases opnieuw
doorlopen?
Werkelijke gebruik van het systeem Soort druk dat aanzet tot gebruik nieuwe product
Houding t.o.v. gebruik In hoeverre is implementatieproces ingevuld in netwerkvorm?
Contractvariabelen Wordt gebruik software beschouwd als
een probleem?
Bijdrage systeem aan gehele proces Inbedden nieuwe software in organisatie Onzekerheidsvermijding/veranderingsgezindheid Verwachtingsmanagement algemeen en
t.a.v. cursus
Macht in klantorganisatie Communicatie
Goede implementatiebegeleider Opleiding
Draagvlak bij toekomstige eindgebruikers Overdracht kennis over gebruik software
Tabel S.1: Samenvatting theoretisch kader
conceptuele model voor nazorg de overdracht van kennis aan de gebruikers. Na het verwerken van de resultaten uit de dataverzamelingsmethodes zijn de wensen van de respondenten verwerkt en deze aanzetten tot conceptuele modellen geverifieerd en aangepast. Hierbij valt op dat het aanvankelijke model voor implementatie redelijk goed aansluit bij het uiteindelijke. Aan het aanvankelijke model van implementatie wordt namelijk slechts toegevoegd dat ingeschatte bruikbaarheid een directe relatie heeft met het werkelijke gebruik van de software en onzekerheidsvermijding staat in verband met ingeschatte bruikbaarheid. Het uiteindelijke conceptuele model voor nazorg klopt in mindere mate met het oorspronkelijke model. Verwachtingsmanagement en interactie blijken toch niet van invloed te zijn op de overdracht van kennis over het gebruik van de software. Het inbedden van de nieuwe software in de organisatie blijkt van indirecte invloed te zijn, in tegenstelling tot directe invloed, op de overdracht van kennis, namelijk via het beheersen van veranderingen in de software. Het sociale netwerk heeft in het uiteindelijke model meer invloed dan in het oorspronkelijke model, het is namelijk ook van invloed op de kwaliteit van de nazorg en de communicatie. Tot slot blijkt de interne of externe druk meer relaties te hebben dan voorspeld, namelijk met draagvlak, kwaliteit van nazorg en overdracht van de kennis over het gebruik van de software. Terugkomend op de onderzoeksvraag, blijkt dat de literatuur in meerdere mate een basis vormt voor de praktijk van implementatie, dan voor de praktijk van de nazorg.
Inhoudsopgave Voorwoord ...2 Samenvatting...3 H1 Onderzoeksopzet ...8 § 1.1 Aanleiding ...8 § 1.2 Doelstelling...9 § 1.3 Onderzoeksvraag ...10 § 1.4 Deelvragen...11
§ 1.5 Aanpak per deelvraag...12
§ 1.6 Methodologie...12
§ 1.6.1 Typering van het onderzoek ...12
§ 1.6.2 Case study methode...14
§ 1.6.3 Dataverzamelingsmethoden...15
§ 1.7 Domeinen afstudeeronderzoek ...16
§ 1.7.1 Krachtendomein ...16
§ 1.7.2 Procesdomein...18
H2 Theoretisch kader...21
§ 2.1 Inleiding theoretisch kader ...21
§ 2.2 Rational Unified Process (RUP)...22
§ 2.3 Enterprise Unified Process (EUP) ...25
§ 2.4 Institutionele theorie ...27
§ 2.5 Actor-Network Theory...28
§ 2.6 Oorzaken van beperkte acceptatie ...30
§ 2.6.1 Systeem factoren ...31
§ 2.6.2 Financiële factoren ...32
§ 2.6.3 Bijdrage van het nieuwe systeem aan het gehele proces...32
§ 2.6.4 Culturele factoren...33
§ 2.6.5 Structuur van de organisatie ...33
§ 2.7 Organisatorische aspecten van een implementatie ...34
§ 2.7.1 Organisatorische aspecten volgens Treur en Mast (1997) ...34
§ 2.7.2 Organisatorische aspecten volgens Bentvelsen, Mast en Treur-Smit (?) ...35
§ 2.8 Eerste aanzet tot conceptueel model ...36
H3 Bedrijfsprofiel...39
§ 3.1 Historie van FINAN Financial Analysis ...39
§ 3.2 Productbeschrijving FINAN Financial Analyzer ...40
§ 3.3 Huidige implementatiebegeleiding en nazorg ...42
H4 Interviews ...44
§ 4.1 Informatie interviews ...44
§ 4.2 Inhoud interviews ...46
§ 4.2.1 Inhoud semi-vrije interviews ...46
§ 4.2.2 Inhoud korte interviews...50
H5 Resultaten...51
§ 5.1.3 Resultaten telefonisch interview ...55
§ 5.2 Resultaten observatie ...55
H6 Discussie ...57
§ 6.1 Toelichting statistische testen...57
§ 6.2 Conceptueel model van implementatie ...57
§ 6.3 Conceptueel model van nazorg...60
H7 Conclusie en aanbevelingen ...62
§7.1 Conclusie ...62
§ 7.2 Beperkingen case-onderzoek...65
§ 7.3 Aanbevelingen voor wetenschap ...66
§ 7.4 Aanbevelingen voor Finan ...67
H1 Onderzoeksopzet
In dit hoofdstuk wordt de onderzoeksopzet van deze afstudeeropdracht beschreven. In de eerste paragraaf wordt de aanleiding tot deze afstudeeropdracht vermeld. Hierna wordt de doelstelling van de afstudeeropdracht vastgesteld en toegelicht. Vervolgens wordt de onderzoeksvraag vermeld en wordt deze opgesplitst in deelvragen. Hierna wordt de aanpak per deelvraag kort toegelicht. Vervolgens wordt de aanpak van de afstudeeropdracht onderbouwd in de methodologie. Tenslotte wordt het onderzoeksveld van de afstudeeropdracht duidelijk afgebakend met behulp van een krachten- en een procesdomein.
§ 1.1 Aanleiding
FINAN Financial Analysis (kortweg: Finan) is een organisatie die financiële software ontwikkelt en verkoopt. Deze software, de FINAN Financial Analyzer, ondersteunt financiële analyses. Uit ervaringen van de medewerkers van FINAN Financial Analysis blijkt dat de leden van een middelgrote accountantsorganisatie problemen ondervinden bij het implementeren van de producten van Finan. De leden van deze organisatie zijn alvorens het echt gebruiken van het product, enthousiast over de FINAN Financial Analyzer. Een mogelijke omschrijving van het doel van implementatie is dat er optimaal gebruik wordt gemaakt van een nieuw ingevoerd product of systeem. Deze accountantsorganisatie is echter niet de enige groep klanten van Finan; naast accountants behoren onder andere banken en adviesorganisaties tot de klantenkring van Finan. Het vermoeden bestaat dat deze klanten ook problemen hebben met de implementatie van de producten vanFinan.
Ter Bogt en Van Helden (2000) maken gebruik van de indeling van implementatie van accounting instrumenten in een institutionele, een pragmatische en een gedragsmatige benadering. De institutionele benadering neemt aan dat elke organisatie onderhevig is aan een instituut. Onderzoeken die behoren tot de pragmatische benadering richten zich op nut en bruikbaarheid. Gedragsmatige benadering onderzoekt het gedrag van personen en / of organisaties, vaak in combinatie met de aanwezige cultuur in die organisatie.
een financieel product, is de implementatie op een abstract niveau vergelijkbaar, omdat beide implementaties gaan over de invoering van een nieuw systeem in een organisatie. Player en Keys (1995) vallen ook onder de pragmatische benadering. Zij hebben, op basis van 50 interviews, geconcludeerd dat de successen van implementaties nogal verschillen en onderscheiden 30 valkuilen voor de implementatie van Activity Based Management.
De twee laatst genoemde artikelen geven aan dat de implementaties bij organisaties vaak niet in orde zijn. Er zijn een aantal knelpunten waar geen of onvoldoende aandacht aan wordt besteed bij een implementatieproces en dit heeft tot gevolg dat het gewenste effect uitblijft. Deze knelpunten zijn in het algemeen op het gebied van menselijke en organisatorische aspecten, in plaats van de technische aspecten van het te implementeren product. Enkele voorbeelden van die knelpunten zijn: het ontbreken van de gedragsmatige aspecten in het implementatieproces, gebrek aan scholing van de werknemers en de (afwezigheid van) druk. Met dit laatste wordt bedoeld dat er situaties bestaan waarbij het management wel of niet druk uitvoert op de gebruikers om de desbetreffende software te gaan gebruiken óf waarbij de druk van bijvoorbeeld concurrenten ervoor zorgt dat het management besluit de financiële software aan te schaffen. De laatste situatie kan tot gevolg hebben dat er vervolgens voldoende (intrinsieke) motivatie ontbreekt om dit product optimaal te gebruiken.
Na het bestuderen van de genoemde artikelen is duidelijk geworden dat elke benadering zijn aanhangers heeft. Het is de vraag welke aandachtspunten uit de theorie het meest behulpzaam zullen zijn bij het helpen van de betrokkenen uit de genoemde praktijkcase. Hieronder volgt de doelstelling van deze afstudeeropdracht en daarna zullen de probleemstelling en bijbehorende deelvragen worden vermeld.
§ 1.2 Doelstelling
De doelstelling van deze afstudeeropdracht is te bepalen in hoeverre aandachtspunten uit de wetenschappelijke literatuur een toereikende basis vormen voor de implementatie en nazorg van een financieel product in de praktijk.
product. Het verband én verschil tussen nazorg en implementatie wordt uitgelegd in hoofdstuk 1.7.2.
De literatuur die de basis vormt voor de aandachtspunten betreft literatuur op het gebied van implementatie en nazorg van financiële producten. De aandachtspunten ontstaan uit een kritische analyse van de literatuur. De relevantie van de gevonden aandachtspunten uit de literatuur wordt getoetst met behulp van de praktijkcase. Het desbetreffende bedrijf is FINAN Financial Analysis en het desbetreffende product is de FINAN Financial Analyzer.
Indien bovenstaande doelstelling gerealiseerd wordt, zal dit voor de praktijk betekenen dat getracht is de gewenste implementatie(begeleiding) en nazorg van de klanten van de FINAN Financial Analyzer in kaart te brengen. In eerste instantie levert dit onderzoek een lijst met aandachtspunten uit de (wetenschappelijke) literatuur op. Vervolgens kan deze lijst gebruikt worden om, na vergelijking met de praktijkcase, een lijst samen te stellen met aandachtspunten die in de praktijk ook relevant blijken te zijn. Om het maximale resultaat uit dit afstudeeronderzoek te halen, zal worden geprobeerd een aanpak voor intensieve implementatiebegeleiding en een conceptueel model over implementatie en nazorg te ontwerpen.
§ 1.3 Onderzoeksvraag
In deze paragraaf wordt de onderzoeksvraag van deze afstudeeropdracht vermeld en toegelicht. De onderzoeksvraag beschrijft hoe de doelstelling uit de vorige paragraaf behaald kan worden. In de volgende paragraaf wordt de onderzoeksvraag opgesplitst in deelvragen. De onderzoeksvraag voor dit afstudeeronderzoek is:
‘Welke belangrijke aandachtspunten van de implementatie en nazorg van een financieel product zijn op basis van een kritische analyse te ontlenen aan de literatuur en in hoeverre vormen deze aandachtspunten een toereikende basis voor de implementatie en nazorg van zo’n product in de praktijk?’
Het is ook nog mogelijk dat er een aanknopingspunt ontstaat voor andere producten. Deze producten zullen dezelfde kenmerken hebben als het onderzochte product uit de praktijkcase, namelijk: regelgeving, voorschriften en kundige klanten. Voorbeelden van deze producten zijn: software voor de belastingdienst en juridische en medische software.
In het afstudeeronderzoek wordt voornamelijk gekeken naar het resultaat van de implementatieaanpak en nazorg. Er wordt geen onderzoek gedaan tijdens het uitvoeren van de aanpak, met uitzondering van een aantal observaties die worden toegelicht in hoofdstuk 1.6.3.
§ 1.4 Deelvragen
Hieronder worden de deelvragen, ter beantwoording van de probleemstelling, gepresenteerd. In de volgende paragraaf zal de aanpak per deelvraag worden toegelicht en zal worden toegelicht in welk hoofdstuk elke deelvraag behandeld zal worden.
1. Welke aandachtspunten geeft de literatuur over de wijze waarop financiële productontwikkelaars nieuwe producten bij hun klanten moeten implementeren?
2. Uit welke activiteiten bestaat de nazorg van financiële producten volgens de literatuur?
3. Wat moet er volgens de betrokkenen in de praktijk worden veranderd opdat het waarschijnlijker is dat de implementatie en nazorg van een financieel product succesvol worden?
4. Hoe verhouden de aandachtspunten uit de literatuur én de praktijk zich tot elkaar? Om verwarring te voorkomen, staan hieronder de gebruikte definities voor implementatie en nazorg. De definitie van implementatie is: ‘de invoering van een systeem (…) in een organisatie’.1 Met nazorg worden de (ondersteunende) activiteiten bedoeld die door de leverancier van het product aangeboden worden om, bij de gebruikers, de kennis en het gebruik van het product te verbeteren. Nazorg vindt plaats nádat het product is overgedragen van de ontwikkelaar naar de klant.
§ 1.5 Aanpak per deelvraag
Deelvragen 1 en 2 geven het eerste gedeelte van de probleemstelling weer; namelijk de kritische analyse van de wetenschappelijke literatuur, met als doel de aandachtspunten te vinden die van belang zouden kunnen zijn voor de gewenste implementatiebegeleiding en nazorg in de praktijkcase. Hoofdstuk 2 gaat uitgebreid in op de theorieën en concepten waaruit de belangrijke aandachtspunten zullen worden ontleend en in hoofdstuk 2.8 staat de eerste aanzet tot het conceptuele model.
Deelvraag 3 behandelt het gedeelte van de afstudeeropdracht dat betrekking heeft op het veldonderzoek. Hoofdstuk 3 geeft informatie over de case study, in hoofdstuk 4 worden de interviews toegelicht en hoofdstuk 5 behandelt de resultaten de het veldonderzoek. De aandachtspunten uit de deelvragen 1 en 2 sturen de inhoud van de interviews.
Deelvraag 4 is gesteld om er zeker van te zijn dat er een antwoord wordt verkregen op de geponeerde probleemstelling. Deze deelvraag confronteert de gevonden aandachtspunten uit de literatuur met de resultaten van de interviews en observaties uit de praktijkcase. In hoofdstuk 6 wordt deze deelvraag beantwoord. Het uiteindelijke resultaat van deze vergelijking is een lijst met relevante aandachtspunten, een aanpak voor intensieve implementatiebegeleiding en conceptuele modellen voor implementatie en nazorg.
§ 1.6 Methodologie
In deze paragraaf wordt de methodologie van dit onderzoek toegelicht. De eerste subparagraaf behandelt de typering van het onderzoek. Vervolgens wordt de case study methode toegelicht en tenslotte worden de te gebruiken dataverzamelingsmethoden behandeld.
§ 1.6.1 Typering van het onderzoek
§ 1.6.1.1 Kwalitatief vs. kwantitatief onderzoek
Een onderscheid met betrekking tot onderzoek is: kwalitatief versus kwantitatief onderzoek. Miles (1979) heeft onderzoek gedaan naar de achterliggende redenen voor het verzamelen van kwalitatieve gegevens. Volgens hem zijn kwalitatieve data aantrekkelijk vanwege de volgende redenen: ‘… they are rich, full, earthy, holistic, real’ (p. 590). Hij is van mening dat één van de grootste nadelen van kwalitatief onderzoek is dat het verzamelen ervan nogal arbeidsintensief is. Volgens Patton (1990) is een ander nadeel dat de validiteit en betrouwbaarheid van kwalitatieve data in grote mate afhankelijk zijn van onder andere de vaardigheden en integriteit van de onderzoeker.
Patton (2002) beweert dat er drie soorten kwalitatieve data zijn: - diepte-interviews, open vragen, conversaties en verhalen;
- directe observaties van o.a. gedrag, acties, organisatorische / ‘community’ processen en elk ander aspect van observeerbaar menselijk gedrag;
- documenten zoals ‘records’, brieven, officiële publicaties en rapporten; en correspondentie.
In dit afstudeeronderzoek zal er gebruik worden gemaakt van kwalitatief onderzoek, concreet ingevuld door interviews, observaties en documenten. In paragraaf 6.3 van dit hoofdstuk zullen deze dataverzamelingsmethoden worden toegelicht.
§ 1.6.1.2 Explorerend, descriptief en evaluatief onderzoek
Op basis van de onderzoeksvraag, genoemd in hoofdstuk 1.3, kan worden gesteld dat het onderzoek voor deze afstudeeropdracht valt onder twee types onderzoek. Ten eerste valt dit onderzoek onder descriptief onderzoek, aangezien er een kritische analyse van de literatuur uitgevoerd wordt om de belangrijkste aandachtspunten van het implementatieproces van de financiële software te beschrijven. Ten tweede valt dit onderzoek onder explorerend onderzoek vanwege twee redenen. De eerste reden is dat er een verband wordt gelegd tussen deze aandachtspunten en de voorkeuren en consequenties hiervan volgens de mensen in de praktijk. De tweede reden is dat er verbanden worden gelegd tussen de verschillende aandachtspunten in de vorm van een conceptueel model.
§ 1.6.2 Case study methode
Dit afstudeeronderzoek zal gebruik maken van de case study2 methode. Swanborn (2003) en Yin (1994) omschrijven case study als een (empirisch) onderzoek dat een verschijnsel in zijn natuurlijke omgeving bestudeert. Volgens Berry en Otley (2004) is het bestuderen van een verschijnsel in zijn natuurlijke omgeving een voordeel van de case study methode, omdat het verschijnsel hierdoor beter begrepen kan worden.
Om het centrale verschijnsel van het case study onderzoek zo goed mogelijk te kunnen bestuderen, wordt gebruik gemaakt van meerdere bronnen die vaak verschillend van aard zijn, bijvoorbeeld interviews, observaties en documenten. Dit is een tweede voordeel van een case study. Overigens kan volgens Eisenhardt (1989, p.534-535) een case study kwalitatieve en / of kwantitatieve gegevens betreffen.
Aangezien in deze afstudeeropdracht de grenzen tussen de implementatie zelf en de bijbehorende context niet geheel duidelijk zijn én omdat de context veel invloed heeft op de implementatie van een nieuw product, is het aannemelijk dat de vorm van case study onderzoek voor deze afstudeeropdracht is gekozen.
Met betrekking tot de bevindingen van Schramm (1971) is te vermelden dat in dit afstudeeronderzoek met name sprake is van de beantwoording van de vragen ‘Hoe zijn de beslissingen geïmplementeerd?’ en ‘Welk resultaat hadden de beslissingen?’. Er wordt tevens onderzoek gedaan naar de vraag waarom de klant voor de desbetreffende software heeft gekozen. De toepassing van de bevindingen van Schramm op deze afstudeeropdracht maakt nogmaals duidelijk dat deze afstudeeropdracht valt onder case study onderzoek.
§ 1.6.3 Dataverzamelingsmethoden
Yin (1994) onderscheidt zes vormen van het verzamelen van bewijs, namelijk: documentatie, archiefdocumenten, interviews, fysieke artefacten en directe en participantenobservaties. Fysieke artefacten zijn fysieke bewijzen die verzameld worden tijdens een observatiebezoek. Hierbij kan gedacht worden aan bijvoorbeeld computeroutput. Directe observaties nemen het gedrag waar van organismen in hun natuurlijke omgeving, of, vrij vertaald, het waarnemen van gedrag in de praktijk. Participantenobservatie houdt in dat de onderzoeker ook deel uitmaakt van de waargenomen gebeurtenis.
Er is bij deze afstudeeropdracht geprobeerd om gegevens te verzamelen van bronnen die zoveel mogelijk verschillen van aard. Het case study onderzoek in deze afstudeeropdracht zal gebruik maken van met name interviews en daarnaast documenten, directe observaties en fysieke artefacten. Volgens Yin (1994, p. 83) zijn interviews een essentiële bron van informatie voor een case study onderzoek. Hij definieert interviewen als ‘het stellen van vragen aan diegenen die informatie hebben over een verschijnsel dat de onderzoeker niet direct kan observeren’. In hoofdstuk 4 wordt meer informatie gegeven over de interviews die worden afgenomen in het afstudeeronderzoek.
Tevens zal er tevens gebruik worden gemaakt van directe observaties, omdat particpantenobservaties als groot nadeel hebben dat er een potentiële bias aanwezig is. De vier directe observaties in dit afstudeeronderzoek zijn: een implementatiebegeleider tijdens een acceptatietest van gebruikers, één gebruiker ten tijde dat hij werkt met het softwarepakket, gebruikers tijdens een cursus en gebruikers tijdens een acceptatietest. Om te proberen volledige informatie te verkrijgen tijdens deze observaties, worden de drie laatst genoemde observatiemomenten gecombineerd met interviews bij respondenten en informanten. Tenslotte zal in dit afstudeeronderzoek gebruik worden gemaakt van fysieke artefacten. Dit betreft met name de computeroutput tijdens de testfase bij een klant van Finan.
§ 1.7 Domeinen afstudeeronderzoek
Deze paragraaf behandelt op twee manieren het domein van het afstudeeronderzoek. Ten eerste worden in het krachtendomein de verschillende partijen en krachten benoemd die een rol spelen bij de implementatie en nazorg van financiële software. Ten tweede wordt het onderzoek afgebakend door goed weer te geven welke processen wel en niet worden onderzocht in de afstudeeropdracht. Beide domeinen kunnen worden toegepast op producten met dezelfde kenmerken als financiële software, zoals al beschreven is in hoofdstuk 1.3. Door het in kaart brengen van de domeinen, kan dit afstudeeronderzoek als basis dienen voor bestudering van soortgelijke situaties waarin partijen en processen uit de beide modellen een belangrijke rol spelen die voor dit afstudeeronderzoek buiten dit onderzoek vallen. Tevens is dit model een uitstekende gelegenheid om het onderzoeksveld duidelijk af te bakenen, door aan te geven welke partijen en processen uit de modellen een rol spelen in het desbetreffende onderzoek.
§ 1.7.1 Krachtendomein
implementatie van financiële software. De definitie van een softwareontwikkelaar is ‘een persoon die of bedrijf dat zich bezighoudt met het programmeren van software … .’3
De ontwikkelaar biedt een (gedeeltelijke) oplossing aan voor een probleem van de klant. De klant heeft een probleem - dat misschien efficiënter opgelost kan worden – en zoekt daarvoor software. De vraag is of het desbetreffende product de match is tussen beide probleemdefinities. Het product is in dit geval datgene dat de klant en de ontwikkelaar bij elkaar brengt. In het kader van onderzoek is het overigens van belang onderscheid te maken tussen ‘maatwerksoftware’ en ‘confectiesoftware’. In het eerste geval bestaat de klant meestal uit één organisatie en in het tweede geval bestaat de klant doorgaans uit een groep ondernemingen.
Het is niet noodzakelijk de ontwikkelaar verder te specificeren, maar de klant kan wel worden opgedeeld met behulp van Boonstra (2002). Hij onderscheidt drie belangengroepen die een rol spelen bij ICT-gerelateerde projecten. Volgens Freeman (1984) is een belangengroep te definiëren als: elke groep of individu die beïnvloedt of wordt beïnvloed door het bereiken van de doelen van de organisatie.
De belangengroepen van Boonstra zijn: gebruikers, algemeen management en ICT-experts. Er is vaak sprake van een kloof tussen deze belangengroepen, omdat ze elk, in eerste instantie, hun eigen belangen zullen nastreven en het is mogelijk dat deze belangen conflicteren. Volgens Klein (2000) zou deze kloof geminimaliseerd kunnen worden met behulp van het creëren van een omgeving waarin de meningen van iedereen gegeven kan worden en waarin dan vervolgens gereageerd kan worden op die meningen. Een voorbeeld hiervan is een brainstormsessie of een forum waarvan de gehele organisatie gebruik kan maken.
De drie belangengroepen van Boonstra worden verder toegelicht en eventueel opnieuw gedefinieerd met betrekking tot het te ontwikkelen conceptuele model. De belangengroep ‘gebruikers’ blijft gebruiker(sgroep); hiermee worden de personen bedoeld die werkelijk in aanraking komen met het desbetreffende financiële product. In dit afstudeeronderzoek staan de kleine accountancykantoren en adviesorganisaties centraal als gebruikers. In het kader van het onderzoek is het van belang dat de belangengroep ‘algemeen management’ werkelijk de personen zijn die een belangrijk bijdrage hebben gemaakt aan de beslissing om het
desbetreffende financiële product aan te schaffen. De ‘ICT-experts’ zullen worden vertaald als systeembeheerders. De gebruikers, het algemeen management en systeembeheerders hebben een (in)formele invloed op elkaar.
Tevens is in hoofdstuk 1.3 al aangegeven dat regelgeving en voorschriften een rol spelen bij de implementatie van een dergelijk product. In figuur 1 is de hierboven beschreven situatie overzichtelijk in beeld gebracht. In deze figuur is een duidelijk onderscheid gemaakt tussen de klant, de ontwikkelaar, het product en de regelgeving en voorschriften en zijn er tevens relaties gelegd tussen deze krachten.
Klant
Figuur 1: Krachtendomein afstudeeronderzoek
§ 1.7.2 Procesdomein
Van Bommel (2002) beschrijft Prince2 projectmanagement met behulp van acht hoofdprocessen. Deze processen worden in figuur 2 weergegeven. Dit figuur maakt ook duidelijk hoe deze processen zich verhouden tot elkaar qua tijdsplanning. Het is belangrijk om te vermelden dat voorafgaand aan het opstarten van het project de klant een oriëntatiefase doormaakt, met als doel een geschikte ontwikkelaar voor hun systeem te vinden. De ontwikkelaar probeert in de oriëntatiefase de klant zover te krijgen dat deze met hem in zee gaat. Voor de ontwikkelaar is het dus om ten eerste ervoor te zorgen dat de klant zijn naam kent en vervolgens de klant te overtuigen dat juist zijn product het beste alternatief is voor de oplossing van het probleem van de klant.
Figuur 2: Procesdomein afstudeeronderzoek (http://www.van-bommel.org/Basis%20PRINCE2.html)
In dit afstudeeronderzoek spelen de volgende fases een grote rol: start up, initiating, managing product delivery en closing. Het bepalen van de uitgangspunten in de start-up fase is van belang omdat het gehele project in werking zet en dus onmisbaar is bij een project. In de initiating fase wordt de business case opgeleverd, inclusief een kosteranalyse van het project. Het opleveren van het product (managing product delivery) is een belangrijk proces bij het ontwikkelen van software, omdat dit direct tot gevolg heeft dat de software in gebruik genomen wordt bij de klant. Tot slot is het afsluiten van het project een belangrijk proces omdat hierin onder andere de ‘follow on’ acties worden bepaald. In het kader van het afstudeeronderzoek kan dit vertaald worden als nazorg. De twee laatst genoemde processen zullen de grootste rol spelen in dit afstudeeronderzoek.
Tevens behandelt deze afstudeeropdracht een gedeelte van de oriëntatiefase van de (potentiële) klant, namelijk de motivatie om over te gaan tot de aanschaf van het desbetreffende product. In hoofdstuk 2.4 en 2.5 wordt verduidelijkt waarom de oriëntatiefase wordt behandeld in dit afstudeeronderzoek.
H2 Theoretisch kader
In dit hoofdstuk worden de theorieën beschreven die de basis zullen vormen voor de aandachtspunten van de nazorg en implementatie van een financieel product. In de eerste paragraaf van dit hoofdstuk zal een inleiding worden gegeven op het theoretische kader. In de vier paragrafen die daarna volgen, worden de theorieën en concepten besproken die de basis zullen vormen voor de aandachtspunten. De eerste twee concepten zijn: Rational Unified Process (RUP) en Enterprise Unified Process (EUP). De theorieën zijn de institutionele theorie en de Actor-Network Theory (ANT). In de twee paragrafen daarna worden, met behulp van drie artikelen, een aantal mogelijke oorzaken van implementatieproblemen besproken. In de laatste paragraaf worden de beschreven aandachtspunten van dit hoofdstuk gepresenteerd in een eerste aanzet tot een conceptueel model.
§ 2.1 Inleiding theoretisch kader
In dit hoofdstuk zal worden ingegaan op verschillende artikelen en theorieën met betrekking tot implementatie. Zoals eerder aangegeven, worden de aandachtspunten voor de praktijkcase weergegeven in twee eerste aanzetten tot conceptuele modellen in hoofdstuk 2.8.
In de wetenschappelijke literatuur bestaan vele invalshoeken met betrekking tot implementatie van veranderingen op financieel/management-control gebied. De benaderingen (institutioneel, pragmatisch en gedragsmatig) uit het in hoofdstuk 1.1 genoemde artikel van Ter Bogt en Van Helden (2000) zijn echter benaderingen die redelijk algemeen zijn. Deze benaderingen, met bijbehorende theorieën, kunnen gebruikt worden voor een algemene kennismaking met implementatie op financieel/management-control gebied.
Twee andere benaderingen geven een completer en concreter beeld van de implementatie van veranderingen op financieel/management-control gebied. Deze twee benaderingen zijn: de ‘netwerkbenadering’ en de ‘IT-implementatie-benadering’. De netwerkbenadering omvat sociale netwerken in plaats van een netwerk van computers. Tot de netwerkbenadering behoren onder andere Briers en Wai Fong Chua (2001) en Harrison en Laberge (2002). De artikelen die vallen onder de IT-implementatie-benadering behandelen specifiek de problemen bij de invoering van een IT-systeem. Deze artikelen concluderen ook dat de implementatie van deze producten lang niet altijd goed doordacht is. Dat lang niet elk bedrijf de meest geschikte implementatie gebruikt bij IS-systemen, is onder andere te lezen in het artikel van McFarlan (1981).
§ 2.2 Rational Unified Process (RUP)
Rational Unified Process (RUP) is een raamwerk dat beschrijft hoe software effectief ontwikkeld kan worden en is geschikt voor grote software-ontwikkelingsteams die werken aan grote projecten. RUP is ontstaan als gevolg van een onderzoek naar de oorzaken van mislukte softwareprojecten. Een aantal van deze oorzaken zijn: slechte communicatie, te grote complexiteit en onvoldoende testen. Volgens Kruchten (2001) wordt RUP beschreven met behulp van een object-georiënteerd model en UML. Dit hoofdstuk zal eerst RUP beschrijven en vervolgenswordt RUPP (Rational Unified Process Product) toegelicht.
Vier belangrijke kenmerken van RUP zijn: 1. herhaalde (‘iteratieve’) ontwikkeling;
2. het op tijd oplossen van onderdelen met een hoog risico;
3. interactie met de consument tijdens het gehele ontwikkeltraject; 4. vaak testen en kwaliteit verifiëren van de software.
betrekking hebben op een onderzoek dat veel dieper ingaat op het ontwikkelen van de software in plaats van de implementatie van software.
RUP bestaat uit verschillende activiteiten en deze activiteiten vallen onder negen disciplines. Voorbeelden van deze disciplines zijn: de implementatie van de nieuwe software en het testen van de software. Naast deze disciplines deelt RUP de levenscyclus van software op in individuele ontwikkelingscycli. Deze worden verder opgedeeld in vier fases. Iedere fase wordt afgerond na het behalen van de bijbehorende mijlpaal van die fase. Als een mijlpaalcriterium niet gehaald wordt, kan het project worden stopgezet of aangepast. In figuur 3 worden de negen disciplines in combinatie met de vier fases weergegeven.
Figuur 3: RUP systeem levenscyclus (http://www.phptr.com/articles/article.asp?p=438989&rl=1)
Martin (2001)4 beschrijft deze vier fases van RUP: aanvangsfase (‘inception’), specificatiefase (‘elaboration’), bouwfase (‘construction’) en implementatiefase (‘transition’). In de eerste fase wordt de business case samengesteld. Een belangrijk onderdeel van de business case is het financiële plaatje behorende bij de (eventueel) ontwikkelen software. De mijlpaal in deze fase is een ‘go / no-go beslissing’ die deels gebaseerd is op dat financiële plaatje. In de tweede fase wordt een analyse gemaakt van het probleemgebied en worden de
eisen aan het systeem vastgesteld. In de praktijk is deze analyse een discussie tussen de klant en de ontwikkelaar. De gebruikersgroep binnen de klantorganisatie en de ontwikkelaar zijn belangrijke partijen in deze discussies. Het is de bedoeling dat deze discussies duidelijk maken welke eisen de klant stelt aan het ontwerp van de software. Het bevriezen van deze eisen is tevens de mijlpaal van deze fase. Na deze fase wordt het risico van het project hoger en wordt het dus ook moeilijker om het project te stoppen of te herontwerpen. In de bouwfase worden de componenten en andere kenmerken van het systeem herontworpen met behulp van codering. In deze fase worden de tussenversies van de software getest door de ontwikkelaar. De mijlpaal van deze fase is de eerste externe oplevering van de software. De laatste fase is in het kader van het afstudeeronderzoek ‘implementatiefase’ genoemd om duidelijk te maken dat deze fase niet plaats vindt bij de ontwikkelaar, maar bij de eindgebruiker. In deze fase vindt het testen door (eind)gebruikers en de ontwikkelaar plaats. Tevens worden de gebruikers in deze fase getraind en eventueel wordt het opgeleverde systeem op details aangepast. De mijlpaal van deze fase, en dus van de gehele RUP-levenscyclus, is dat het systeem voldoet aan de eisen uit de tweede fase. Als alle doelen en mijlpalen in deze laatste fase worden behaald, wordt de cyclus beëindigd.
Een belangrijke beperking van RUP is dat het slechts een softwareontwikkelingsproces is dat geen rekening houdt met de gevolgen van het softwaregebruik voor de organisatie. Vanwege deze beperking van RUP is Enterprise Unified Process (EUP) ontwikkeld. Deze benadering wordt toegelicht in de volgende paragraaf.
§ 2.3 Enterprise Unified Process (EUP)
Ambler et al. (2005) beschrijven Enterprise Unified Process (EUP). EUP is een uitbreiding van RUP. RUP gaat slechts in op de ontwikkelingslevenscyclus van software, terwijl EUP de totale IT-levenscyclus beschrijft. Het gevolg hiervan is dat EUP de aanname maakt dat het gebruiken van software gevolgen heeft voor de gebruikersorganisatie. Vanwege deze aanname is EUP interessant voor het afstudeeronderzoek. In figuur 4 is te zien dat EUP twee fases en acht disciplines toevoegt aan RUP. De twee extra EUP-fases worden toegevoegd na de laatste (vierde) fase van de RUP-ontwikkelingscyclus. De vijfde fase is de gebruikersfase (‘production’) en de zesde fase is de verwijderingsfase (‘retirement’).
Figuur 4: EUP IT levenscyclus
verwijderingsfase vindt plaats na de productiefase. De mijlpaal van deze fase is dat het systeem definitief verwijderd is uit de gebruikersorganisatie.
De strikte fase-indeling van RUP en EUP heeft voor- en nadelen. Een voordeel is dat de resultaten van de ontwikkeling objectief geëvalueerd kunnen worden aan de hand van de vastgestelde eisen in de specificatiefase. Dit is vooral praktisch indien het systeem problemen oplevert, omdat de tussentijdse, gedocumenteerde resultaten een indicatie kunnen geven waar het is misgegaan in het ontwikkelingstraject. Ook zijn hierdoor RUP en EUP geschikt voor het uitbestede projecten of andere situaties waarin harde contracten nodig zijn vanwege een gebrek aan (wederzijds) vertrouwen tussen de partijen. Tevens kunnen door het nauwkeurig vastleggen van deze eisen er telkens andere specialisten worden ingezet.
Een nadeel is dat de bijbehorende methodologie en hulpmiddelen (‘tools’) nodig zijn om RUP en EUP formeel te gebruiken. Een ander nadeel is dat het te praktisch zou zijn, omdat RUP en EUP op UML gebaseerd zijn en de gebruikte fases niet goed wetenschappelijk onderbouwd c.q. getoetst kunnen worden. RUP en EUP worden echter wel tamelijk intensief door de praktijk getoetst en verbeterd. Een andere beperking van RUP en EUP is dat het juist niet praktisch zou zijn, omdat men vast zit aan de strikte fases en de klant kan dus geen (deel)product opgeleverd worden voordat álle producteisen vastliggen. Het vastleggen van de overeengekomen specificaties kost tijd en geld. Ook kunnen de ontwikkelaar en de klant hun nieuwe ideeën niet flexibel toevoegen aan de te ontwikkelen software, als de eisen van de software al bevroren zijn. Tevens kunnen de behoeften van de klant en de algemene technische ontwikkelingen in de loop van het project wijzigen; de fase-indeling van RUP en EUP is niet flexibel genoeg om hier rekening mee te houden. Foute vastgelegde specificaties kunnen gevolgen hebben op de kwaliteit van de werkzaamheden en het resultaat van de latere fasen.
Bepaalde aspecten van EUP en RUP zullen toch gebruikt worden in het afstudeeronderzoek vanwege twee redenen. De eerste reden is dat de betreffende onderdelen belangrijk zijn voor softwareontwikkeling, implementatie en nazorg, ongeacht voor welke vorm van fase-indeling wordt gekozen. De tweede reden is dat RUP en EUP tamelijk intensief in de praktijk gebruikt en dus getoetst worden.
over het testen van de software wordt onderzocht in een observatie bij een klant, waar op het moment van het onderzoek een acceptatietest plaatsvindt. Het ontwikkelen van nieuwe versies van de software is ook een aspect van de gebruikersfase. Ambler et al. (2005) beweren dat de ontwikkeling van een nieuwe versie weer de eerste vier fases van EUP door dient te lopen.In de vorige paragraaf is al aangegeven op welke manier het ontwikkelen en beheren van nieuwe versies van de software onderzocht kan worden in het kader van het afstudeeronderzoek. Naar aanleiding van EUP wordt hieraan toegevoegd dat nagegaan zal worden in hoeverre de eerste vier fases van EUP opnieuw doorlopen worden bij het ontwikkelen van een nieuwe versie.De aandachtspunten ontleend aan EUP worden vooralbeoordeeld bij de gebruikersorganisatie.
§ 2.4 Institutionele theorie
De institutionele theorie van Burns en Scapens (2000) is een geschikte theorie om aandachtspunten te vinden, aangezien zij van mening zijn dat kan worden aangenomen dat een management accounting systeem beïnvloed wordt door en invloed heeft op de instituties binnen een organisatie.
Van der Steen (2005) vertaalt ‘instituut’ uit Burns en Scapens (2000) als: ‘een manier van denken en bepaalde gewoonten die voldoende permanent en invloedrijk zijn, en die ingebed zijn in de gewoonten of gebruiken van een groep’. De definitie van regels van Burns en Scapens is: ‘a formally recognized way in which ‘things should be done’. Routines zijn volgens hen terugkerende actie- of denkpatronen die in de gewoontes van een groep terugkomen. Voor het afstudeeronderzoek kan onder andere worden getoetst hoe de ‘regels’ en de ‘routines’ van implementatiebegeleiding en nazorg zich tot elkaar verhouden, bijvoorbeeld met betrekking tot een cursus in het softwaregebruik. Hierbij zal dus vooral worden gekeken naar de ontwikkelaar. Overigens worden de routines van de software impliciet behandeld worden in hoofdstuk 2.6.1.
specifiek zijn; dit onderzoek is gericht op de implementatie van de software van Finan op organisatieniveau, in plaats van op individueel niveau.
Het tweede punt van kritiek van Van der Steen is dat de institutionele theorie geen uitspraken doet over ‘de manier waarop de noodzaak tot verandering wordt vastgesteld binnen de organisatie’ (p. vi). Om deze kritiek te weerleggen zou de theorie van Cyert en March (1963) gebruikt kunnen worden. Zij ontwikkelden de ‘behavioral theory of the firm’ die veranderingen binnen een organisatie zou kunnen verklaren. Deze theorie kan inzicht geven over de omstandigheden waaronder de verandering in de organisatie heeft plaatsgevonden. Volgens Cyert en March zijn veranderingen het gevolg van een toename van interne of externe druk tot die verandering. Van déze suggestie wordt in de afstudeeropdracht gebruik gemaakt om erachter te komen of interne en / of externe druk heeft veroorzaakt dat de gebruiker overgegaan is tot aanschaf van het nieuwe product. De keuze tot aanschaf van het betreffende product wordt door de (potentiële) klant gemaakt in de oriëntatiefase. Deze oriëntatiefase wordt ook genoemd in het procesdomein uit hoofdstuk 1.7.2.
§ 2.5 Actor-Network Theory
In deze paragraaf wordt de Actor-Network Theory (ANT) behandeld. De ANT valt onder de netwerkbenadering. Met ‘netwerk’ wordt een sociaal netwerk bedoeld in plaats van een netwerk van computers. Volgens de ANT is een netwerk een set van relaties, objecten en rollen die een alliantie vormen rondom een verandering en heeft een netwerk als doel om overeenstemming te krijgen over doelen en acties. Volgens Klijn en Van Twist (2000) is een ‘actor’ een analytisch te onderscheiden eenheid, waarvan het belangrijkste kenmerk is dat hij zich als handelende partij in de dynamiek van een netwerk opstelt.Binnen een netwerk zijn de factoren afhankelijk van elkaar in het bereiken van hun doelen, namelijk het oplossen van hun problemen. De bronnenverdeling en regelvorming leiden tot een zekere geslotenheid voor de omgeving buiten het netwerk. De ANT kan in het afstudeeronderzoek gebruikt worden om te bestuderen hoe de implementatie en de nazorg binnen de gebruikersorganisatie zijn georganiseerd, in termen van aanspreekpunten, leiders en verantwoordelijkheden.
aan dat elk individu een identiteit aan zichzelf verbindt. Binnen de ANT zijn er vier fases die beschrijven hoe een netwerk binnen een organisatie of collectief tot een doel kunnen leiden. De eerste fase is de constructie van het probleem. Deze fase vindt plaats om het probleem opnieuw te benoemen zodat de leden van het netwerk hun eigen voordeel ontdekken in het oplossen van het probleem. Deze eerste fase is erg belangrijk voor het creëren van individuele motivatie en collectief draagvlak. In de tweede fase (‘interessement phase’) probeert men regelmaat te ontdekken in het gedrag van andere netwerkleden om zo verrassingen te voorkomen. Tijdens de derde fase (‘enrolment phase’) worden de rollen (in)formeel toebedeeld aan de netwerkleden. In deze fase is het belangrijk dat de rollen naar het collectief buiten het netwerk worden gecommuniceerd én dat de rollen overeenkomen met de individueel bepaalde identiteiten. Het overeenkomen tussen een rol en identiteit is een voorwaarde voor het creëren van individuele motivatie. De laatste fase is het mobiliseren. In deze fase wordt de (inhoud van de) verandering gecommuniceerd naar het collectief en treden de leden van het netwerk dus naar buiten als ambassadeurs; dit laatste is tevens het doel van het stappenplan. Communiceren betekent in deze fase dat een betekenis wordt gedeeld. De ANT is beschreven door verscheidene auteurs, onder andere Briers en Wai Fong Chua (2001) en Harrison en Laberge (2002). Beide artikelen passen de ANT toe op een case van één bedrijf. Het belang van de ANT bij onderzoeken naar implementatie wordt ook onderkend door Tatnall en Gilding (1999). Zij verdedigen dat de ANT tot het onderzoek naar de implementatie van informatiesystemen behoort. Volgens hen kan met behulp van een ANT-analyse begrepen worden waarom een innovatie een succes of mislukking is geworden. Zij gebruiken de definitie van Rogers (1995) voor een innovatie, namelijk ‘een idee dat als nieuw wordt beschouwd door een persoon of een groep personen’.
Met behulp van de Actor-Network Theory kan worden nagegaan in hoeverre een sociaal netwerk wordt ingezet om de implementatie en nazorg van het product van de betreffende ontwikkelaar beïnvloed. Om dit met betrekking tot de afstudeeropdracht te beoordelen wordt er onderzocht of de kenmerken van de eerste en derde fase aanwezig zijn bij de gebruikersorganisatie en de ontwikkelaar. Indien er inderdaad van een netwerk gebruik wordt gemaakt bij de implementatie en nazorg van de software, kan worden nagegaan hoe goed dit netwerk functioneert en wat er eventueel aan verbeterd kan worden.
motivatie en draagvlak. Voor draagvlak bij de eindgebruikers is het belangrijk dat de gebruikers betrokken worden bij de invoer van het nieuwe product. Concreet betekent deze fase dat wordt nagegaan in hoeverre het gebruik van de software als een probleem wordt gezien door de ontwikkelaar en de klantorganisaties. Tevens wordt in het afstudeeronderzoek onderzocht of er inderdaad een relatie kan worden gelegd tussen de kenmerken van de eerste fase van ANT en de aanwezigheid van draagvlak in een organisatie. De derde fase wordt behandeld in de afstudeerscriptie omdat het kenmerk van deze fase, het toebedelen van rollen aan de netwerkleden, een activiteit is die te signaleren en de beoordelen is. Deze fase, voor zover het gezien de tijd realistisch is dat deze al aanwezig is, wordt voor het afstudeeronderzoek gebruikt om na te gaan in hoeverre de netwerkrollen, met hun verschillende verantwoordelijkheden, zijn (in)formeel toebedeeld binnen de klantorganisatie en de ontwikkelaar. Wat betreft de klantorganisatie wordt gevraagd naar de rol van de respondent en zijn collega’s en bij de ontwikkelaar worden de verantwoordelijkheden met betrekking tot de gebruikersorganisaties ook bestudeerd.
Het is overigens mogelijk dat de externe of interne druk die de aanschaf van een nieuw product beïnvloed (Cyert en March (1963)), het ontstaan van een (in)formeel netwerk beïnvloed. Naast de bewering dat interne of externe druk de oorzaak is van een verandering (zie hoofdstuk 2.4), is dit een tweede geldige reden voor het betrekken van de oriëntatiefase bij het afstudeeronderzoek.
§ 2.6 Oorzaken van beperkte acceptatie
- systeem factoren - financiële factoren
- bijdrage van het nieuwe systeem aan het gehele proces - culturele factoren
- structuur van de organisatie
Deze vijf categorieën zullen in de volgende vijf subparagrafen worden behandeld.
§ 2.6.1 Systeem factoren
Bij de eerste categorie, ‘systeem’, kan onder andere worden gekeken naar het Technology Acceptance Model (TA-model) van Davis et al. (1989). Dit model is weergegeven in figuur 5. Het TA-model legt verbanden tussen enerzijds de kenmerken van het systeemontwerp, en anderzijds de ingeschatte bruikbaarheid en het ingeschatte gebruiksgemak. In het TA-model wordt tevens een verband gelegd tussen het ingeschatte gebruiksgemak en de ingeschatte bruikbaarheid. Vervolgens zorgen, volgens dit model, de ingeschatte bruikbaarheid en het ingeschatte gebruiksgemak samen voor de houding ten opzichte van het gebruik. En dit laatste element zorgt vervolgens weer voor het werkelijke gebruik van het systeem.
Alle onderdelen van het TA-model, kenmerken van het systeem(ontwerp), ingeschatte bruikbaarheid en gebruiksgemak, houding ten opzichte van gebruik en werkelijke gebruik van het systeem zullen worden onderzocht in het afstudeeronderzoek. De ingeschatte bruikbaarheid, gebruiksgemak, houding ten opzichte van het gebruik en werkelijke gebruik van het systeem hebben allen betrekking op de gebruikers uit de klantorganisatie.
Figuur 5: TA-Model (Davis, et. al (2004))
§ 2.6.2 Financiële factoren
Bij de tweede categorie, ‘financiële factoren’, valt te denken aan de mate waarin de prijs, duur van de licentie en andere variabelen in de koopcontracten van de desbetreffende financiële software aangepast worden aan de individuele wensen van de klant. Hierbij wordt dus ingegaan op het ‘beheersaspect’ van de financiële factoren. Deze informatie zal verkregen worden bij de ontwikkelaar. Tevens zal bij de klant worden getracht te achterhalen in hoeverre deze factoren een rol spelen bij de implementatie van het betreffende financiële product.
§ 2.6.3 Bijdrage van het nieuwe systeem aan het gehele proces
De derde categorie, ‘bijdrage van het systeem aan het gehele proces’, is belangrijk omdat het mogelijk is dat de implementatie verbetert als gebruikers een grotere bijdrage van het nieuwe systeem aan het gehele proces van werkzaamheden verwachten en / of ondervinden. Het is dus voor de ontwikkelaars van een systeem van belang om erachter te komen hoe ze het systeem kunnen verbeteren om een betere bijdrage aan het gehele proces bij de gebruiker te kunnen leveren.
§ 2.6.4 Culturele factoren
Hofstede (1980) definieert cultuur als ‘een collectieve programmering van de geest die leden van de ene groep onderscheidt van de leden van de andere groep’. Normen en waarden zijn belangrijke onderdelen van een cultuur. Cultuur is een onderwerp waar veel over geschreven is. Hofstede (1980) gebruikt de volgende vier dimensies om nationale culturen aan te relateren: individualisme vs. collectivisme, mate van machtsafstand, mate van onzekerheidsvermijding en mate van masculiniteit.
De afstudeeropdracht heeft betrekking op de implementatie van een product bij een klant. Onzekerheidsvermijding kan een belangrijke factor zijn die de implementatie van een nieuw product tegenhoudt. Deze dimensie hangt samen met de mate waarin een organisatie veranderingsgezind is. Er wordt in het kader van het afstudeeronderzoek getracht de veranderingsgezindheid van de gehele klantorganisatie van de betreffende respondent te bepalen en niet van de individuele respondent. Voor de afstudeeropdracht kan dit aandachtspunt concreet worden ingevuld door te beoordelen in welke mate men gebruik maakt van nieuwe functies in een nieuwe versie van het financiële product en in hoeverre men een positieve houding heeft tegenover suggesties die worden gemaakt. Tevens kan er worden gekeken naar de mate waarin de organisatie georiënteerd is op het verleden.
§ 2.6.5 Structuur van de organisatie
hun artikel aan dat het belangrijk is dat de macht die voortvloeit uit een informatiesysteem, overeenkomt met onder andere de macht die (impliciet) voortvloeit uit de organisatiestructuur.
In dit afstudeeronderzoek zal de invloed van het product op de machtsverdeling in de klantorganisatie impliciet worden opgemaakt uit de interviews met de gebruikers en de observaties van de gebruikers. Indien de respondent de enige gebruiker binnen de organisatie is, is de machtsverdeling na invoer van het product ook van toepassing, omdat het mogelijk is dat de respondent als gevolg van de invoering van dit product meer macht heeft gekregen binnen de organisatie. Deze laatste situatie is echter zeer moeilijk na te gaan.
§ 2.7 Organisatorische aspecten van een implementatie
In deze paragraaf worden twee artikelen behandeld over de organisatorische aspecten van een implementatie. Het eerste artikel is van Treur en Mast (1997) en het tweede van Bentvelsen, Mast en Treur-Smit (?).
§ 2.7.1 Organisatorische aspecten volgens Treur en Mast (1997)
Treur en Mast (1997) benadrukken het belang van de organisatorische implementatie van een informatiesysteem dat gebaseerd is op FAST (Flexibele Applicatie Shell Technologie). Bij de introductie van een nieuw informatiesysteem wordt vaak de nadruk gelegd op de technische aspecten van het nieuwe systeem, maar het inbedden van het nieuwe systeem in de organisatie is ook erg belangrijk. Als dit laatste niet gebeurt, bestaat er een kans dat het systeem niet op de bedoelde wijze wordt gebruikt. Andere belangrijke stuurfactoren binnen een organisatie zijn: verwachtingsmanagement, communicatie, ambassadeurs / netwerk, opleiding en een goede implementatiebegeleider.
niet mogelijk om de verwachtingen ten aanzien van het product te beoordelen met een bezoek aan een gebruiker. Daarom is gekozen om de verwachtingen van de cursus te beoordelen, omdat dit wel mogelijk is. De algemene verwachtingen worden in het afstudeeronderzoek beoordeeld aan de hand van de gehouden interviews. Communicatie heeft in dit artikel niet dezelfde betekenis als bij de Actor-Network Theory. Treur en Mast (1997) gebruiken een andere betekenis van communicatie, namelijk het uitwisselen van informatie.
In het kader van het afstudeeronderzoek kan communicatie onderzocht worden door de mening van de gebruiker over de nazorg te achterhalen en ook wordt de (frequentie van de) communicatie in het algemeen onderzocht. Communicatie hangt tevens samen met verwachtingsmanagement en de overgang naar een nieuwe versie. De stuurfactor ambassadeurs / netwerk is al besproken in paragraaf 6 van dit hoofdstuk. Verder zal bij de gebruiker en bij de ontwikkelaar worden gevraagd naar de cursus die bij het product hoort, om er zo achter te komen wat er aan de opleiding verbeterd kan worden. Als laatste is het van belang dat degene die de implementatie begeleidt, de functionele consequenties van beslissingen goed in de gaten heeft. Een observatie van een implementatiebegeleider is een manier om meer inzicht te krijgen in deze laatste stuurfactor.
§ 2.7.2 Organisatorische aspecten volgens Bentvelsen, Mast en Treur-Smit (?)
Bentvelsen, Mast en Treur-Smit (?) benadrukken dat het belangrijk is om voldoende draagvlak voor de verandering te creëren bij de toekomstige eindgebruikers en de overige betrokkenen. Draagvlak kan gestimuleerd worden door een sociaal netwerk. Naast draagvlak onderscheiden zij de volgende succesfactoren die van belang zijn om een succesvolle verandering te krijgen: management commitment, tijdige en reële communicatie, opleiding en borging van nazorg. Tevens behandelen zij overige factoren, waaronder de acceptatietest. De factor opleiding is al besproken in de vorige paragraaf.
uit de interviews en observaties op te maken in hoeverre de gebruiker probeert om het product te promoten bij bijvoorbeeld (potentiële) gebruikers binnen of buiten de klantorganisatie. Borging van nazorg zal ook behandeld worden als aandachtspunt in de interviews met de gebruikers. Met betrekking tot nazorg zijn Bentvelsen, Mast & Treur-Smit van mening dat de invoering van een nieuw systeem in de organisatie alleen succesvol kan zijn als medewerkers uit de desbetreffende gebruikersorganisatie ook als ambassadeur worden betrokken bij dit traject. Nazorg kan verder concreet behandeld worden door dieper in te gaan op een wensenprocedure. Tevens kan aan de werknemers van de leverancier uit de praktijkcase worden gevraagd of de gebruikers van de software de juiste kanalen gebruiken om hun vragen te stellen. Tevens wordt de communicatie van de nazorg onderzocht. Tot slot wordt de acceptatietest als onderdeel gezien van implementatiebegeleiding. Volgens Bentvelsen, Mast & Treur-Smit dient een acceptatietest aan verschillende eisen te voldoen, namelijk acceptatiecriteria, zorgvuldige planning qua tijdstip locatie en mensen en de acceptatietest dient bij voorkeur uitgevoerd te worden door (toekomstige) eindgebruikers van het product.
§ 2.8 Eerste aanzet tot conceptueel model
Het doel van implementatie (zie hoofdstuk 1.1) is: het optimale gebruik van de nieuwe software. Dit leidt tot twee mogelijkheden voor de centrale pijl in figuur 6, namelijk het ingeschatte gebruiksgemak en het werkelijke gebruik van de software. Er is voor de laatste mogelijkheid gekozen, omdat deze in het TA-model (zie hoofdstuk 2.6.1) een centralere rol speelt dan gebruiksgemak. Vervolgens is figuur 6 aangevuld met de onderdelen en opbouw van dit TA-model. Tot slot zijn de overige secundaire, tertiaire en quartaire pijlen toegevoegd. De definitie van nazorg (zie hoofdstuk 1.4) is: de overdracht van kennis over het gebruik van de nieuwe software. In de interviews wordt dit gemeten door na te gaan in hoeverre de gebruikers op de hoogte zijn van de een aantal functies van de software. Deze definitie is als centrale pijl voor figuur 7 gekozen. Vervolgens zijn de secundaire en tertiaire pijlen toegevoegd.
Figuur 6: Eerste aanzet tot conceptueel model van implementatie: werkelijke gebruik van software.
Werkelijk gebruik software Houding t.o.v. gebruik Ingeschatte gebruiksgemak Kenmerken software Ingeschatte bruikbaarheid Onzekerheids-vermijding Bijdrage software aan gehele proces
Contract-variabelen Structuur
organisatie Goede acceptatietest
Figuur 7: Eerste aanzet tot conceptueel model van nazorg: overdracht van kennis over gebruik van software.
Overdracht kennis over gebruik software Opleiding Verwachtings-management Mate van interactie met klant Beheersen veranderingen software Communicatie van veranderingen 4 fases EUP opnieuw doorlopen? Communicatie (algemeen) Inbedden nieuwe software in organisatie Sociaal netwerk Interne / externe druk
Is er een software-probleem?
Draagvlak
H3 Bedrijfsprofiel
In dit hoofdstuk wordt het bedrijf FINAN Financial Analysis beschreven aan de hand van drie onderwerpen. De eerste twee onderwerpen die besproken worden, de historie van het bedrijf (3.1) en de huidige producten van het bedrijf (3.2), zijn tamelijk algemene onderwerpen. Het derde onderwerp is gekozen gezien de inhoud van het afstudeeronderzoek; dit onderwerp is: de huidige implementatiebegeleiding en nazorg (3.3).
§ 3.1 Historie van FINAN Financial Analysis
FINAN Financial Analysis (kortweg: Finan) is een organisatie die financiële software ontwikkelt en verkoopt. Deze software ondersteunt financiële analyses. Op dit moment zijn er bij Finan veertien werknemers in dienst en heeft de onderneming een vestiging in Zwolle en in Rotterdam. De historie van Finan gaat ongeveer 25 jaar terug.
Begin jaren ’80 van de vorige eeuw maakte het Centraal Instituut voor Midden- en Kleinbedrijf (CIMK), inmiddels IMK, een begin met het ontwikkelen van een financieel model voor een mainframe computer. Vanaf 1982 werkte het CIMK samen met de Economische Faculteit van de Rijksuniversiteit Groningen om een computerprogramma voor financiële modellen voor PC-gebruik te ontwikkelen. In datzelfde jaar werd een computerprogramma gepresenteerd dat een uitgebreid simulatiemodel bevatte. Dit programma resulteerde uiteindelijk in drie toepassingen: HISAN (voor analyse van historische financiële gegevens), FINPRO (voor consistente prognoses op basis van historische data) en STARTPRO (voor analyse van gegevens van startende ondernemingen). Na verloop van tijd zijn deze drie onderdelen samengevoegd in één toepassing: FINAN.
bij Finan verkrijgbaar; naast de al genoemde FINAN Financial Analyzer is tien jaar geleden de FINAN Database Reporter ontwikkeld. Dit laatste product is een pakket om ‘de gegevens uit de Financial Analyzer op portefeuille niveau te ontsluiten en te analyseren.’5
In de volgende paragraaf wordt de FINAN Financial Analyzer toegelicht en wordt vermeld op welke configuraties van dit product het afstudeeronderzoek zich specifiek richt.
§ 3.2 Productbeschrijving FINAN Financial Analyzer
Finan ontwikkelt twee soorten software. De eerste soort is ‘maatwerksoftware’ en de tweede is ‘confectiesoftware’. RUP is van toepassing op de eerste soort software. In het tweede geval bestaat de belangengroep ‘klant’ uit hoofdstuk 1.7.1 uit een groep ondernemingen in plaats van één onderneming. De eerste fase van de ANT, het definiëren van het probleem van het netwerk, is bij confectiesoftware complexer. Finan zet zijn producten relatief hoog in qua prijs en daarmee probeert men duidelijk te maken dat het de bedoeling is dat de klanten de software intensief in plaats van incidenteel gebruiken.
De producten van Finan zijn ontwikkeld door een combinatie van financieel-economische principes en praktische ervaringen van de medewerkers en klanten. Bij de ontwikkeling van de producten wordt tegenwoordig nauw samengewerkt met de Economische Faculteit van de Rijksuniversiteit Groningen en andere gerenommeerde instituten. De eindproducten bestaan uit configuraties die goed theoretisch onderbouwd zijn én ook in de dagelijkse werkzaamheden van financiële dienstverleners toepasbaar zijn.
Een belangrijke eigenschap van de FINAN Financial Analyzer is dat het een strikt onderscheid maakt tussen de model- en de gebruikerskant van de software. Dit zorgt ervoor dat de rekenmodellen binnen de applicatie correct blijven. Tevens zitten er in het product twee rekenkundige standaardcontroles en er verschijnen waarschuwingskruizen zodra één van de twee standaardcontroles in het pakket een fout ontdekken. De rapportages kunnen niet geprint worden zolang de waarschuwingskruizen in beeld staan. Tot slot bestaat de software uit redelijk veel niveaus en de gebruiker kan het overzicht behouden met behulp van een Explorer.
De vier meest gebruikte configuraties van de FINAN Financial Analyzer zijn de FINAN Financial Analyzer Advice (Plus) en de FINAN Financial Analyzer Valuation (Plus). Daarnaast is het product verkrijgbaar in de volgende configuraties: Agri, Banking, Education, Garage en Scoring. Met de Banking configuratie kan men zakelijke bancaire relaties, inclusief zekerheden en kredietgegevens, vastleggen. Tevens kunnen de configuraties desgewenst aangepast worden aan de wensen van één of meerdere klantorganisaties.
Het afstudeeronderzoek zal zich in het bijzonder richten op de configuraties Valuation en Valuation Plus omdat men vermoed dat de verbetering van de implementaties van deze producten urgent is. De FINAN Financial Analyzer Valuation maakt gebruik van diverse waarderingstechnieken voor ondernemingen. In de configuratie Valuation Plus worden elf waarderingstechnieken toegepast. Beide configuraties worden gebruikt door banken, accountantskantoren, financiële en belasting adviseurs, inkoopcombinaties, ontwikkelingsmaatschappijen, onderwijsinstellingen en andere (grote) ondernemingen waar inzicht in financiële gegevens belangrijk is. Dit afstudeeronderzoek concentreert zich op de kleine gebruikers van deze configuraties, deze gebruikers zijn accountants en adviseurs. Deze respondenten geven slechts een deelterrein van de activiteiten van Finan weer.
Tevens richt het afstudeeronderzoek zich op de configuratie Banking, omdat tijdens de onderzoeksperiode deze configuratie een acceptatietest ondergaat en er een cursus wordt gegeven aan de toekomstige gebruikers van deze applicatie. in de onderzoeksperiode. De acceptatietest en de cursus worden beide geobserveerd.
configuraties van producten zijn ontwikkeld en nieuwe versies van configuraties uitgebracht zijn, is men tot het besef gekomen dat er meer moet worden gekeken naar de wensen van de klant. In termen van Voss en Voss (2000) is dit een overgang van ‘product orientation’ naar ‘customer orientation’. Deze overgang komt tot uitdrukking in het feit dat de werknemers van Finan graag een afstudeeronderzoek wilden laten doen naar de gewenste implementatiebegeleiding en nazorg. Om achter deze wensen te komen, dienen echter eerst de huidige implementatiebegeleiding en nazorg van Finan beschreven te worden. Deze zijn te vinden in de volgende paragraaf.
§ 3.3 Huidige implementatiebegeleiding en nazorg
De huidige implementatiebegeleiding en nazorg van de FINAN Financial Analyzer Valuation (Plus) omvat veel aspecten. Deze aspecten kunnen worden aangepast aan de wensen van de klantorganisatie. De onderdelen van de implementatie van het product die voor de hand liggen zijn de handleiding en het testtraject.
De overige onderdelen worden systematisch genoemd aan de hand van het artikel van Bentvelsen, Mast en Treur-Smit (?), omdat dit artikel een opsomming bevat van de onderdelen van implementatie. Zoals vermeld in hoofdstuk 2.7.2, behandelen zij de volgende factoren: management commitment, draagvlak bij toekomstige eindgebruikers en bij overige betrokkenen, tijdige en reële communicatie, opleiding en borging van nazorg. De eerste twee factoren zijn niet relevant voor dit hoofdstuk, omdat dat niet iets wezenlijks is wat de firma Finan aanbiedt in haar implementatiebegeleiding. Communicatie wordt impliciet behandeld bij de overgebleven factoren. De factoren die dus overblijven zijn: handleiding, testtraject, opleiding en nazorg. Deze factoren worden in deze volgorde hieronder toegelicht.
Bij elke applicatie die nieuw verkocht wordt, wordt per licentiehouder een handleiding verstrekt. De handleiding wordt ook verstrekt indien een gebruiker een nieuwe versie van het product ontvangt. De handleiding volgt de volgorde van het programma Finan en bevat een lijst met nieuwe functies van de nieuwe versie.
Ten aanzien van de factor ‘opleiding’ verzorgt de firma Finan cursussen op allerlei niveaus en voor alle applicaties. Het doel van deze cursus is dat de cursisten na het volgen van de cursus zich zelfstandig kunnen redden met de basisfuncties van het programma. De cursussen worden in een trainingscentrum of ‘in-house’ georganiseerd. Tijdens deze cursus wordt financiële analyse in het algemeen behandeld én wordt uitleg en instructie over de applicaties gegeven. De cursussen worden gegeven met behulp van een cursusboek met instructies en opdrachten. Tevens wordt tijdens de cursus een case behandeld, waardoor men inzicht krijgt in de opbouw van de software. Na afloop van een cursus(dag) wordt een evaluatieformulier aan de deelnemers uitgedeeld.
Een stoffelijk aspect van de huidige nazorg is een naslagkaart waarop onder andere de belangrijkste functietoetsen staan. Ook worden in het kader van de te ontwikkelen nieuwe versie van de FINAN Financial Analyzer een aantal klantorganisaties van Finan bezocht, die eventuele eisen, wensen en problemen onder de aandacht van de Finan-medewerkers kunnen brengen. Tevens wordt er eens in de paar jaar een gebruikersdag georganiseerd. Indien de gebruikers vragen hebben, kunnen ze deze per e-mail, telefoon, fax of via de website stellen aan de Finan-medewerkers. De huidige implementatiebegeleiding en nazorg van Finan wordt in tabel 1 overzichtelijk gepresenteerd. In de linkerkolom staan de onderdelen waaruit de huidige implementatiebegeleiding van Finan bestaat en in de rechterkolom staan opmerkingen over deze onderdelen.
Huidige implementatiebegeleiding Finan: Opmerkingen:
Handleiding Eventueel inclusief lijst met functies van de
nieuwe versie
Testtraject Communicatieplan, acceptatietest
Opleiding Cursusboek, evaluatieformulier
Nazorg Naslagkaart, klantenronde, gebruikersdag,
vragen gebruikers
Communicatie Communicatie tijdens discussies over
ontwerp van product, informatie bij de overgang naar een nieuwe versie
H4 Interviews
In de eerste paragraaf van dit hoofdstuk wordt informatie gegeven over de gehouden interviews. Er wordt vooral gemotiveerd waarom voor de desbetreffende aanpak is gekozen. In de tweede paragraaf worden de inhoud van de interviews behandeld.
§ 4.1 Informatie interviews
Interviews kunnen worden gehouden bij respondenten of bij informanten. Volgens Kumar, Stern & Anderson (1993) zijn respondenten leden van een groep die zullen antwoorden op de gestelde vragen in de vorm van hun persoonlijke gevoelens, opinies en gedrag. Van informanten wordt aangenomen dat ze een gespecialiseerde en uitgebreide kennis hebben over het onderzochte gebied.
In het kader van het afstudeeronderzoek zijn interviews bij respondenten afgenomen, omdat dit de mensen zijn die in de praktijk te maken hebben met de implementatie en zij kunnen dus ook het beste beoordelen welke aandachtspunten uit de literatuur belangrijk zijn voor de implementatie van financiële software. Deze interviews dienen in kaart te brengen welke preferenties de gebruikers hebben ten aanzien van het product en de bijbehorende implementatie en nazorg. Er is voor gekozen om beginnende en ervaren gebruikers te interviewen. Het is mogelijk dat het verschil in ervaring leidt tot verschillende preferenties ten opzichte van de producten, implementatie(begeleiding) en nazorg van de firma Finan.
Yin (1994) maakt onderscheid tussen de volgende drie verschillende vormen van interviews: open-vragen (‘open-ended’) interview, semi-vrij (‘focused’) interview en gestructureerd (‘structured’) interview. In dit afstudeeronderzoek is gekozen voor semi-vrije interviews, om de respondenten een kans te geven zo goed mogelijk hun mening te verwoorden over de desbetreffende aandachtspunten. Er is voor gekozen om, op basis van een afweging van Baarda en de Goede (1995), mondeling in plaats van schriftelijk te interviewen. Op deze wijze kunnen eventuele onduidelijkheden relatief gemakkelijk worden toegelicht.
