Amsterdam Business School
Succesvolle ERP implementatie bij een MKB onderneming?
Een casestudy
Name: Matthijs Prins Student number: 11425490
Thesis supervisor: dhr. A.T.A. Koet RA Date: 19 augustus 2018
Word count: 14.953
MSc Accountancy & Control, specialization Control Amsterdam Business School
2
Contents
1 Introductie ... 5
Aanleiding ... 5
2 Achtergrond en bestaande literatuur ... 8
2.1 Beschrijving onderneming ... 8
2.2 ERP-systemen ... 9
2.3 Risicofactoren bij de implementatie ... 10
2.4 Implementatie ERP-systemen bij MKB/ SME bedrijven ... 14
3 Methodologie ... 16
Kwalitatief onderzoek ... 16
Kwantitatief onderzoek ... 17
4 Resultaten kwalitatief onderzoek ... 19
4.1 Aanleiding ... 19
4.2 Conceptfase ... 20
4.3 Implementatiefase ... 27
4.4 Informatievoorziening en -technologie ... 38
5 Resultaten kwantitatief onderzoek ... 40
6 Analyse risicofactoren en doelstellingen ERP project ... 45
6.1 Risicofactoren ... 45
6.2 Doelstellingen ... 47
7 Conclusie ... 51
Referenties ... 53
Statement of Originality
This document is written by Student Matthijs Prins who declares to take full responsibility for the contents of this document. I declare that the text and the work presented in this document is original and that no sources other than those mentioned in the text and its references have been used in creating it.
The Faculty of Economics and Business is responsible solely for the supervision of completion of the work, not for the contents.
Abstract
In deze casestudy is onderzoek gedaan naar de ERP implementatie bij een MKB-onderneming en in hoeverre deze verschilt ten opzichte van grotere ondernemingen. De resultaten zijn zowel afkomstig uit kwalitatief als kwantitatief onderzoek. Topmanagement betrokkenheid en kwaliteiten van de consultant blijken conform bestaande literatuur nadrukkelijk van belang bij de MKB-onderneming. In tegenstelling tot bestaande literatuur hecht de onderneming in de casus veel waarde aan flexibiliteit in het ERP-systeem. Een mogelijke verklaring hiervoor is het starre kenmerk van het vervangen ERP-systeem.
Nader onderzoek zal moeten plaatsvinden in hoeverre de resultaten uit deze case overeenkomen met andere MKB-ondernemingen. Daarnaast is verder onderzoek nodig naar betrokkenheid van medewerkers tijdens de selectie en implementatie van een ERP-systeem in een MKB-onderneming. Er blijkt namelijk een verband (hoewel beperkt) te bestaan tussen de ervaring van betrokken medewerkers en de uiteindelijke beoordeling van het succes van een ERP project.
1 Introductie
ERP-systemen zijn “geïntegreerde cross functionele systemen met selecteerbare software modules zoals finance,
sales and operations planning en logistiek” (Grabski, Leech & Schmidt, 2011). De grootste leveranciers
van ERP-systemen zijn SAP, Microsoft, Oracle en Exact (Computer Profile, 2017). Een van de grootste voordelen van ERP-systemen, ten opzichte van het gebruik van meerdere ICT-systemen, is de integratie van veel bedrijfsprocessen van een bedrijf ondersteunende modules in één systeem. De voordelen van integratie zijn dat informatie centraal is vastgelegd, real-time inzichtelijk is voor gebruikers en meerdere dataentries voorkomt. Naast de aanschaf van een geïntegreerd ERP-systeem of de aanschaf van meerdere ICT-systemen kan een onderneming ook kiezen voor een ‘custom made systeem’ dat specifiek voor de onderneming is ontworpen.
De kosten van aanschaf van een Enterprise Resource Planning systeem (ERP) zijn hoog en de implementatie is risicovol in die zin dat de implementatie vaak niet loopt zoals gepland en zelfs volledig mislukt. Jaarlijks geven bedrijven wereldwijd naar schatting $18,3 miljard uit aan ERP-systemen (Rikhardsson, Rohde, & Rom, 2006). De gemiddelde kosten van een ERP project zijn $1,0 miljoen (Aloini, Dulmin, & Mininno, 2007). ERP implementaties zijn risicovol doordat 90% van de ERP-implementaties uitlopen (Aloini, et al., 2007), het implementatieproces een aantal risicofactoren bevat (Aloini et al., 2007) en uiteindelijk kan leiden tot problemen in cruciale bedrijfsprocessen.
Er zijn een groot aantal casestudies (Teittinen, Pellinen & Järvenpää, 2012; Dechow en Mouritsen, 2005; Scapens en Jazayeri, 2003) beschikbaar waarbij de implementatie van ERP-systemen wordt beschreven. Het merendeel van deze casestudies richt zich op relatief grote bedrijven en het ERP-systeem SAP. De bijdrage van deze thesis is dat de ERP implementatie zal worden beschreven binnen een (kleinere) MKB-onderneming, van een ander ERP-systeem: Microsoft Dynamics AX.
Aanleiding
Vanaf september 2015 ben ik in mijn functie als controller binnen een groothandel, hierna geanonimiseerd ‘FIETS’, betrokken bij de implementatie van een nieuw ERP-systeem als vervanging van het bestaande en verouderde ERP-systeem. Als een van de key-users binnen de finance afdeling heb ik het traject vanaf de ontwikkelfase meegemaakt. Een traject met uitdagingen in de ontwikkeling (van functionaliteit tot het testen), informatievoorziening en het, ondanks vertraging, gemotiveerd houden van de medewerkers gedurende alle fasen van het
6
course Accounting Information Systems (AIS) doen interesseren in het veranderproces en de bijdrage van een ERP-systeem in een organisatie.
In januari 2014 besluit FIETS het huidige ERP-systeem te vervangen. Motivatie voor de aanschaf van een nieuw ERP-systeem waren hoge onderhoudskosten, beperkte ontwikkeling door de leverancier van het bestaande systeem en dat het huidige systeem niet geschikt werd geacht voor toekomstige ontwikkelingen in de Retail branche. Uit gesprekken met de leverancier (Unit4) van dit ERP-systeem bleek dat het systeem zich in de toekomst zou richten op leveringen aan consumenten en het gebruik door het midden- en kleinbedrijf. FIETS was het ERP-systeem ontgroeid. De tekortkomingen en nieuwe wensen werden opgevangen door het bouwen van applicaties rond het oude ERP-systeem. Dat ging gepaard met veel extra kosten en ook het onderhoud van al die systemen was kostbaar. Bij het schrijven van deze paper is het nieuwe ERP-systeem ruim 1½ jaar ‘live’.
Onderzoeksvraag en contributie
De onderzoeksvraag die in deze scriptie wordt beantwoord is de volgende:
Hoe verloopt het implementatieproces van een ERP-systeem in een MKB-onderneming, en waarin verschilt dat proces bij grote ondernemingen?
Door het beantwoorden van de onderzoeksvraag krijgen we inzicht in het resultaat van de implementatie van een ERP-systeem en de risicofactoren die binnen deze case plaatsvinden bij een MKB-onderneming. De contributie van de thesis is daarmee tweeledig. Deze case biedt inzicht in het verloop van een ERP project en hoe deze werkt. Daarbij is het bijzonder dat het gaat om een ERP implementatie bij een MKB-onderneming. Bestaande literatuur richt zich voornamelijk op grotere ondernemingen in omvang en met meerdere productielocaties over de wereld (zie bijvoorbeeld Dechow en Mouritsen, 2005; Scapens en Jazayeri, 2003) en op het ERP-systeem SAP.
De uitkomsten van deze casestudy geven verdieping aan bestaande literatuur door in deze specifieke casus binnen een MKB-onderneming, het effect van de implementatie en ERP-systeem te beschrijven. Maar deze zijn ook een uitbreiding doordat literatuur met name te aanzien van MKB ondernemingen beperkt is.
Het vervolg van deze paper bestaat uit achtergrond en bestaande literatuur (hoofdstuk 2) gevolgd door de methodologie (hoofdstuk 3), de resultaten van het kwalitatieve onderzoek (hoofdstuk 4) en het kwantitatieve onderzoek (hoofdstuk 5). Hoofdstuk 6 betreft de beoordeling van risicofactoren en doelstellingen van de ERP implementatie. In hoofdstuk 7 wordt de
conclusie gevormd, met nadere aanbeveling voor verder onderzoek naar ERP implementaties binnen een middelgroot bedrijf.
8
2 Achtergrond en bestaande literatuur
Dit hoofdstuk is een beschrijving van de onderneming (paragraaf 2.1), bestaande literatuur (paragraaf 2.2) en literatuur specifiek gericht op MKB-ondernemingen(paragraaf 2.3).
2.1 Beschrijving onderneming
De onderneming FIETS is een familiebedrijf met meer dan 170 medewerkers en actief in de fietsenbranche. De activiteiten bestaan enerzijds uit groothandelsactiviteiten in fietsonderdelen en -accessoires (O&A). Daarnaast is het eigenaar van twee A-fietsmerken waarbij de productie door een externe partij plaatsvindt. FIETS heeft een omzet van circa 85 miljoen euro en levert niet rechtstreeks aan consumenten, maar aan de (online) fietsenwinkels. De activiteiten vinden plaats op één bedrijfslocatie in Nederland. Daarnaast huurt FIETS verschillende opslaglocaties in Nederland.
Het bedrijf is het gevolg van een fusie van twee ondernemingen binnen één familie en vindt zijn oorsprong in 1955. Vanaf het jaar 2010 groeit FIETS hard als gevolg van de introductie van een populaire stadsfiets, ook de groothandelsactiviteiten in onderdelen en accessoires nemen toe. Het personeelsbestand stijgt van 90 in 2010 naar circa 140 Full Time Equivalent (FTE) in 2017. In 2017 besluit FIETS de activiteiten in te delen in business units om zich specifieker op haar klantsegmenten te kunnen richten en sneller in te spelen op kansen en ontwikkelingen in specifieke markten. FIETS is anno 2018 nog steeds volledig in eigendom van de familie.
Steeds meer verkopen in Nederland vinden plaats via het internet (GfK Netherlands, 2018), ook in de fietsbranche. De traditionele fietsenhandelaar moet steeds meer concurreren met (goedkopere) online aanbieders. Een trend die invloed heeft op FIETS. De klanten, zijnde de fietsenhandelaren, verkopen naast uit een fysieke winkel steeds meer online. FIETS verwacht dat in de toekomst verkopen niet exclusief online worden verkocht, maar zowel in de fysieke winkel als online (de zogenoemde omni-channel strategie). Deze strategie is gericht op een eenduidige communicatie met de klant via zowel het online als offline kanaal.
Doordat steeds meer verkopen online plaatsvinden, dan wel oriëntatie van de consument online plaatsvindt, is informatie-uitwisseling tussen FIETS en haar klanten steeds belangrijker geworden. Real-time informatie-uitwisseling over assortiment, beschikbaarheid en levertijden zijn daarom essentieel voor FIETS.
De markt waarin FIETS opereert vertoont een sterk seizoen patroon. In de zomermaanden en met mooi weer worden de meeste fietsen en onderdelen en accessoires verkocht. De
maanden voordat het zomerseizoen van start gaat worden gebruikt voor het opbouwen van voorraden. Voor het assortiment fietsen maakt FIETS gebruik van modeljaren. Een modeljaar start in de maand oktober en loopt één jaar. Een fietsmodel kan na deze periode doorlopen of worden uit gefaseerd. De levertijd van een fiets bij de producent bedraagt gemiddeld 4 à 5 maanden. Het proces van ontwerp tot daadwerkelijke levering van een nieuw model fiets duurt in totaal 15 tot 18 maanden. Het is dus van belang betrouwbare informatie te hebben over onder andere specificaties van fietsen, voorraden van onderdelen van deze fiets en levertijden van de producten. Voor onderdelen en accessoire artikelen is deze termijn korter (aantal weken tot een aantal maanden) omdat rechtstreeks bij de leverancier kan worden besteld vanuit hun voorraad.
De productie van fietsen is uitbesteed aan een drietal producenten (geen eigendom onderneming) in de Europese Unie (EU). De geproduceerde fietsen worden opgeslagen bij een logistieke partner in Nederland. De O&A artikelen, meer dan 20.000 Stock Keeping Units (SKU’s), zijn opgeslagen in het magazijn van FIETS. Op weekdagen en incidenteel in het weekend worden deze artikelen na bestelling op dezelfde dag verstuurd naar ruim 2.000 klanten in Nederland, België en Duitsland.
2.2 ERP-systemen
ERP-systemen zijn de grootste, meest complexe en veeleisende informatiesystemen die bedrijven implementeren (Grabski, Leech & Schmidt, 2011). ERP implementaties wijken af van traditionele systemen door omvang, complexiteit, kosten, medewerkersbetrokkenheid en impact op de organisatie (Grabski & Leech, 2007). De implementatie van een ERP-systeem heeft, door integratie, betrekking en impact op de hele organisatie (Aloini et al., 2007; Davenport, 2000). Daarnaast is het verloop van een ERP project moeilijk te voorspellen (Quatrone & Hopper, 2005). Aloini et al. (2007) identificeren op basis van uitgebreide literatuurstudie de tien meest voorkomende risicofactoren bij de implementatie van een ERP-systeem. In onderstaande paragrafen 2.3 zullen deze risicofactoren worden toegelicht.
Naast integratie zijn verdere kenmerken van ERP-systemen standaardisatie, centralisatie en het automatiseren van veel routinematige werkzaamheden. Standaardisatie heeft betrekking op het gebruik maken van door ERP-systemen aangeboden best practices zowel voor wat betreft de inrichting van de processen als ook het vastleggen van gegevens. Centralisatie heeft betrekking op zowel integratie als standaardisatie. Doordat de gegevens geïntegreerd zijn vastgelegd volgens eenzelfde wijze is het mogelijk de onderneming centraal aan te sturen. Het
10
werkzaamheden zoals kostendoorbelastingen, facturenregistratie en rapportages over te nemen die in het verleden handmatig werden uitgevoerd (Scapens en Jazayeri, 2003).
Het ERP project bestaat volgens Aloini et. al (2007) uit een drietal fasen: de conceptfase van strategische planning en selectie. De implementatiefase waarin het ERP-systeem wordt uitgerold, geïntegreerd en gestabiliseerd. En de laatste fase, de post implementatiefase, waarin het ERP verder wordt ontwikkeld. De eerste fase van een ERP-project is cruciaal, want zeven van de tien meest voorkomende risicofactoren vinden plaats in deze fase.
2.3 Risicofactoren bij de implementatie Inadequate ERP selection
De meest voorkomende risicofactor is een inadequate ERP selectie. Voordat een besluit wordt genomen tot vervanging dienen allereerst de eisen en wensen van de onderneming in kaart gebracht te worden. Een gedetailleerde beschrijving daarvan, voor selectie, verhoogt de kans dat het ERP-systeem voldoet aan de doelstellingen van de organisatie en de business processen (Grabski & Leech, 2007). Koch, Slater & Baatz, (1999) geven aan dat het ontbreken van aansluiting van de operationele processen met het ERP-systeem de meest genoemde reden is voor het afbreken van een ERP-project.
Van belang is dat de onderneming zich bewust is van de specifieke kenmerken van ERP-systemen. Een van deze kenmerken is dat een ERP-systeem gestandaardiseerd is. Er zijn verschillende ERP-systemen voor specifieke bedrijven met best practices. Dit is van belang omdat het kan zijn dat specifieke wensen niet mogelijk zijn binnen het ERP-systeem, anders dan tegen hoge kosten. De onderneming kan ervoor kiezen deze specifieke wensen alsnog te realiseren door middel van maatwerk. Hieraan zijn kosten van ontwikkeling verbonden, maar ook toekomstige extra onderhoudskosten. Ondernemingen selecteren gestandaardiseerde ERP-systemen, ondanks dat het niet de beste mogelijkheden biedt voor een onderneming. Ondernemingen kiezen voor deze oplossing in het streven naar integratie, centralisatie en organisatorische verbeteringen (Teittinen et al., 2012).
Onjuiste ERP selectie heeft grote gevolgen. Aanpassingen die achteraf worden gedaan kunnen zeer complex zijn (Dechow en Mouritsen, 2005).
Ineffective strategic thinking and planning strategic
De tweede meest voorkomende risicofactor, op basis van bestaande literatuur, is het ontbreken van aansluiting tussen de strategie van de onderneming en de IT-strategie. De mogelijkheden van
het ERP-systeem dienen aan te sluiten bij de strategie van de onderneming. Volgens Aloini (2007) dient de onderneming in het planningsproces rekening te houden met kritische ondernemingsdoelstellingen, strategische ondernemingsissues en strategische vereisten van het ERP-systeem. Organisaties kunnen unieke kenmerken en doelstellingen verliezen doordat bestaande best practices worden overgenomen door industrie best practices. Hierdoor dienen er binnen het bedrijf veranderingen plaats te vinden ten aanzien van de bedrijfscultuur, structuur en rollen (Kanellou & Spathis, 2011).
Strategie behelst de lange termijn doelstelling van de onderneming. De ERP implementatie heeft invloed op de strategie van de onderneming, want de wijze waarop een ERP-systeem is geconfigureerd kan zorgen voor beperkingen op de lange termijn, met name ten aanzien van management control (Grabski et al., 2011). Een onderdeel van management control behelst de informatievoorziening binnen de onderneming.
De kwaliteit van de informatievoorziening om routinematige processen aan te sturen door een ERP-systeem neemt toe (Goretzki, Strauss & Weber (2013). Dit heeft een effect op het besluitvormingsproces en organisatorische veranderingen (zie ook paragraaf ‘inadequate changemanagement hierna). Maar zoals gezegd, alleen ten aanzien van de operationele processen. Het verhogen van de kwaliteit komt onder andere door de specifieke kenmerken van het ERP-systeem: standaardisatie, integratie en het overnemen van routinematige werkzaamheden. Door standaardisatie dwingt het ERP-systeem gegevens gestructureerd vast te leggen.
Ineffective project management techniques
Naast een adequate selectie(procedure) van het ERP-systeem is het van belang dat het ERP project goed wordt gemanaged. Risicomanagement wordt door het management vaak gezien als extra werk en kosten, waardoor de risico’s niet stelselmatig in kaart worden gebracht (Aloini et al., 2007). Er dient een gedetailleerd plan te worden opgesteld. Mits goed gemanaged zorgt dat ervoor dat tijdig wordt geëscaleerd en risico's van het niet behalen van de doelstellingen tijdig worden geïdentificeerd (Grabski & Leech, 2007).
Escalatie en verlies van controle gedurende het ERP project kunnen volgens Grabski & Leech (2007) op een tweetal manieren plaatsvinden. Dit zijn: het verlies van controle over het projectteam en het verlies van controle over de gebruikers als het ERP-systeem in gebruik is genomen. Gebrek aan controle over het projectteam heeft als gevolg dat er gedecentraliseerd besluiten worden genomen terwijl deze niet effectief en in het belang van de onderneming kunnen zijn. Om dit te voorkomen is het volgens Grabski & Leech (2007) gebruikelijk om een
12
projectteam oordeelt over zijn of haar eigen besluiten worden deze beoordeeld door senior-managers. Door gedetailleerde planning, met duidelijke mijlpalen is het mogelijk de voortgang van het project te volgen. Het verlies van controle over de gebruikers wanneer het ERP-systeem in gebruik wordt genomen zal worden toegelicht onder de risicofactor ‘inadequate change management’.
Inadequate change management
De implementatie van een ERP-systeem heeft door integratie, impact op de gehele organisatie. Volgens Davenport (2000) is herstructurering van een organisatiestructuur, -cultuur en gedrag van werknemers binnen een organisatie nodig om te profiteren van het ERP-systeem. Door herstructurering wijzigen personele verhoudingen. Deze veranderingen kunnen bij het personeel angst, weerstand en onzekerheid veroorzaken (Glover, Prawitt & Romney, 1999). ERP-systemen zorgen voor verandering in de wijze waarop data wordt verzameld, opgeslagen en gebruikt en hebben effect op het accounting proces (Kanellou & Spathis, 2013). Maar ook de inrichting van de werkprocessen en dus de werkwijze van medewerkers veranderen.
Grabski & Leech (2007) identificeren het verlies van controle op het personeel bij het in gebruik nemen van het ERP-systeem. Bestaande literatuur laat zien dat het van belang is dat het initiatief voor het ERP project vanuit de medewerkers van de business moet worden gedragen. Dit vereist strategische visie over de business en waar de onderneming waarde toevoegt (de risicofactor ‘ineffective strategic thinking and planning strategic’). Volgens Rom en Rohde (2007) kan de implementatie in plannen worden voorbereid, maar het uiteindelijke gebruik door werknemers niet. Om weerstand van personeel in een ERP project te beperken zijn training, communicatie, team building, betrokkenheid van personeel bij het implementatieproces en ondersteuning door het management essentiële onderdelen (Grabski & Leech, 2007).
Inadequate training and instruction
Inadequate training en instructie worden door Aloini et. al (2007) eveneens als risicofactor geïdentificeerd. Personeel moet adequaat worden opgeleid voor het nieuwe ERP-systeem, zodat men de nieuwe taken goed kan uitvoeren en de gegevens juist in het systeem kan vastleggen. Een reguliere training voor IT-systemen is volgens Grabski et al. (2001) niet voldoende. Wijzigingen in data entries door personeel hebben niet alleen effect op zijn of haar eigen afdeling, maar kunnen door integratie invloed hebben op de gehele organisatie.
Training is ook essentieel voor de acceptatie van het personeel van het nieuwe ERP-systeem. Het adequaat trainen van personeel wordt door Grabski et al. (2001) geïdentificeerd als
een factor voor ERP succes. Door voortdurende ontwikkelingen en updates van het systeem is het van belang dat ook na een implementatie de training wordt voortgezet.
Goede training en educatie vormen een essentieel onderdeel van het change management binnen organisaties bij de implementaties en het in gebruik nemen van ICT systemen.
Low top management involvement
Lage betrokkenheid en toewijding van het top management wordt gezien als een risicfactor voor succes van het ERP project. Betrokkenheid van het senior management verhoogt het belang van het ERP project binnen een onderneming (Grabski & Leech, 2007).
Poor project team skills
Beperkte vaardigheden binnen het project zijn een risico als het gaat om ERP implementaties. Het is van belang dat het projectteam gebalanceerd is als het gaat om interne en externe expertise, management vaardigheden, kennis van de processen en IT kennis (Aloini et al., 2007).
Inadequate Business Process Re-engineering (BPR)
BPR is een methodologie om bedrijfsprocessen in een onderneming te herstructureren. Implementatie van een ERP-systeem zorgt er veelal voor dat bedrijfsprocessen geherstructureerd moeten worden, omdat het systeem vaak niet volledig aansluit bij de processen van de onderneming (Aloini et al., 2007). Het herstructureren van processen kan zorgen voor medewerkersweerstand, omdat medewerkers het risico lopen dat hun werkzaamheden verdwijnen of uit hun bestaande positie worden gehaald (Grabski & Leech, 2007). Het negeren van BPR in een ERP implementatie is een risicofactor (Aloini et al., 2007).
Bad managerial conduction
Begeleiding vanuit het management ten aanzien van het ERP project is cruciaal, waarbij duidelijk moet zijn wat de doelen van het project zijn en dienen helder te blijven gedurende het verloop van het project (Aloini et al. (2007). Managementvaardigheden van communicatie en teambuilding zijn een van de belangrijkste onderdelen van een succesvolle ERP implementatie (Grabski & Leech, 2007).
In de case van Teittinen et al. (2012) was betrokkenheid van het management van belang om dicht bij de standaard van het ERP-systeem te blijven.
14 Low key-user involvement
De laatste van de top tien meest geïdentificeerde risicofactoren betreft lage betrokkenheid van key-users gedurende het ERP project. Deze risicofactor is van belang om te voldoen aan verwachtingen van de medewerkers. Key-users moeten overtuigd zijn van het systeem en expert zijn, zodat zij gebruikers kunnen ondersteunen in training (Aloini et al., 2007).
2.4 Implementatie ERP-systemen bij MKB/ SME bedrijven
Het implementatieproces en de keuze van ERP-systemen bij MKB-bedrijven, in de literatuur geclassificeerd als Small and Medium Enterprise (SME), wijken af van grotere ondernemingen. Ondernemingsomvang wordt als een significante factor gevonden als het gaat om ERP implementaties. Allereerst worden de verschillen in het selectieproces beschreven, gevolgd door verschillen gedurende de implementatiefase en de in bestaande literatuur beschreven oorzaken van verschillen tussen MKB-ondernemingen en grotere ondernemingen.
Selectieproces
MKB-ondernemingen kiezen andere systemen, kennen een andere waarde toe aan selectiecriteria en het besluitvormingsproces tot ERP projecten wijkt af van grotere ondernemingen (Bernroider & Koch, 2001).
MKB-ondernemingen kiezen andere ERP-systemen dan grotere ondernemingen. Het marktaandeel van SAP binnen grotere ondernemingen is hoger (Bernroider & Koch, 2001). Uit deze survey van Bernroider & Koch (2001) blijkt verder dat MKB-ondernemingen in het selectieproces minder waarde toekennen aan onder andere organisatorische flexibiliteit en procesverbetering ten opzichte van grotere ondernemingen. De keuze wordt volgens Bernroider en Koch (2001) gemaakt omdat deze bedrijven al flexibel zijn en een ERP-systeem niet nodig hebben om dit doel te bereiken.
Het besluitvormingsproces wijkt volgens Bernroider & Koch (2001) ook af. Van de vier verschillende typen structuren van het selectie team (topmanagement met externe consultant, sterke focus vanuit de IT-afdeling en beperkte betrokkenheid interne afdelingen, centrale beslissing en een mix van deze structuren) wordt binnen MKB-ondernemingen meer gebruik gemaakt van selectieteams met sterke focus op de IT-afdeling en beperkte betrokkenheid van interne afdelingen.
Implementatieproces
De implementatietijd van ERP-systemen bij ondernemingen is korter, MKB-ondernemingen hebben een grotere behoefte aan topmanagement betrokkenheid, kwaliteit van consultants en proces discipline (Grabski et al., 2011).
In de case van Muscatello, Small & Chenn (2003) zorgt top management betrokkenheid in het implementatieproces voor de juiste focus en ondersteuning in het ERP project. Daarnaast zorgt top management betrokkenheid ervoor dat het belang van het ERP project wordt gedragen binnen de onderneming.
Volgens Snider, da Silveira & Balakrishnan (2009) is er een direct verband tussen het succes van ERP projecten en kwaliteit van de consultant. MKB-ondernemingen zijn meer dan grotere ondernemingen in hun kennis afhankelijk van de kwaliteit van de externe consultant.
Proces discipline heeft betrekking op de naleving van vastgelegde procedures binnen een organisatie (Snider et al., 2009). Volgen Snider et al. (2009) is proces discipline een kritische succesfactor van ERP projecten binnen MKB-ondernemingen. Het ontbreken daarvan zorgt voor een mismatch tussen kennis van de business en kennis van de externe consultant, omdat deze processen niet goed zijn beschreven.
Oorzaken
De oorzaken van verschillen kunnen worden gezocht dat het minder beschikbaar zijn van resources (personeel en budget) beschikbaar zijn binnen deze MKB-ondernemingen ten opzichte van de grotere ondernemingen. Snider et al. (2009) identificeren daarnaast de volgende verschillen bij MKB-ondernemingen ten opzichte van grotere ondernemingen: het management is betrokken bij de dagelijkse gang van zaken in de onderneming, vaak minder (formeel) getraind en een lange termijn planning ontbreekt vaak.
16
3 Methodologie
In dit hoofdstuk wordt de methodologie van de thesis beschreven. Voor deze thesis is gebruik gemaakt van zowel kwalitatief (hoofdstuk 4) als kwantitatief onderzoek (hoofdstuk 5). De motivatie voor deze keuze wordt in dit hoofdstuk beschreven.
Kwalitatief onderzoek
De motivatie voor de keuze van kwalitatief onderzoek is dat het een specifieke situatie in detail beschrijft. Het betreft een exploratief onderzoek om het proces en de risicofactoren gedurende de ERP implementatie te beschrijven. Dit kan beschreven worden, omdat er vooraf een scan door een extern bureau is gemaakt van de bestaande situatie van het ERP-systeem, de eisen van en verwachte toekomstige ontwikkelingen in het bestaande of nieuwe ERP-systeem. Daarnaast kan een vergelijking worden gemaakt met bestaande literatuur.
Kwalitatief onderzoek vindt plaats aan de hand van semi-gestructureerd interviews. Deze interviews zijn gestructureerd, maar bieden de mogelijkheid om naast de theoretische aspecten de ruimte in te bouwen voor nieuwe inzichten. De opbouw van interviews is op basis van de relevante risicofactoren, als beschreven in paragraaf 2.3 Daarnaast is ten aanzien van de implementatie veel documentatie beschikbaar zoals notulen, e-mailberichten, PowerPointpresentaties en overige documentatie.
Kwalitatief onderzoek is wetenschappelijk verantwoord. Dit type onderzoek is van belang omdat deze voorbeelden biedt, een wetenschappelijke discipline zonder deze voorbeelden is een ineffectieve (Flyvbjerg, 2006).
Gezien de organisatiecultuur is de toegankelijkheid van de betreffende personen hoog. Voor deze thesis zijn 10 betrokkenen personen in de periode 26 juni tot en met 12 juli geïnterviewd. Een overzicht van de interviews is opgenomen in figuur 3.1. Met een product owner wordt bedoelt diegene in de organisatie die verantwoordelijk is voor de functionaliteit in het ERP-systeem van zijn of haar functioneel gebied.
Daarmee zijn 3 van de 6 product owners gesproken. Een interview met de andere drie product owners heeft niet plaatsgevonden omdat de betreffende medewerker uit dienst is (product owner 5, finance), besloten is om deze module niet te implementeren (product owner 2, CRM) en vanwege andere redenen (product owner 6, service en garantie). Dit is ondervangen door key-users van de betreffende functionele gebieden te spreken. Naast de product owners zijn andere betrokkenen gesproken: IT-beheerder, programmamanager en algemeen directeur.
Kwantitatief onderzoek
Om daarnaast organisatiebreed onderzoek te doen naar het behalen van de doelstellingen en de risicofactoren is gebruik gemaakt van een enquête.
De uitkomsten zullen tweeledig worden gebruikt. Enerzijds om de uitkomst aan het kwalitatieve onderzoek te toetsen, anderzijds kan deze verder richtinggevend zijn voor de semi-gestructureerde interviews. Voor de opbouw van de enquête is gebruik gemaakt van de risicofactoren van Aloini (2007), zoals beschreven in paragraaf 2.3. De enquête is uitgezet en op 4 juli 2018 verzonden naar 102 e-mailadressen. De enquête is bijgevoegd in bijlage I. In totaal zijn 16 van de 102 personen afgevallen doordat zij geen gebruik maken dan wel geen ervaring hebben met het geselecteerde nieuwe ERP-systeem AX. 47 personen hebben in de periode 4 juli tot en met 13 juli gereageerd. Met een response rate, gecorrigeerd voor het aantal afgevallen personen, van ruim 53% is dat een mooi resultaat. Een overzicht van de opbouw van de response is opgenomen in figuur 3.2.
Hieruit blijkt een spreiding in het aantal dienstjaren en de ervaring met het vervangen ERP-systeem AW. Het merendeel (87%) van de door personen ingevulde enquêtes heeft ervaring met zowel AW als AX. Ook is er spreiding in de enquête in de ervaring met het gebruik van verschillende modules.
4 Resultaten kwalitatief onderzoek
In dit hoofdstuk zijn de resultaten ten aanzien van het kwalitatieve onderzoek verantwoord. De onderzoeksresultaten zijn afkomstig van semi-gestructureerde interviews en overige documentatie dat beschikbaar is ten aanzien van het ERP project zijnde: e-mailberichten, PowerPoint presentaties, externe rapportage en nieuwsberichten. Omwille van anonimiteit zijn citaten gecodeerd, zodat deze niet zijn te herleiden naar de personen.
Het hoofdstuk is chronologische opgebouwd. Paragraaf 4.1 beschrijft de aanleiding van het ERP project gevolgd door de conceptfase (paragraaf 4.2) van de ERP implementatie bestaande uit strategische planning, selectie, strategische keuzes, vorming van het projectteam en keuze voor de implementatiemethode. Aan het einde van deze paragraaf is een conclusie gevormd over de conceptfase. Paragraaf 4.3 beschrijft de implementatiefase waarbij onderscheid wordt gemaakt in projectmanagement, change management en training en instructie. Het onderdeel informatievoorziening en -technologie is beschreven in paragraaf 4.4.
4.1 Aanleiding
FIETS maakt vanaf december 2005 gebruik van het ERP-systeem Agresso Wholesale (AW) van de leverancier Unit4. AW is een ERP-systeem specifiek gericht op het midden- en kleinbedrijf. Er wordt door FIETS gebruik gemaakt van de modules inkoop, verkoop, logistiek en accounting.
De technische en functionele kennis van AW binnen FIETS ligt voornamelijk bij twee personen, de functioneel beheerder en de IT-manager. Onderhoud en aanpassingen in het ERP-systeem worden door de leverancier Unit4 verricht. Omdat de strategie van Unit4 is om onderhoud en ontwikkeling van AW volledig in eigen beheer te houden, is FIETS afhankelijk van deze leverancier. De prijsstelling van Unit4 voor werkzaamheden aan AW worden door de IT-afdeling maar ook de logistieke afdeling als hoog ervaren. Dit blijkt bijvoorbeeld uit het doorberekenen van kosten voor het opstellen van een offerte, zonder dat er daadwerkelijk werkzaamheden zijn uitgevoerd en hoge tarieven voor het inschakelen van een consultant van Unit4.
Het retail landschap, waar de klanten van FIETS zich in begeven, verandert. Steeds meer aankopen van de consument vinden plaats via het internet (Centraal Bureau voor de Statistiek, 2017). FIETS krijgt steeds meer klanten die uitsluitend of ook via het internet verkopen. De
real-20
klanten en leveranciers worden daarbij steeds meer van belang. De oplossing van Unit4 betekent ingrijpend maatwerk, die FIETS volledig moet betalen.
Naast het bestaande maatwerk in AW zijn er buiten dit ERP-systeem een aantal IT-oplossingen gebouwd: logistieke dashboards, CRM-functionaliteit, communicatie (inkooporders, verzendlijsten etc.) met leveranciers en logistieke partners. Het kost steeds meer tijd en onderhoud om gegevens van deze oplossingen up-to-date te houden en op elkaar af te stemmen. Vanuit beheersbaarheid is de wens van FIETS om deze onderdelen in één systeem onder te brengen.
Samengevat bestaat er binnen FIETS ontevredenheid ten aanzien van de bestaande functionaliteit en hoge kosten door ontwikkeling van AW. De verwachting is dat toekomstige ontwikkelingen, waarbij real-time informatie-uitwisseling steeds belangrijker zal worden, ervoor zullen zorgen dat FIETS het huidige ERP-systeem ontgroeit. AW biedt niet een integrale oplossing met één database maar een aantal andere IT-systemen.
4.2 Conceptfase
De conceptfase van een ERP project bestaat volgens Aloini et al. (2007) uit de strategische planning en selectie. Het vervolg van deze paragraaf is een beschrijving van de strategische keuzes die zijn gemaakt. Aan het einde van de paragraaf wordt de vorming van het projectteam en de keuze van de implementatiemethode beschreven. Uiteindelijke geformuleerd tot een conclusie ten aanzien van deze fase.
Strategische planning
Strategische planning heeft betrekking op de aansluiting van de IT-strategie op de strategie van FIETS. Om een goede afweging te maken wordt met behulp van een externe onafhankelijke partij een scan uitgevoerd op het bestaande ERP-systeem. Enerzijds wordt gekeken naar de korte termijn aansluiting van het ERP-systeem op de processen, producten en diensten. Daarnaast wordt gekeken naar de langetermijnvisie t.a.v. het huidige ERP-systeem. De externe partij brengt de IT-architectuur in kaart, identificeert kritische bedrijfsprocessen, interviewt en presenteert aan het Management Team en gaat in gesprek met de leverancier van AW Unit4.
De bevindingen van de scan worden door de externe partij gerapporteerd en gepresenteerd aan het Management Team van FIETS. Voor de opbouw van de scan wordt door de externe partij gebruik gemaakt van het bedrijfsarchitectuurmodel van Novius. Dit model wordt gebruikt om, aan de hand van vier pijlers (producten en diensten, processen en organisatie, informatievoorziening en informatietechnologie) de onderneming in kaart te brengen. Deze vier
pijlers zijn verder onderverdeeld in verschillende onderwerpen. Het architectuurmodel is hieronder opgenomen in figuur 4.1.
Figuur 4.1: Novius bedrijfsarchitectuurmodel
Op basis van interviews binnen FIETS identificeert de externe partij per onderwerp onderscheidende elementen van FIETS. Deze elementen worden, in overleg met de IT-manager gescoord op 'termijn' en 'prioriteit'. Een hoge score (van 1 tot 3) betekent dat dit element op korte termijn specifieke aandacht kan of moet krijgen. Een hoge score (van 1 tot 3) op prioriteit betekent dat dit element hoge prioriteit heeft. De uiteindelijke score is een vermenigvuldiging van termijn en prioriteit, wat betekent dat de hoogst mogelijke score 9 is. Alle onderdelen met de hoogste score zijn hieronder opgenomen in figuur 4.2.
De beoordeling van de realisatie van de hierboven, in figuur 4.2, beschreven doelstellingen is opgenomen in paragraaf 6.2.
Informatievoorziening en -technologie
De pijlers informatievoorziening en -technologie zijn door de externe partij samengevoegd in één hoofdstuk. Dit hoofdstuk gaat vooral in op informatietechnologie en beschrijft het functioneel beheer, versiebeheer en de ontwikkeling in de toekomst van het bestaande ERP-systeem AW. Conclusie is dat de IT-architectuur van AW verouderd is (“mid 1990”). Om de gewenste functionaliteiten beschikbaar te maken is maatwerk benodigd. Volgens de externe partij gaat de investering hierin naar schatting meer dan € 100.000 gaan kosten. Deze investering zal verloren gaan indien FIETS in de toekomst toch besluit over te stappen op een nieuw ERP-systeem.
Unit4 heeft voor het midden- en grootbedrijf een ERP-productlijn aangekocht door Unit4 "AW2" genoemd. De naamstelling is volgens de externe partij verwarrend, want de IT-architectuur van beide ERP-oplossingen is afwijkend. Voor FIETS betekent dit dat overstappen naar AW2 gelijk staat aan implementatie van een nieuw ERP-systeem. AW2 biedt, ten opzichte van AW, verder de mogelijkheid van E-Commerce via B2C in plaats van de B2B functionaliteit die FIETS wenst.
In januari 2014 wordt, mede op basis van het externe rapport, besloten het bestaande ERP-systeem te vervangen. Belangrijke overwegingen in het besluit tot vervanging zijn:
Ø IT-architectuur van het bestaande ERP-systeem AW is verouderd.
Ø Onvoldoende ontwikkelingen voor de lange termijn (o.a. B2B oplossing); het bestaande ERP-systeem gaat FIETS beperken in zijn activiteiten door marktontwikkelingen.
Selectie nieuw ERP-systeem en implementatiepartner
Met behulp van de externe partij worden de functionele en niet-functionele eisen in kaart gebracht en een longlist van vijf ERP-systemen opgesteld. Dat zijn Oracle, SAP, Microsoft Dynamics AX, Epicor en IFS. De longlist is opgesteld en beoordeeld op basis van een ranglijst van Gartner research, een bedrijf gespecialiseerd in onder andere onderzoek naar IT-research. Gartner biedt een overzicht van ERP-systemen en beoordelingen van gebruikers op de verschillende onderdelen van deze systemen. Op basis van deze gegevens en het advies van de externe partij wordt besloten deze longlist in te korten naar twee systemen: Microsoft Dynamics AX (AX) en SAP. De overige drie ERP-systemen vielen af op functionele eisen binnen het Wharehouse Management System (WMS) of omdat deze geen multi-site oplossing bood. Zes implementatiepartners worden geselecteerd om een Request for Proposal (RFP) uit te zetten, drie partijen voor SAP en drie partijen voor AX.
De RFP bevat in totaal 110 functionele en 71 niet-functionele vereisten vanuit FIETS. De functionele eisen hebben betrekking op de volgende modules: accounting, HRM, inkoop, verkoop, klant en logistiek. Deze eisen zijn verder uitgesplitst naar de verschillende taken. Zo is bijvoorbeeld voor accounting onderscheid gemaakt naar facturatie, grootboek en algemene vereisten binnen accounting. De partijen kunnen in de RFP ten aanzien van de functionele vragen antwoorden met ‘standaard’, ‘configuratie’ of een toelichting te geven. Daarnaast biedt de RFP de partijen de mogelijkheid om aanvullende informatie bij FIETS op te vragen. De niet-functionele eisen hebben betrekking op beveiliging, logging, compliance, support, SLA en architectuur. Voor wat betreft de niet-functionele eisen zijn er zowel gesloten als open vragen. Bij gesloten vragen is alleen een antwoord ‘ja’ of ‘nee’ mogelijk, bij open vragen is een aanvullende toelichting mogelijk. In juli 2014 wordt de RFP aan de partijen verstuurd.
In november 2014 stelt de IT-manager samen met de externe adviseur, in een presentatie aan het Management Team en de product owners (een overzicht van de product owners is opgenomen in figuur 5.2), voor om de selectie nader te richten op AX in plaats van SAP. De argumenten zijn:
Ø Het ERP-systeem AX is zo’n € 80.000 per jaar goedkoper door lagere investering en onderhoudskosten;
Ø AX ligt dichter bij het DNA van FIETS dan SAP. De overgang van AW naar SAP is te groot omdat SAP een (te) groot en 'log' pakket voor FIETS is.
Wel zijn er een aandachtspunten bij de keuze voor AX in plaats van SAP:
Ø Het logistieke onderdeel van AX is relatief nieuw en vormt daardoor een aandachtspunt;
Ø Het implementatietraject van SAP is meer bewezen dan AX.
Er wordt besloten in te stemmen met het voorstel om het selectieproces verder te richten op AX in plaats van SAP. Dit houdt in dat er verder wordt gegaan met de twee implementatiepartners, hierna ‘partij A’ en ‘partij B’, één AX partij is duidelijk onder de maat en valt af. In januari 2015 krijgen beide partijen de gelegenheid om zich, in aparte sessies op de gebieden accounting, logistiek, IT-infrastructuur en verkoop, te presenteren aan de verschillende afdelingen van FIETS. Daarnaast is er een aparte presentatie ten aanzien van projectmanagement. De medewerkers krijgen de opdracht om beide partijen op de volgende drie aspecten te beoordelen: kennis en ervaring, interactie en samenwerking. In totaal zijn er negen aandachtspunten binnen deze categorieën, waarbij voor elk aandachtpunt een voorkeur dient te worden aangeven voor
24
Op twee van de vier gebieden, met uitzondering van logistiek en verkoop, en projectmanagement krijgt partij A de voorkeur boven partij B. Waarbij, op basis van het beoordelingsformulier ("maar bij beide een goed gevoel"), binnen de logistiek een lichte voorkeur is voor partij B. Op basis van de overige criteria zoals ervaring, aantal implementaties in Nederland en aanpak van de implementatie scoort partij B hoger dan partij A. De uiteindelijke doorslag in de keuze tussen beide partijen vindt plaats op basis van gevoel, omdat de beoordelingen geen doorslag hebben gegeven. De aard van FIETS past beter bij partij A. Met partij A worden vervolgstappen gezet om de implementatie in te zetten.
Twee van de product owners (product owner 3 en 4: inkoop O&A en logistiek en inkoop fietsen) zijn samen met de IT-programmamanager en de externe partij intensief betrokken geweest bij het selectieproces. Daarnaast heeft deze externe onafhankelijke partij met verschillende product owners binnen FIETS gesproken.
Uit interviews blijkt dat zowel personen die direct bij het selectieproces betrokken waren, als diegenen die hier verder vanaf stonden, unaniem positief zijn over de uitvoering van de selectie van het ERP-systeem zijn. Volgens hen heeft de selectie grondig en zorgvuldig plaatsgevonden. Het merendeel van de geïnterviewden heeft dan ook ervaring met eerdere ERP implementaties. Volgens één geïnterviewde persoon heeft het selectieproces van een ERP-systeem binnen FIETS niet eerder zó zorgvuldig plaatsgevonden. Deze zorgvuldigheid blijkt mede uit de inhuur van een externe en onafhankelijke adviseur, met bevindingen in een rapportage, en het feit dat er ruim één jaar de tijd is genomen om een ERP-systeem te selecteren. Meerdere personen geven aan dat, mocht een nieuwe ERP implementatie zich voordoen, zij het selectieproces op eenzelfde zorgvuldige wijze zouden willen uitvoeren. In tegenstelling tot de selectie van het ERP-systeem waarbij een selectie van de product owners betrokken was, hebben alle product owners invloed gehad op de keuze van de implementatiepartner, door beoordeling van de presentatie van partij A en B.
Selectie van de implementatiepartner en grondige voorbereiding zijn belangrijke onderdelen die worden genoemd door de product owners als wordt gevraagd naar de ervaring uit eerdere ERP projecten.
“Het pakket is één ding, maar ook degene die het pakket implementeert is belangrijk. … Het pakket wordt niet onderschat, maar de implementatiepartner (bij AW was dat Unit 4) is minstens zo belangrijk”. (geïnterviewde medewerker 4)
Met name binnen één logistieke afdeling hebben zij zich gedurende de selectie en implementatie onvoldoende gehoord gevoeld. Op de vraag wat er bij een nieuwe ERP implementatie anders zou moeten is geantwoord:
“Voordat er een keuze wordt gemaakt meerdere afdelingen erbij betrekken. Ik kan mij niet heugen dat dit heeft plaatsgevonden”. (geïnterviewde medewerker 5)
Een mogelijke verklaring hiervoor is dat de betreffende medewerker key-user was en de belangen van deze afdeling door een product owner die verder van het proces (geen onderdeel afdeling) stond werden waargenomen. Daarnaast is er gedurende de implementatie op deze afdeling zowel geschoven met consultant als product owner.
Strategische keuzes nieuw ERP-systeem
Met de selectie van AX zijn door FIETS de volgende strategische keuzes gemaakt: (I) Flexibiliteit door broncode ERP-systeem, (II) Aansluiting filosofie onderneming en ERP-systeem en (III) Strategische ontwikkelingen in de toekomst.
I. Flexibiliteit door beschikbaarheid broncode van ERP-systeem
De broncode van AW was exclusief beschikbaar voor Unit4, de leverancier van AW. Microsoft, de leverancier van AX, daarentegen werkt met meerdere IT-dienstverleners. Daardoor heeft FIETS zowel meer keuzevrijheid ten aanzien van de IT-dienstverlener, alswel dat FIETS in staat is in eigen beheer ontwikkelingen door te voeren.
“AW was van Unit4 en er waren geen andere partijen. Nu in AX zijn het externe partijen die de mogelijkheid hebben de code van AX aan te passen. Mocht de partij niet bevallen dan kunnen we naar een andere partij. Bij AW waren wij verplicht alles bij Unit4 te doen … in AW moest alles door Unit4 heen… bijvoorbeeld klantgegevens aanpassen, daar heb ik in AX een interface voor gebouwd ”. (geïnterviewde medewerker 6)
“…IT-afdeling kan zelf dingen aanpassen. In Unit4 werd er omheen gewerkt. Daar zie je nog steeds de restanten van. (geïnterviewde medewerker 1)
Hiermee wordt eveneens verwezen naar de (gedeeltelijke) eigen ontwikkeling van B2B-bestelsysteem, zoals beschreven in paragraaf 6.2.
“FIETS in niet meer afhankelijk van de leverancier van het ERP-systeem (“vendor lock-in”). Voor mij zijn de belangrijkste aspecten van het overstappen naar een nieuw ERP-systeem vanuit IT-perspectief: 1) Vendor lock-in: Unit4 heeft alles in eigen hand. 2) Niet voldoende visie: AW voor het kleinbedrijf en AW2 voor het midden- en grootbedrijf. 3) Gesloten systeem: niet makkelijk aan te sluiten op andere systeem 5) Verouderede techniek: two
26 II. Aansluiting filosofie
De filosofie van het ERP-systeem heeft meegespeeld in de overweging tussen tussen SAP en AX. Kernwaarden van FIETS zijn: betrokken, betrouwbaar en dynamisch. Vooral het onderdeel ‘dynamisch’ was hierbij van invloed:
“Een van de redenen in keuze voor AX, maar niet voor SAP is dat SAP steeds groter en dus complexer wordt. Microsoft neemt afscheid van oude functionaliteit. Dit past bij FIETS door mee te gaan met de markt en niet vast te houden aan het oude. En heeft invloed op de complexiteit van het ERP-systeem.” (geïnterviewde medewerker 1)
III. Strategische ontwikkelingen
Als wordt gevraagd naar de toekomstige ontwikkeling van FIETS en de ondersteuning van het ERP-systeem dan geeft men het volgende antwoord:
“Steeds meer met leveranciers en klanten in verbinding staan. Ik zie FIETS in de ideale wereld als een soort vertaalbureau. Wij vertalen de data uit de markt naar vraag naar klanten en leveranciers en vertalen dat terug. Ik zie ons écht als een hub in het midden. Het moet makkelijk zijn om aan- en uit te schakelen. In AW was dat niet mogelijk”. (geïnterviewde medewerker 4)
En ten aanzien van processen binnen FIETS:
“De geautomatiseerde groothandel worden. Van bestelling tot levering helemaal geautomatiseerd. Een geautomatiseerd proces waar geen mensen meer voor nodig zijn.” (geïnterviewde medewerker 1)
Vorming projectteam en keuze implementatiemethode
Nadat de implementatiepartner is geselecteerd wordt in het Management Team besloten een projectteam te vormen bestaande uit een zestal product owners, een overzicht is opgenomen in figuur 4.3. De product owners hebben over het algemeen mensen op de werkvloer en hebben een leidinggevende functie binnen een functioneel gebied. De IT-manager krijgt de leiding over het projectteam.
Als implementatiemethode kiest FIETS in samenspraak met partner A voor Agile scrum. Een methodiek die het mogelijk maakt in kort cyclische stappen van maximaal drie weken te ontwikkelen. De methodiek is specifiek gericht op het ontwikkelen, opleveren en behouden van complexe producten (Schwaber & Sutherland, 2017).
Bij het werken volgens deze methode wordt een ‘scrum team’ gevormd bestaande uit teamleden met verschillende rollen: de product owner, het ontwikkelteam en de scrum master. De rol van de product owner is om maximaal gebruik te maken van de kennis van het ontwikkelteam en prioriteiten te bepalen. Het ontwikkelteam bestaat uit verschillende disciplines binnen het functioneel gebied, die in deze korte stappen de wensen aanleveren en testen. De scrum master in dienst bij partij A, is specialist in de scrum methodiek en begeleidt het team in het ontwikkelproces. De kort cyclische stappen, genaamd ‘sprints’, eindigen met een ‘sprint review’ waarin het resultaat met het gehele team wordt doorgenomen. Door kort cyclische stappen, focus en toewijding van het team kunnen complexe producten worden opgeleverd.
Conclusie conceptfase
Geconcludeerd kan worden dat de keuze voor AX aansluit op de strategische visie van FIETS. Met name de flexibiliteit van het systeem, omdat de broncode beschikbaar is en de filosofie van de leverancier van het ERP-systeem sluiten aan bij de IT-strategie van FIETS. Verder is in de keuze voor AX rekening gehouden met toekomstige ontwikkelingen, zoals verregaande communicatie tussen FIETS en klanten of leveranciers van FIETS.
De keuze van FIETS voor het ERP-systeem AX, een minder omvangrijk systeem dan SAP, komt overeen met onderzoek van Bernroider & Koch (2001) dat MKB-ondernemingen andere ERP-systemen kiezen. In tegenstelling tot dit onderzoek kent FIETS wel een hoge waarde toe aan het kenmerk flexibiliteit in het ERP-systeem. Mogelijk door kenmerken van het vervangen ERP-systeem AW, wat door diverse geïnterviewden als ‘star’ wordt getypeerd. In het besluitvormingsproces tot vervanging en selectie van het ERP-systeem is door FIETS gebruik gemaakt van het type waarbij sterke focus is vanuit de IT-afdeling met beperkte betrokkenheid van interne afdelingen, deze vorm komt overeen met het merendeel van de MKB ondernemingen (Bernroider & Koch, 2001).
4.3 Implementatiefase
De implementatiefase is de fase die volgt op de conceptfase (paragraaf 4.2) en is onderverdeeld in de onderdelen projectmanagement, change management en training en instructie. Aan het eind
Projectmanagement
Voor het onderdeel projectmanagement wordt onderscheid gemaakt tussen intern (binnen FIETS) en extern projectmanagement (door partner A).
Intern projectmanagement
Het interne projectteam wordt geleid door de programmamanager en bestaat uit product owners en key-users van de verschillende afdelingen binnen FIETS. De verantwoordelijkheid van de product owner is realisatie van functionaliteit in het ERP-systeem binnen zijn of haar functioneel gebied. De rol van de programmamanager is het beheersen van het projectteam, ondersteuning van de product owners en communicatie en afstemming met de implementatiepartner.
Allereerst worden de eisen en wensen van de product owners besproken met de consultants en volgens de scrum methodiek vastgelegd in zogenoemde 'stories'. De prioriteiten worden toegewezen en er wordt een inschatting gemaakt van de tijdsduur. In deze fase wordt duidelijk dat niet alle eisen en wensen gerealiseerd kunnen worden, dit heeft de volgende oorzaken:
• Realisatie niet mogelijk voor geplande ‘live’ datum 1 januari 2016 en gestelde budget;
• Niet alle processen zijn voldoende uitgewerkt. De wensen van de product owners zullen beter in kaart moeten worden gebracht.
In aparte sessies per functioneel gebied, worden de functionaliteiten door de consultant gepresenteerd aan de key-users en product owners. In november 2015 is de inrichting van de basisfunctionaliteit afgerond en kan worden begonnen met testen van deze functionaliteit. Ieder functioneel gebied heeft testscripts voorbereid, hiermee worden verschillende scenario’s getest. Indien er een functionaliteit niet voldoet of er fouten ontstaan wordt er een ‘issue’ op Microsoft SharePoint aangemaakt. De ontwikkelaars en consultants handelen op basis van prioriteit deze issues af. Indien deze wordt opgelost door partij A krijgt het issue de status ‘testen’. Nadat deze akkoord is bevonden door FIETS wijzigt deze status naar ‘getest, opgelost’. In het gehele traject, inclusief livegang, zijn ruim 860 issues aangemaakt.
Twee wekelijks vindt er met het projectteam inclusief key-users een update plaats van de status van de issues. In de daaropvolgende weken blijkt dat met name in de logistiek het Warehouse Management System (WMS) en de afdeling service en garantie een livegang tegen te houden. Het WMS is een relatief nieuw onderdeel binnen AX, dit is onderkend als aandachtspunt bij de presentatie aan het Management Team in november 2014. Daarnaast is er
binnen de logistiek een consultant op de opdracht geplaatst die niet functioneert. Deze consultant levert niet de juiste functionaliteit op. Lange tijd is dit voor zowel FIETS als partij A niet bekend. Dit wordt met name veroorzaakt doordat het WMS onderdeel relatief nieuw is binnen AX. Tezamen met partij A wordt besloten deze consultant te verwijderen van de opdracht.
Er wordt besloten om de geplande datum 1 januari 2016 van livegang op te schuiven naar eind maart 2016. Maart 2016 is een cruciaal moment, want vanaf deze maand start het traditionele hoogseizoen. In de periode naar maart 2016 blijken te veel onzekerheden waardoor mede door het aankomende seizoen, wordt besloten om de livegang te verplaatsen naar oktober 2016. AX gaat op 28 oktober 2016 live. In totaal heeft de implementatie ruim 1,5 jaar geduurd. Het gehele implementatietraject, zoals hierboven beschreven, is hieronder schematisch
weergegeven in figuur 4.4.
De ervaring van meerdere geïnterviewden is dat de projectomvang is onderschat en te ambitieus is geweest.
“Ik heb de projectomvang onderschat: de tijd en energie om mensen met de juiste dingen bezig te laten houden en te laten doen… Ik ging ervan uit dat mensen vanzelf enthousiast zouden worden over het pakket.” (geïnterviewde medewerker 1)
“… Best intensief, tegengevallen. Zeker omdat het selectietraject heel zorgvuldig heeft plaatsgevonden. (geïnterviewde medewerker 4)
“… De tijdsplanning van het project was te ambitieus. In eerste instantie moest het in negen maanden gebeuren. (geïnterviewde medewerker 6)
De programmamanager communiceerde maar niet op structurele basis over voortgang en eventuele knelpunten met de algemeen directeur. De algemeen directeur had geen actieve rol in het projectteam, een rol die bij scrum methodiek wel is overeengekomen: de stakeholder.
30 “… Geen actieve rol. Ik heb veel gevraagd naar de status bij mensen die betrokken waren. Ik werd geïnformeerd en vroeg over de voortgang bij de programmamanager. … Soms moesten er keuzes worden gemaakt, hier was ik bij betrokken. Terugkijkend vond ik mijn rol hierin lastig. Als ik nu kijk naar mij rol bij het bestelsysteem daar is mijn rol veel gestructureerder als stakeholder.”
Mede door de problemen binnen de logistieke afdeling, met betrekking tot de WMS module, en ambitieuze planning is de livegang een aantal malen uitgesteld. De programmamanager geeft aan dat door de omvang van het project deze inhoudelijk bijna niet meer te managen was, ook door discussies met de implementatiepartner (zie ‘extern projectmanagement’).
Terugkijkend op het gehele implementatieproces zijn de verantwoordelijkheden volgens meerdere gesproken personen té diep in de organisatie gelegd.
“Ik denk dat wij de inhoud te diep in de organisatie hebben gelegd. Waardoor er dingen zijn gemaakt die achteraf niet meer worden gebruikt. Er is gekeken naar dingen die beter moesten, maar hierbij zijn we vergeten te kijken naar dingen die we al deden. De product owners lagen te diep in de organisatie, managers onvoldoende betrokken. Deze managers van de product owners hadden meer betrokken moeten zijn.” (geïnterviewde medewerker 1)
Volgens betrokkenen heeft de cultuuromslag binnen FIETS hierbij ook een rol in gespeeld.
“Werken met product owners vraagt een andere aanpak. Een cultuuromslag die misschien wel is onderschat. Vroeger vertelde de IT-afdeling de medewerkers hoe het moest. Nu moesten afdelingen zelf processen gaan beschrijven. Daar werd vervolgens het programma op ingeregeld. Mensen (red: op de afdelingen) moesten dus meer verantwoordelijkheden nemen, het werd in feite dus meer gedragen door de business.” (geïnterviewde medewerker 4)
En er was tijdens de implementatie duidelijk verschil zichtbaar tussen een aantal afdelingen:
“Veel verschil per afdeling. Zo is de kennis op afdeling X hoog, heeft veel kennis, maak je niks wijs. Terwijl binnen een andere afdeling de kennis beperkt is… Voor mijn gevoel is een trucje geleerd. Door IT is een werkwijze bedacht en tegen deze afdeling is gezegd hoe ze moeten gaan werken … Onvoldoende invloed, maar ook met het niveau van deze afdeling.” (geïnterviewde medewerker 8)
Deze afdeling zelf heeft zich vooral onvoldoende gehoord gevonden.
"Heel moeizaam gegaan. Voor onze afdeling in het begin al helemaal fout gegaan: op moment dat de stories werden aangemaakt. Wij hadden het idee dat wij niet gehoord werden door de consultant. Wij willen het zo hebben, probeer dat zo in te regelen. Wij hadden het idee dat hij er meer voor andere afdelingen was. Wij moesten maar werken op de manier zoals hij dat bedacht had." (geïnterviewde medewerker 5)
“Je hebt toewijding nodig. Daar komt de beschikbaarheid en tijd bij kijken. En dat is niet altijd in acht genomen bij de implementatie van AX. Voorbeelden zijn: Dagelijkse stand-ups zijn van de baan geraakt, bij elkaar zitten, vaste blokkentijden: die werden door partij A wel gehanteerd. Heel veel mensen waren er gewoon niet.” (geïnterviewde medewerker 6)
Op de vraag aan een andere persoon of dit haalbaar is:
“De complexiteit zit wel in de tijd om beschikbaar te zijn om dingen te doen. Als je het nog een keer doet, dan zou je focus moeten hebben op het systeem. Niet op andere projecten die daarnaast lopen. Als organisatie de keuze maken dat dit de belangrijkste is voor dat jaar.” (geïnterviewde medewerker 7)
“En waar we niet van hebben geleerd zijn de hoeveelheid van projecten met wat we aanpakken.” (geïnterviewde medewerker 2)
Samengevat kan worden dat ten aanzien van het interne projectmanagement de omvang in tijd en om mensen gemotiveerd te houden, van het ERP project is onderschat. Hoewel in de scrum methodiek een rol is weggelegd voor de stakeholder, was er gedurende het ERP project bij FIETS geen formele structuur met betrekking tot ondersteuning vanuit het management. Naast de door geïnterviewden onderkende cultuurverandering is ook het kennisniveau (of het ontbreken daarvan) van invloed geweest op het ERP project. Volgens sommige geïnterviewden zijn de verantwoordelijkheden in het project te diep in de organisatie gelegd.
Extern projectmanagement
Onder het externe projectmanagement wordt de aansturing door de implementatiepartner partij A verstaan. De geïnterviewden zijn onverdeeld negatief tot zeer negatief betrekking hebbend op (I) aansturing en communicatie door de externe projectleider, (III) onvoldoende kennis bij de consultants en (III) toepassing van de scrummethodiek.
I. Aansturing en communicatie
De consultants van de implementatiepartner, partner A, werden aangestuurd door een projectmanager. In totaal bestond het team van partner A uit zes consultants, met ieder zijn eigen werkgebied. Een aantal consultants had de verantwoordelijkheid over meerdere modules in AX.
Gedurende het project na circa 8 of 9 maanden, is in overleg tussen FIETS en implementatiepartner besloten te wisselen van projectmanager.
32 consultants beschikbaar waren. De WMS consultant was bijvoorbeeld 3 maanden niet beschikbaar. Voor mijn gevoel liet hij binnen partner A over zich heenlopen in de planning van consultants op andere opdrachten.” (geïnterviewde medewerker 1)
Partner A werd niet als zodanig, als 'partner', ervaren.
“Niet als een goede partner ervaren. … Het eerste wat mij te binnen schiet is de pyramide van Lencioni (red: een managementmodel om teamwork te beschrijven). De eerste fase, vertrouwen, ontbrak echt hierin. Er moest heel veel geweld plaatsvinden voordat je het voor elkaar had om een gesprek te krijgen. Niet op een constructieve manier…. Minder gezamenlijk aan een project werken.” (geïnterviewde medewerker 4)
Een andere geïnterviewde persoon is het hier mee eens:
“Logistiek (red: consultant) was waardeloos, inkoop zijn wij gewisseld van consultant. Zegt genoeg dat je geswitched bent van projectleider.” (geïnterviewde medewerker 3)
II. Onvoldoende kennis
Deze consultant verantwoordelijk voor de relatief nieuwe module in AX WMS bleek niet te functioneren.
“Pech gehad met de eerste consultant. Aan de voorkant zijn wij de enige partij geweest die voor partij B koos. Deze consultant snapte ons verhaal. Bij partij A verkochten zij een praatje, waar wij zijn ingetrapt.” (geïnterviewde medewerker 8)
Na een periode van drie of vier maanden kwamen de eerste indicaties. Door FIETS en partner A vond hierover meermaals overleg plaats. Na een periode van circa zes maanden is besloten deze consultant te vervangen. Achteraf bleek deze consultant ook het vorige ERP project niet succesvol te hebben afgerond.
“Vanaf het begin vonden we hem teveel babbels hebben. Na 3 à 4 maanden kwamen de eerste indicaties. Verdere ervaring met partij A: ik heb het gevoel dat wij momenteel op hetzelfde kennisniveau zitten. Het advies van partij A binnen onze module kost nu veel tijd en geld. (geïnterviewde medewerker 8)
“Laat doorgekregen dat sommige consultants niet functioneerden. Zelf niet goed gezien of door rookwolken. Dat heeft de boel enorm gefrustreerd. (geïnterviewde medewerker 4)
“Achteraf bleek dat de betreffende consultant op een ander project dezelfde problemen heeft veroorzaakt en dit dus bij partner A bekend was.” (geïnterviewde medewerker 1)
III. Scrum methodiek
Uitvoering door middel van de scrum methodiek is één van de doorslaggevende factoren geweest bij de keuze van de implementatiepartner.
“Juist de scrum methodiek, de manier van werken, was belangrijk in de keuze voor partner A.” (geïnterviewde medewerker 4)
Voorafgaande aan de implementatie hebben de product owners een basistraining van één middag gehad over de scrum methode. In de praktijk tijdens de implementatie blijkt deze methodiek niet of onvoldoende te zijn gehanteerd. Er zijn volgens de product owners en gebruikers verschillende oorzaken aan te wijzen waardoor deze methodiek niet van de grond is gekomen:
I. De scrum master vanuit de implementatiepartner was niet senior genoeg. Zij is op een gegeven moment teruggetrokken;
II. Gevoel is dat deze methodiek onvoldoende vanuit de consultants van de implementatiepartner werd gedragen;
III. Het belang van de vaste meetmomenten, blokkentijd en aanwezigheid werd door de product owners en key-users onvoldoende erkend. Product owners kwamen bij deze vaste momenten niet en gaven prioriteit aan andere werkzaamheden.
Er is onder de geïnterviewden geen overeenstemming over het al dan wel uitvoeren van een eventueel vervolg ERP project middels deze methodiek. Voor de één is een ERP project te complex om deze methodiek te gebruiken. Een van de doelen van scrum is om een korte periode te evalueren welke functionaliteit de meeste waarde toevoegt voor FIETS. De kennisachterstand tussen gebruiker en consultants maakt dat deze gesprekken niet op eenzelfde niveau konden plaatsvinden. Voor de gebruikers is dus niet te bepalen of de wensen standaard zijn te realiseren in het ERP-systeem.
De transitie, zoals beschreven onder het kopje ‘intern projectmanagement’, van een onderneming waarin de IT afdeling bepaalt naar verantwoordelijkheden die door de business worden gedragen heeft hierin niet bijgedragen.
“Inherent aan de methodiek hebben de eindgebruikers de stories opgesteld. Op die manier wordt een pakket opgesteld hoe de gebruikers gewend zijn het pakket te gebruiken, dus zoals men in AW gewend was. Dat is inherent aan deze projectmethodiek. Wij hebben niet gezien hoe het pakket standaard werkt. Of dat aan de methodiek ligt of aan de consultants zelf weet ik niet. Die hebben niet naar aanleiding van de wensen eerst
34 kritisch gekeken of dit ook binnen de standaard mogelijk was. Wensen zijn niet beoordeeld voordat deze in ontwikkeling is gekomen. Key-users bepaalden de wensen.” (geïnterviewde medewerker 6)
Volgens één van de werknemers werd het gebruik van de scrum methodiek door de implementatiepartner zelfs gebruikt om geen ‘harde afspraken’ te maken over functionaliteit van het ERP-systeem. Dit heeft er mede voor gezorgd dat er veel discussie is geweest over kosten en werkzaamheden die zijn uitgevoerd door de implementatiepartner.
“Scrum is leuke naam, maar in de praktijk is hier weinig invulling aan gegeven. Als ik zie hoe dat bij andere scrum projecten loopt ... Scrum was voor de implementatiepartner een excuus om geen harde afspraken te maken over functionaliteit. Hierdoor lag niet alle functionaliteit met de implementatiepartner vast. Hier hebben wij flinke discussies over gehad. Maar hiervoor hadden wij terug moeten krijgen: zijn we met de juiste dingen bezig? Is het de tijd en geld waard? Deze kort cyclische stappen zijn er niet geweest.” (geïnterviewde medewerker 1)
Samengevat kan worden dat ten aanzien van het externe projectmanagement zowel wisseling van projectmanager als consultant van invloed zijn geweest op het ERP project. De hierbij horende scrum methodiek, wat voor FIETS een belangrijke rol speelde in de selectie van implementatiepartner, is zeer beperkt gehanteerd in het ERP project.
Conclusie projectmanagement
Geconcludeerd kan worden over zowel het interne als externe projectmanagement als de implementatiemethode scrum dat managementbetrokkenheid, kennis van consultants en projectmanagement een grote rol spelen bij de MKB-onderneming. Mede door discussies over het niet functioneren van consultants, beschikbaarheid van consultants en externe projectmanagement is capaciteit verloren gegaan op het beheersen van het project binnen FIETS en is het project vertraagd. Gezien de complexiteit van ERP projecten is de vraag of de scrum methodiek een geschikte methode is. Omdat deze methode zeer beperkt is gehanteerd door zowel FIETS als partner A kan in deze case study over het gebruik van scrum methodiek in ERP projecten geen goede conclusie worden gevormd.
Change management
Verandermanagement heeft betrekking op wijzigingen ten aanzien van werkzaamheden, optimalisatie van processen veranderingen in de organisatie.
Wijzigingen werkzaamheden
Opvallend is dat een meerderheid (78,7%, figuur 4.5) van de geënquêteerden aangeeft dat zijn of haar werkzaamheden inhoudelijk niet zijn veranderd. Van degene die deze vraag positief hebben
