Onderzoek naar de determinanten voor een succesvolle implementatie van een ERP-systeem

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2006 - 2007

Onderzoek naar de determinanten voor een succesvolle implementatie van een ERP-systeem

Scriptie voorgedragen tot het bekomen van de graad van licentiaat in de Toegepaste Economische Wetenschappen

Tim Vermeersch Onder leiding van Prof. Dr. R. Paemeleire

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2006 - 2007

Onderzoek naar de determinanten voor een succesvolle implementatie van een ERP-systeem

Scriptie voorgedragen tot het bekomen van de graad van licentiaat in de Toegepaste Economische Wetenschappen

Tim Vermeersch Onder leiding van Prof. Dr. R. Paemeleire

PERMISSION

Tim Vermeersch

Woord vooraf

WOORD VOORAF

Het schrijven van een licentiaatverhandeling als bekroning van een vier jaar durende studie is een boeiende, doch moeilijke opgave. Langs deze weg zou ik graag een aantal personen willen bedanken die me hebben bijgestaan tijdens het schrijven van mijn thesis. In eerste instantie dient een speciaal dankwoord gericht te worden tot mijn promotor Prof. Dr. Paemeleire voor de vakkundige begeleiding. Vervolgens wil ik eveneens Frederik Gailly bedanken voor de nuttige tips en kritische opmerkingen die mij in de goede richting stuurden. Bovendien mag de Universiteit Gent niet vergeten worden die mij door het statuut student-topsporter de kans bood ook mijn sportieve carrière verder uit te bouwen tijdens mijn studies. Voorts wens ik dank te betuigen aan degene die mijn scriptie nagelezen hebben om mogelijke taalfouten op te sporen. Tevens wens ik de heer Luc Verschraegen en de heer Piet de Geest te bedanken voor hun tijd en bijdrage die ze geleverd hebben aan deze scriptie. Niet in het minst gaat mijn dank uit naar mijn ouders die me toelieten deze studies te vervolmaken. Tim Vermeersch Ruddervoorde, 2 mei 2007

-I-

Tim Vermeersch

Inhoudsopgave

INHOUDSOPGAVE

WOORD VOORAF..................................................................................................................................................... I INHOUDSOPGAVE ..................................................................................................................................................II GEBRUIKTE AFKORTINGEN...............................................................................................................................V LIJST VAN TABELLEN EN FIGUREN............................................................................................................... VI

INLEIDING .................................................................................................................................................................1

HOOFDSTUK 1:

WAT IS ERP? ...........................................................................................................................3

1.1

Inleiding .......................................................................................................................................... 3

1.2

ERP gedefinieerd ........................................................................................................................... 3

1.3

De evolutie van ERP-systemen...................................................................................................... 6

1.3.1

Geschiedenis..........................................................................................................................................6

1.3.2

Toekomst................................................................................................................................................8

1.4

Karakteristieken van een ERP-systeem....................................................................................... 10

1.4.1

Modulair ..............................................................................................................................................10

1.4.2

Eén database .......................................................................................................................................11

1.4.3

Best practice ........................................................................................................................................12

1.4.4

Configuratie.........................................................................................................................................12

1.5

Implementatiestrategieën ............................................................................................................. 13

1.5.1

Stap voor stap ......................................................................................................................................13

1.5.2

Big bang...............................................................................................................................................13

1.5.3

Uitrollen ..............................................................................................................................................14

1.6

Voordelen ERP............................................................................................................................. 14

1.7

De ERP-markt .............................................................................................................................. 15

1.8

Besluit........................................................................................................................................... 16

HOOFDSTUK 2:

SELECTIE EN IMPLEMENTATIE VAN EEN ERP-SYSTEEM ....................................18

2.1

Inleiding ........................................................................................................................................ 18

2.2

De selectie van een ERP-systeem............................................................................................... 19

2.2.1

Het AHP selectiemodel ........................................................................................................................19

2.2.2

Verschillen in het selectieproces tussen kmo’s en grote ondernemingen ............................................22

2.3

De implementatie van een ERP-systeem .................................................................................... 23

- II -

Tim Vermeersch

Inhoudsopgave

2.3.1

De implementatiekost ..........................................................................................................................23

2.3.2

Het 5-fasen model van Ross en Vitale .................................................................................................24

2.3.3

De Process-theorie van Markus en Tanis............................................................................................26

2.3.4

Het Project Phase Model.....................................................................................................................30

2.3.5

Het 6-fasen model van Cooper en Zmud .............................................................................................32

2.3.6

Samenvattend implementatiemodel......................................................................................................34

2.4

Wanneer is de implementatie een succes? ................................................................................. 37

2.4.1

Het DeLone en McLean informatiesysteem succes model ...................................................................39

2.4.2

De balanced scorecard ........................................................................................................................41

2.5

Besluit........................................................................................................................................... 45

HOOFDSTUK 3:

KRITIEKE SUCCESFACTOREN .......................................................................................46

3.1

Inleiding ........................................................................................................................................ 46

3.2

Algemeen overzicht kritieke succesfactoren ................................................................................ 46

3.2.1

Organisatie ..........................................................................................................................................47

3.2.2

Gebruiker.............................................................................................................................................54

3.2.3

Systeem ................................................................................................................................................55

3.2.4

Verkoper ..............................................................................................................................................57

3.3

Samenvatting kritieke succesfactoren per auteur ........................................................................ 58

3.4

Besluit........................................................................................................................................... 61

HOOFDSTUK 4:

KRITIEKE SUCCESFACTOREN AFHANKELIJK VAN DE FASE IN DE

IMPLEMENTATIE ..................................................................................................................................................62 4.1

Inleiding ........................................................................................................................................ 62

4.2

Kritieke succesfactoren tijdens de Process-theorie ..................................................................... 62

4.2.1

Project chartering fase ........................................................................................................................63

4.2.2

Project fase..........................................................................................................................................63

4.2.3

Shakedown fase ...................................................................................................................................64

4.2.4

Onward en upward fase.......................................................................................................................65

4.2.5

Overzicht..............................................................................................................................................65

4.2.6

Kritiek op de process theorie...............................................................................................................66

4.3

Kritieke succesfactoren tijdens het Project Phase Model ............................................................ 66

4.4

Kritieke succesfactoren tijdens het 6-fasen model van Cooper en Zmud.................................... 67

4.5

Kritieke succesfactoren tijdens het samenvattende model .......................................................... 69

4.6

Besluit........................................................................................................................................... 71

- III -

Tim Vermeersch

HOOFDSTUK 5:

Inhoudsopgave

PRAKTIJKONDERZOEK NAAR DE DETERMINANTEN VOOR EEN

SUCCESVOLLE IMPLEMENTATIE VAN EEN ERP-SYSTEEM....................................................................72 5.1

Inleiding ........................................................................................................................................ 72

5.2

Doel van het onderzoek ............................................................................................................... 72

5.3

Keuze en voorstelling van de onderneming ................................................................................. 73

5.4

Onderzoeksmethodiek ................................................................................................................. 74

5.5

De implementatie van SAP HR bij de UGent ............................................................................... 76

5.5.1

Het implementatieproces .....................................................................................................................76

5.5.2

Kritieke succesfactoren tijdens de implementatie................................................................................77

5.5.2.1

Algemene factoren ........................................................................................................................................... 77

5.5.2.2

Selectie............................................................................................................................................................. 79

5.5.2.3

Implementatieteam........................................................................................................................................... 81

5.5.2.4

Implementatie .................................................................................................................................................. 82

5.5.2.5

Gewenning & Routine ..................................................................................................................................... 82

5.5.2.6

Continuous improvement ................................................................................................................................. 83

5.5.3

Het meten van succes...........................................................................................................................83

5.6

Onderzoeksresultaten .................................................................................................................. 84

5.7

Besluit........................................................................................................................................... 86

ALGEMEEN BESLUIT ...........................................................................................................................................87

LIJST VAN GERAADPLEEGDE WERKEN ......................................................................................................VII

BIJLAGEN .............................................................................................................................................................. 1-1 Bijlage 1

SAP HR module .......................................................................................................................................1-1

Bijlage 2

Projectplanning van de implementatie van SAP HR aan de UGent..........................................................2-1

- IV -

Tim Vermeersch

Gebruikte afkortingen

GEBRUIKTE AFKORTINGEN

AFKORTING

BETEKENIS

AHP

Analytic Hierarchy Process

ATP

Administratief en Technisch Personeel

BPR

Business Process Reengineering

CRM

Customer Relationship Management

CSF

Critical Success Factor

DCF

Discounted Cash Flow

ERP

Enterprise Resource Planning

HR

Human Resources

HRM

Human Resource Management

IS

Informatie Systeem, Information System

IT

Information Technology

KMO

Kleine of Middelgrote Onderneming

MPS

Master Production Schedule

MRP

Material Requirements Planning

MRP II

Manufacturing Resource Planning

PPM

Project Phase Model

ROI

Return On Investment

SAP

Systeme,

Anwendungen,

Produkte

Datenverarbeitung SCM

Supply Chain Management

UGent

Universiteit Gent

ZAP

Zelfstandig Academisch Personeel

-V-

in

der

Tim Vermeersch

Lijst van tabellen en figuren

LIJST VAN TABELLEN EN FIGUREN

TABELLEN Tabel 1

De verschillen tussen ERP en ERP II........................................................................................ 9

Tabel 2

Mogelijke voordelen van ERP-systemen................................................................................. 14

Tabel 3

Marktaandeel van de 5 grootste ERP-verkopers .................................................................... 16

Tabel 4

Aandeel van de verschillende implementatiekosten ............................................................... 24

Tabel 5

ERP balanced scorecard ......................................................................................................... 44

Tabel 6

Algemeen overzicht kritieke succesfactoren ........................................................................... 46

Tabel 7

Geciteerde kritieke succesfactoren per auteur ........................................................................ 59

Tabel 8

Kritieke succesfactoren tijdens de Process-theorie................................................................. 65

Tabel 9

Kritieke succesfactoren tijdens het project phase model ........................................................ 67

Tabel 10

Kritieke succesfactoren tijdens het 6-fasen model van Cooper en Zmud ............................ 67

Tabel 11

Succes relatief ten opzicht van de doelstellingen ................................................................. 84

FIGUREN Figuur 1

De evolutie van ERP................................................................................................................... 8

Figuur 2

De recente ontwikkelingen van ERP-systemen.......................................................................... 9

Figuur 3

De architectuur van een ERP-systeem .................................................................................... 12

Figuur 4

Voorbeeld hiërarchie fundamentele doelstellingen .................................................................. 21

Figuur 5

Het 5-fasen model van Ross en Vitale ..................................................................................... 25

Figuur 6

Het 4-fasen model van Markus en Tanis.................................................................................. 27

Figuur 7

Het Project Phase Model .......................................................................................................... 30

Figuur 8

Het 6-fasen model van Cooper en Zmud ................................................................................. 32

Figuur 9

Samenvattend implementatiemodel ......................................................................................... 35

Figuur 10

De structuur van het volledige implementatieteam ............................................................... 36

Figuur 11

De 6 dimensies van succes .................................................................................................. 39

Figuur 12

Het nieuwe IS succesmodel van DeLone en McLean .......................................................... 41

Figuur 13

De 4 dimensies van BPR ...................................................................................................... 52

Figuur 14

Kritieke succesfactoren tijdens het samenvattende model................................................... 70

Figuur 15

Het HR implementatieproces bij de UGent ........................................................................... 77

- VI -

Tim Vermeersch

Inleiding

INLEIDING

Enterprise resource planning is niet meer weg te denken uit de hedendaagse onderneming. Zowel kleine als grote ondernemingen hebben de weg naar ERP gevonden. Perfecte integratie van alle informatie doorheen de onderneming is vandaag de dag dan ook erg belangrijk in een markt vol onzekerheden. Het grootste obstakel is echter erg vaak de implementatie. Dit is dan ook meten het onderwerp van deze eindverhandeling. Bedoeling is een aantal factoren te ontdekken die de kans op een succesvolle implementatie verhogen. Een belangrijke opmerking vooraf is dat deze thesis zich beperkt tot de implementatie van het ERPsysteem. De technologie die aan de basis ligt van deze systemen wordt niet uitgediept. Vooraleer over te gaan tot de eigenlijke theorie, wordt hieronder eerst een korte uiteenzetting gemaakt over de wijze waarop deze scriptie aangepakt wordt. Deze scriptie bestaat uit twee delen. Het eerste deel, bestaande uit vier hoofdstukken, is een grondige literatuurstudie over de implementatie van een ERP-systeem. Het doel hiervan is een algemeen implementatiemodel te ontwikkelen waarin de determinanten voor een succesvolle implementatie weergegeven worden. In het tweede deel, hoofdstuk 5, volgt een empirisch onderzoek naar de determinanten voor een succesvolle implementatie. De bedoeling is het model aan de hand van een case study verder te verfijnen. Het eerste hoofdstuk is eerder een inleidend hoofdstuk. Hierin wordt uit de doeken gedaan wat een ERPsysteem precies is en hoe het werkt. Voorts wordt de evolutie besproken en wordt een eerste maal over de implementatie zelf gesproken. Er worden namelijk een aantal implementatiestrategieën overlopen. In het tweede hoofdstuk wordt dan dieper ingegaan op de selectie en implementatie van een ERPsysteem. Er wordt gestart met een selectiemodel zodat een onderneming het best passende systeem kan aankopen. Daarna worden een aantal implementatiemodellen overlopen. Elk model legt specifieke klemtonen en heeft zijn goede en minder goede punten. Daarom wordt een samenvattend model voorgesteld dat met deze zaken rekening houdt. Dit model is noodzakelijk om dan in een later hoofdstuk de determinanten voor een succesvolle implementatie te kunnen weergeven. Het laatste onderdeel in dit hoofdstuk geeft een tweetal methodes om succes te meten. Er zal blijken dat “een succesvolle implementatie” geen eenduidig begrip is. Hoofdstuk drie geeft een samenvatting van de kritieke succesfactoren die in de literatuur te vinden zijn. Ze worden ingedeeld naar de organisatie, de gebruiker, het systeem en de verkoper. Een overzichtelijke tabel op het einde van dit hoofdstuk geeft dan een duidelijk overzicht van de kritieke factoren per auteur.

-1-

Tim Vermeersch

Inleiding

Hoofdstuk twee en drie worden als het ware samengevoegd in hoofdstuk 4. De verschillende implementatiemodellen worden gecombineerd met de kritieke succesfactoren. Uiteindelijk wordt een model ontwikkeld dat het implementatieproces weergeeft met bijhorende kritieke succesfactoren. In hoofdstuk vijf wordt het empirisch onderzoek besproken. Daarin wordt eerst de methodologie en de onderzoeksopzet uit de doeken gedaan. Er werd geopteerd om een exploratief en kwalitatief onderzoek uit te voeren aan de hand van een case study. Een belangrijke beperking hierbij is dat enkel inzichten kunnen verworven worden en geen conclusies. Bedoeling is het implementatiemodel verder te verfijnen. Zodoende is verder onderzoek in dit domein noodzakelijk. Ten slotte worden de resultaten en interpretaties van de gegevens van het empirisch onderzoek besproken. Voor de literatuurstudie werden zowel handboeken, internetbronnen als wetenschappelijke artikels gebruikt. De voorkeur werd gegeven aan de vakliteratuur uit wetenschappelijke tijdschriften.

-2-

Tim Vermeersch

Hoofdstuk 1: Wat is ERP?

Hoofdstuk 1: WAT IS ERP?

1.1

INLEIDING

De doelstellingen van dit inleidende hoofdstuk zijn tweeërlei. Enerzijds is het de bedoeling de lezer een globaal beeld te geven over de werking van ERP-systemen. Dit is noodzakelijk om in een later hoofdstuk de verschillende stappen in de implementatie en de belangrijkste determinanten voor succes goed te begrijpen. De andere intentie die dit hoofdstuk heeft, is trachten duidelijk te maken dat een ERP-systeem veel meer is dan een gewoon softwareprogramma. Meer op het vlak van grootte, functionaliteit, complexiteit, database… Door dit aan te tonen wordt gerechtvaardigd waarom een implementatiemodel voor een normaal informatiesysteem niet volstaat bij de implementatie van een ERP-systeem. Er wordt gestart met een aantal definities van een ERP-systeem (1.2). Hieruit blijkt direct het complexe karakter. Daarna wordt een overzicht gegeven van de evolutie die geleid heeft tot ERP en wat mogelijkerwijze nog in het verschiet ligt (1.3). Definities kunnen onmogelijk een perfect beeld geven van wat ERP juist is, daarom wordt in punt 1.4 een overzicht gegeven van de karakteristieken die een ERPsysteem kenmerken. In het daaropvolgende punt (1.5) wordt meteen de link gelegd met de implementatie; er worden namelijk een aantal implementatiestrategieën uit de doeken gedaan. Daarna wordt een samenvatting gegeven van de mogelijke voordelen die ERP-systemen aan bedrijven kunnen bieden (1.6). Dit hoofdstuk wordt afgesloten met een blik op de ERP-markt en de potentiële groei (1.7).

1.2

ERP GEDEFINIEERD

Alvorens te kunnen spreken over de implementatie van een ERP-systeem is het noodzakelijk te weten wat nu juist een ERP-systeem is. Daarom wordt in dit punt een overzicht gegeven van de beschikbare definities die in de literatuur te vinden zijn. Heel wat auteurs hebben zich gewaagd aan het formuleren van een definitie, vaak vrij gelijkaardig aan de bestaande. Het verschil ligt dan meestal in de mate waarin een bepaald kenmerk meer benadrukt wordt dan een ander. Het meest belangrijke kenmerk van een ERP-systeem, dat in bijna alle definities vermeld wordt, is het geïntegreerde karakter. Alle functies in de onderneming worden door één enkel systeem met elkaar gelinkt waardoor alle afdelingen binnen de onderneming als één geheel werken. Gable (1998) en Davenport (1998) beklemtonen dit dan ook in hun definitie van een ERP-systeem. Davenport (1998) werpt zelfs al de mogelijkheid op van integratie tussen verschillende ondernemingen onderling. Hij is daarmee voor op zijn tijd en omschrijft hierdoor eigenlijk al een ERP II-systeem (infra 1.3).

-3-

Tim Vermeersch


“…A comprehensive package software solutions seek to integrate the complete range of a business processes and functions in order to present a holistic view of the business from a single information and IT architecture (Gable, 1998).”

“ERP systems are commercial software packages that enable the integration of transactionoriented data and business processes throughout an organization. From a base in manufacturing and financial systems, ERP systems may eventually allow for integration of interorganizational supply chains (Davenport, 1998, blz. 121).” Loh en Koh (2004) maken een onderscheid tussen het strategische en het operationele niveau. Op het strategische niveau gebruikt men een definitie van Davenport (1998):

“The ERP-system is defined as an integrated application programme for enterprise business organization, management and supervision (Davenport, 1998, blz. 124).” Net zoals bij Gable (1998) benadrukken Loh en Koh (2004) op het strategisch vlak dus vrij sterk het geïntegreerde karakter van ERP-systemen. Op het operationele niveau hebben ze het dan weer over het feit dat een ERP-systeem voor zowat elke functie binnen de onderneming zijn nut heeft. De multifunctionaliteit is een erg belangrijk kenmerk. Daarvoor gebruiken ze de definitie van Wight (1993). Ook Laughlin (1999) ziet deze multifunctionaliteit als de meest belangrijke karakteristiek:

“ERP is a game plan for planning and monitoring the resources of a manufacturing enterprise, including the functions of manufacturing, marketing, finance and engineering (Wight, 1993).”

“...Software packages that affect everything from order capturing to accounting and procurement to warehousing. They grew out of the need to plan, manage and account for resources in predominately discreet manufacturing environments (Laughlin, 1999, blz 32).” Ook in de volgende definitie wordt de klemtoon gelegd op de integratie van de verschillende functies binnen de onderneming. Bovendien wordt een andere karakteristiek geaccentueerd, namelijk dat alle data in één gemeenschappelijke database opgeslagen wordt:

“An Enterprise Resource Planning system is an integrated enterprise computing system to automate the flow of material, information, and financial resources among all functions within an enterprise on a common database (Kumar et al., 2002, blz. 511).” Door het feit dat alle data in één database opgeslagen wordt, ontstaat de mogelijkheid om in elke afdeling met real-time data te werken. O’Leary (2001) neemt dit dan ook op in zijn definitie:

-4-

Tim Vermeersch


“ERP systems are computer-based systems designed to process an organization’s transactions and facilitate integrated and real-time planning, production, and customer response” (O’Leary, 2000, blz. 27). Een ander kenmerk van ERP-systemen is dat ze aangepast kunnen worden aan de specifieke kenmerken van elke onderneming. Dit wordt in volgende definities van Rosemann (1999) en Kumar en Hillegersberg (2000) benadrukt:

“...A customizable, standard application software which includes integrated business solutions for the core processes (e.g. production planning and control, warehouse management) and the main administrative functions (e.g. accounting, human resource management) of an enterprise” (Rosemann, 1999).

“ERP systems are configurable information systems packages that integrate information and information-based processes within and across-functional areas in an organization (Kumar and Hillegersberg, 2000, blz. 23).” Een vrij omvangrijke definitie is deze van Parr en Shanks (2000). Naast de reeds vermelde karakteristieken als integratie en mogelijkheid tot aanpassen, wordt hier het modulair karakter genoemd. Door deze modules is het voor de onderneming vrij te kiezen in welke mate men gebruik zal maken van het ERP-systeem. Zo kan er geopteerd worden om slechts een beperkt aantal modules te implementeren of zoveel mogelijk modules. Al naar gelang de preferenties van het bedrijf.

“Enterprise Resource Planning (ERP) systems are software packages composed of several modules, such as human resources, sales, finance and production, providing cross-organization integration of data through embedded business processes. These software packages can be customized to cater for the specific needs of an organization (Parr en Shanks, 2000, blz. 289).” Ten slotte wordt nog de definitie van Tadjer (1998) vermeld. Hij beschrijft erg beknopt, maar daarom niet minder duidelijk, de belangrijkste kenmerken van een ERP-systeem:

One database, one application and a unified interface across the entire enterprise (Tadjer, 1998). Op basis van voorgaande omschrijvingen kan nu tot een geïntegreerde definitie gekomen worden die de meest belangrijke kenmerken samenvat:

Een ERP-systeem is een softwareprogramma dat bestaat uit verschillende geïntegreerde modules die aan te passen zijn aan de kenmerken van de onderneming. Aan de hand van de gemeenschappelijke database beschikt elke afdeling over real-time informatie zodat de bedrijfsprocessen en administratieve functies sterk geïntegreerd zijn.

-5-

Tim Vermeersch

1.3 1.3.1


DE EVOLUTIE VAN ERP-SYSTEMEN Geschiedenis

Omdat de capaciteiten van computers en de verschillende programmeertalen tot voor de jaren ’80 te beperkt bleven, bleef het beeld van één enkel geïntegreerd informatiesysteem voor de gehele organisatie jarenlang een utopie. In de plaats daarvan ontwikkelden ondernemingen voor elke functionaliteit een afzonderlijk informatiesysteem. Vaak waren de verschillende systemen amper met elkaar geïntegreerd. Als gevolg daarvan was het bijvoorbeeld onmogelijk om data van de verkopen of de productie te combineren met deze van de boekhouding. Dezelfde data moest dan ook dikwijls in verschillende informatiesystemen ingegeven worden, wat duidelijk inefficiënties met zich meebrengt. Vanaf de jaren ’80 echter begonnen bepaalde softwareondernemingen in Duitsland, Nederland, de Verenigde Staten… de droom van één geïntegreerd systeem na te streven, wat leidde tot informatiesystemen met meerdere functionele toepassingen die één enkele database deelden. Eén enkele transactie, bijvoorbeeld een verkoop, had tot gevolg dat automatisch alle data bijgewerkt werd zoals financiële en voorraadgegevens (Markus en Tanis, 2000). De oorsprong van het ERP-systeem kan gesitueerd worden in de jaren ’60. Tijdens deze periode ontstond bij heel wat ondernemingen de behoefte aan een systeem om de voorraad bij te houden. In die tijd was het nog mogelijk om grote voorraden aan te houden en toch nog competitief te zijn (Umble et al., 2003). De belangrijkste doelstelling van deze voorraadcontrolesystemen was enkel op een gecentraliseerde basis controle behouden over de grote voorraad (Rashid et al., 2002). Vanaf de jaren ’70 wordt het echter duidelijk dat ondernemingen niet langer de luxe hebben grote hoeveelheden voorraad aan te houden. Dit leidde geleidelijk tot de ontwikkeling van ‘material requirements planning’ (MRP) systemen. Voor de eerste maal werd gebruikt gemaakt van een master production schedule (MPS). Een MPS specificeert de hoeveelheid gereed product die nodig is tijdens elke planningsfase. Aan de hand van een bill of material kan dan een planning gemaakt worden van de hoeveelheid grondstoffen en onderdelen die nodig is in elke fase, afhankelijk van de noodzakelijke productietijd. Met behulp van een accuraat voorraadsysteem dat de bestaande, maar ook de nog te leveren voorraad nauwgezet bijhoudt, kan dan de netto materiaalbehoefte bepaald worden. Dit betekende een heuse stap vooruit op het vlak van productiviteit (Chen, 2001; Umble et al., 2003). Tijdens het begin van de jaren ’80 begonnen ondernemingen te profiteren van de toegenomen mogelijkheden en de betaalbaarheid van de beschikbare technologie (Umble et al., 2003). Bijgevolg evolueerde MRP van een plannings- en controlesysteem tot een systeem dat in staat was zowat alle A

middelen van de onderneming te plannen. Deze uitbreiding was van die mate dat Wight in 1984 de term

A

WIGHT O.W., 1984, Manufacturing Resource Planning: MRP II, Oliver Wight Ltd. Publications, Essex Junction, VT

-6-

Tim Vermeersch


MRP II lanceerde: manufacturing resource planning. Bij MRP II worden de primaire functies (productie, markting en financiën) in het planningsproces geïntegreerd met andere functies zoals human resource management, project management, techniek en inkoop (Chen, 2001; Rashid et al., 2002). Dit liet de ondernemingen toe gedetailleerd de activiteiten in te geven en in te grijpen indien deze werkzaamheden niet overeenkomen met de gewenste planning (Umble et al., 2003). MRP II-systemen waren dan ook vaak uitgerust met een “what if” mogelijkheid zodat verschillende scenario’s getest konden worden. Er waren echter nog steeds enkele struikelblokken. Data moest vaak nog meerdere malen ingegeven worden of erg complexe interfaces waren nodig om belangrijke informatie te delen. De efficiëntie van de verschillende business units werd dus geoptimaliseerd; of de algemene efficiëntie van heel de onderneming geoptimaliseerd werd, is echter twijfelachtig (Mabert et al., 2001). Hoewel MRP II een significante verbetering betekende ten opzichte van de vorige systemen, bleef als gevolg van de dynamische ontwikkelingen bij de ondernemingen de vraag bestaan naar meer geïntegreerde systemen. Almaar grotere afzetmarkten, internationalisering, integratie met klanten en leveranciers… veranderden de manier van zakendoen wereldwijd. Kwaliteit en kost werden vanzelfsprekend geacht, terwijl leveringstijden, flexibiliteit, productdifferentiatie almaar belangrijker werden. Zo ontstonden ook nieuwe technieken, bijvoorbeeld make-to-order in plaats van make-to-stock (Rajagopal en Tyler, 2000). De nieuwe generatie van informatiesystemen moest dus sneller informatie beschikbaar kunnen stellen en ondernemingen als SAP, Oracle, Peoplesoft, Baan… speelden daar perfect op in (Mabert et al., 2001). Zo werd het Enterprise Resource Planning (ERP) systeem ontwikkeld. De term ERP werd geïntroduceerd door The Gartner Group in het begin van de jaren ’90. Zij omschrijven ERP als volgt:

“Such software should include integrated modules for accounting, finance, sales and distribution, HRM, material management, and other business functions based on a common architecture that linked the enterprise to both customers and suppliers” (Mabert et al., 2001, blz. 70). Terwijl MRP II zich traditioneel focuste op de planning van de interne middelen van de onderneming, streeft ERP ernaar ook de middelen van de leveranciers te plannen, gebaseerd op de dynamische vraag van de klanten (Chen, 2001). De omschrijving van The Gartner Group geeft de 3 voornaamste kenmerken van ERP-systemen. Ten eerste zijn ze multifunctioneel: van financiële resultaten, over productieplanning, tot HRM. Een tweede kenmerk is dat ze geïntegreerd zijn. Dit betekent dat indien data in één van de functies ingegeven wordt, de informatie in alle gerelateerde functies eveneens onmiddellijk aangepast wordt. Ten derde zijn ERP-systemen modulair. Een onderneming kan bijvoorbeeld alle modules implementeren terwijl een andere slechts enkele modules gebruikt. Eender welke combinatie is mogelijk (Mabert et al., 2001). Op deze kenmerken en andere wordt dieper ingegaan in een verder punt (infra: 1.4).

-7-

Tim Vermeersch


Eind de jaren ’90 beslisten heel wat bedrijven uit niet-productiesectoren een ERP-systeem te implementeren als ruggengraat voor de financiële transacties. Dit leidde tot een nieuwe benaming, namelijk extended ERP (Bond et al., 2000). De evolutie van ERP-systemen is natuurlijk nog niet tot stilstand gekomen. Nieuwe markten worden aangesproken, nieuwe modules worden toegevoegd, bestaande modules worden geoptimaliseerd en ook de kenmerken van de markt blijven wijzigen. Daarom wordt in volgend punt een blik op de toekomst geworpen om te zien wat nog verwacht mag worden van de nieuwe ERP-systemen.

Figuur 1

De evolutie van ERP 2000

Extended ERP / ERP II

1990

Enterprise Resource Planning (ERP)

1980

Manufacturing Resources Planning (MRP II)

1970

Material Requirements Planning (MRP)

1960

Inventory Control Packages / Voorraadcontrolesystemen

Bron: Rashid et al., 2002, blz. 4

1.3.2

Toekomst

De huidige ERP-systemen zijn zoals eerder vermeld al vrij omvangrijk qua functionaliteiten. Er blijven echter nog enkele problemen, zoals bij de data-intensieve activiteiten als supply chain planning, customer management en marketing. De recente ontwikkelingen liggen dan ook op het vlak van supply chain management (SCM) en customer relationship management (CRM) waarbij men de front office diensten (marketing, klantendiensten…) sterker tracht te integreren met de back office (logistieke diensten, financiële diensten, productieplanning…) (Chen, 2001). Deze evolutie heeft geleid tot de naam “ERP II” en wordt als volgt gedefinieerd:

“The automation and integration of information, processes and functions in a manufacturing (or other) environment with the result being a closed-loop, functionally integrated, real-time planning, execution and control system that is location- and languange-independent and that increasingly includes customers, vendors and partners” (Weston, 2003, blz. 50). Deze definitie beschrijft perfect een ERP-systeem met daarbovenop de nieuwe functionaliteiten die ERP II kenmerken: CRM en SCM (Weston, 2003).

-8-

Tim Vermeersch

Tabel 1

Rol


De verschillen tussen ERP en ERP II ERP

ERP II

Optimaliseren van de onderneming

Creëren van waardeketen, collaborativeB

commerce (c-commerce) Domein

Productie en distributie

Functie

Productie,

verkoop

Alle sectoren en

distributie,

Specifieke

industrieën,

specifieke

financiële processen

industriële processen

Proces

Intern, verborgen

Extern verbonden

Architectuur

Monolithisch

Open, web-based

Data

Intern gegenereerd en gebruikt

Intern en extern openbaar gemaakt

Bron: Michel, 2001, blz. 42

ERP is sterk gericht op het optimaliseren van alle processen binnen de onderneming. ERP II tracht daarbovenop nog de samenwerking met de verschillende partners te verbeteren. Het informatiesysteem zal niet langer beperkt blijven tot de 4 muren van de onderneming. Zo zal de gegenereerde data niet langer enkel in de onderneming zelf gebruikt worden, maar bijvoorbeeld gedeeld worden met klanten en leveranciers. Dit wordt allemaal mogelijk gemaakt via een architectuur die open is en gemakkelijk te integreren met andere systemen. De nieuwe generatie ERP-systemen zal ook niet langer alles bieden aan iedereen. Verkopers zullen zich meer en meer moeten specialiseren in bepaalde sectoren om nog betere functionaliteiten te kunnen bieden (Taking the pulse of ERP, 2001).

Figuur 2

De recente ontwikkelingen van ERP-systemen SCM

Leveranciers

CRM

Onderneming (ERP)

Klanten

Bron: Chen I., 2001, blz. 382

Jarenlang hebben ondernemingen ernaar gestreefd, onder andere door het gebruik van ERP-systemen, de interne processen te optimaliseren. Bijgevolg zijn de mogelijkheden voor verdere interne verbetering vrij beperkt. De aandacht van ondernemingen is dan ook gekeerd naar de totale waardeketen, meer

B

“Collaborative commerce (c-commerce) involves the collaborative, electronically enabled business interactions

among an enterprise’s internal personnel, business partners and customers throughout a trading community. The trading community can be an industry, industry segment, supply chain or supply chain segment” (Bond et al., 2000, blz. 2).

-9-

Tim Vermeersch


bepaald SCM. Het kernconcept van SCM kan omschreven worden als een volledige waardeketen die sterk geïntegreerd is. Om dat te bewerkstelligen is het noodzakelijk dat ondernemingen samenwerken (Möller, 2005). ERP-ontwikkelaars zijn volop bezig meer geavanceerde planningssystemen te ontwikkelen die dergelijke manier van werken mogelijk maakt. Aan de hand van gesofisticeerde mathematische algoritmes wordt de logistiek geanalyseerd en gemodelleerd tot optimale oplossingen (Chen, 2001). Via het Internet, gecombineerd met intranet en extranet, is het mogelijk een omgeving te creëren die vlotte communicatie tussen verschillende ondernemingen toelaat (Weston, 2003). De toegenomen macht van kopers en afgenomen marktbarrières hebben ondernemingen ertoe gedwongen de manier waarop ze klantentrouw en bijgevolg winstmarges in stand houden, te herdenken. CRM betekent hier een lange termijn relatie met de klant opbouwen en one-to-one marketing is hiertoe de manier bij uitstek. Daarvoor zijn krachtige systemen vereist die een profiel kunnen opstellen van de meest winstgevende klanten, patronen in het koopgedrag… Een compleet beeld van wat de klant eist en wenst, kan dan leiden tot superieure klantentrouw, verminderde diensten- en verkoopkosten en uiteindelijk hogere winsten. ERP-verkopers werken dan ook erg hard om dergelijke systemen te ontwikkelen (Chen, 2001).

1.4

KARAKTERISTIEKEN VAN EEN ERP-SYSTEEM

In dit punt worden de kenmerken van een ERP-systeem uit de doeken gedaan. In de verschillende definities (supra 1.2) zijn reeds de meest belangrijke karakteristieken vermeld. Hier worden ze grondiger uitgewerkt zodat het voor de lezer duidelijk wordt hoe een ERP-systeem precies werkt. Een bijkomende doelstelling van dit onderdeel is aantonen dat ERP eigenlijk groter, moeilijker en omvangrijker is dan elke andere traditionele bedrijfssoftware zodat logischerwijze ook de implementatie heel wat complexer is.

1.4.1

Modulair

De meeste ERP-systemen bestaan uit verschillende modules. Op deze manier kunnen ondernemingen kiezen welke functies ze wensen te verwezenlijken met het ERP-systeem. De open architectuur is zo opgevat dat elke module kan geïntegreerd of losgemaakt worden, zonder de andere modules te beïnvloeden. Een praktisch gevolg van het modulaire karakter is dat de data in elke module op een gelijkaardige manier opgesteld wordt. Zo heeft de informatie in heel organisatie dezelfde vorm en kan het beslissingsproces heel wat accurater worden (Yen et al., 2002). De financiële en boekhoudkundige modules worden door zowat alle organisaties aangekocht (Davenport, 1998). De meest gangbare modules in ERP-paketten zijn onder te verdelen in volgende categorieën:

- 10 -

Tim Vermeersch


• Financieel • Operaties en logistiek • Human resources • Verkoop en marketing Indien de organisatie zelf voor een bepaalde functie een perfect werkend systeem ontwikkeld heeft, is het uiteraard niet noodzakelijk de overeenkomstige module aan te schaffen. Men kan er ook van uitgaan dat een zelf ontwikkeld systeem unieke strategische voordelen kan bieden ten opzichte van de concurrentie. Soms heeft een onderneming een module simpelweg niet nodig. Een dienstenonderneming zal bijvoorbeeld geen behoefte hebben aan een productiemodule (Davenport, 1998).

1.4.2

Eén database

Eén van de belangrijkste punten bij de definities van ERP dat telkens naar voren kwam, is het geïntegreerde karakter. “Seamless integration of all the information flowing through a company”, aldus Davenport (1998, blz. 121). Kenmerkend voor de manier waarop de verschillende modules bij een ERPsysteem geïntegreerd zijn, is de wijze waarop de data opgeslagen wordt. Alle informatie van de verschillende modules wordt namelijk opgeslagen in één relationele database. Bijvoorbeeld in plaats van bij elke verkoopsorder alle klanteninformatie bij te voegen, wordt enkel het klantnummer genoteerd. Indien men meer gedetailleerde informatie over deze klant nodig heeft, kan men via de relationele database aan de hand van het klantnummer verdere gegevens over deze klant te weten komen (O’Leary, 2000). Data moet dus maar één maal in het systeem ingegeven worden, wat de efficiëntie verhoogt. Zo wordt ook de integriteit van de informatie gewaarborgd (Yen et al., 2002). Bovendien is het mogelijk doordat alle informatie uit de verschillende modules in één database gegroepeerd zit, de data in “real time” te raadplegen (Bingi et al., 1999).

- 11 -

Tim Vermeersch

Figuur 3


De architectuur van een ERP-systeem

Managers en Stakeholders

RapportingsToepassingen Financiële Toepassingen

Verkoops- & LeveringsToepassingen

Klanten

VerkoopDiensten Team & KlantenToepassingen dienst

Centrale Database

Human Resource Management Toepassingen

Productie Toepassingen

Voorraad Toepassingen

Leveranciers BackOffice Werknemers

Werknemers Bron: Davenport, 1998, blz. 124

1.4.3

Best practice

Omdat ze ontworpen zijn om te voldoen aan de noden van heel wat organisaties, ondersteunen ERPsystemen de algemene bedrijfsprocessen van de ondernemingen. Deze kunnen echter sterk verschillen van de manier van werken van een bepaalde onderneming. Daarom hebben ERP-verkopers zo veel mogelijk geprobeerd voor elk proces (van de boekhouding tot de werkvloer) de beste manier van werken, de zogenaamde best practice, te vinden en deze wijze te programmeren in het systeem. Dit heeft tot gevolg dat ondernemingen die investeren in ERP-systemen erg vaak aan business process reengineering (BPR) moeten doen (Markus en Tanis, 2000).

1.4.4

Configuratie

ERP-systemen zijn commerciële pakketten die bij een verkoper aangekocht worden. Ze worden dus niet door de onderneming zelf ontwikkeld. Dit heeft tot gevolg dat het systeem nog geconfigureerd zal moeten worden aan de specifieke wensen en kenmerken van de onderneming (Markus en Tanis, 2000). Zo zal

- 12 -

Tim Vermeersch


bijvoorbeeld geselecteerd moeten worden welke voorraadwaardering (FIFO, LIFO…) gebruikt zal worden. Gemiddeld moet een onderneming ongeveer 3000 dergelijke keuzes maken (Davenport, 1998). Aangezien ERP-systemen volgens de best practice methodes opgevat zijn, worden vaak de processen en de organisatie gewijzigd, eerder dan het systeem (Markus en Tanis, 2000).

1.5

IMPLEMENTATIESTRATEGIEËN

Nu duidelijk geworden is hoe een ERP-systeem in elkaar zit, wordt in dit punt dieper ingegaan op de verschillende manieren waarop een dergelijk complex systeem kan geïmplementeerd worden. Er zijn namelijk drie modelmethodes: stap voor stap, big bang en uitrollen. Een combinatie van deze 3 werkwijzen is uiteraard steeds mogelijk.

1.5.1

Stap voor stap

Bij een stap voor stap implementatie wordt de software in verschillende stappen geïnstalleerd en gewoonlijk slechts enkele modules in één keer. Het risico op mislukken is vrij laag doordat het project minder complex wordt om te coördineren, controleren en organiseren. Daarnaast is er een geleidelijke overgang in de onderneming waardoor de werknemers de kans krijgen om zich aan te passen aan de veranderingen in hun werkomgeving. Een groot nadeel is dat er tijdelijke interfaces gebouwd moeten worden tussen het nieuwe en de oude systemen. Het aanmaken van deze interfaces kost heel wat tijd en geld en dragen bovendien niets bij aan de kwaliteit van het uiteindelijke resultaat. Een ander nadeel is dat de implementatie vrij lang zal duren en de motivatie bij het implementatieteam wel eens kan dalen naarmate het project vordert (Welti, 1999).

1.5.2

Big bang

Een big bang implementatie vervangt de bestaande systemen door het ERP-systeem in één enkele operatie.

Vooraf

moet

het

systeem

uiteraard

intensief

getest

worden.

Voordeel

bij

deze

implementatiewijze is dat geen tijdelijke interfaces gecreëerd moeten worden. Bovendien kan het systeem na de implementatie dadelijk in gebruik genomen worden. Natuurlijk heeft deze manier van werken ook zijn nadelen, zo zal er een verhoogde nood zijn aan coördinatie en integratie. Werknemers krijgen de kans niet om zich rustig aan te passen aan het nieuwe systeem. Daarom ook dat de organisatorische veranderingen bij een big bang implementatie niet al te groot mogen zijn om de werknemers niet te overweldigen. De kwaliteit van de data na de verandering moet bovendien perfect zijn om grote problemen te vermijden. Het is duidelijk dat de organisatiestructuur niet al te complex mag zijn om een ERP-systeem via een big bang methode te implementeren (Welti, 1999).

- 13 -

Tim Vermeersch

1.5.3


Uitrollen

De derde mogelijkheid is dat in één site van de onderneming een volledige implementatie gedaan wordt, waarna deze dan uitgerold wordt naar de andere sites. Dat uitrollen kan dan opnieuw stap voor stap of via de big bang methode. Het voordeel bij deze werkwijze is dat men na de eerste implementatie deze ervaring kan gebruiken in de volgende implementaties. Bijgevolg daalt het risico op falen. Een ander gevolg is dat de verschillende sites heel goed met elkaar geïntegreerd zullen zijn via een uniform systeem. Gevaar bij deze manier van implementeren, is dat specifieke processen van bepaalde sites verwaarloosd worden en als normale processen behandeld worden (Welti, 1999).

1.6

VOORDELEN ERP

Volgens een onderzoek van AMR Research (2006) bedroegen in 2005 de inkomsten van de ERP softwaremarkt wereldwijd 25,4 miljard dollar. Davenport (1998) verklaart dat de implementatiekosten wel tot 5 à 10 keer meer dan de licentiekosten kunnen bedragen. Bijgevolg spendeerden ondernemingen in 2004 wereldwijd 120 tot 250 miljard dollar aan ERP-systemen. De vraag kan dus gesteld worden welke voordelen deze ondernemingen van ERP-systemen verwachten en dus met welke motieven ze dergelijke miljoeneninvestering rechtvaardigen. De mogelijke voordelen worden in onderstaande tabel kort samengevat. Ze worden volgens Shang en Sheddon (2000) in 5 categorieën onderverdeeld: operationeel, management, strategisch, IT infrastructuur en organisatorisch. Er kunnen echter 2 beperkingen bij deze indeling aangehaald worden. Ten eerste worden hier de voordelen niet met de motieven gelinkt. Met motieven worden de redenen bedoeld waarom ondernemingen beslissen al dan niet te investeren in ERP. De tweede beperking die aangehaald kan worden, is dat er geen rekening gehouden wordt met de factor tijd. Bepaalde voordelen zullen pas later blijken dan andere (Chand et al., 2005)

Tabel 2 Operationeel

Mogelijke voordelen van ERP-systemen Kostenreductie (arbeidskosten, voorraadkosten…) Kortere cyclustijd Productiviteitsverhoging Kwaliteitsverbetering Betere klantenservice

Management

Beter resource management Betere besluitvorming Verhoogde controlemogelijkheden (financieel, productie…)

- 14 -

Tim Vermeersch

Strategisch


Staat de groei van de onderneming niet in de weg Makkelijkere integratie van overgenomen ondernemingen Verbeterde innovatie Kostenleiderschap (schaalvoordelen) Productdifferentiatie C-commerce Mogelijkheid tot wereldwijde groei E-business

IT infrastructuur

Verhoogde flexibiliteit Kostenreductie in IT Stabieler en flexibel systeem

Organisatorisch

Ondersteunt organisatorische veranderingen Vergemakkelijkt opleiding en training Zorgt voor pro-actieve gebruikers (betrokkenheid bij beslissingen) Eenduidige bedrijfscultuur Verbeterde werknemersingesteldheid Hogere tevredenheid bij werknemers

Bron: Shang en Seddon, 2000, appendix 1

Er valt op te merken dat ondernemingen niet noodzakelijk alle voordelen in alle 5 dimensies dienen te ondervinden. Voorgaande tabel geeft eerder een overzicht van alle mogelijke baten die bedrijven kunnen ervaren (Shang en Seddon, 2000). Het nut van dit overzicht wordt later duidelijk. Om te meten of de implementatie van een ERP-systeem succesvol verlopen is, moet namelijk rekening gehouden worden met verschillende criteria. Enkel kijken of de implementatie binnen budget of op tijd gebeurd is, volstaat dus niet. De mate waarmee de geciteerde voordelen behaald zijn, kan als basis dienen om succes te meten (infra 2.4). Voorwaarde is dat de verschillende baten gekwantificeerd kunnen worden. Heel wat voordelen zijn echter ontastbaar wat kwantificering erg moeilijk maakt (Al-Mashari, 2003).

1.7

DE ERP-MARKT

De toekomst van de ERP-verkopers ziet er erg rooskleurig uit. De markt is gigantisch en haalde in 2005 wereldwijd nog een omzet van 25,4 miljard dollar. In 2006 wordt de omzet op $29 miljard geschat. Men verwacht bovendien dat dit de komende 5 jaar in totaal met een jaarlijks gemiddeld groeipercentage van 10% zal blijven toenemen (AMR Research, 2006). Voor de Europese markt wordt een groei van ongeveer 7% verwacht (AMR Research, 2005b). Het geloof bij de ondernemingen dat ze een geïntegreerd informatiesysteem nodig hebben om competitief te blijven, stuwt deze groei (AMR

- 15 -

Tim Vermeersch


Research, 2006). Dit blijkt ook uit cijfers die de uitgaven weergeven die ondernemingen van plan zijn te spenderen aan ERP-systemen. Onderzoek toont aan dat deze budgetten met 12,3% zullen toenemen in 2007. Een andere verklaring voor deze sterke stijging, is het feit dat ondernemingen voor almaar meer functionaliteiten een beroep doen op ERP (AMR Research, 2006b). Bij de verkopers van ERP-systemen is een trend aan de gang van almaar minder aanbieders (fusies en overnames) die een groter marktaandeel bezitten. Zo nam eind 2004 Oracle, op dat moment de nummer e

3 in de wereld op het vlak van inkomsten, Peoplesoft over dat toen de 2 grootste aanbieder op de ERPmarkt was (AMR Research, 2005). Zodoende hebben SAP en Oracle, de 2 grootste spelers in de markt, samen een aandeel van 65% in de licentieverkopen (AMR Research, 2006).

Tabel 3

Marktaandeel van de 5 grootste ERP-verkopers Marktaandeel Marktaandeel

Marktaandeel

(omzet)

Geschatte

(omzet)

(omzet)

Schatting

Groei

groei

Verkoper

2004

2005

2006

2004-2005

2005-2006

1

SAP

40%

42%

43%

12%

17%

2

Oracle

10%

20%

23%

110%

29%

3

Sage Group

5%

6%

5%

16%

10%

4

Microsoft

3%

4%

4%

15%

18%

5

SSA Global

3%

3%

3%

7%

3%

Bron: AMR Research, 10 oktober 2006 Een andere opvallende trend is dat de focus bij de ERP-verkopers zich verlegd heeft van de grote ondernemingen naar de middelgrote (jaarlijkse omzet tussen $50 miljoen en $1 miljard) en kleine ondernemingen (jaarlijkse omzet lager dan $50 miljoen). Bijgevolg wordt als het ware een nieuwe markt aangeboord. Ook dit ondersteunt de verwachte groei voor de komende jaren (AMR Research, 2005).

1.8

BESLUIT

De doelstelling van dit inleidende hoofdstuk was de lezer kennis te laten maken met de term ERPsysteem. Daarvoor werden een aantal definities aangehaald en de belangrijkste karakteristieken grondig uitgewerkt. Zaken als het geïntegreerde karakter, de relationele database, het modulaire karakter… zouden nu duidelijk moeten zijn. Een belangrijk besluit dat hieruit getrokken werd, is het feit dat ERPsystemen op elk vlak erg complex zijn en dus de implementatie geen eenvoudige opdracht is. Ook de ontstaansgeschiedenis werd niet over het hoofd gezien, net als de verwachtingen voor de toekomst. Dit toont aan dat de ERP-systemen blijven evolueren. De mogelijk voordelen hebben aangetoond dat ondernemingen met een ERP-systeem een competitief voordeel hebben ten opzichte van de

- 16 -

Tim Vermeersch


concurrentie. Dit besef bij de ondernemingen werd dan nog eens benadrukt door de kosten die ze jaarlijks spenderen aan ERP-systemen. Bovendien wordt verwacht dat de groei de komende 5 jaar niet zal verminderen. Nu duidelijk geworden is wat een ERP-systeem is, kan overgegaan worden tot de implementatie. In het volgende hoofdstuk wordt dieper ingegaan op het implementatieproces.

- 17 -

Tim Vermeersch

Hoofdstuk 2: Selectie en implementatie van een ERP-systeem

Hoofdstuk 2: SELECTIE EN IMPLEMENTATIE VAN EEN ERPSYSTEEM

2.1

INLEIDING

De bedoeling van deze thesis is een overzicht te geven van welke factoren doorslaggevend zijn voor een succesvolle implementatie. Afhankelijk van de fase waarin de implementatie zich bevindt, zullen deze determinanten verschillend zijn. In de literatuur zijn echter meerdere implementatiemodellen te vinden, daarom wordt in dit hoofdstuk uit deze een algemeen model gepuurd waarmee later dan verder gewerkt kan worden. Meerdere malen werd al benadrukt dat een ERP-systeem veel meer is dan een ordinair IS, zo ook de implementatie (Davenport, 2000). Een groot verschil tussen ERP- en traditionele informatiesystemen is het geïntegreerde karakter van ERP-toepassingen. Bij de implementatie van een ERP-systeem wordt de focus verlegd van een technisch probleem naar een softwareontwikkeling die op de bedrijfsprocessen gericht is (Al-Mudimigh et al., 2001) Dit is dan ook de reden waarom naast de implementatiemodellen voor gewone software, speciale modellen voor ERP-systemen ontwikkeld werden. Het grote probleem hierbij is echter dat er haast zoveel modellen als ERP-systemen bestaan. Daarom wordt in dit hoofdstuk eerst een overzicht gegeven van de meest geciteerde. Zoals eerder vermeld is de bedoeling van dit hoofdstuk dan om daaruit een algemeen model te puren dat de sterktes van elk model bevat, terwijl de punten waarop kritiek gegeven werd niet meer aanwezig zijn. Er wordt gestart met een methodiek om een ERP-systeem te selecteren (2.2). In het daaropvolgende punt wordt overgegaan tot de eigenlijke implementatie (2.3). Er wordt gestart met een resumé van de verschillende implementatiekosten (2.3.1). Vervolgens wordt een overzicht gegeven van de meest belangrijke implementatiemodellen, respectievelijk: het 5-fasen model van Ross en Vitale (2.3.2), de process-theorie van Markus en Tanis (2.3.3), het Project Phase Model (PPM) (2.3.4) en het 6-fasen model van Cooper en Zmud (2.3.5). In punt 2.3.6 worden deze modellen samengevat in één algemeen model. Dit is de basis om dan in een later hoofdstuk de onderzoeksvraag te kunnen beantwoorden. Het samenvattend implementatiemodel kan als een handleiding dienen tijdens het implementatieproces. Wat in de praktijk echter moeilijk blijkt, is de beoordeling of een implementatie al dan niet succesvol verlopen is. Het project is te complex om het succes te kunnen meten aan de hand van één enkele maatstaf. In punt 2.4 worden een tweetal methodes aangereikt die deze moeilijkheid kunnen verhelpen.

- 18 -

Tim Vermeersch

2.2


DE SELECTIE VAN EEN ERP-SYSTEEM

De bestaande ERP-pakketten kunnen onmogelijk een totaaloplossing bieden voor elk proces in elke industrie. Geen enkel ERP-systeem kan dus voldoen aan alle vereisten die een onderneming stelt. Daarom moeten ondernemingen kiezen voor een flexibel systeem en een ERP-verkoper die bereid is samen te werken met de klant en luistert naar zijn noden. Het gebeurt echter al te vaak dat ondernemingen zonder enig systematisch selectieproces een ERP-systeem aanschaffen. Onderzoek toont aan dat een passend systeem dat weinig aanpassingen vereist het belangrijkste criterium is waarop ondernemingen zich baseren. Verenigbaarheid met de bestaande processen wordt dus noodzakelijk geacht, hoewel heel wat ondernemingen nog steeds wijzigingen in deze processen moeten doorvoeren (van Everdingen et al., 2000). De grootste fiasco’s tijdens implementaties lijken te gebeuren wanneer de bestaande processen moeilijk te combineren zijn met het nieuwe systeem (Umble et al., 2003). Andere gewichtige selectiecriteria zijn flexibiliteit, gebruiksvriendelijkheid van het systeem en in mindere mate hulp en steun van de ERP-verkoper (van Everdingen et al., 2000). Wat ook dikwijls voorkomt, is dat men te algemene criteria hanteert zonder deze aan te passen aan de specifieke kenmerken van de onderneming, de competitieve omgeving en de bedrijfsstrategie (Wei et al., 2005). Andere elementen die in de beslissing opgenomen moeten worden zijn de kenmerken van het productieproces, de marktsegmenten die men wenst aan te spreken, de wensen van de klant, de beschikbare middelen… Een mooi voorbeeld is dat van Compaq dat bij de selectie rekening hield met de wijziging die het in de strategie zou doorvoeren. Gedreven door het succes van ondernemingen als Dell en Gateway besliste Compaq om te schakelen van build-to-stock naar build-to-order (Chen J., 2001). Bijgevolg is een systematisch selectieproces hier op zijn plaats om de beslissingsnemers bij te staan in hun zoektocht naar het meest passende ERP-systeem. In de literatuur zijn verschillende selectiemodellen te vinden, maar aangezien deze thesis handelt over de implementatie zal slechts 1 model beschreven worden, namelijk de AHP-methode.

2.2.1

Het AHP selectiemodel

AHP staat voor “analytic hierarchy process”:

“The AHP method, introduced by Saaty, directs how to determine the priority of a set of alternatives and the relative importance of attributes in a multiple criteria decision-making problem” (Wei et al., 2005, blz. 48). Dit model is enorm gestructureerd en blinkt uit door de mate van detail waarmee het uitgewerkt is. Het selectieproces wordt samengevat in 7 stappen. Bovendien is het vrij recent en dus nog zeker up to date.

- 19 -

Tim Vermeersch


Eventueel nadeel door het recente karakter is het gebrek aan gestructureerde kritiek.

Stap 1: het vormen van een projectteam en het verzamelen van alle mogelijke informatie over ERP-verkopers en -systemen. Het projectteam dient te bestaan uit een aantal personen die de bevoegdheid hebben de uiteindelijke beslissing te nemen, experts op het vlak van IT en leden van het senior management. De informatie die verzameld moet worden kan via allerhande bronnen bekomen worden: professionele magazines, beurzen, internet en andere. Op deze manier wordt er voor gezorgd dat geen enkel mogelijk systeem over het hoofd gezien wordt (Wei et al., 2005, blz. 49).

Stap 2: identificeer de noodzakelijke karakteristieken Een ERP-systeem kan om verschillende redenen gekozen worden, zowel technische als commerciële. Het projectteam staat in voor het formuleren van de elementen waarop men zich zal baseren bij het kiezen van een welbepaald systeem. Daarenboven moeten de verschillende stakeholders geanalyseerd worden, de verschillende alternatieven, de doelstellingen en risico’s van het project… Ze moeten proberen wat duidelijkheid te scheppen in de complexe informatie. Ten slotte dienen ook de beperkingen van de onderneming enerzijds en de beschikbare middelen anderzijds geformuleerd te worden (Wei et al., 2005, blz. 49).

Stap 3: maak een structuur van de verschillende doelstellingen Nadat de noodzakelijke karakteristieken van het systeem bekend zijn, kan men overgaan tot het ordenen van deze doelstellingen. Een onderscheid moet gemaakt worden tussen principiële en andere, gewone doelstellingen. Principiële doelstellingen weerspiegelen wat het projectteam wenst tot stand te brengen. De andere doelstellingen daarentegen helpen bij het vervullen van de fundamentele. Deze laatste kunnen op 2 manieren geordend worden: top-down of bottom-up. Het bovenste niveau verwijst naar de meer algemene doelen, hoe lager het niveau, des te meer gedetailleerd de objectieven uitgewerkt worden. Er moet echter steeds rekening gehouden worden met de beperkingen die in de vorige fase geformuleerd werden (Wei et al., 2005, blz. 50). Een voorbeeld op onderstaande figuur maakt veel duidelijk.

- 20 -

Tim Vermeersch

Figuur 4


Voorbeeld hiërarchie fundamentele doelstellingen Prijs Onderhoudskost Totale kost minimaliseren Implementatietijd minimaliseren

Het beste ERP-systeem selecteren

Complete functionaliteit

Kost consultants Voldoende modules Veiligheid

Gebruiksvriendelijke interface Systeemflexibiliteit

Het meest passende ERP-systeem selecteren

Kost infrastructuur

Gemak van updaten Integratiemogelijkheid

Systeembetrouwbaarheid Financiële situatie

Een goede reputatie De beste ERP-verkoper selecteren

Marktaandeel R&D bekwaamheid

Goede technische bekwaamheid

Technische bijstand

Goede service

Waarborgen Opleiding en training Snelheid service

Bron: Wei et al., 2005, blz. 53

De minder belangrijke doelstellingen worden op een gelijkaardige manier voorgesteld. De boomstructuur wordt aangevuld met een soort van netwerk. In die boomstructuur worden de minder belangrijke doelstellingen met de principiële verbonden indien ze verband houden met elkaar. Op deze manier wordt duidelijk hoe de principiële doelstellingen vervuld zullen worden. Een volledig voorbeeld zou te veel uitweiden, daarom enkele korte voorbeeldjes. De principiële doelstelling onderhoudskost zal afhankelijk zijn van de mate van aanpassingen die aan het systeem gedaan worden, de prijs die de verkoper oplegt, het al dan niet voorhanden zijn van een handleiding, de programmeertaal… Dit zijn dan de bijkomende doelstellingen. De programmeertaal zal dan weer zijn invloed hebben op de systeemflexibiliteit, het gemak van updaten, de integratiemogelijkheden… Op deze manier kan een volledig netwerk opgebouwd worden wat in een grafische boomstructuur erg overzichtelijk is (Wei et al., 2005, blz. 51).

- 21 -

Tim Vermeersch


Stap 4: bepaal de attributen nodig voor de evaluatie van de ERP-systemen Nadat deze structuur helemaal opgebouwd is, kan het projectteam de attributen evalueren die van toepassing zijn voor de selectie van het ERP-systeem. Het is aan te raden zelf een dergelijke structuur te construeren aangepast aan de kenmerken van de onderneming en haar omgeving. Enkel de karakteristieken die in de lijn liggen van de doelstellingen van de onderneming mogen in aanmerking komen (Wei et al., 2005, blz. 51).

Stap 5: verwijder de ongeschikte ERP-verkopers door het informeren naar specifieke zaken die te maken hebben met de noodzakelijke karakteristieken Bijgevolg ontstaat een lijst met een aantal ERP kandidaten. Via vergaderingen, vragenlijsten, checklists kan naar meer specifieke informatie gepeild worden. Aan de hand van de verschafte antwoorden kan de lijst met kandidaten verder ingekort worden (Wei et al., 2005, blz. 52).

Stap 6: evalueer de ERP-systemen door middel van de AHP-methode De AHP-methode omvat 3 fases: ontleding, vergelijken en synthese van de prioriteiten. De eerste fase gebeurt aan de hand van de boomstructuur van de fundamentele doelstellingen. Tijdens de tweede fase gaat elke beslissingnemer via gepaarde vergelijking de verschillende karakteristieken tegenover elkaar afwegen. Dit kan bijvoorbeeld gedaan worden met een negen punten schaal. In de derde en laatste fase worden de verschillende karakteristieken via statistische methodes als het berekenen van de eigenwaarde in volgorde van belangrijkheid gerangschikt. Het al dan niet aanwezig zijn van een bepaald kenmerk zal invloed hebben op de score die uiteindelijk aan elk in aanmerking komend systeem gegeven wordt. Dit proces wordt best gedaan door de verschillende beslissingsnemers om op die manier geen eenzijdig beeld te krijgen (Wei et al., 2005, blz. 52).

Stap 7: discussieer over de resultaten en maak de uiteindelijke beslissing Tijdens deze laatste stap gaat men met het projectteam nog een laatste maal discussiëren over de mogelijke kandidaten om dan tot de uiteindelijke beslissing te komen.

2.2.2

Verschillen in het selectieproces tussen kmo’s en grote ondernemingen

Een groot deel van de grote ondernemingen hebben reeds een ERP-systeem geïmplementeerd, vandaar dat ERP-verkopers zich ook zijn gaan toespitsen op kleine en middelgrote ondernemingen. Daarom is het aangewezen te wijzen op de verschillen in de eisen die kmo’s en grote ondernemingen stellen. Dit heeft bovendien zijn gevolgen op het selectie- en implementatieproces. Zo zullen kmo’s minder eisen stellen op het vlak van flexibiliteit (organisatorische flexibiliteit, verbeterd vermogen tot innovatie…) doordat ze door hun beperkte grootte sowieso erg flexibel zijn. Flexibiliteit van de software wordt dan weer belangrijker geacht om bijvoorbeeld hun unieke bedrijfsprocessen te beschermen (Bernroider en Koch, 2001, blz. 253). Het belang van compatibiliteit met de bestaande

- 22 -

Tim Vermeersch


processen is voor kmo’s dus erg groot (Van Everdingen et al., 2000, blz. 28). Vaak ontbreekt het de kmo’s aan de nodige middelen en daarom is een korte implementatietijd ook enorm belangrijk. Verrassend is misschien wel dat kmo’s het minder belangrijk vinden of een ERP-systeem ook in andere landen beschikbaar is terwijl de trend van integratie tussen verschillende ondernemingen en wereldwijde e-commerce zich verder zet (Bernroider en Koch, 2001, blz. 253). Op het vlak van verschillen in het selectieproces is er een eerste opvallend verschil op het vlak van informatieverzameling. De analyse van een prototype, het gebruik van consultants, het extern aankopen van studies zijn methoden die enkel door grote ondernemingen worden toegepast. Het is duidelijk dat kmo’s de duurdere methodes trachten te mijden (Bernroider en Koch, 2001, blz. 255). Ook

het

beslissingsproces

zelf

toont

heel

wat

verschillen.

Terwijl

kmo’s

vooral

statische

investeringstechnieken gaan gebruiken, zullen grote ondernemingen vaak dynamische procédés hanteren. Het gebruik van optietheorieën of methodes waarbij een rangschikking gemaakt wordt, zoals het AHP-model, zijn hen niet vreemd. Kmo’s daarentegen durven al eens meer gebruiken maken van minder formele manieren om tot een beslissingen te komen (Bernroider en Koch, 2001, blz. 255). Het beslissingsproces bij kmo’s duurt gemiddeld 19,3 weken en brengt een kost mee van €30 000. Bij grote ondernemingen neemt deze beslissing dan weer 26,8 weken in beslag terwijl de kost gemiddeld heel wat hoger ligt dan bij kmo’s, namelijk €72 000. Opmerkelijk bij kmo’s is dat de uiteindelijke beslissingsbevoegdheid vaker gecentraliseerd is bij de IT-afdeling. Andere departementen worden hier dikwijls minder geraadpleegd (Bernroider en Koch, 2001, blz. 256).

2.3 2.3.1

DE IMPLEMENTATIE VAN EEN ERP-SYSTEEM De implementatiekost

De implementatie van een ERP-systeem is een vrij dure aangelegenheid. Zelfs bij kleine ondernemingen kan de prijs oplopen tot meer dan 1 miljoen dollar. Voor grote ondernemingen kan dit zelfs enkele tientallen miljoenen dollar bedragen. Indien de kost als aandeel van de jaarlijkse inkomsten bekeken wordt, bedraagt dit ongeveer 1,5 tot 6 procent. Bij kleine ondernemingen ligt dit aandeel iets hoger dan bij grote, wat betekent dat er toch sprake is van ‘economies of scale’ ofwel schaalvoordelen. Het gaat hier dan alleen nog maar over de eenmalige implementatiekosten, daarbovenop komen ook operationele en onderhoudskosten (Mabert et al., 2001, blz. 73). Als we de implementatiekost nader bekijken, kan opgemerkt worden dat de software slechts een fractie van de totale kost bedraagt. Het leeuwendeel van het budget gaat vaak op aan consultants. Vooral tijdens de jaren ‘90 was dit een groot probleem omdat toen ervaren consultants erg schaars waren en 1600 tot 2500 dollar per dag durfden aan te rekenen (Mabert et al., 2001; Bingi et al., 1999). Bovendien

- 23 -

Tim Vermeersch


duurt een typische implementatie ongeveer tussen de 14 en 23 maanden en kan ze tot 150 consultants vergen (Bingi et al., 1999; Umble et al., 2003). Onderstaande tabel geeft een overzicht van de andere kostensoorten.

Tabel 4

Aandeel van de verschillende implementatiekosten

Soort kost

Gemiddelde kost

Betrouwbaarheidsinterval

Consultants

30%

20-60%

Hardware/infrastructuur

25%

0-50%

Implementatieteam

15%

5-20%

Training

15%

10-20%

Software

15%

10-20%

Bron: Mabert et al., 2001, blz. 73

De ‘return on investment’ (ROI) varieert sterk van onderneming tot onderneming. Indien men dit bekijkt over een periode van 6 jaar merken Umble et al. (2003) gemiddeld een verlies van 1,5 miljoen dollar. Kijkt men over een langere periode, dan ligt de ROI gemiddeld tussen 5 en 20 procent (Mabert et al., 2001, blz. 73). Gewoonlijk kent men aanvankelijk een daling in de productiviteit waarna deze dan opnieuw geleidelijk stijgt. Na 12 maanden wordt doorgaans het punt bereikt waarop men volop de mogelijkheden van het systeem kan benutten (Mabert et al., 2001, blz. 73). Een vlotte en snelle implementatie kan heel wat kosten besparen zodat de return on investment heel wat hoger komt te liggen. Het belang van een zorgeloze implementatie is dus erg groot. Vandaar dat in volgende punten enkele implementatiemodellen gegeven worden die hierbij kunnen helpen.

2.3.2

Het 5-fasen model van Ross en Vitale

Het model dat als eerste beschreven zal worden is het 5-fasen model van Ross en Vitale. Dit model wordt vooral gekenmerkt door een gebrek aan detail. Het omschrijft vrij vaag de verschillende stadia van een implementatieproces, die eigenlijk in elk model voorkomen. Bovendien zijn de grenzen tussen de verschillende fases vrij onduidelijk en zijn de uitkomsten, laat staan optimale uitkomsten, van elke fase niet beschreven. Men laat zelfs enkele belangrijke punten achterwege zoals bijvoorbeeld het belang van een goed selectieproces voor een gepast ERP-pakket. Het model is wel nuttig om een eerste beeld te krijgen van hoe een implementatie globaal verloopt. Ross en Vitale (2000, blz. 235) vergelijken de fases in het implementatieproces van een ERP-systeem met de ontsnapping van een gevangene uit een op een eiland gelegen gevangenis. Eerst zal de gevangene een ontsnappingsplan maken met daarin de route die hij zal nemen. Vervolgens zal hij van de

- 24 -

Tim Vermeersch


rots moeten springen en naar de bodem van de zee zinken. Daarna zal hij proberen terug aan het wateroppervlak te geraken zonder in ademnood te belanden en erop hopend dat hij niet neergeschoten wordt eenmaal opnieuw zichtbaar. In de vierde fase bereikt hij het wateroppervlak en kan hij beginnen zwemmen naar zijn vrijheid. Ten slotte, als de ontsnapping een succes is, zal de gevangene de kust bereiken en een vrij man zijn. De vergelijkbare fases tijdens het implementatieproces van een ERPsysteem zijn: design, implementation, stabilization, continuous improvement en transformation (Ross en Vitale, 2000, blz. 235).

Figuur 5

Het 5-fasen model van Ross en Vitale

Performance Transformation

Continuous Improvement Design Implementation

Stabilization

Time Bron: Ross J., 1999, blz. 66

ERP design Tijdens de eerste fase (het opstellen van het ontsnappingsplan) wordt men voor 2 belangrijke keuzes gesteld. De eerste gaat over de manier waarop de data door de onderneming zal stromen. Elk ERPpakket maakt verschillende veronderstellingen hierover en de onderneming moet beslissen deze te aanvaarden of aan te passen. Indien men beslist het systeem aan te passen, kan dit later problemen opleveren, bijvoorbeeld bij het uitbrengen van een nieuwe versie (Ross en Vitale, 2000, blz. 236). De tweede beslissing die genomen moet worden, gaat over de standaardisatie van de processen. Het management dient te beslissen of men de processen over heel de onderneming gaat standaardiseren tussen de verschillende regio’s, productlijnen, afdelingen… Dit is een belangrijke beslissing omdat het achteraf, na de implementatie van het ERP-systeem, nog moeilijk te veranderen is (Ross en Vitale, 2000, blz. 236).

Implementation Dit is de fase waarin de gevangene de duik neemt, bij het implementatieproces heet dit “going live”. Het ERP-systeem wordt in gebruik genomen. Dit gaat samen met de wijziging van de processen in de

- 25 -

Tim Vermeersch


onderneming. Het is onmogelijk om deze 2 zaken apart te implementeren omdat ze onderling te veel van elkaar afhankelijk zijn. Het is de bedoeling dat een implementatieteam tegen dan ook de gebruikers geïnformeerd heeft over het nieuwe systeem en de nieuwe processen (Ross en Vitale, 2000, blz. 236).

Stabilization Tijdens deze fase, waarin de gevangene opnieuw aan het oppervlak verschijnt, zal de onderneming proberen zich aan te passen aan de nieuwe situatie. In het begin zullen de prestaties, bijvoorbeeld de efficiëntie, een dipje kennen. Deze mindere periode duurt gewoonlijk vier tot twaalf maanden. Typische activiteiten zijn een grote schoonmaak in de data, additionele training voor de gebruikers en de laatste bugs in de software wegwerken, eventueel met de hulp van de ERP-verkoper en consultants (Ross en Vitale, 2000, blz. 237).

Continuous improvement Na de stabilisatie volgt gewoonlijk een fase waarin de onderneming meer functionaliteiten toevoegt aan het systeem, en dit aan de hand van nieuwe modules. Bovendien kunnen reeds significante voordelen geboekt worden zoals een verminderde voorraad, verhoogde voorraadrotatie, lagere logistieke kosten… Ontastbare voordelen bestaan uit grotere flexibiliteit, verhoogde systeembetrouwbaarheid… Tijdens deze fase werkt men niet alleen aan een continue verbetering van het systeem, maar probeert men ook verder de processen te wijzigen om de voordelen van het systeem nog meer te kunnen benutten. Dit stadium staat in de vergelijking met de gevangene equivalent met de fase waarin hij tracht naar het vasteland te

zwemmen (Ross en Vitale, 2000, blz. 237).

Transformation Indien de kust bereikt wordt, is de ontsnapping een succes. De kust kan bij de implementatie als het doel gezien worden en als de verschillende doelstellingen bereikt zijn, zal ook de implementatie een succes zijn. Deze kunnen sterk variëren: verbetering in de bedrijfsprocessen, verhoogde klantentevredenheid, mogelijkheid tot versnelde strategische beslissingen… Dit kan tot gevolg hebben dat de onderneming een ware transformatie ondergaat (Ross en Vitale, 2000, blz. 238). Het model van Ross en Vitale heeft duidelijk nog heel wat gebreken en gaat helemaal niet in detail de verschillende fase uitpluizen. De volgende modellen zijn heel wat uitvoeriger uitgewerkt.

2.3.3

De Process-theorie van Markus en Tanis

Het implementatiemodel dat Markus en Tanis (2000) ontwikkelden is wellicht het meest uitgebreide en gedetailleerde dat in de literatuur te vinden is. Het omvat een viertal fases: de project chartering fase, de

project fase, de shakedown fase en de onward and upward fase. De verschillende stadia zijn duidelijk afgebakend en na elke fase wordt een optimale uitkomst gegeven. Ondernemingen die al over een ERPsysteem beschikken, maar een belangrijke update van hun systeem doen, overlopen eveneens deze 4

- 26 -

Tim Vermeersch


fases.

Figuur 6

Het 4-fasen model van Markus en Tanis

Fase I

Project (configure & rollout)

Project Chartering

Ideas to dollars

Fase III

Fase II

Dollars to assets

Shakedown

Assets to impacts

Fase IV Onward and upward

Impacts to performance

Bron: Markus en Tanis, 2000, blz.189

Vooraf moet echter gewezen worden op 3 belangrijke punten. Ten eerste stelt men dat de aanwezigheid van noodzakelijke voorwaarden niet steeds voldoende is voor een succesvolle implementatie. Er kunnen zich steeds externe gebeurtenissen voordoen die er voor zorgen dat de implementatie niet loopt zoals verwacht. Een plotse recessie, veranderingen in de concurrententie-omgeving zijn maar enkele voorbeelden (Markus en Tanis, 2000). Het tweede punt waarop gewezen wordt, is dat de uitkomst van één fase de startvoorwaarde voor een volgende fase betekent. Beslissingen en acties in eender welke fase beïnvloeden bijgevolg het potentiële succes in de daaropvolgende fase(s). Bovendien werken in de verschillende fases ook verschillende groepen van mensen aan het project, wat een bijkomende moeilijkheid oplevert qua communicatie. Vermelden in samenvattend model Derde en laatste opmerking is dat de uitkomst van een fase bepaald wordt door zowel bedoelde acties en beslissingen als door de eerder vermelde externe gebeurtenissen die oncontroleerbaar zijn. Daarnaast kunnen beslissingen ook vertraagd een effect hebben op de implementatie (Markus en Tanis, 2000).

De project chartering fase De chartering fase bestaat uit alle beslissingen die uiteindelijk leiden tot de goedkeuring om te investeren in een ERP-systeem. Eerst en vooral ontstaat de idee om ERP-systeem te implementeren. Vandaar ook de bijnaam voor deze fase: “ideas to dollars”. Belangrijkste activiteiten die tijdens deze fase plaatsvinden zijn het maken van een bedrijfsplan met betrekking tot het ERP-systeem, de selectie van het softwarepakket (hoewel dit ook in de volgende fase kan gebeuren), het zoeken van een ervaren projectmanager en het opstellen van een tijdsschema en budget. De belangrijkste personen in deze fase zijn uiteraard de ERP-verkopers, eventuele consultants, de bestuurders van de onderneming en de ITspecialisten (Markus en Tanis, 2000). Het adequaat omschrijven van de eisen op het vlak van datatoegang en –rapportering is een vaak voorkomend probleem tijdens deze fase. Ook de contracten die met consultants en ERP-verkopers

- 27 -

Tim Vermeersch


opgesteld worden, kunnen eventueel moeilijkheden zorgen. De uiteindelijke uitkomst van deze fase is de beslissing om al dan niet te investeren in een ERP-systeem (Markus en Tanis, 2000). Indien beslist wordt om verder te investeren in een ERP-systeem, bestaat de mogelijkheid dat deze beslissing foutief is. Dit zal zijn gevolgen hebben later in het implementatieproces. Davenport (1998) geeft het voorbeeld van een gedecentraliseerde onderneming die beslist te investeren in een pakket dat bedrijfsprocessen standaardiseert, zodat voor dit bedrijf bepaalde voordelen verloren gaan.

De project fase De project fase omvat alle activiteiten die er voor zorgen dat het systeem werkt in één of meerdere afdelingen van de onderneming. Deze fase wordt ook wel eens de “dollars to assets” fase genoemd. De monetaire investering wordt als het ware omgezet in een activa voor de onderneming (Markus en Tanis, 2000). Eerst en vooral wordt de projectplanning opgesteld. Daarna start men met het selecteren van een projectteam dat de implementatie tot een goed einde moet brengen. Eenmaal het team samengesteld is, dient het opgeleid en getraind worden. Er moet ook beslist worden of men het systeem zal aanpassen aan de bestaande operaties, of omgekeerd de operaties zal aanpassen aan het systeem. Indien voor deze laatste optie gekozen wordt, kiest men dus voor Business Process Reengineering (BPR). Eventueel zal de noodzaak bestaan om de organisatiestructuur te wijzigen (Markus et al., 2000). De software zal dus geconfigureerd worden naar de noden van de onderneming en misschien zullen oude systemen naast het nieuwe blijven bestaan. Integratie tussen beide systemen zal eveneens nodig zijn. Ondertussen dient de implementatie aan de werknemers gecommuniceerd te worden zodat deze weten wat hen te wachten staat (Markus en Tanis, 2000). Het laatste dat in deze fase nog moet gebeuren is de training en opleiding van de eindgebruikers (Markus et al., 2000). Belangrijkste actoren tijdens deze fase zijn de projectmanager, het projectteam, de interne ITspecialisten, de verkopers en de consultants (Markus en Tanis, 2000). Opnieuw zijn er verschillende uitkomsten mogelijk voor deze fase. Het project kan geannuleerd worden, bijvoorbeeld wegens te grote technische problemen of de implementatie kan verder gezet worden (Markus en Tanis, 2000). Tijdens deze fase worden de grootste uitgaven gedaan, bijgevolg worden er hier weinig winsten geboekt. Gevolg is dat hoe langer de project fase duurt, des te lager de financiële voordelen zullen uitvallen indien C

men werkt met de discounted cash flow methode (DCF) (Markus et al., 2000).

C

Discounted cash flow methode (netto contante waarde methode): “bepaalt de contante waarde van alle kasstromen van een investeringsproject met behulp van een gegeven minimumrendement na belastingen. Indien de netto contante waarde groter is dan of gelijk is aan 0, wordt het project aanvaard. Zo niet, wordt het verworpen (Ooghe et al., 2003).”

DCF =

CF1 1 (1 + r)

+

CF2 CFn 2 + … + n (1 + r) (1 + r)

Met CF = in- of uitgaande kasstroom in een bepaalde periode t r = minimumrendement

- 28 -

Tim Vermeersch


De shakedown fase De derde fase in het Markus en Tanis model betreft de shakedown fase. Deze fase eindigt wanneer de onderneming opnieuw normale operaties en een dagelijkse routine bereikt heeft. Het projectteam kan dan de controle aan de operationele managers en de eindgebruikers overdragen. Een andere mogelijkheid is dat de onderneming de implementatie opgeeft en het systeem desinstalleert (Markus en Tanis, 2000). De belangrijkste activiteiten tijdens deze fase hebben vooral betrekking op het oplossen van kleinere technische problemen. Het systeem wordt verder “ge-finetuned”. Aan eindgebruikers worden additionele training aangeboden en ze worden ingelicht over eventuele wijzigingen. Dit is de fase waarin fouten die in eerdere fases gemaakt werden voelbaar worden in de vorm van verminderde productiviteit of problemen in het productieproces, bijvoorbeeld stockbreuken. Vandaar ook de alternatieve naam voor deze fase: assets to impacts (Markus en Tanis, 2000). Dit betekent niet dat er zich in deze fase geen problemen meer kunnen voordoen.

De onward en upward fase De laatste fase is de onward en upward fase, deze start eenmaal de dagelijkse routine bereikt is en eindigt wanneer het systeem vervangen wordt door een upgrade of een ander systeem. Hier tracht men de productiviteit nog te verhogen door middel van continuous improvement (Kraemmeraard et al., 2003). Het is tijdens deze fase dat de onderneming de vruchten plukt van de investering en dus de beoogde voordelen tracht uit te buiten (Markus en Tanis, 2000): impacts to performance. Deze baten laten echter soms op zich wachten en dit om een aantal redenen. Veel voordelen doen zich pas voor eenmaal de gebruikers het systeem echt beheersen. Daarnaast moeten ook managers leren omgaan met de data verkregen via het nieuwe ERP-systeem om beslissingen te nemen. Voordelen zullen ook hier dus maar later merkbaar zijn. Eventueel is het mogelijk dat nog wijzigingen moeten gebeuren in het productieproces, de configuratie van de software… (Markus et al., 2000). Bijkomende training van de eindgebruikers kan steeds zijn nut hebben. Tijdens deze fase kan mogelijks reeds gestart worden met het plannen van de implementatie van additionele modules en nieuwere versies (Markus et al., 2000). Elke onderneming zal bij de implementatie elk van voorgaande fases doorlopen, maar geen enkele implementatie zal echter dezelfde zijn. Toch kunnen enkele regelmatigheden onderscheiden worden. In elke fase kunnen enorm veel dingen fout gaan. Bovendien zijn niet alle fouten direct merkbaar en kunnen ze niet onmiddellijk rechtgezet worden. Voor elke fase zijn er verschillende uitkomsten mogelijk. Voor de chartering fase bijvoorbeeld kan de beslissing om verder te gaan met het project met een goed bedrijfsplan een optimale uitkomst zijn. Beëindiging van het project is een tweede. Een derde afloop kan de beslissing zijn verder te werken met onontdekte fouten of niet gecorrigeerde problemen. Deze derde uitkomst heeft een welbepaalde variantie. In het algemeen zijn er verschillende personen betrokken tijdens de verschillende fases van de implementatie. Dit vergroot de waarschijnlijkheid dat fouten uit vorige fases ook verder niet ontdekt en opgelost worden totdat ze uiteindelijk een significant probleem opleveren voor de verdere implementatie (Markus en Tanis, 2000).

- 29 -

Tim Vermeersch


Bij dit model dient ten slotte opgemerkt te worden dat de eigenlijke implementatie van het ERP-systeem slechts in 1 fase beschreven wordt zonder verder in detail te treden. Volgend model komt tegemoet aan deze tekortkoming.

2.3.4

Het Project Phase Model

Het project phase model (PPM) omvat 3 belangrijke fases: planning, project en enhancement. Opvallend in de voorgaande modellen is dat de eigenlijke implementatie telkens in slechts één fase gebeurt. In het 5-fasen model van Ross en Vitale is dit tijdens de “implementation”, in de process-theorie van Markus en Tanis tijdens “de project fase”. Dit is dan ook meteen de sterkte van het project phase model. Het project phase model splitst deze fase, “de project fase”, op in 5 kleinere subfases: set up, re-engineer, design, configuration & testing en installation. Ten slotte is het nog belangrijk op te merken dat het project phase model de implementatie zuiver als een project ziet. Een succesvolle implementatie betekent hier dan ook enkel het project binnen de vooropgestelde planning en het vooropgestelde budget blijft (Parr en Shanks, 2000, blz. 291).

Figuur 7

Het Project Phase Model

FASE 1

FASE 2

FASE 3

PLANNING

PROJECT

ENHANCEMENT

SET UP

INSTALLATION

CONFIGURATION & TESTING

RE-ENGINEER

DESIGN

Bron: Parr en Shanks, 2000, blz. 292

Planning fase Tijdens de planning fase wordt een ERP-systeem geselecteerd. Er wordt ook bepaald in welke mate men de implementatie zal doorvoeren. Daarmee wordt bijvoorbeeld bedoeld dat beslist wordt of men slechts enkele modules installeert of zo veel mogelijk, in enkele afdelingen of allemaal… Daarnaast wordt een projectmanager aangesteld en ten slotte dient vastgelegd te worden met welke middelen dit alles gefinancierd zal worden (Shanks en Parr, 2000, blz. 291).

- 30 -

Tim Vermeersch


Project fase Het tweede en meest belangrijke stadium is de project fase. Omdat de focus eigenlijk op deze fase ligt, is ze dan ook onderverdeeld in 5 subfases:

• In de set up fase wordt het implementatieteam samengesteld. Dit moet zowel uit mensen bestaan met technische kennis, als uit mensen met kennis over de onderneming en de bedrijfsprocessen. Dit team moet goed geïntegreerd zijn zodat de communicatie vlot verloopt. Rapporteringregels worden eveneens vastgelegd.

• Tijdens het re-engineering stadium gaat men de huidige bedrijfsprocessen analyseren met als bedoeling te weten komen hoe sterk men aan BPR zal moeten doen. Het ERP-systeem wordt geïnstalleerd en de bedrijfsprocessen worden dan ook aangepast aan de functionaliteiten van het ERP-systeem.

• De design subfase legt dan weer de laatste hand aan het aanpassen van zowel de processen als het systeem zodat deze optimaal op elkaar afgestemd zijn. Belangrijk tijdens deze fase is dat er communicatie bestaat tussen het implementatieteam en de uiteindelijke gebruikers. Deze laatste moeten weten waar ze straks aan toe zijn, eenmaal het systeem ten volle gebruikt wordt.

• Eén van de belangrijkste activiteiten tijdens de configuration & testing fase is de ontwikkeling van een uitgebreide configuratie. In het systeem wordt reële data ingevoerd. De verschillende interfaces dienen grondig getest te worden, maar ook de manier waarop rapporten zullen geschreven worden moet al eens uitgeprobeerd worden. Ten slotte dient het systeem in zijn geheel grondig getest te worden.

• De laatste subfase is de installation. Daarin worden de nodige desktops geïnstalleerd en wordt het netwerk opgebouwd. Héél belangrijk tijdens deze fase is het opleiden en trainen van de eindgebruikers. Bovendien moeten ze ook later nog ergens terecht kunnen met al hun problemen (Parr en Shanks, 2000, blz 292).

Enhancement fase Ten slotte is er nog de enhancement fase. Deze fase kan meerdere jaren duren en omvat allerlei zaken als het herstellen van het systeem na eventuele problemen, verdere uitbreiding of het updaten met nieuwere versies. Deze fase is vergelijkbaar met de “continuous improvement” en “stabilization” fases bij Ross en Vitale en “de onward en upwards” fase bij Markus en Tanis (Parr en Shanks, 2000, blz 291). Dit model kan bekritiseerd worden doordat het vrij sterk gefocust is op de implementatie van de software en in mindere mate op de het organisatorische en de bedrijfsprocessen. Het volgende model daarentegen, dat van Cooper en Zmud, benadrukt dit veel sterker.

- 31 -

Tim Vermeersch

2.3.5


Het 6-fasen model van Cooper en Zmud

Het model dat Cooper en Zmud (1990) ontwikkelden, omvat zes fases: initiation, adoption, adaptation, acceptance, routiniziation en infusion. Oorspronkelijk beschreef het de implementatie van MRPsystemen. Maar aangezien ERP-systemen zoals eerder vermeld een verdere evolutie zijn van MRPsystemen, kan dit model gemakkelijk uitgebouwd worden voor de implementatie van ERP-systemen (Rajagopal, 2002). Dit model valt op doordat het vooral oog heeft voor het organisatorische aspect van de implementatie en minder voor de technische kant. Zo wordt bijvoorbeeld veel aandacht geschonken aan de weerstand die het personeel gewoonlijk heeft tegenover veranderingen in de onderneming. En zoals reeds duidelijk geworden is, brengt de implementatie van een ERP-systeem heel wat veranderingen met zich mee.

Figuur 8

Het 6-fasen model van Cooper en Zmud Volgende Innovatie

INITIATION

INFUSION

ADOPTION

ERP Implementatie

ROUTINIZATION

ADAPTATION

ACCEPTANCE

Bron: Rajagopal, 2002, blz. 92

Initiation De eerste fase, de initiation stage, wordt getypeerd door een aantal factoren die de onderneming ertoe beïnvloeden een geïntegreerd ERP-systeem te implementeren (Rajapogal, 2002). Deze wil om te veranderen kan komen vanuit organisatorisch of technologisch opzicht, of beide (Cooper en Zmud, 1990). Een onderneming kan het bijvoorbeeld nodig achten om over snellere beslissingsprocessen te beschikken en dit door middel van real-time data die steeds opvraagbaar is (Rajapogal, 2002).

- 32 -

Tim Vermeersch


Adoption Tijdens deze tweede fase wordt aan de hand van een kosten-batenanalyse de investeringsbeslissing definitief. Daarnaast wordt de beslissing getroffen met welk ERP-pakket of welke ERP-verkoper verder gewerkt zal worden. In sommige gevallen duurt deze fase meer dan een jaar alvorens men een gepaste verkoper gevonden heeft (Rajapogal, 2002). Eenmaal het pakket gekozen, zal het nog aangepast moeten worden aan de noden van de onderneming.

Adaptation Tijdens deze fase wordt het ERP-systeem ontwikkeld, geïnstalleerd en onderhouden. De uiteindelijke uitkomst van deze fase is een systeem dat klaar is voor gebruik in de onderneming (Cooper en Zmud, 1990). Dit is echter het moeilijkste stadium van de implementatie aangezien men volledig inzicht moet hebben in de productieprocessen. Het is noodzakelijk dat de bedrijfsprocessen gedetailleerd geanalyseerd worden en men op zoek gaat naar eventuele verbeteringen. Om ten volle van de voordelen van de ERP technologie te profiteren, moeten de bedrijfsprocessen opnieuw ontworpen worden (Rajagopal, 2002).

Acceptance Nadat in de vorige fase het ERP-systeem geïnstalleerd werd, worden hier de eindgebruikers ertoe aangezet het systeem toe te passen (Cooper en Zmud, 1990). Deze gebruikers kunnen ook aangeven waar zich nog problemen voordoen. Een proces van continuous improvement ontstaat dan waardoor fouten snel verbeterd worden en het systeem gemakkelijk te gebruiken wordt. Tijdens deze fase zouden de voordelen van het gebruik van het nieuwe systeem duidelijk moeten worden (Rajagopal, 2002). Ideale uitkomst van deze fase zou een algemeen gebruik moeten zijn door de gehele organisatie (Cooper en Zmud, 1990).

Routinization Het gebruik van het ERP-systeem wordt tijdens deze fase een dagelijkse routineactiviteit. Het is de bedoeling dat de eindgebruikers het systeem aanvaard hebben. Vroeger werkte men met verschillende programma’s, verspreide informatie, verouderde data… terwijl men nu met 1 programma bezig is dat real-time informatie verschaft (Rajagopal, 2002). Deze fase heeft als optimale uitkomst dat het ERPsysteem niet langer als iets ongewoons waargenomen wordt (Cooper en Zmud, 1990).

Infusion Het systeem wordt nu gebruikt om de prestaties van de onderneming te verbeteren (Rajagopal, 2002). Tijdens de infusion fase wordt het potentieel van het ERP-systeem zo veel mogelijk benut (Cooper en Zmud, 1990). Wegens de snelle ontwikkelingen in de technologie kan dit echter wel de kortste fase van dit implementatiemodel zijn. Indien een onderneming bijvoorbeeld erg tevreden is over het geïmplementeerde systeem, kan het al snel beslissen nieuwe modules, updates… te implementeren. Dit brengt de organisatie dan meteen weer bij de initiation fase waardoor de cirkel rond is (Rajagopal, 2002).

- 33 -

Tim Vermeersch


Dit model heeft duidelijk een aantal sterke punten. De organisatorische aspecten, net als de veranderingen in de bedrijfsprocessen worden goed uitgewerkt. Ook de optimale uitkomst na elke fase is een goed punt dat in dit model naar voor komt.

2.3.6

Samenvattend implementatiemodel

Hierboven werd een overzicht gegeven van de meest belangrijke modellen die in de vakliteratuur te vinden zijn. Een eerste stap om de onderzoeksvraag te beantwoorden, is de ontwikkeling van één algemeen implementatiemodel. In een later hoofdstuk (hoofdstuk 4) wordt dit dan verder uitgewerkt om tot een volledig antwoord te komen. In dit samenvattend model worden de beschreven modellen samengevat waarbij telkens de sterke punten van elk model weerhouden worden terwijl de mindere aspecten achterwege gelaten worden. Dit heeft geleid tot onderstaand implementatiemodel dat 5 fases heeft: selectie, implementatieteam, implementatie, gewenning & routine en ten slotte continuous improvement. De implementatiefase wordt naar voorbeeld van het project phase model onderverdeeld in enkele subfases, meer bepaald 3: BPR, installatie en systeem testen. Vooraf moet opgemerkt worden dat in dit model verondersteld wordt dat men in de onderneming reeds de beslissing genomen heeft te investeren in een ERP-systeem. Er wordt van uit gegaan dat deze beslissing op een rationele manier tot stand gekomen is, bijvoorbeeld via een kosten-batenanalyse. Welk systeem geïmplementeerd zal worden, werd echter nog niet beslist. Deze veronderstelling is in tegenstelling tot het model van Cooper en Zmud waarbij men in de initiation fase nog moet beslissen al dan niet te investeren in een ERP-systeem. Eén van de sterke punten van het model van Markus en Tanis en dat van Cooper en Zmud is dat na elke fase een optimale uitkomst gegeven wordt. Naar analogie van deze modellen wordt hier dan ook na elke fase een optimaal resultaat gegeven. Bijgevolg is de uitkomst van één fase de startvoorwaarde voor een volgende fase. Beslissingen en acties in eender welke fase beïnvloeden dus het potentiële succes in de daaropvolgende fase(s).

- 34 -

Tim Vermeersch

Figuur 9


Samenvattend implementatiemodel

SELECTIE

IMPLEMENTATIETEAM

IMPLEMENTATIE

BPR

GEWENNING & ROUTINE

CONTINUOUS IMPROVEMENT

Systeem testen

Installatie Bron: eigen voorstelling

Selectie De eerste fase in dit model is de selectie van een ERP-systeem. In de voorgaande modellen werd telkens het belang van een gepast ERP-systeem sterk benadrukt. Bijgevolg wordt de selectie als erg belangrijk beschouwd. Wat echter in elk model ontbreekt, is een duidelijke omschrijving van hoe het selectieproces moet plaatsvinden. Vandaar dat in dit model de selectie als een aparte fase in het implementatieproces omschreven wordt. Het selectieproces moet duidelijk gestructureerd zijn en daarom wordt het AHP selectiemodel aangeraden. Andere rationele selectieprocessen zijn uiteraard ook mogelijk. Belangrijk tijdens deze fase is dat een goed gebalanceerd selectieteam gevormd wordt zoals vermeld in het AHP selectiemodel. Bovendien worden tijdens dit stadium de eisen en karakteristieken die van het systeem verwacht worden al vastgelegd. Het zou voor de onderneming dus al vrij duidelijk moeten zijn welke modules geïmplementeerd zullen worden, welke wijzigingen de organisatiestructuur zal ondergaan, welke veranderingen in het productieproces zullen plaatsvinden… De optimale uitkomst van deze fase kan als volgt omschreven worden: de onderneming heeft beslist te investeren in een gepast ERP-systeem dat voldoet aan de gestelde eisen. Een goede relatie met de ERP-verkoper is eveneens een noodzakelijke voorwaarde.

Implementatieteam Eenmaal deze beslissing genomen is, kan men starten met het vormen van een implementatieteam. Indien tijdens het selectieproces een goed selectieteam gevormd werd, kan dit als basis dienen voor het implementatieteam. De vorming van het team wordt als een apart stadium in de implementatie gezien omdat het tijdens het volledige proces een cruciale rol heeft. Het is dus erg belangrijk dat deze groep goed samengesteld is met enerzijds teamleden met technische kennis als met teamleden die eerder een commerciële functie hebben. Essentieel voor de goede werking van het team is een uitstekende communicatie tussen de verschillende leden. Aan het hoofd van het team dient een bekwame project champion te staan die voldoende leiderscapaciteiten heeft. Naast het implementatieteam zelf is ook de stuurgroep belangrijk om hen de nodige steun te verschaffen. Daarnaast kunnen nog eens externe consultants onder de arm genomen worden die met hun specifieke ervaring de implementatie vlotter

- 35 -

Tim Vermeersch


zullen laten verlopen. Zoals in voorgaand stadium, kent ook deze fase een optimaal resultaat. Er dient voor gezorgd te worden dat een gebalanceerd team gevormd is met aan het hoofd een bekwame project champion en dit alles geruggensteund door de stuurgroep. De onderstaande figuur geeft dergelijke optimale structuur weer.

Figuur 10

De structuur van het volledige implementatieteam

Stuurgroep

Project champion

Externe Consultant(s)

Implementatieteam Bron: Eigen voorstelling gebaseerd op Welti, 1999, blz. 108

Implementatie Deze fase is sterk gebaseerd op de projectfase van het project phase model aangezien hier dit stadium erg gedetailleerd uitgewerkt is in tegenstelling tot de overige modellen. Er worden echter enkele subfases achterwege gelaten of samengevoegd. Zo valt de set up fase weg omdat hier het implementatieteam reeds samengesteld is. Ook worden de re-engineer en de design fase samengenomen omdat verondersteld wordt dat een grondig selectieproces de implementatie voorafgaat. Daarom is het niet meer noodzakelijk te analyseren welke processen zullen wijzigen en hoe de structuur aangepast zal worden. De eerste taak die het implementatieteam dient te volbrengen is het opstellen van een projectplanning. Van zodra deze planning opgemaakt is, kan gestart worden met de eigenlijke implementatie van het systeem. In dit model wordt dit opgesplitst in 3 subfases: BPR, de installatie van het systeem en ten slotte moet het nog getest worden. Indien men een grondig selectieproces gevolgd heeft, zou tijdens de eerste fase, de selectie, al duidelijk gebleken moeten zijn welke processen wijzigingen zouden ondergaan. Ook op het vlak van de organisatiestructuur zouden de veranderingen dan reeds gekend moeten zijn. Deze aanpassingen zullen nu, tijdens de BPR fase, in de praktijk omgezet moeten worden. Terwijl dit gebeurt, kan gestart worden met de installatie van het systeem op de computers. Bijgevolg zullen de bedrijfsprocessen en het ERPsysteem op elkaar afgestemd worden. Indien de nodige infrastructuur niet aanwezig is, is dit het ogenblik om de noodzakelijke hardware te installeren. De laatste fase omvat het testen van het systeem. De

- 36 -

Tim Vermeersch


verschillende interfaces dienen getest te worden en reële data moet ingevoerd worden om eventuele fouten nog voor “going live” te ontdekken. Lijkt alles in orde dan kan het systeem daadwerkelijk in de praktijk toegepast worden. Het ideale resultaat van de implementatiefase is een ERP-systeem dat online is met een minimum aan fouten.

Gewenning en routine Nu het systeem in werking is, moet het natuurlijk correct gebruikt worden door de gebruikers. Zoals tijdens de stabilization fase in het model van Ross en Vitale bestaat de mogelijkheid dat de onderneming een aanpassingsperiode nodig heeft waardoor aanvankelijk de efficiëntie een dipje kent. Het is dan erg belangrijk dat de gebruikers goed opgeleid en getraind worden zodat ze snel overweg kunnen met het nieuwe systeem. Een vaak voorkomend probleem dat in veel artikels vermeld wordt, is het wat men noemt “resistance to change”. Bij de eindgebruikers bestaat een soort aversie tegen veranderingen in de onderneming. Een gevolg daarvan zou kunnen zijn dat indien men in het begin problemen kent met de nieuwe manier van werken, men al snel zal teruggrijpen naar de oude methodes en systemen. Bijgevolg zou een miljoeneninvestering alsnog kunnen falen. De optimale uitkomst van de gewenning en routine fase is een ERP-systeem dat algemeen gebruikt wordt in de hele onderneming zonder dat men teruggrijpt naar de oude manier van werken of naar de oude systemen.

Continuous Improvement Zo wordt de laatste fase bereikt. Tijdens dit laatste stadium is het de bedoeling de efficiëntie van de onderneming te verhogen. De prestaties van het systeem moeten dus geoptimaliseerd worden, eventuele kleine fouten worden nog weggewerkt. Indien de ERP-verkoper upgrades aanbiedt, is het aan te raden deze eveneens te implementeren. Eventueel kunnen later nieuwe modules aan het bestaande systeem toegevoegd worden. Het uiteindelijke resultaat dat bereikt dient te worden is een systeem dat perfect werkt en regelmatig geüpdatet wordt zodat het steeds up to date blijft.

2.4

WANNEER IS DE IMPLEMENTATIE EEN SUCCES?

Er zijn al heel wat studies verricht naar de factoren die bijdragen tot het succes van de implementatie van IS-systemen. Wat juist bedoeld wordt met succes, is echter veel moeilijker te definiëren. Uit onderzoek van KPMG Management Consulting blijkt dat van alle ondernemingen die gereageerd hebben op hun enquête, 89% beweerde dat hun implementatie succesvol was. Slechts een kwart van hen had echter alle vooropgestelde voordelen gekwantificeerd en behaald (Markus en Tanis, 2000). Dit toont duidelijk

- 37 -

Tim Vermeersch


aan dat men in de praktijk zelden termen als succes en faling definieert en kwantificeert. Nochtans zijn er voldoende maatstaven voorhanden. Verrassend genoeg wordt succes in de praktijk meestal bepaald door slechts 2 factoren: op tijd en binnen budget (Rosemann en Wiese, 1999). Hier worden een zevental maatstaven onderscheiden:

• Gebruikerstevredenheid • Geplande efficiëntieverbeteringen van de onderneming • Oliver Wights ABCD classificatieschema

D

• Op tijd • Binnen budget • De mate waarin het systeem benut wordt door de gebruikers • Vooraf vastgelegde ondernemingsdoelstellingen Van bovenstaande criteria is de ABCD-classificatie van Wight in ieder geval onbruikbaar als maatstaf voor ERP-implementaties. ERP-systemen zijn zo ontworpen dat de modules perfect met elkaar geïntegreerd zijn, zodat alle ondernemingen tot de klasse A zouden behoren. De mate waarin het systeem benut wordt door de gebruikers kan evenmin als maatstaf voor succes gebruikt worden. Eenmaal het systeem volledig geïnstalleerd en geïmplementeerd is, zal het gebruik, bij gebrek aan een alternatief, verplicht worden. Zelfs als een implementatie niet op tijd of binnen het budget klaar raakt, kan ze door de betrokken onderneming nog steeds als een succes gezien worden, bijvoorbeeld indien op lange termijn de baten van het ERP-systeem toch nog groter zijn dan de kosten (Zhang et al., 2005). Bijgevolg blijven er maar 3 criteria over om het succes van een ERP-implementatie te meten: gebruikerstevredenheid, geplande efficiëntieverbeteringen van de onderneming en vooraf vastgelegde ondernemingsdoelstellingen. Bovendien kunnen deze laatste 2 samengenomen worden als de mate waarin aan de doelstellingen van het management voldaan wordt (Zhang et al., 2005). Eén maatstaf om succes van een ERP-systeem te meten volstaat duidelijk niet. Daarom is het beter er een multidimensionale visie op na te houden (Markus en Tanis, 2000). DeLone en McLean (1992) ontwikkelden een model om succes te meten aan de hand van meerdere maatstaven. Een meer recente techniek die gehanteerd wordt om de mate van succes van een ERP-implementatie te meten, is de balanced scorecard.

D Oliver Wights ABCD classificatieschema was oorspronkelijk een classificatieschema voor MRP II-gebruikers. Ze werd aanvankelijk gebruikt voor ondernemingen die al een MRP II-systeem gebruiken en ze evalueert de efficiëntie en effectiviteit ervan. Later ging men zich concentreren op de implementatie van MRP II. Wight ontwierp een checklist (Wight’s ABCD checklist) om de waarschijnlijkheid van een succesvolle MRP II-implementatie te evalueren. Een klasse A onderneming heeft een voorraadsysteem geïntegreerd met de marketing-, productie-, financiële… afdeling. Een klasse B heeft eveneens een goed productie- en voorraadcontrolesysteem, maar verschilt van een klasse A doordat het systeem zich niet uitstrekt over de hele onderneming. Bij een klasse C wordt het voorraadsysteem enkel gebruikt voor het verwerken van orders, terwijl bij een klasse D het enkel gebruikt wordt als dataverwerkingssysteem en weinig impact heeft op de operaties (Burns et al., 1991).

- 38 -

Tim Vermeersch


In punt 1.6 werd een overzicht gegeven van de verschillende voordelen van ERP-systemen. De mate waarmee deze baten voelbaar zijn, kan als basis dienen voor deze multidimensionele visies.

2.4.1

Het DeLone en McLean informatiesysteem succes model

DeLone en McLean (1992) bouwden een model om de mate van succes waarmee een informatiesysteem geïmplementeerd werd, te meten. Succes omvat volgens hen 6 dimensies:

• Kwaliteit van het informatiesysteem • Kwaliteit van de informatie gegenereerd door het systeem • Gebruik (zowel van het systeem als de gegenereerde informatie) • Gebruikerstevredenheid • Individuele impact: het effect dat de informatie op het gedrag van de gebruikers heeft • Organisatorische impact: het effect dat de informatie op de prestaties van de onderneming heeft

Figuur 11

De 6 dimensies van succes

Kwaliteit van het systeem

Gebruik

Individuele impact Kwaliteit van de informatie

Organisatorische impact

Gebruikerstevredenheid

Bron: DeLone en McLean, 1992, blz. 87; Zhang et al., 2005, blz. 59

Bovenstaande figuur toont aan dat zowel de kwaliteit van het systeem als de gegenereerde informatie het gebruik en de gebruikerstevredenheid beïnvloeden. Gebruik en gebruikerstevredenheid kunnen positief of negatief op elkaar werken (Delone en McLean, 1992). Indien we ze op een procesgerichte manier bekijken, dan moet gebruik logischerwijze gebruikerstevredenheid voorafgaan. Op een causale manier zullen positieve ervaringen met het systeem eveneens gebruikerstevredenheid induceren. Bovendien zal toegenomen gebruikerstevredenheid dan weer het gebruik verder doen toenemen (DeLone en Mclean, 2002). Deze 2 factoren hebben dan weer directe invloed op de individuele impact. De individuele impact bepaalt ten slotte de impact op de organisatie (Delone en McLean, 1992).

- 39 -

Tim Vermeersch


Gebruik van het ERP-systeem is gewoonlijk verplicht, bijgevolg hebben de kwaliteit van het systeem zelf en de informatie geen invloed op het gebruik ervan. Dit betekent dat deze 3 dimensies moeilijk als maatstaf voor succes gehanteerd kunnen worden. Technische kwaliteit van het systeem is dus noodzakelijk, maar niet voldoende om succes te garanderen (Zhang et al., 2005). Gebruikerstevredenheid wordt hier als volgt gedefinieerd:

“User satifaction is defined as the extent to which users believe the information system available to them meets their information requirements (Ives et al., 1980).” De individuele impact verwijst naar het effect dat de verkregen informatie heeft op het gedrag van de gebruikers. Dit kan op verschillende manieren gemeten worden: de individuele productiviteit van een werknemer, de kwaliteit van de genomen beslissingen, de tijd die nodig is om een beslissing te nemen… De organisatorische impact ten slotte meet de verbetering van de prestaties van de onderneming in het algemeen. Ook dit kan op meerdere wijzen gemeten worden: de operationele kosten, de algemene stijging van de productiviteit, de kwaliteit van de klantendienst en de realisatie van de vooropgestelde doelen van de implementatie. Slechts als alle dimensies (en zeker deze laatste drie) positief geëvalueerd worden, kan er gesproken worden over een succesvolle implementatie. Worden gebruikerstevredenheid, individuele impact en organisatorische impact negatief beoordeeld, dan is de implementatie zeker niet succesvol. Zijn enkele dimensies positief, terwijl andere negatief zijn, dan is het moeilijk te beoordelen of het al dan niet een succes geworden is (Zhang et al., 2005). Zoals hierboven vermeld, is het gebruik van het systeem bij gebrek aan alternatieven gewoonlijk verplicht. Een terechte kritiek is dan ook dat gebruik niet als maatstaf voor succes gehanteerd kan worden. Doch, gebruik is echter niet volledig nutteloos als maatstaf. De kwaliteit en intensiteit waarmee het nieuwe systeem benut wordt, zal een belangrijke invloed hebben op de mate van succes. Bovendien is het gebruik nooit volledig verplicht. Terwijl het op een lager niveau verplicht is, heeft het management steeds de keuze gebruik stop te zetten indien de verwachte resultaten niet gehaald worden. Bijgevolg kwamen DeLone en McLean (2002) tegemoet aan deze kritiek door hun model aan deze situatie aan te passen. Gebruik wordt vervangen door de intentie tot gebruik: de mate waarin de gebruikers bereid zijn het nieuwe systeem ten volle te benutten. Om ook aan andere terechte commentaren, die in deze context minder belangrijk zijn, te beantwoorden, gebeurden nog enkele wijzigingen. Zo komt naast de kwaliteit van de informatie en het systeem nog de kwaliteit van de geboden ondersteuning aan de eindgebruiker. Dit is om tegemoet te komen aan de hedendaagse systemen. Individuele en organisatorische impact worden dan weer vervangen door netto voordelen. Netto omdat geen enkele uitkomst volledig positief is zonder enige nadelen. Het is dan aan de onderzoeker om te definiëren wat deze voordelen precies zijn, zowel op individueel als op organisatorisch vlak (DeLone en McLean, 2002).

- 40 -

Tim Vermeersch

Figuur 12


Het nieuwe IS succesmodel van DeLone en McLean

Kwaliteit van de informatie Intentie tot gebruik Kwaliteit van het systeem

Netto voordelen Gebruikerstevredenheid

Kwaliteit van de ondersteuning

Bron: DeLone en McLean, 2002, blz. 9

De beoordeling of de implementatie van een ERP-systeem succesvol verlopen is, is echter steeds relatief op 2 vlakken. Enerzijds is het relatief ten opzichte van het moment waarop beoordeeld wordt. Bijvoorbeeld systemen die aanvankelijk op heel wat weerstand van de gebruikers botsten (en dus een lage initiële gebruikerstevredenheid hadden), kunnen na verloop van tijd toch positief beoordeeld worden, afhankelijk van hoe de situatie evolueert. Anderzijds is succes ook relatief ten opzichte van de doelstellingen die vooropgesteld werden. Bijvoorbeeld 2 ondernemingen met identieke verbeteringen in hun voorraadsysteem kunnen verschillend beoordeeld worden indien bij de ene onderneming de E

doelstelling was hun oude “legacy systeem” te vervangen, terwijl bij de andere een groter marktaandeel behalen de betrachting was. Doelstellingen kunnen ook meer of minder ambitieus zijn (Markus en Tanis, 2000).

2.4.2

De balanced scorecard

In een erg belangrijk artikel uit 1992 introduceren Kaplan en Norton de balanced scorecard: een hulpmiddel om succes te meten. De balanced scorecard wordt in dit artikel als volgt omschreven:

E

“Legacy system refers to software that preceded the software that is now being implemented or considered for implementation. Legacy software typically has been developed by and for the specific firm.Typically, there is a substantial maintenance cost of a legacy system as it is updated to meet emerging organizational needs. (O’Leary, 2000, blz. 19)”

- 41 -

Tim Vermeersch


A set of measures that gives top managers a fast but comprehensive view of the business. The balanced scorecard includes financial measures that tell the results of actions already taken. And it complements the financial measures with operational measures on customer satisfaction, internal processes, and the organization's innovation and improvement activities (Kaplan en Norton, 1992, blz. 71). De balanced scorecard gaat succes dus vanuit 4 perspectieven analyseren: de interne bedrijfsprocessen, de klanten, de financiële resultaten en ten slotte de leer- en groeimogelijkheden. Oorspronkelijk werd deze methode echter ontworpen om bedrijfsprocessen te controleren (Rosemann en Wiese, 1999). Het doel is een beperkt aantal maatstaven te identificeren en te definiëren die het management ertoe in staat stellen de organisatie beter te controleren en te sturen (Chand et al., 2005). Indien men deze werkwijze wil gebruiken voor het analyseren van een project, zullen enkele aanpassingen moeten gebeuren. Rosemann en Wiese (1999) stellen daarom voor een vijfde perspectief toe te voegen, namelijk het project perspectief. Vanuit deze invalshoek worden dan alle taken van het project management belicht en geanalyseerd (Rosemann en Wiese, 1999). Deze techniek wordt echter bekritiseerd door Chand et al. (2005). Zij stellen dat door het toevoegen van een perspectief de maatstaven voor succes niet gelinkt worden aan de doelen en strategie die de onderneming nastreeft. En uiteindelijk is het toch de bedoeling deze doelstellingen te halen (Chand et al., 2005). Chand et al. (2005) ontwikkelden een model dat wel aan deze eisen voldoet. Ze gaan er van uit dat succes afhangt van de mate waarin de onderneming in staat is volgende doelstellingen te vervullen: automatiseren, informeren en transformeren (automate, informate, transformate). De primaire doelstelling is gewoonlijk de processen efficiënter maken en automatiseren met behulp van één geïntegreerd systeem. Dit zal tot gevolg hebben dat consistente data doorheen de hele onderneming stroomt (informeren). Bovendien moet de onderneming alert en flexibel blijven en in staat zijn zich aan te passen om te overleven in de hedendaagse complexe markten (transformeren). Indien deze 3 dimensies gecombineerd worden met de 4 perspectieven van de balanced scorecard ontstaat een nuttig kader met 12 elementen. Het automatisatie perspectief focust op de operationele voordelen terwijl het informatieniveau zich vooral richt op de tactische besluitvorming en de gevolgen voor de implementatie. De transformatiedimensie is dan weer gericht op de strategische impact die de implementatie van een ERP-systeem kan hebben (Chand et al., 2005). In punt 1.6 werd het model van Shang en Seddon (2000), dat een overzicht geeft van de mogelijke voordelen, bekritiseerd door onder andere te stellen dat men geen rekening houdt met de factor tijd. Zoals eerder vermeld is de mate van succes van de implementatie relatief ten opzichte van het moment waarop beoordeeld wordt (Markus en Tanis, 2000).Het model van Chand et al. (2005) integreert wel degelijk deze factor. Logischerwijze zullen eerst de operationele voordelen gerealiseerd worden.

- 42 -

Tim Vermeersch


Eenmaal de gebruikers vertrouwd zijn met het nieuwe systeem, zullen ook de voordelen van de beschikbare informatie voelbaar worden in de vorm van betere besluitvorming (tactische voordelen). Ook klantenbehoeften zullen beter beantwoord worden waardoor de strategische voordelen niet kunnen uitblijven (Chand et al., 2005). Onderstaande tabel geeft een overzicht.

- 43 -

Tabel 5

ERP balanced scorecard Interne bedrijfsprocessen

Klanten

Financiële resultaten

Leer- en groeimogelijkheden

Efficiëntie van de processen

Beter aan klantenbehoeften

Kosten verminderen

Productiviteit verhogen

verbeteren

voldoen

Foutenreductie; snellere

Verbeterde reactietijd; minder

Lagere voorraadkosten; lagere

Betrokkenheid van gebruikers bij

processen; consistente data;

klachten; foutenreductie

arbeidskosten

de training van andere gebruikers

“Automate”: operationele voordelen Doel Uitkomst

verkorte productietijd; verhoogde

bij operationele taken

verwerkte hoeveelheid materiaal “Informate”: tactische voordelen Doel Uitkomst

Tactische besluitvorming

Pro-actief klantenbehoeften

verbeteren

identificeren en bevredigen

Inkomsten verhogen

Werknemers omvormen tot meer doeltreffende beslissingnemers

Verbeterd werkschema; verbeterde Verbeterde technieken om

Betere voorspellingstechnieken;

Training voor betere

–toewijzing; betere toegang tot

klantenbehoeften te voorspellen;

verhoogd marktaandeel

besluitvorming; werknemers

informatie; verbeterde controle;

hogere klantentevredenheid

machtigen acties te ondernemen

verbeterd kwaliteitsmanagement “Transformate”: strategische voordelen Doel

In staat zijn zich zonder veel

Voldoen aan nieuwe

Marktwaarde verhogen

problemen aan te passen aan

klantenbehoeften of nieuwe

radicale wijzigingen in de

klanten aantrekken

Radicale wijzigingen als standaard veronderstellen

omgeving Uitkomst

Veranderingen in technologie,

Toegenomen klantenaantal;

regels en competitie

samenwerking met klanten

Nieuwe markten

Change management; bredere horizon

Bron: Chand et al., 2005, blz. 568

- 44 -

Tim Vermeersch

2.5


BESLUIT

Dit hoofdstuk heeft geprobeerd een duidelijk beeld te geven van hoe een implementatie juist verloopt. Elke implementatie moet voorafgegaan worden door een grondig selectieproces zodat voor een onderneming het best passend systeem aangekocht wordt. Daardoor kunnen heel wat problemen bij de implementatie vermeden worden en zal ook de kost heel wat lager liggen. Een mooi voorbeeld van dergelijk selectieproces is de AHP methode. De verschillende implementatiemodellen hebben aangetoond dat de implementatie van een ERP-systeem erg complex is. Elk model legt verschillende klemtonen en daarom werd in dit hoofdstuk een model opgesteld dat als het ware een samenvatting is van de sterke punten van elk model. Dit model zal dan in hoofdstuk 4 gebruikt worden om de determinanten voor een succesvolle implementatie te weten te komen. Om te meten of een implementatie al dan niet succesvol is, werden 2 werkwijzen aangeboden die daarbij kunnen helpen, namelijk het DeLone en McClean succes model en de balanced scorecard. Hoofdstuk 3 geeft een overzicht van een aantal factoren die kritiek zijn tijdens de implementatie van een ERP-systeem. Gecombineerd met het samenvattende implementatiemodel krijgen we in hoofdstuk 4 dan een zicht op de determinanten voor een succesvolle implementatie van een ERP-systeem.

- 45 -

Tim Vermeersch

Hoofdstuk 3: Kritieke succesfactoren

Hoofdstuk 3: KRITIEKE SUCCESFACTOREN

3.1

INLEIDING

De bedoeling van deze thesis is te onderzoeken welke factoren een succesvolle ERP-implementatie garanderen. In het vorige hoofdstuk werd daarom eerst de implementatie besproken. In dit hoofdstuk wordt nu dieper ingegaan op deze factoren. In de literatuur worden ze kritieke succesfactoren genoemd (Critical Success Factor, CSF). Het volgende hoofdstuk zal deze twee zaken dan combineren. CSF wordt als volgt gedefinieerd:

“Those few critical areas where things must go right for the business to flourish (Parr en Shanks, 2000, blz. 292).” De structuur is vrij eenvoudig. Er wordt gestart met een algemeen overzicht van de verschillende kritieke succesfactoren (3.2). Omdat ze vrij talrijk zijn, worden ze verder opgedeeld naar: organisatie (3.2.1), gebruiker (3.2.2), systeem (3.2.3) en verkoper (3.2.4). In punt 3.3 wordt een overzichtelijke tabel weergegeven waarin de kritieke succesfactoren per geciteerde auteur vermeld staan.

3.2

ALGEMEEN OVERZICHT KRITIEKE SUCCESFACTOREN

In de literatuur zijn heel wat kritieke succesfactoren te vinden. Vaak spreekt men in verschillende termen over dezelfde fenomenen of overlappen bepaalde factoren elkaar. De ene auteur durft al eens een kritieke succesfactor toe te voegen, terwijl anderen dan weer bepaalde elementen negeren. In volgend punt wordt een overzicht gegeven van de in de literatuur meest voorkomende kritieke succesfactoren. Om wat structuur in al deze factoren te krijgen, wordt de indeling van Zhang et al. (2005) gebruikt.

Tabel 6 Organisatie

Algemeen overzicht kritieke succesfactoren Bedrijfsplan/doelen/visie Projectplanning Steun en medewerking van het topmanagement Project champion Change management Communicatie Business proces reengineering Evaluatie van de performance

- 46 -

Tim Vermeersch


Multi-site implementaties Gebruiker

Opleiding en training Een goed implementatieteam Gebruik van ERP consultants

Systeem

Minimale aanpassing van de ERP-software Integratie met de oude systemen Integratie met andere systemen Testen van het systeem

Verkoper

Selectie van het ERP-pakket Lange termijn relatie met de ERP-verkoper

Bron: Eigen voorstelling gebaseerd op Zhang et al. (2005)

3.2.1

Organisatie

Omdat ERP-implementaties gewoonlijk over een vrij lange periode lopen, is een goed bedrijfsplan F

(business case ) noodzakelijk met duidelijke doelen en een welbepaalde visie (Nah et al., 2003). Het hebben van een duidelijk bedrijfsplan wordt sterk benadrukt. Daarin worden naast de strategie ook de tastbare voordelen, middelen, kosten, risico’s en tijdsschema uit de doeken gedaan (Wee, 2000). Bovendien kan een goed opgesteld bedrijfsplan de werknemers overtuigen van de nood aan verandering en bijgevolg kan hun steun en medewerking voor de implementatie versterkt worden. Davenport (1998) benadrukt dat het bedrijfsplan continu aangepast moet worden en interactief moet zijn tijdens alle fases van de implementatie om ten volle van de voordelen ervan te kunnen profiteren. De doelstellingen moeten duidelijk en transparant zijn, maar toch specifiek genoeg om een indicatie te geven over de globale richting van het project. Goed gedefinieerde doelstellingen houden het implementatieteam op koers door heel het implementatieproces. Daarenboven moet bij het formuleren van deze doelen nog eens rekening gehouden worden met 3 beperkingen: bereik, tijd en kosten (Welti, 1999). Een goed bedrijfsplan vormt dan ook de basis van een solide projectplanning. Gewoonlijk duurt het volledige implementatieproces van een ERP-systeem 1 tot 2 jaar, met een gemiddelde van ongeveer 14 maanden (Bingi et al, 1999). Ongeveer 90% van alle ERP-implementaties liggen achter op schema of overschrijden het vooropgestelde budget (Al-Mashari et al., 2003). Bedrijven hebben dus nood aan een degelijke projectplanning om voldoende controle te hebben over het implementatieproces, het budget niet te overschrijden en binnen het vooropgestelde tijdsschema te blijven (Zhang et al., 2005). Eén van de manieren om het succes van de implementatie te evalueren die in de praktijk gehanteerd wordt, is F

Business case: “A structured proposal for business improvement that functions as a decision package for organizational decision-makers. A business case includes an analysis of business process performance and associated needs or problems, proposed alternative solutions, assumptions, constraints, and a risk-adjusted costbenefit analysis” .

- 47 -

Tim Vermeersch


namelijk de mate waarin men binnen het budget en het vooropgestelde tijdsschema gebleven is (Nah et al., 2003). Zoals eerder vermeld, is dit echter geen goede manier van werken. Zelfs als een implementatie niet op tijd of binnen het budget klaar raakt, kan ze door de betrokken onderneming nog steeds als een succes gezien worden (Zhang et al., 2005). Desalniettemin illustreert dit dat een goede projectplanning van groot belang is. Projectplanning (‘project management’) wordt door Spinner (1997) als volgt gedefinieerd:

“Project management is defined as managing and directing time, material, personnel/labor, and costs to complete a project in an orderly, economical manner and to meet the established objectives of time, costs, and technical and/or service results (Spinner, 1997).” Uit onderzoek van Al-Mudimigh et al. (2001), kunnen in een degelijke projectplanning 3 deelaspecten onderscheiden worden: Ten eerste zijn er de plannen en tijdsschema’s die opgesteld moeten worden. Dit zijn gedetailleerde specificaties van alle stappen die genomen moeten worden om het project tot een goed einde te brengen (Slevin en Pinto, 1987). De tijdsplanning moet ambitieus, maar uitvoerbaar opgesteld worden (Laughlin, 1999).

Controle en feedback zijn een tweede deelaspect. Tijdens elke stap van het implementatieproces moet informatie vrijgegeven worden via allerhande rapporten en verslagen. Welti (1999) duidt dit aan als één van de meest belangrijke taken van de projectleider. Bovendien blijkt uit onderzoek van Jiang et al. (1996) dat een competente projectmanager de tweede meest belangrijke CSF is (na steun en medewerking van het topmanagement). Deze projectleider moet bovendien een ware ‘project champion’ (infra) zijn (Zhang et al., 2005). Ook vergaderingen op geregelde tijdstippen dragen bij tot het welslagen van de implementatie. Hierin wordt vaak duidelijk of bepaalde deadlines al dan niet gehaald zijn (Bancroft et al., 1998). Derde en laatste deelaspect van projectplanning is risicobeheer. Weten wat de mogelijke risico’s zijn, vermindert de kans op onverwachte risico’s, niet beheersbare interne en externe risico’s. Dus ook de kans dat er afgeweken wordt van de vooropgestelde planning wordt kleiner (Slevin en Pinto, 1987). Elke afwijking van de planning, het budget of de vooropgestelde doelen moet erkend en van nabij opgevolgd worden. Eventueel moeten gepaste maatregelen genomen worden (Al-Mudimigh et al., 2001). Onvoorwaardelijke steun en medewerking van het topmanagement is een van de meest geciteerde kritieke succesfactoren. Bovendien wordt deze CSF in het algemeen aanzien als één van de meest belangrijke factoren tijdens de implementatie van een ERP-systeem. Het implementeren van een ERPsysteem bestaat niet enkel uit het wijzigen van de softwaresystemen, maar is eerder het herpositioneren van het bedrijf en het hervormen van de bedrijfsprocessen. Wegens de enorme impact op het competitief voordeel dat dit met zich mee kan brengen, is de steun en medewerking van het topmanagement onontbeerlijk (Davenport, 1998). Slevin en Pinto (1987) definiëren ‘top management support’ als volgt:

- 48 -

Tim Vermeersch


“The willingness of top management to provide the necessary resources and authority or power for project success” (Slevin en Pinto, 1987). Reeds van bij de start is de inbreng van het management van groot belang. Het topmanagement moet als het ware een stuurgroep vormen die op de hiërarchische ladder boven het implementatieteam komt te staan. Bovendien is het aan te raden er een zo plat mogelijke organisatiestructuur op na te houden zodat de stuurgroep en het implementatieteam nauw met elkaar samenwerken. Dit zal voor een optimale communicatie zorgen (Welti, 1999, blz. 23). Men moet zich vragen stellen als: hoe moet het ERPsysteem ons competitief voordeel opleveren, hoe zal de organisatiestructuur en –cultuur er uit zien, zullen we het systeem in slechts enkele afdelingen of het hele bedrijf implementeren…(Bingi et al., 1999) Het topmanagement moet ook op de hoogte zijn van de mogelijkheden en beperkingen van het nieuwe, te installeren systeem. (Somers en Nelson, 2001). Jarrar et al. (2000) beklemtonen echter dat de rol van het management hier niet eindigt, maar doorgaat tot het systeem volledig geïmplementeerd is. Al te vaak worden implementatie en dus ook belangrijke strategische beslissingen aan de IT-afdeling overgelaten. Het management moet bij elke stap van de implementatie betrokken zijn. Eén aspect bestaat er in dat voldoende middelen en tijd verschaft worden (Roberts and Barrar, 1992). Hun taak omvat eveneens de controle op een goede samenwerking van de verschillende departementen, oplossen van conflicten, controleren van het implementatieproces en richting geven aan de implementatieteams (Bingi et al., 1999). Wanneer het topmanagement duidelijk laat blijken dat de implementatie van het ERP-systeem een topprioriteit is, zal dit ook doorsijpelen naar de lagere niveaus in het bedrijf. Dit zal dan op zijn beurt leiden tot betrokkenheid van de hele onderneming die duidelijk zicht- en voelbaar is en een succesvolle implementatie verzekert (Bingi et al., 1999). Dit doorsijpelen naar de lagere niveaus kan bevorderd worden door het aanstellen van een ‘project

champion’, letterlijk vertaald een ‘project-voorvechter’. Naast de leiding over het implementatieteam en proces heeft de project champion ook de cruciale opdracht om het implementatieproces vlotter te laten verlopen en de gebruikers van het nut van het nieuwe systeem te overtuigen (Beath, 1991). De project champion is essentieel om overzicht te behouden over het gehele proces (Rosario, 2000). Er wordt aangeraden dat de champion het best reeds een hoge functie in de onderneming heeft, want hij is verantwoordelijk voor het uiteindelijke resultaat (Nah et al., 2003). Zoals vermeld staat hij aan het hoofd van het implementatieteam, wat met zich meebrengt dat hij verantwoordelijk is voor de projectplanning. Bovendien is hij de tussenpersoon tussen het management, de stuurgroep, en het implementatieteam (Welti, 1999). Gewoonlijk vergt het implementatieproces extra werkuren voor de werknemers naast hun gewone dagtaak. Stress en de lange werkdagen kunnen bijgevolg een slechte invloed hebben op hun moreel. Het is dan aan de project champion om hun moreel terug op te krikken en volledige toewijding te bekomen van alle werknemers (Nah et al., 2003).

- 49 -

Tim Vermeersch


De implementatie van een ERP-systeem brengt duidelijk grote veranderingen met zich mee. Een doeltreffend “change management” programma is daarom een vaak geciteerde CSF. Change management, in de context van de implementatie van ERP-systemen, wordt door Cooke en Peterson (1998) als volgt gedefinieerd:

“Activities,

processes

and

methodologies

that

support

employee

understanding

and

organisational shifts during the implementation of ERP systems and reengineering initiatives” (Cooke en Peterson, 1998). Pawlowski en Boudreau (1999) schatten dat bijna de helft van ERP-projecten de vooropgestelde doelstellingen niet halen. Dit is het gevolg van het feit dat managers de inspanningen die nodig zijn om alle veranderingen effectief te leiden, onderschatten. Gewoonlijk is de weerstand tegenover veranderingen het grootste obstakel. De middelen die een goed change management programma ter beschikking heeft, zijn sterk leiderschap, communicatie, training, planning en een aanmoedigingssysteem (‘incentives’). Ze werken als hefbomen om de weerstand met een minimum aan inspanning te omzeilen. Om een ERP-systeem succesvol te implementeren, moet niet alleen de manier waarop ondernemingen werken veranderen, maar ook de manier waarop de werknemers hun werk doen, moet veranderen (Davenport, 1998). Daarbij verandert dus niet alleen de structuur in het bedrijf, maar ook de bedrijfscultuur kan een grondige wijziging ondergaan. Yusuf et al. (2004) argumenteren dat ofwel de technologie zich moet aanpassen aan de huidige bedrijfsstructuur en -cultuur, ofwel de structuur en cultuur afgestemd moeten worden op de vereisten van het nieuwe systeem. Daarom wordt sterk benadrukt dat gebruikers van het systeem, de werknemers, al van bij de implementatie betrokken worden. Vandaar dat een zorgvuldig geplande transformatie op basis van een duidelijke strategie en training en opleiding noodzakelijk zijn (Bingi et al., 1999). In de realiteit blijkt echter dat training en opleiding gewoonlijk als eerste geslachtofferd worden wanneer een project over het geplande budget gaat. Men raadt dan ook aan een of ander hulpmiddel op poten te zetten, bijvoorbeeld een helpdesk of een online gebruikershandleiding, dat aan de noden van de gebruikers beantwoordt (Murray en Coffin, 2001). Dergelijke hulpmiddelen bevorderen ook de communicatie naar en tussen de verschillende departementen in het bedrijf. Communicatie wordt door Slevin en Pinto (1987) als volgt gedefinieerd:

“The provision of an appropriate network and necessary data to all key factors in the project implementation” (Slevin en Pinto, 1987). Niet enkel tussen de leden van het implementatieteam onderling is goede communicatie noodzakelijk, maar ook tussen het implementatieteam en de rest van de onderneming. ERP-systemen hebben de bedoeling verschillende ondernemingsfuncties met elkaar te integreren. Daarom is samenwerking en communicatie tussen de verschillende departementen en het implementatieteam onderling van vitaal

- 50 -

Tim Vermeersch


belang voor de vooruitgang van het implementatieproject (Akkermans en van Helden, 2002). Om communicatiemoeilijkheden tegen te gaan, is een beleid nodig dat streeft naar openheid met betrekking tot de implementatie van het ERP-systeem. Voorbeelden van methoden om de gebruikers geïnformeerd te houden zijn onder andere maandelijkse rapporten, nieuwsbrieven, wekelijkse vergaderingen… Communicatie is namelijk erg belangrijk omdat naast de vooruitgang ook doelen en verwachtingen voor iedereen duidelijk moeten zijn. Bovendien is het nuttig dat gebruikers feedback krijgen over processen en problemen waarmee ze in aanraking gekomen zijn (Nah et al., 2003). Dit kan bijvoorbeeld opnieuw via een helpdesk. Een andere vaak voorkomende CSF is business process reengineering, kortweg BPR. In de literatuur wordt BPR als volgt gedefinieerd (Hammer en Champy, 2001):

“The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance such as cost, quality, service and speed” (Hammer en Champy, 2001). Business Process wordt dan weer als volgt gedefinieerd:

“An activity in the organization fundamental to operating the business that serves an internal or external customer and has a well-defined outcome or series of outcomes” (Schnitt, 1993 ). ERP-implementatie betekent niet enkel de installatie van een software programma, maar omvat ook het herontwerpen van de bestaande bedrijfsprocessen tot de beste standaarden die er bestaan. ERPsystemen zijn namelijk ontworpen volgens de ‘best practice’ die in een bepaalde industrie geldt. Alle processen in een bedrijf moeten conform het ERP-model zijn of omgekeerd het ERP-model moet conform de gebruikte processen zijn. Op die manier is de gegenereerde data accuraat. De vraag die zich dus voor bedrijven stelt, is de volgende: Zullen we het ERP-pakket implementeren zoals het standaard geleverd wordt en onze processen en structuur wijzigen, of zullen we het ERP-pakket aanpassen aan onze bedrijfsspecifieke noden? Onderzoek heeft aangetoond dat zelfs het beste pakket slechts voor 70% tegemoet komt aan de noden van de klant. Er zijn dus 3 opties, namelijk: de processen afstemmen op het pakket, het pakket aanpassen aan de processen of zich niet druk maken om die 30% (Bingi et al., 1999). Murray en Coffin (2001) tonen aan dat veel bedrijven nutteloze, complexe wijzigingen aanbrengen in de ERP-software omdat diegene die de wijzigingen aanbrengen de bedrijfsprocessen en hun onderlinge relaties niet ten volle begrijpen. Wanneer een onderneming het ERP-pakket naar de eigen noden wijzigt, zal ook de implementatiekost stijgen (Bingi et al., 1999). Daarom wordt aangeraden dat bedrijven openstaan voor de aangeboden ‘best practice’ en, indien mogelijk, hun bedrijfsprocessen en structuur naar deze manier modelleren (Nah et al., 2003). Dit is ook belangrijk om aanpassings-, toekomstige onderhouds- en upgradekosten te verminderen (Bingi et al., 1999). Sterk gewijzigde ERP-software is immers veel moeilijker te onderhouden en te updaten.

- 51 -

Tim Vermeersch


BPR kan op 4 vlakken in de onderneming plaatsvinden: de processen, de methodes en procedures, de organisatie en de IT.

Figuur 13

De 4 dimensies van BPR

IT

Organisatie Doeltreffendheid en efficiëntie

Processen

Methodes en procedures

Bron: Welti, 1999, blz. 92

De bedrijfsprocessen moeten eenvoudig en betrouwbaar zijn. De gebruikte methodes en procedures moeten dan weer aangepast zijn aan het product en conform de wensen van de klant zijn. Een goede organisatiestructuur wijst de juiste taak toe aan de juiste werknemer. Verantwoordelijkheid, taken en gezag zijn duidelijk verdeeld. Op het vlak van de IT moet er voor gezorgd worden dat het systeem ten volle benut wordt zodat dit zo snel mogelijk de juiste management informatie genereert (Welti, 1999, blz. 93).

Evaluatie van de performance is een erg kritieke factor om de implementatie een succes te laten worden. Performance kan hier op 2 zaken slaan. Aan de ene kant is er de evaluatie van het project zelf. Al van bij het begin zijn maatstaven nodig om te zien of de implementatie al dan niet een succes gaat worden. Voorbeelden van dergelijke criteria zijn opleveringstermijnen, kosten, kwaliteit… (Loh en Koh, 2004). Rosario (2000) vermeldt dat best zo snel mogelijk bewijs van succes wordt geleverd om scepticisme tegen te gaan. Aan de andere kant kan performance ook opgevat worden als de efficiëntie van de bedrijfsprocessen. Men moet dus evalueren of deze processen al dan niet efficiënter geworden zijn. Ook hier wordt best snel gebruik gemaakt van specifieke maatstaven. Deze criteria kunnen zijn: aantal leveringen die op tijd gebeuren, voorraadrotatie, brutomarge, order-to-ship time…(Umble et al., 2003). Ook het gebruik van interne audits

G

H

en benchmarking

wordt aangeraden. Externe benchmarking kan nieuwe ideeën en

G

Internal audit: “Internal auditing is an independent, objective assurance and consulting activity designed to add value and improve an organization's operations. It helps an organization accomplish its objectives by bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk management, control, and
- 52 -

Tim Vermeersch


kennis aanbrengen, best practices over allerhande processen aanleren… (Al-Mashari et al., 2003) Al van bij het begin moet met deze evaluatie gestart worden. Managers en werknemers denken immers vaak dat de performance wel zal verbeteren eenmaal het ERP-systeem operationeel is. In realiteit blijkt de efficiëntie vaak eerst te dalen. Eenmaal men met het systeem vertrouwd is, stijgt de productiviteit dan weer (Umble et al., 2003). Daarom is het voor het management ook enorm van belang realistische verwachtingen aan elke van de stakeholders te verschaffen (Somers en Nelson, 2001). Indien een onderneming meerdere sites heeft, dient ook het ERP-systeem in al deze sites geïmplementeerd te worden. Zogenaamde multi-site implementaties zorgen uiteraard voor bijkomende moeilijkheden. Een eerste moeilijkheid is de gewenste graad van autonomie die men aan de verschillende sites wenst te geven. Het objectief van een ERP-implementatie kan ofwel zijn de centrale controle te versterken. Het kan ook de bedoeling zijn de verschillende sites meer autonomie te geven zodat de bedrijfsprocessen kunnen aangepast worden aan hun specifieke situatie (Umble et al., 2003). Er zijn dus tal van mogelijkheden. Een eerste is volledige autonomie voor elke dochtermaatschappij. De potentiële voordelen om data, processen en systemen te integreren gaan hier echter verloren. Het risico dat de implementatie mislukt, vermindert dan weer. Een andere mogelijkheid is dat alles op het financiële niveau gecentraliseerd is, terwijl de rest autonoom door de dochters gebeurt. Deze strategie is het meest effectief indien de dochters sterk van elkaar verschillen. Wat ook mogelijk is, is een sterke autonomie voor de dochters op het vlak van de operaties, terwijl de moederonderneming de globale supply chain leidt. Het vormen van een soort netwerk is een andere optie. Hierbij opereren de verschillende dochterondernemingen als klanten en leveranciers van elkaar. Er is dus een laterale coördinatie in plaats van een top-down benadering. De laatste optie is totale centralisatie. Alle beslissingen worden centraal gemaakt en daarna aan de dochters gecommuniceerd. Dit is een duidelijke top-down benadering (Markus et al., 2000b). Cultuurverschillen tussen de verschillende sites zijn een bijkomende moeilijkheid. De keuze bestaat nu uit standaardisatie over de gehele onderneming of lokale optimalisatie. Standaardisatie brengt relatief eenvoudige en gelijkaardige interfaces met zich mee over het hele bedrijf en zorgt voor gemakkelijke data transfers. Lokale optimalisatie heeft dan weer als voordeel dat de operaties effectiever en efficiënter kunnen gebeuren (Umble et al., 2003). Het laatste probleem is de manier waarop de implementaties in de verschillende sites gebeuren. Men heeft de keuze tussen een gelijktijdige implementatie in alle sites of een gefaseerde benadering per module, productlijn of site. Over het algemeen wordt een gefaseerde benadering aangeraden. Vaak start men met een pilootimplementatie in één site waardoor een soort van momentum gecreëerd kan worden voor de volgende implementaties (Umble et al., 2003).

framework/definition-of-internal-auditing>. H Benchmarking: “Continuous measurement of a process, product, or service compared to those of the toughest competitor, to those considered industry leaders, or to similar activities in the organization in order to find and implement ways to improve it. This is one of the foundations of both total quality management and continuous quality improvement. Internal benchmarking occurs when similar processes within the same organization are compared” .

- 53 -

Tim Vermeersch

3.2.2


Gebruiker

Ondernemingen die van plan zijn een ERP-systeem te implementeren, moeten bereid zijn enkele van hun beste mensen in te zetten voor het project. Wegens de complexiteit van het dagelijkse bestuur van een onderneming is het niet ongewoon dat de verschillende afdelingen in een onderneming vaak niet bereid zijn hun beste mensen ter beschikking te stellen van het ERP-project. Het inzetten van een goed

implementatieteam is echter een erg belangrijke CSF (Bingi et al., 1999). Het implementatieteam is van enorm belang omdat het verantwoordelijk is voor het initiële ontwerp, de planning… van het ERPimplementatieproces. Daarnaast dient dit team ook de verantwoordelijkheden te verdelen en ervoor te zorgen dat er voldoende middelen vrijgemaakt worden. Vandaar dat het management voortdurend in contact moet staan met het implementatieteam (Umble et al., 2003). Het implementatieteam moet goed uitgebalanceerd zijn, enerzijds bestaande uit technisch geschoolde mensen, anderzijds bestaande uit mensen met een goede bedrijfseconomische achtergrond. Bovendien bestaat dit team vaak uit een aantal externe consultants die de interne medewerkers bijstaan met hun technische kennis over de implementatie (Holland en Light., 1999). De mate van interactie tussen deze consultants en de interne medewerkers staat in rechtstreeks verband met de kans op slagen van de implementatie (Nah et al., 2003). De technische experts moeten niet enkel in de bedrijfsprocessen van de onderneming gespecialiseerd zijn, maar ze moeten ook op de hoogte zijn van de best practice die geldt in de industrie (Bingi et al., 1999). Voor een goede afloop van het ERP-project wordt aangeraden dat de implementatie de enige topprioriteit is voor het team. De leden van het team werken het best fulltime aan de implementatie. Bovendien wordt aanbevolen dat ze in één ruimte samenwerken en ze regelmatig samenkomen om een goede samenwerking te bevorderen. Om het doel zo snel en efficiënt mogelijk te halen, gaat men best ook op zoek naar een gepast beloningssysteem (Loh en Koh, 2004). Zoals hierboven vermeld bestaat een implementatieteam uit interne medewerkers enerzijds en externe consultants anderzijds. Het gebruik van ERP consultants is eveneens een kritieke succesfactor. De implementatie van een ERP-systeem vereist verschillende kwaliteiten: bedrijfseconomische kennis, technische bagage, sociale vaardigheden… Bovendien is elke implementatie anders afhankelijk van het bedrijf of de industrie. Bijgevolg zijn er weinig consultants die alle vereiste kennis en vaardigheden beheersen (Bingi et al., 1999). Consultants kunnen tijdens alle fases van de implementatie ingezet worden: van de selectie van het ERP-pakket tot het onderhouden van het geïmplementeerde pakket (Al-Mudimigh et al., 2001). Het grote nadeel echter aan het gebruik van ERP consultants is dat de kost enorm hoog kan liggen. Bingi et al. (1999) schatten dat de kost van het inhuren van externe consultants kan op oplopen tot 30% van het totale budget van de implementatie. De grafische voorstelling van de structuur van het volledige team dat verantwoordelijk is voor de implementatie van het ERP-systeem ziet er dus uit zoals op een eerder weergegeven figuur (supra: Figuur 10

De structuur van het volledige implementatieteam).

- 54 -

Tim Vermeersch


Opleiding en training van de gebruikers is wellicht de meest geciteerde CSF. Het is reeds duidelijk dat ERP-systemen extreem complexe systemen zijn en dus ook een grondige opleiding vereisen alvorens ze ten volle benut kunnen worden. Opleiding verwijst hier naar het aanleren van de algemene concepten en logica van een ERP-systeem aan de werknemers om de relatie uit te leggen tussen hun job en de andere afdelingen in de onderneming (Zhang et al., 2005). Ze moeten namelijk begrijpen hoe wijzigingen die zij in de data aanbrengen de rest van de processen in het bedrijf beïnvloeden. Sommige beslissingen die eindgebruikers nu maken, werden misschien eerder door hun manager genomen. Ook voor die managers is het dus belangrijk dat zij de wijziging in hun job goed begrijpen. Bovendien moeten ze de eindgebruikers wijzen op deze nieuwe verantwoordelijkheid en hen stimuleren dergelijke beslissingen zelf te nemen (Bingi et al., 1999). De training die aan de systeemgebruikers aangeboden wordt, moet over alle aspecten van het systeem gaan en continu zijn. Een bijkomend probleem is dat de implementatie vaak door externe consultants gedaan wordt. Ook hun kennis moet aan de gebruikers overgebracht worden en vaak is dit erg moeilijk in een korte tijdsspanne (Bingi et al., 1999). Al te vaak verwacht men van de werknemers dat ze het nieuwe systeem ten volle begrijpen en hanteren na het krijgen van opleiding en training. Een groot deel van het leerproces volgt echter uit het gebruik van het systeem onder normale omstandigheden. Daarom is het beter dat een verantwoordelijke, bij voorkeur de project champion, aangesteld wordt om contact te houden met de eindgebruikers en hun gebruik van, en eventuele problemen met, het systeem op de voet volgt. Ook periodieke vergaderingen met de systeemgebruikers kunnen problemen aan het licht brengen en bevorderen bovendien de uitwisseling van ervaringen met het systeem (Umble et al., 2003). Reeds eerder vermelde methodes als een helpdesk of een online gebruikershandleiding zijn hier eveneens van toepassing. Om opleiding en training van de eindgebruikers een succes te laten zijn, dient deze vroeg te starten, zelfs al voor de implementatie begint. Het topmanagement durft al eens de kosten hiervan te onderschatten. Het reserveren van 10-15% van het totale implementatiebudget voor opleiding en training zorgt er voor dat de onderneming 80% kans heeft dat de implementatie een succes zal zijn (Umble et al., 2003). Bingi et al. (1999) vermelden dat 30-40% van de eindgebruikers hun nieuwe ERP-systeem onvoldoende beheersen bij gebrek aan degelijke training.

3.2.3

Systeem

Minimale aanpassing van de ERP-software aan de specifieke eisen van de onderneming (in de Engelse vakliteratuur: ‘minimal customization’) komt vaak voor als CSF. Hiermee wordt bedoeld dat een onderneming best zo weinig mogelijk aan de oorspronkelijke broncode van de verkoper wijzigt, zelfs al gaat dit gepaard met een verlies aan functionaliteit. Onderzoek van Fortune 1000 heeft uitgewezen dat 41% van de ondernemingen hun bedrijf reorganiseren om zich aan het ERP-systeem aan te passen, 37% kiezen voor een systeem dat goed bij hun organisatie past en wijzigen slechts een beetje aan de broncode en slechts 5% passen de broncode aan om aan de bestaande organisatie te voldoen. De kosten van implementatie zullen hoger liggen en de implementatie zelf zal langer duren naarmate de

- 55 -

Tim Vermeersch


aanpassingen groter zijn. Bovendien zal de onderneming veel minder kunnen genieten van het onderhoud dat en de upgrades die door de verkoper aangeboden worden. Wijzigingen aan het systeem zouden enkel mogen aangebracht worden indien deze echt noodzakelijk zijn, of indien ze een competitief voordeel scheppen (Somers en Nelson, 2001). Als conclusie kan gesteld worden dat het aanpassen van het ERP-systeem aan de noden van de onderneming noodzakelijk is, maar dat alles er dient aan gedaan te worden om die aanpassingen zo minimaal mogelijk te houden. Dit kan bijvoorbeeld door een zo goed mogelijk passend ERP-systeem te kiezen of een systeem dat gemakkelijk te wijzigen is (Zhang et al., 2005). De kans bestaat dat een onderneming naast het ERP-systeem ook andere gespecialiseerde systemen moet gebruiken omdat het ERP-systeem niet aan alle specifieke eisen kan voldoen. Deze systemen, ‘middleware’ genoemd, moeten echter ook geïntegreerd worden. Integratie met andere systemen is daarom noodzakelijk. De ERP-software werkt dan vaak als ruggengraat van de onderneming waarop de andere systemen dan bevestigd worden. Producenten van dergelijke systemen richten zich echter vooral op de grotere spelers op de ERP-markt waardoor ze vaak moeilijk te integreren zijn met ERP-pakketten van de minder bekende spelers. Dikwijls moeten ondernemingen dan zelf interfaces ontwikkelen om alles op een degelijke wijze te laten samenwerken. Dit schept dan opnieuw problemen voor het onderhoud en eventuele upgrades van elk van de systemen. Indien ondernemingen voor middleware kiezen, is het aan te raden de ERP-verkoper om een lijst van gecertificeerde verkopers te vragen. Jaarlijks publiceren alle grote ERP-verkopers namelijk een lijst van middleware-verkopers waarmee ze samenwerken. Dit zou reeds een grote hulp kunnen betekenen bij de reeds vermelde problemen van onderhoud en upgrading (Bingi et al., 1999). Een bijkomende moeilijkheid bij de implementatie van een ERP-systeem is dat er reeds oude, minder geïntegreerde systemen in de onderneming aanwezig zijn, zogenaamde ‘legacy systems’. Deze ‘oude systemen’ omvatten de bestaande bedrijfsprocessen, de organisatiestructuur en –cultuur en vooral de bestaande IT-programma’s (Holland en Light, 1999). Gewoonlijk zal de situatie voor de implementatie van een ERP-systeem er al volgt uitzien: elke afdeling heeft haar eigen computersysteem ontwikkeld waardoor data en informatie erg verspreid zijn. Bijgevolg zal ook elke interface verschillend zijn. Dit creëert zowel directe als indirecte kosten. De directe kosten zijn onder andere het onderhoud van de verschillende systemen, data die meermaals ingegeven moet worden en data die aangepast dient te worden om het van het ene systeem op een ander te kunnen gebruiken. De indirecte kosten, die daarom niet minder belangrijk zijn, zijn de kosten die ontstaan door de moeilijke communicatie die ontstaat (Abdinnour-Helm et al., 2003). Indien de oude systemen niet vervangen worden, is een goede integratie

met de oude systemen daarom onontbeerlijk. De mate van complexiteit van de oude systemen zal de graad van verandering die nodig is tijdens de implementatie bepalen. Hoe complexer (bijvoorbeeld het hebben van verschillende technologie platforms), des te groter de wijziging zal zijn op technologisch en organisatorisch vlak (Holland en Light, 1999). Voorheen werkte elk departement als het ware als een eiland. De data werden niet in één centrale database opgeslagen, maar eerder verdeeld over verschillende computers. De informatie stroomde vrij

- 56 -

Tim Vermeersch


traag door de onderneming en de gevolgen van fouten (eventueel gemaakt door andere departementen) werden maar laat gesignaleerd. Voordeel daarvan was dat er nog ruim de tijd was om fouten recht te zetten alvorens deze de rest van de onderneming zouden schaden. Door de implementatie van een ERPsysteem en de integratie van alle departementen komen fouten gemaakt in één afdeling echter in realtime in de rest van de onderneming terecht. Bovendien worden deze fouten groter naarmate ze verder door de waardeketen stromen. Bijvoorbeeld indien de productieafdeling de ‘bill of material’ foutief opstelt, heeft dit niet alleen gevolgen voor de productie, maar ook voor de voorraadafdeling, de boekhouding… Financiële analisten die zich onder andere baseren op aankoopprijzen van grondstoffen kunnen dan tot een foutieve waardering van de onderneming komen. Ondernemingen moeten daarom bewust zijn van de mogelijke risico’s die dergelijke fouten teweeg brengen en de nodige acties ondernemen zoals het controleren van de transacties en eventuele fouten zo snel mogelijk rechtzetten. Het is dan ook van enorm belang de overgang van het ene systeem naar het andere zo vlot mogelijk te laten verlopen (Bingi et al., 1999). Ook het opstellen van procedures hoe data in het systeem ingevoerd dient te worden, kan hierbij helpen (Umble et al., 2003). Alvorens het ERP-systeem definitief te introduceren, moet het voldoende getest zijn. Het testen van het

systeem is enerzijds noodzakelijk om te controleren of technisch alles in orde is, anderzijds om te zien of de bedrijfprocessen correct geconfigureerd zijn in het systeem (Al-Mudimigh et al., 2001). Een belangrijke test is namelijk kijken of de processen zoals ze beschreven zijn in het systeem ook overeenkomen met de processen die werkelijk plaatsvinden. Daarop volgt dan nog slecht één stap, namelijk ‘going live’. Hierbij wordt niet enkel het nieuwe ERP-systeem geactiveerd, maar wordt ook het oude systeem achter zich gelaten (Al-Mashari et al., 2003).

3.2.4

Verkoper

Eén van de eerste keuzes die gemaakt moet worden en de rest van het verloop van de implementatie in sterke mate bepaalt, is de selectie van het ERP-pakket. Bingi et al. (1999) schatten dat er ongeveer 500 verschillende ERP-pakketten op de markt beschikbaar zijn. Er is echter een trend merkbaar van minder ERP-verkopers die een groter marktaandeel bezitten (AMR Research, 2006). Het juiste pakket is datgene dat het beste aansluit bij de bedrijfsprocessen en de nood aan informatie. Bovendien vereist het een minimum aan modificatie, succesvolle implementatie en gemakkelijk gebruik verzekert (Somers en Nelson, 2001). Daarom wordt het best gekozen voor een pakket dat gemakkelijk aan te passen is, zodat de kosten en tijd nodig voor de aanpassingen zoveel mogelijk gereduceerd worden (Zhang et al., 2005). Het verkeerde pakket implementeren betekent dat men gebruik zal moeten maken van een organisatiestructuur, bedrijfstoepassingen, bedrijfsprocessen… die de onderneming niet optimaal passen (Somers en Nelson, 2001). Naast het ERP-pakket zelf is ook de situatie van de verkoper van belang. Het opbouwen van een lange

termijn relatie met de ERP-verkoper is een must. Het management moet zich verschillende vragen

- 57 -

Tim Vermeersch


stellen over de verkoper. Op welke markt focust de verkoper (bijvoorbeeld kleine of grote bedrijven), hoe verliepen vorige implementaties waarbij hij betrokken was, gaat het om een gezond bedrijf dat op lange termijn denkt… Voor internationale bedrijven is er de bijkomende vraag of de verkoper ERP-software beschikbaar stelt die in alle landen waar de onderneming actief is, gebruikt kan worden (Bingi et al., 1999). Kortom, zal de ERP-verkoper tijdens en na het implementatieproces de nodige, continue ondersteuning kunnen bieden? De kwaliteit van de verkoper kan op het vlak van de implementatie in 3 dimensies onderverdeeld worden. De eerste dimensie is de tijd die de verkoper nodig heeft om problemen op te lossen. Een tweede is het voorhanden zijn van gekwalificeerde consultants met zowel kennis van IT als van de productieprocessen in de onderneming. De laatste dimensie ten slotte is de mate van participatie van de ERP-verkoper tijdens de implementatie (Zhang et al., 2005). Ook na de implementatie is een goede relatie met de ERP-verkoper van enorm belang. Er zullen steeds nieuwe modules ontwikkeld worden waardoor het systeem en de processen nauwer met elkaar zullen aansluiten, er zal technische assistentie nodig zijn, speciale gebruikerstrainingen zullen noodzakelijk zijn... (Somers en Nelson, 2001).

3.3

SAMENVATTING KRITIEKE SUCCESFACTOREN PER AUTEUR

Om het overzicht te bewaren wordt in onderstaande tabel een samenvatting gegeven van de verschillende geraadpleegde werken over kritieke succesfactoren. Per auteur wordt weergegeven welke kritieke succesfactoren in het desbetreffende artikel benadrukt worden.

- 58 -

Tabel 7

Geciteerde kritieke succesfactoren per auteur Akkermans en van

Al-Mashari Al-Mudimigh et al, 2003

et al, 2001

Beath, 1991

Bingi et al, Davenport, Holland en

Jarrar et

Laughlin,

1998

al., 2000

1999

●

●

1999

Light., 1999

Helden, 2002 Bedrijfsplan/doelen/visie

●

●

●

●

Projectplanning

●

●

●

●

Steun en medewerking van het

●

●

●

●

● ●

●

●

● ●

●

topmanagement Project champion

●

●

Change management

●

●

●

Communicatie

●

●

●

Business proces reengineering

●

●

●

Evaluatie van de performance

● ●

●

●

●

●

●

●

●

●

●

●

Multi-site implementaties Opleiding en training

●

●

●

Een goed implementatieteam

●

Gebruik van ERP consultants

●

Minimale aanpassing van de ERP-

●

●

●

●

●

●

●

●

●

●

● ●

●

●

●

●

software Integratie Testen van het systeem Selectie van het ERP-pakket

●

Lange termijn relatie met de ERP-

●

● ●

●

verkoper

- 59 -

●

●

Loh en Koh, 2004

Markus Murray en et al.,

Coffin,

2000b

2001

Nah et

Roberts and Rosario,

al, 2003 Barrar, 1992

2000

Somers en

Umble et

Welti,

Zhang et

Nelson,

al., 2003

1999

al, 2005

2001, 2004

Bedrijfsplan/doelen/visie

●

●

Projectplanning

●

●

●

Steun en medewerking van het

●

●

●

Project champion

●

●

●

Change management

●

●

●

Communicatie

●

Business proces reengineering

●

●

●

Evaluatie van de performance

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

topmanagement

Multi-site implementaties

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

Gebruik van ERP consultants Minimale aanpassing van de ERP-

●

●

●

●

●

●

Opleiding en training Een goed implementatieteam

●

●

●

●

●

●

● ●

●

●

Integratie

●

●

●

Testen van het systeem

●

●

●

Selectie van het ERP-pakket

●

●

●

●

software ●

●

●

●

● ●

Lange termijn relatie met de ERP-

●

verkoper Bron: eigen voorstelling

- 60 -

●

Tim Vermeersch

3.4


BESLUIT

In dit hoofdstuk werd een overzicht gegeven van een aantal factoren die kritiek zijn bij de implementatie van een ERP-systeem. Het is duidelijk dat er heel wat zijn en dat het dus erg moeilijk is om een klaar inzicht te behouden. Bovendien werden deze factoren niet gekoppeld aan de implementatie zelf. Daarom wordt in het volgende hoofdstuk deze connectie wel gelegd. Er wordt namelijk gepoogd per fase in de implementatie een aantal factoren naar voren te schuiven die dan het meest belangrijk zijn. Zo is het gemakkelijker om deze determinanten tijdens de implementatie niet uit het oog te verliezen.

- 61 -

Tim Vermeersch

Hoofdstuk 4: Kritieke succesfactoren afhankelijk van de fase in de implementatie

Hoofdstuk 4: KRITIEKE SUCCESFACTOREN AFHANKELIJK VAN DE FASE IN DE IMPLEMENTATIE

4.1

INLEIDING

In hoofdstuk 2 werd een overzicht gegeven van de verschillende implementatiemodellen die in de literatuur terug te vinden zijn. In hoofdstuk 3 werden dan weer de verschillende kritieke succesfactoren overlopen. Afhankelijk van de fase waarin men zich bevindt, zijn er echter verschillende factoren cruciaal voor de implementatie (Loh en Koh, 2004). Vandaar dus dat in dit hoofdstuk de link gelegd wordt tussen de implementatiemodellen en deze kritieke succesfactoren. Een drietal van de eerder vermelde modellen hebben getracht de kritieke succesfactoren te linken aan de fase waarin de implementatie zich bevindt: de process theorie (4.2), het project phase model (4.3) en het 6-fasen model van Cooper en Zmud (4.4). Deze modellen worden telkens zo kritisch mogelijk benaderd. In punt 4.5 wordt dan het samenvattende model uit hoofdstuk 2 als basis gebruikt om per fase een aantal kritieke succesfactoren weer te geven.

4.2

KRITIEKE SUCCESFACTOREN TIJDENS DE PROCESS-THEORIE

De basis van deze theorie is de opeenvolging van verschillende fases, met aan het einde van elke fase een tussentijdse uitkomst, al dan niet optimaal. Optimaal succes wordt in dit kader als volgt gedefinieerd:

“The best outcomes the organization could achieve with enterprise systems, given its business situation. Optimal succes can be far more or less than the organization’s goals for an enterprise system. Optimal succes can be dynamic, what is possible for an organization to achieve may change over time as business conditions change” (Markus et al., 2000, blz. 247 ). Deze tussentijdse uitkomsten beïnvloeden de finale uitkomst, maar bepalen deze niet. Bijgevolg kunnen voorvallen en acties op om het even welk moment tijdens de implementatie, de implementatie terug op het juiste spoor helpen (Markus en Tanis, 2000). Afhankelijk van de fase zijn er telkens verschillende van dergelijke kritieke succesfactoren. Zoals eerder vermeld (supra 2.4) is succes multidimensioneel en moeilijk te meten. Succes in een vroeg stadium van de implementatie is niet sterk gerelateerd met later succes. Bijgevolg is het belangrijk dat men bezorgd is over succes in elke fase van de implementatie. Daarom dat men een model heeft

- 62 -

Tim Vermeersch


uitgewerkt, waarin men zegt wat de uitkomst zou moeten zijn na elke fase en welke factoren (CSF) per fase van belang zijn (Markus et al., 2000).

4.2.1

Project chartering fase

De eerste fase is de chartering fase. Een vaak voorkomend probleem is dat een ERP-verkoper of externe consultant zijn product bovenmatig aanprijst. Bijgevolg bestaat het gevaar dat niet het meest passende softwarepakket aangeschaft wordt. Ook langetermijncontracten met externe partijen leveren vaak problemen op. Vaak is men in het begin van de implementatie nog niet in staat de impact van een ERPsysteem in te schatten. Vandaar dat men de nood aan verandering in de bedrijfsprocessen en de organisatorische structuur overziet. Gevolg is dan een onrealistisch bedrijfsplan (Markus en Tanis, 2000). De optimale uitkomst volgens de process-theorie is de beslissing om het ERP-systeem verder te implementeren en dit met een grondig uitgewerkt bedrijfsplan (Markus en Tanis, 2000). De steun en medewerking van het topmanagement is in deze fase onontbeerlijk. Daarnaast dient een project manager (project champion) aangesteld te worden en zoals eerder vermeld (supra 3.2.1), wordt het best gekozen voor iemand uit de onderneming die een hoge functie heeft. Indien tijdens deze fase reeds een beslissing genomen wordt welk ERP-pakket aan te schaffen, is een goed selectieproces noodzakelijk (Markus en Tanis, 2000). De project champion zal dan ook een goed implementatieteam moeten samenstellen en samen kunnen ze dan reeds een nauwgezette projectplanning opstellen (Loh en Koh, 2004). Niet alleen binnen het implementatieteam is er nood aan communicatie, maar ook tussen het team en de externe consultants, de gebruikers en de rest van de onderneming (Markus en Tanis, 2000).

4.2.2

Project fase

Tijdens deze fase kunnen zich heel wat problemen voordoen. Een eerste probleem is dat het implementatieteam niet voldoende gediversifieerd is en bijvoorbeeld te veel gericht is op het technologische aspect en te weinig op het organisatorische. Bovendien is verloop binnen het implementatieteam een bijkomende moeilijkheid. Een bepaalde mate van continuïteit in het team is aan te raden. Op het technologisch vlak doen zich vaak moeilijkheden voor op het vlak van de integratie van het nieuwe systeem met de oude systemen, de zogenaamde legacy systemen, of bijkomende modules. Aanpassingen die aan het programma gedaan worden die niet werken en externe consultants die hun kennis slechts in beperkte mate vrijgeven zijn eveneens ingewikkelde kwesties. Ook is het dikwijls erg moeilijk binnen het vooropgestelde budget en tijdsschema te blijven (Markus en Tanis, 2000). De optimale uitkomst van de project fase is het uitrollen, binnen redelijke grenzen qua tijd en kost, van een ERP-systeem dat operationeel is en voldoet aan de noden van de onderneming. De onderneming

- 63 -

Tim Vermeersch


moet bovendien bereid zijn het systeem te aanvaarden. Met onderneming worden onder andere de gebruikers bedoeld (Markus en Tanis, 2000). Aangezien het risico op problemen tijdens deze fase erg groot is, spelen er heel wat factoren een belangrijke rol. Het aantal activiteiten tijdens deze fase is eveneens enorm. Vandaar dat het erg belangrijk is dat reeds in de chartering fase een grondige projectplanning opgesteld is (Loh en Koh, 2004). Het belang van een goed implementatieteam is reeds aangegeven. Op het vlak van de technologie dient men heel sterk te letten op de aanpassingen die aangebracht worden in de software. Deze aanpassingen zijn het best zo minimaal mogelijk. Ook de integratie met de legacy systemen komt hier erg sterk naar voor. Op organisatorisch vlak wordt aangeraden een change management programma al tijdens deze fase op te stellen, hoewel de eindgebruikers nog niet met het systeem in contact gekomen zijn. Zodoende weten gebruikers wat hen te wachten staat en welke veranderingen de structuur van de organisatie zal ondergaan. Opleiding en training van de gebruikers kan daarbij heel sterk helpen. Naast de structuur van de organisatie zullen wellicht ook de processen sterke wijzigingen ondergaan, namelijk via BPR. Ook hier dient men de nodige aandacht aan te besteden (Markus en Tanis, 2000).

4.2.3

Shakedown fase

Ook deze fase kent haar specifieke problemen. Problemen met en onderbrekingen van het productieproces zijn wellicht de meest belangrijke. Tijdens dit stadium dient het implementatieteam de verantwoordelijkheid als het ware over te dragen aan de gebruikers. Ook dit levert soms moeilijkheden omdat men te veel afhankelijk is en blijft van het projectteam. De gebruikers blijven al te vaak volgens de oude procedures werken met als gevolg dat de nieuwe mogelijkheden die het systeem te bieden heeft niet aangeleerd worden en ook niet benut worden. Het gebeurt dus dikwijls dat de bedrevenheid van de eindgebruikers met betrekking tot het systeem na hun initiële opleiding nog weinig verder groeit. Dit alles kan zelfs tot gevolg hebben dat het systeem nooit een normaal operationeel niveau haalt (Markus en Tanis, 2000). Het optimale einde van deze fase wordt omschreven als: het bereiken van normale operaties, binnen redelijke grenzen qua tijd en kost, met effecten en gevolgen die voldoen aan de noden van de onderneming (Markus en Tanis, 2000). Het is duidelijk dat het erg belangrijk is grondig te investeren in opleiding en training van de eindgebruikers. De bereidheid om met het systeem te werken, dient eveneens aangemoedigd te worden (Loh en Koh, 2004). Ook het productieproces zal nog verdere wijzigingen moeten ondergaan totdat opnieuw een dagelijkse routine bereikt wordt. Verdere integratie met de legacy systemen en eventuele middleware applicaties zal eveneens geoptimaliseerd moeten worden (Markus en Tanis, 2000).

- 64 -

Tim Vermeersch

4.2.4


Onward en upward fase

Tijdens deze fase bestaat het gevaar dat het ERP-systeem van vandaag, het legacy systeem van morgen wordt. Dit heeft dan te maken met het feit dat de onderneming niet bereid is verder te investeren in upgrades. Wat eveneens vaak voorkomt, is dat de organisatie efficiëntieverbeteringen en andere resultaten niet op regelmatige wijze controleert en beoordeelt. Ten slotte worden werknemers met uitgebreide kennis van het ERP-systeem, zowel IT-specialisten als eindgebruikers, dikwijls weggekaapt door concurrenten of consultancybedrijven (Markus en Tanis, 2000). De meest succesvolle uitkomst is het verbeteren van de competitieve positie van de organisatie als gevolg van de implementatie van het ERP-systeem en het behouden van technologische en organisatorische flexibiliteit voor toekomstige ontwikkelingen (Markus en Tanis, 2000). Een lange termijn relatie en contract met de ERP-verkoper kan voorkomen dat het systeem verouderd raakt. Dit moet er voor zorgen dat updates gemakkelijk en goedkoop beschikbaar blijven. Indien deze updates grote wijzigingen met zich meebrengen, kan het noodzakelijk te zijn opnieuw de gebruikers op te leiden en te trainen. Daarnaast dient de performance permanent geëvalueerd te worden zodat bijvoorbeeld dalingen van de efficiëntie snel opgemerkt worden en de nodige maatregelen vlug genomen kunnen worden (Markus en Tanis, 2000).

4.2.5

Overzicht

Tabel 8

Kritieke succesfactoren tijdens de Process-theorie

Fase

Kritieke succesfactoren

Project chartering fase

Bedrijfsplan/doelen/visie Projectplanning Steun en medewerking van het topmanagement Project champion Communicatie Een goed implementatieteam Eventueel: selectie van het ERP-pakket

Project fase

Change management Business proces reengineering Opleiding en training Gebruik van ERP consultants Minimale aanpassing van de ERP-software Integratie met de oude systemen Integratie met andere systemen

- 65 -

Tim Vermeersch


Shakedown fase

Change management Business proces reengineering Integratie met de oude systemen Integratie met andere systemen Opleiding en training

Onward en upward fase

Evaluatie van de performance Eventueel: Opleiding en training Lange termijn relatie met de ERP-verkoper

Bron: eigen voorstelling

4.2.6

Kritiek op de process theorie

Hoewel het model vrij goed uitgewerkt is, kan toch het volgende opgemerkt worden. Op het vlak van de kritieke succesfactoren is er weinig onderscheid tussen de tweede en derde fase. Alle factoren die tijdens de shakedown fase opgesomd worden, zijn ook terug te vinden in de voorgaande fase, namelijk de project fase.

4.3

KRITIEKE SUCCESFACTOREN TIJDENS HET PROJECT PHASE MODEL

Ook bij dit model heeft men onderzoek gedaan naar welke succesfactoren belangrijk zijn tijdens de verschillende fases van de implementatie. Hierbij moet echter opgemerkt worden dat dit onderzoek vrij kleinschalig is en dus misschien iets minder representatief. Het model werd namelijk slechts in 2 ondernemingen getest op kritieke succesfactoren. Vandaar ook dat aan dit model minder aandacht geschonken wordt. Opvallend echter is dat alle geciteerde factoren, op één na, doorheen het volledige implementatieproces min of meer belangrijk geacht worden.

- 66 -

Tim Vermeersch

Tabel 9


Kritieke succesfactoren tijdens het project phase model

Factor

Fase Planning

Steun topmanagement Project champion

Project

Enhancement

Set-

Re-

up

engineering

●●●●

●●●

●●

●●

●●

●●●

●

●●●

●●

●

●

●

●

●

●●●

●●●

●●

●

●●

●

●●

●

Implementatieteam

Design Configuration Installation & testing

Change management

●●●

●

●

●●

●

Minimale aanpassing

●●●

●

●

●

●●

Projectplanning

●●

●●

●

●

●

●

●

Bedrijfsplan/doelen/visie

●●

●●

●●

●

●

●

●

Bron: Eigen voorstelling gebaseerd op Parr en Shanks, 2000, blz. 299

Parr en Shanks (2000, blz. 301) concluderen dat om het succes te verhogen het hele implementatieproject opgedeeld moet worden in meerdere kleine en meer eenvoudige deelprojecten. Wat ze ook benadrukken is dat er van in het begin van de implementatie een ervaren project champion de leiding neemt.

4.4

KRITIEKE SUCCESFACTOREN TIJDENS HET 6-FASEN MODEL VAN COOPER EN ZMUD

Onderzoek naar de kritieke succesfactoren afhankelijk van de fase waarin men zich bevindt, is bij dit model erg problematisch gebleken. Eensgezindheid is heel moeilijk te vinden, zelfs tussen verschillende artikels van dezelfde auteurs: Somers en Nelson, 2001 en 2004. Onderzoek bij respectievelijk 86 en 111 ondernemingen levert gelijkaardige, doch niet geheel dezelfde resultaten op. Hier worden de factoren aangehaald die in beide onderzoeken erg beduidend gebleken zijn. De volgorde is echter willekeurig gekozen. Eventuele belangrijke verschillen zullen steeds vermeld worden.

Tabel 10

Kritieke succesfactoren tijdens het 6-fasen model van Cooper en Zmud

Fase

Kritieke succesfactoren

Initiation

Keuze met betrekking tot integratie, aanpassing… Lange termijn relatie met de ERP-verkoper Bedrijfsplan/doelen/visie Selectie van het ERP-pakket

Adoption

Change management Steun en medewerking van het topmanagement Lange termijn relatie met de ERP-verkoper

- 67 -

Tim Vermeersch


Business proces reengineering Een goed implementatieteam Adaptation

Communicatie Change management Lange termijn relatie met de ERP-verkoper Opleiding en training Een goed implementatieteam

Acceptance

Een goed implementatieteam Communicatie Change management Steun en medewerking van het topmanagement

Routinization

Opleiding en training Communicatie Steun en medewerking van het topmanagement (Lange termijn relatie met de ERP-verkoper)

Infusion

Gebruik van ERP consultants Communicatie Lange termijn relatie met de ERP-verkoper Steun en medewerking van het topmanagement


Bovenstaande tabel geeft een overzicht van de meest kritieke succesfactoren per fase van de implementatie volgens Somers en Nelson (2001, 2004). Wat niet blijkt uit de tabel, maar wel opmerkelijk is, is het feit dat tijdens de eerste stadia heel wat factoren belangrijk geacht worden. Naarmate het project verder gevorderd is, daalt het aantal factoren dat als kritiek beoordeeld wordt (Somers en Nelson, 2004). Tijdens de initiation fase is het opvallend dat de steun en medewerking van het topmanagement niet bij de meest kritieke factoren geplaatst wordt. Terwijl in het onderzoek van Somers en Nelson in 2001 deze factor nog op een vierde plaats stond, wordt het in 2004 amper als elfde meest belangrijke factor gezien. Bovendien wordt de steun van het topmanagement in andere modellen tijdens de initiële fases als onontbeerlijk gezien, bijvoorbeeld de process-theorie van Markus en Tanis (2000). Ook het implementatieteam levert gelijkaardige problemen op. Terwijl het in 2001 tijdens de adoption fase nog als tweede meest belangrijke factor gezien werd, is het in 2004 veel minder belangrijk geworden. Toch wordt het hier nog bij de kritieke succesfactoren geplaatst omdat een goed implementatieteam over alle fases heen van groot belang geacht wordt. Tijdens de acceptance fase kan hetzelfde fenomeen vastgesteld worden.

- 68 -

Tim Vermeersch


Opvallend bij dit model is dat de nadruk gelegd wordt op organisatorische problemen. Factoren als integratie met legacy systemen, minimale aanpassing… worden niet vermeld als zijnde kritiek. Dit toont nogmaals aan dat de implementatie van ERP-systemen veel meer is dan de installatie van een software programma.

4.5

KRITIEKE SUCCESFACTOREN TIJDENS HET SAMENVATTENDE MODEL

Bij de verschillende modellen heeft men aan de hand van verschillende methodes getracht per fase kritieke factoren aan te duiden. Uit de vorige voorbeelden blijkt dat dit echter heel moeilijk is. Een eerste kritiek die op alle modellen gegeven kan worden is dat heel wat factoren tijdens het hele implementatieproces terug komen en dus bestendig belangrijk zijn. Een mogelijke oplossing is een onderscheid maken tussen factoren die constant belangrijk zijn en de overige factoren die slechts in enkele fases naar voren komen, naar voorbeeld van Al-Mudimigh et al. (2001). In zijn voorstelling worden de overige factoren verder onderverdeeld in een operationeel, tactisch en strategisch niveau. Deze indeling brengt echter niet veel bij aan het beantwoorden van de onderzoeksvraag. Het is namelijk de bedoeling de kritieke succesfactoren te combineren met het implementatieproces om tot een aantal determinanten te komen die het succes tijdens de implementatie bepalen afhankelijk van de fase waarin men zich bevindt. Een bijkomende moeilijkheid is het feit dat het ene model een factor citeert tijdens een bepaalde fase, terwijl een ander model deze factor tijdens een gelijkaardige fase helemaal niet belangrijk vindt. De traditionele manier waarbij per fase een aantal belangrijke factoren genoemd worden, lijkt in dit geval dus niet optimaal te zijn. Daarom wordt hier een alternatief aangeboden dat geïnspireerd is op AlMudimigh et al. (2001), namelijk een model dat met deze problemen rekening houdt. Dit model wordt gecombineerd met het samenvattende implementatiemodel uit hoofdstuk 2. Er zijn dus een aantal kritieke succesfactoren die een overheersend karakter hebben. Deze zijn dan ook van belang gedurende gans het implementatieproces. Opvallend is dat bij deze dominante factoren noch IT-ontwikkeling, noch IT-verbetering voorkomen. De nadruk bij deze elementen ligt vooral op de veranderingen in de organisatiecultuur. Hiermee wordt nogmaals duidelijk dat bij ERP-implementatie de nadruk eerder op de organisatorische veranderingen ligt (Al-Mudimigh et al., 2001). Ook uit het PPM kan dezelfde conclusie getrokken worden. De meest belangrijke factoren in dit model werden doorheen het hele proces als belangrijk verondersteld (Parr en Shanks, 2000).

- 69 -

Tim Vermeersch

Figuur 14


Kritieke succesfactoren tijdens het samenvattende model

• Steun en medewerking van topmanagement • Implementatieteam • Project champion

• Bedrijfsplan/doelen/visie • Projectplanning • Change management

C O M M U N I C A T I E

Selectie

Implementatieteam

• Selectie van het ERP-pakket

• Een goed implementatieteam

Implementatie • BPR

• Project champion • BPR

• Opleiding en training

• Integratie • Minimale aanpassing

Gewenning & routine

Continuous improvement

• Opleiding en training

• Lange termijn relatie met ERPverkoper

• Verdere integratie

• Gebruik ERP consultants • Testen van het systeem

• Evaluatie van de performance • Opleiding en training

Bron: eigen voorstelling gebaseerd op Al-Mudimigh et al., 2001, blz. 218

Het is belangrijk dat het topmanagement niet enkel het project initieert, maar ook het hele proces aandachtig blijft volgen. Aan de hand van een goed bedrijfsplan kan het implementatieteam, onder leiding van de project champion, dan de projectplanning nauwgezet volgen zodat de implementatie zo vlot mogelijk verloopt. De manier waarop men al deze wijzigingen overbrengt aan het personeel en de gebruikers zou echter wel eens de meest cruciale factor kunnen zijn. De manier waarop het change management aangepakt moet worden, zal afhankelijk zijn van hoe groot de “resistance to change “ is. De overige succesfactoren zijn vrij vanzelfsprekend. Zo zal tijdens de selectie uiteraard een goed selectieproces erg belangrijk zijn. Een bekwame project champion die het implementatieteam kan samenstellen is vanaf de start logischerwijze onontbeerlijk. Met BPR wordt tijdens dit stadium bedoeld dat het voor de onderneming al duidelijk moet zijn welke wijzigingen doorgevoerd zullen worden. Tijdens de volgende fase is het van het grootste belang dat het implementatieteam goed samengesteld wordt op de manier die reeds eerder vermeld werd. Daarenboven dient het team opgeleid te worden zodat de leden duidelijk weten wat van hen verwacht wordt en in staat zijn hun taak te volbrengen. De implementatiefase bevat vooral factoren van technologische aard, behalve dan BPR. Dit is dan ook het moment waarop het systeem daadwerkelijk geïmplementeerd wordt. De elementen die hier aangehaald worden, zijn vrij gelijkaardig aan de elementen die men terugvindt in de literatuur over de implementatie van meer standaard softwareprogramma’s. De enige uitzondering hierop is BPR. De

- 70 -

Tim Vermeersch


voorziene wijzigingen in de processen en structuur worden hier effectief doorgevoerd. Tijdens de laatste 2 fases is het vooral van belang dat de gebruikers goed opgeleid en getraind worden. Het systeem wordt verder up-to-date gehouden met behulp van een goede verstandhouding met de ERPverkoper.

4.6

BESLUIT

Een aantal auteurs hebben een poging ondernomen om per fase de kritieke succesfactoren voor de implementatie van een ERP-systeem te vinden. Ook hier was het de bedoeling de kritieke succesfactoren te linken aan het implementatiemodel uit hoofdstuk 2. In het algemeen was er in de literatuur echter weinig eensgezindheid. Bepaalde factoren worden belangrijk geacht tijdens de ene fase terwijl een andere auteur deze factor tijdens een andere fase belangrijk vindt. Een ander opvallend feit was dat bepaalde factoren telkens terugkomen in zowat elke fase van de implementatie. Daarom werd hier naar een alternatief gezocht en Al-Mudimigh (2001) bleek daarvoor de ideale oplossing. Hij stelt dat een onderscheid gemaakt moet worden tussen 2 factoren. Zo zijn er factoren die tijdens het hele implementatieproces belangrijk zijn en andere die dan afhankelijk van de fase naar voor komen. Op die manier werd tot een model gekomen dat de determinanten weergeeft voor een succesvolle implementatie van een ERP-systeem. In het volgende hoofdstuk wordt dit model getoetst aan de realiteit. Via een case study wordt het model verder verfijnd aan de hand van kennis uit de praktijk.

- 71 -

Tim Vermeersch

Hoofdstuk 5: Praktijkonderzoek

Hoofdstuk 5: PRAKTIJKONDERZOEK NAAR DE DETERMINANTEN VOOR EEN SUCCESVOLLE IMPLEMENTATIE VAN EEN ERP-SYSTEEM

5.1

INLEIDING

In de voorgaande hoofdstukken werd de theorie gaandeweg opgebouwd om uiteindelijk tot een implementatiemodel te komen dat de verschillende fases omschrijft met een aantal factoren die kritiek zijn voor een succesvolle implementatie. In dit hoofdstuk zal dit model aan de realiteit getoetst worden om te zien of de theorie ook nauw aansluit met de praktijk. Eerst en vooral wordt in dit hoofdstuk het doel van het onderzoek nader bekeken (5.2). Daarna wordt de onderneming voorgesteld die meegewerkt heeft aan dit onderzoek, namelijk de Universiteit Gent (5.3).In punt 5.4 wordt de onderzoeksmethodiek, de gevalstudie, verder uitgelegd. De belangrijkste kenmerken worden hierbij overlopen. Titel 5.5 heeft het dan over de implementatie aan de UGent. Daarbij wordt eerst en vooral het implementatieproces overlopen (5.5.1). Vervolgens worden de kritieke succesfactoren bestudeerd en hoe deze aangepakt werden (5.5.2). Of de implementatie uiteindelijk een succes geworden is en hoe dit gemeten werd, wordt in 5.5.3 besproken. Afsluitend worden de onderzoeksresultaten overlopen (5.6).

5.2

DOEL VAN HET ONDERZOEK

Om de doelstelling van het onderzoek te kunnen formuleren, stellen we een aantal onderzoeksvragen op. De titel van deze thesis luidt: “Onderzoek naar de determinanten voor een succesvolle implementatie van een ERP-systeem”. Als we deze titel nader bekijken, kunnen we opmerken deze eigenlijk tweeledig is. Enerzijds zijn er de “determinanten”, anderzijds is er de term “succesvolle implementatie”. Bijgevolg kunnen 2 algemene onderzoeksvragen opgesteld worden:

Zijn de geciteerde factoren in het samenvattende model kritiek bij de implementatie van een ERPsysteem? Hoe wordt bij de implementatie van een ERP-systeem succes gemeten? Bij de eerste onderzoeksvraag is het dus de bedoeling het samenvattende model uit hoofdstuk 4 te toetsen aan de praktijk. Dit gaan we doen aan de hand van een gevalstudie. Als gevolg van de kleinschaligheid van dit exploratief onderzoek, heeft dit praktijkonderzoek niet de pretentie het model echt te testen met de werkelijkheid. Wel is het eerder de bedoeling om het eventueel te verfijnen of

- 72 -

Tim Vermeersch


bijkomende kritieke factoren toe te voegen. Indien blijkt dat dit model vrij sterk overeenkomt met de realiteit, kan het aan de hand van verder kwantitatief onderzoek getest worden op haar statistische significantie. Uit de theorie konden reeds enkele bevindingen genoteerd worden:

• Er kan onderscheid gemaakt worden tussen 2 soorten kritieke succesfactoren: algemene factoren en specifieke factoren afhankelijk van de fase in de implementatie. • De uitkomst van de ene fase bepaalt het succes van de volgende fases, dus kritieke factoren in de ene fase bepalen de effectiviteit van factoren in een volgend stadium. • Aandacht voor de kritieke succesfactoren is noodzakelijk, maar biedt geen zekerheid voor een succesvolle implementatie. Ook het onderzoek naar de tweede algemene onderzoeksvraag is vrij beperkt. Via dezelfde gevalstudie zal onderzocht worden op welke manier men de mate van succes van de implementatie heeft gemeten. Bij de bestudering van de literatuur werden reeds een aantal bevindingen vermeld. Op basis van deze bevindingen wordt onderzocht hoe succes in de onderneming van de gevalstudie gemeten werd:

• In de praktijk wordt succes meestal bepaald door slechts 2 factoren: op tijd en binnen budget. • Eén of twee maatstaven om succes van een ERP-systeem te meten volstaan duidelijk niet. Daarom is het beter er een multidimensionele visie op na te houden • Succes van de implementatie is relatief ten opzichte van het moment waarop beoordeeld wordt (factor tijd). • Succes is relatief ten opzichte van de doelstellingen die vooropgesteld werden. Beide onderzoeksvragen werden onderzocht aan de hand van een gevalstudie. Daarvoor werd onder andere een interview gedaan. De vragen werden echter vrij breed gehouden met de bedoeling voldoende ruimte te laten om eventueel nieuwe elementen te ontdekken die tijdens de literatuurstudie over het hoofd gezien werden.

5.3

KEUZE EN VOORSTELLING VAN DE ONDERNEMING

Voor het praktijkonderzoek werd gekozen voor de Universiteit Gent (UGent). Op 26 november 1999 besliste de raad van bestuur namelijk een ERP-pakket in te voeren ter ondersteuning van de bedrijfsprocessen. In 2001 startte de UGent met de implementatie van SAP. De focus werd tijdens de eerste fase gelegd op de financiële processen, namelijk de boekhouding, het facturatie- en het aankoopproces. In 2003 werd dan gestart met de implementatie van de human resources module voor de personeelsadministratie (SAP HR, Beschrijving vereiste functionaliteit en projectaanpak). Het is dan ook dit proces dat in dit praktijkonderzoek verder uitgediept wordt. Voor de implementatie zelf werd de UGent bijgestaan door een externe consultancyfirma, namelijk Arinso. Een meer gedetailleerd overzicht van de

- 73 -

Tim Vermeersch


HR module is te vinden in de bijlagen (Bijlage 1). Het is de meest recente implementatie die bij de UGent gebeurd is. Ze is zelfs nog niet helemaal afgelopen. Als kritiek kan opgemerkt worden dat het misschien interessanter zou zijn de implementatie van de eerste modules te bespreken omdat nog geen leereffecten aanwezig zijn en bijgevolg kritieke factoren meer naar voor zouden treden. Er werden echter meerdere pogingen ondernomen om verschillende personen uit de financiële afdelingen te contacteren, zonder resultaat weliswaar. Bij de human resources was de bereidheid tot medewerking aan dit onderzoek heel wat groter. Vandaar dat het onmogelijk was de implementatie van de financiële modules te behandelen. De UGent telt ongeveer 5200 personeelsleden die bovendien een grote verscheidenheid vertonen. Zo is er het zelfstandig academisch personeel, assisterend academisch personeel, administratief en technisch personeel… Elke categorie heeft haar karakteristieken die telkens in het programma geprogrammeerd moeten

worden

(SAP

HR,

Beschrijving

vereiste

functionaliteit

en

projectaanpak).

Voor

de

salaristoepassing bestaat een Oracle project. De UGent heeft dan ook beslist dat de salarisberekening geen deel uitmaakt van de ERP-implementatie (SAP HR voorstudie).

5.4

ONDERZOEKSMETHODIEK

Zoals eerder vermeld werd voor het praktijkonderzoek in deze thesis gekozen voor een gevalstudie (case study), meer bepaald bij de Universiteit Gent (UGent). Gevalstudies zijn erg geschikt voor onderzoek naar de ontwikkeling, de implementatie en het gebruik van informatiesystemen (Benbasat et al., 1987). In een laboratorium kan een onderzoeker een aantal afhankelijke variabelen meten door het manipuleren van de onafhankelijke variabelen in een gecontroleerde omgeving. Een veldexperiment is vrij gelijkaardig met dat verschil dat het in een natuurlijke omgeving plaatsvindt. Bij een gevalstudie heeft de onderzoeker a priori dan weer minder kennis over de mogelijke variabelen en hoe deze te meten (Benbasat et al., 1987). Een gevalstudie wordt als volgt gedefinieerd:

“A case study examines a phenomenon in its natural setting, employing multiple methods of data collection to gather information from one or a few entities (people, groups or organizations). (Benbasat et al., 1987, blz. 370)” Onderzoek aan de hand van een case study wordt vaak gebruikt bij de vroege ontwikkeling van een theorie of model. Het is belangrijk dat een gevalstudie ondersteund is door een grondige literatuurstudie zodat duidelijke en relevante onderzoeksvragen opgesteld kunnen worden. Het gebruik van een gevalstudie om een theorie te testen moet gebaseerd zijn op een aantal hypotheses van bestaande theorieën. De resultaten kunnen dan vergeleken worden met wat verwacht werd volgens de hypotheses. Bijgevolg kan de theorie bevestigd of ontkracht worden. Eventueel kan ze verder verfijnd worden (Darke et al., 1998).

- 74 -

Tim Vermeersch


“The use of case study research to test theory requires the specification of theoritical propositions derived from an existing theory. The results of case study data collection and analysis are used to compare the case study findings with the expected outcomes predicted by the propositions. The theory is either validated or else found to be inadequate in some way, and may then be further refined on the basis of the case study findings.” (Darke et al., 1998, blz. 275) Ook hier is het de bedoeling een theorie te testen die gebaseerd is op hypotheses uit de bestaande literatuur. De intentie is echter vooral het model verder te verfijnen aan de hand van gegevens uit de praktijk. De case kan een individu, een groep, een organisatie, een project... afhankelijk hoe de algemene onderzoeksvragen opgesteld zijn (Benbasat et al., 1987). Ook het aantal cases hangt af van deze vragen (Darke et al., 1998). In dit praktijkonderzoek werd gekozen om één case, een project, grondig te bespreken. Volgens Darke et al. (1998) levert onderzoek aan de hand van één case grondigere en rijkere informatie op dan onderzoek aan de hand van meerdere cases. Meer gevallen onderzoeken levert dan weer meer zekerheid met betrekking tot de besluiten die getrokken worden. Er is echter geen optimaal aantal gevallen dat bestudeerd moet worden. Om een implementatieproces te onderzoeken is een case study echter de aangewezen methode:

“Since the process of implementation takes place over time, is a complex process involving multiple actors, and is influenced by events that happen unexpectedly, a case study methodology is well-suited to identifying key events and actors and to linking them in a causal chain.” (Benbasat et al., 1987, blz. 378) Een groot gevaar bij onderzoek aan de hand van gevalstudies is dat een theorie ontwikkeld wordt die volledig gebaseerd is op de case en moeilijk veralgemeend kan worden (Eisenhardt, 1987). Daarom kan door de beperkte omvang van het praktijkonderzoek dat in deze thesis gevoerd werd, gesteld worden dat het hier slechts om een exploratief onderzoek gaat. Bij de keuze van de onderneming is het bovendien belangrijk dat zij er voordeel uit haalt. Indien het onderzoek relevant is voor de organisatie en ook de onderzoeksvragen nuttig kunnen zijn, dan is de kans op goede medewerking veel groter (Darke et al., 1998). Misschien was dit de reden waarom de financiële afdeling van de UGent weinig blijk van interesse toonde om mee te werken. Hun implementatieproces was namelijk reeds afgelopen zodat zij weinig nut zouden hebben aan factoren die de implementatie vlotter zouden kunnen doen verlopen. Daarnaast is het belangrijk bij de onderneming die besproken wordt, personen te contacteren die voldoende autoriteit hebben om informatie vrij te geven (Benbasat et al., 1987). Onderzoek aan de hand van een case study kan op meerdere manieren gevoerd worden. Het is belangrijk bewijs van 2 of meer verschillende bronnen te verzamelen die de besluiten kunnen

- 75 -

Tim Vermeersch


ondersteunen. Mogelijke bronnen zijn geschreven documentatie, archiefstukken, interviews, directe observatie… De bedoeling is een ruime set aan data te verzamelen om de complexiteit van de situatie beter te begrijpen (Benbasat et al., 1987). Deze data kan zowel kwalitatief als kwantitatief zijn. Het is erg praktisch van beide gebruik te maken. Het zorgt er voor dat de onderzoeker niet geleid wordt door eventueel valse indrukken die de kwalitatieve informatie nalaat. Kwantitatieve bronnen kunnen dit steeds rechtzetten (Eisenhardt, 1989). Voor het praktijkonderzoek in deze thesis werd onder andere een gesprek gevoerd met de heer DE GEEST, informaticus bij de directie personeel en organisatie aan de UGent. Tijdens het implementatieproces van de HR module was hij projectleider en dus de geknipte persoon om gedetailleerde informatie te verkrijgen. Daarnaast werd zo veel mogelijk gebruik gemaakt van allerhande schriftelijke documenten, rapporten, voorstudies… om eventuele subjectieve informatie te staven met harde feiten.

5.5 5.5.1

DE IMPLEMENTATIE VAN SAP HR BIJ DE UGENT Het implementatieproces

Tijdens het gesprek met de heer DE GEEST werd het implementatieproces van de HR module grondig overlopen. Uit het interview bleek dat het model dat in deze thesis opgebouwd werd vrij sterk met de realiteit overeenkomt. Eventueel kan een fase toegevoegd worden aan het implementatieproces. In de praktijk blijkt het namelijk erg moeilijk reeds van in de selectiefase een gedetailleerd beeld te hebben van de BPR die doorgevoerd zal moeten worden. De heer DE GEEST benadrukte dat het nochtans erg belangrijk is voor de implementatie duidelijkheid te scheppen:

“…In de voorstudie werd vrij concreet geïnventariseerd welke behoeften er waren die door standaard SAP niet konden vervuld worden. In theorie klinkt dit goed, maar dat moet in de praktijk natuurlijk gerelativeerd worden. Er komen steeds zaken naar boven die niet voorzien waren…” (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Bij de voorstudie is de selectiefase reeds achter de rug en is dus al beslist welk pakket geïmplementeerd zal worden. Daarom zou in het model tussen het implementatieteam en de implementatie een fase toegevoegd kunnen worden: “business blueprint”. Ook SAP ziet dit als een aparte fase in het implementatieproces (zie onderstaande figuur).

- 76 -

Tim Vermeersch

Figuur 15


Het HR implementatieproces bij de UGent

Bron: schema verkregen tijdens gesprek met de heer DE GEEST, 3 mei 2007

Het meest opvallende feit bij de implementatie van SAP HR aan de UGent is de duur. Volgens de planning zou de implementatie aan de consultants zo’n 817 werkdagen kosten (zie Bijlage 2). Uiteindelijk bleken 1400 à 1500 dagen nodig om de implementatie tot een goed einde te brengen. Voor de medewerkers van de UGent werd berekend dat ze 1118 dagen nodig zouden hebben (zie Bijlage 2). De uiteindelijke overschrijding was van dezelfde grootteorde als bij de consultants. Oorspronkelijk was het de bedoeling om op 30 november 2005 het systeem in gebruik te nemen. Uiteindelijk was de “going live” pas op 1 mei 2006.

5.5.2 5.5.2.1

Kritieke succesfactoren tijdens de implementatie Algemene factoren

Uit het model dat in de theorie besproken werd, konden 7 factoren gehaald worden die tijdens de gehele implementatie belangrijk zijn. Steun en medewerking van het topmanagement, implementatieteam en

- 77 -

Tim Vermeersch


project champion worden later besproken tijdens de verschillende fases. Er zal blijken dat daar niet alles perfect verlopen is. Zo was de steun van de directie tijdens de hele implementatie vrij zwak, was de communicatie binnen het implementatieteam niet altijd optimaal… Ook de projectplanning bleek allesbehalve perfect. Nochtans werd reeds in de voorstudie een voorlopige projectplanning gemaakt die bovendien erg gedetailleerd was. Toch verliep de implementatie met heel wat vertraging. Zo was de datum voor going live pas op 1 mei 2006 terwijl dit oorspronkelijk voorzien was op 30 november 2005. Een voorbeeld uit de SAP HR project review van 24 februari 2005 maakt duidelijk dat de planning niet altijd foutloos verliep (SAP was tevens verantwoordelijk voor de controle van de kwaliteit van de implementatie):

“De ARINSO project planning blijft altijd op een te abstract niveau. Op basis van een gedetailleerde planning van ARINSO zou de UGENT projectleider een algemene planning met de activiteiten en taken van de UGENT resources kunnen maken. Gedurende de blauwdruk fase waren de activiteiten van de UGENT resources zeer goed gepland, workshop, validatie van documenten… Nu hebben de teamleiders en de users geen zicht op hun toekomstige taken (in maat en in de tijd) op het project.” (SAP HR UGent, Project Review, 24 februari 2005, Gent) Door de tijdsdruk ontstond het gevaar van kwaliteitsvermindering doordat de UGent met het consultancybedrijf Arinso een fixed price overeenkomst bedongen had. De Universiteit Gent keek er echter zeer streng op toe dat kwaliteit opgeleverd werd, aldus de heer DE GEEST (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Een andere belangrijke factor is een duidelijke visie. Daarom heeft de UGent vooraf, voor de implementatie van HR module, een aantal doelstellingen gedefinieerd:

• Integratie: de UGent gebruikt reeds SAP. Directe integratie met de andere modules, en eventueel toekomstige, is noodzakelijk. • Decentralisatie: dubbele registratie van gegevens moet hierdoor vermeden worden. • Uniformiteit: door het centraal en decentraal stellen van dezelfde systemen en functionaliteiten wordt uniforme informatie en werking bekomen. • Onderhoud: SAP levert op regelmatige tijdstippen technische en functionele verbeteringen en aanpassingen. • Uitbreidbaarheid: SAP biedt standaard een brede waaier van functionaliteiten aan die nieuwe behoeften kunnen ondersteunen en die met beperkte inspanning kunnen geïmplementeerd worden. Bij deze doelstellingen staat ook vermeld dat de Universiteit Gent zo veel mogelijk gebruik zal maken van de best practices vervat in het systeem (SAP HR, Beschrijving vereiste functionaliteit en projectaanpak). Uit het gesprek met de heer DE GEEST bleek echter het tegenovergestelde. De best practices werden niet gebruikt en het systeem werd aangepast aan de organisatie.

- 78 -

Tim Vermeersch


“…De Universiteit Gent heeft er bewust voor gekozen de bestaande bedrijfsprocessen niet door te lichten. Het programma werd aangepast aan de processen. Er wordt nu nauwelijks anders gewerkt dan vroeger…” (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Bovendien bleek later in het gesprek dat deze aanpassingen 1 van de oorzaken waren van de vertraging opgelopen tijdens de implementatie. De laatste vermelding bij de doelstellingen is dat veel belang gehecht wordt aan de acceptatie door de eindgebruikers van het nieuwe systeem (SAP HR, Beschrijving vereiste functionaliteit en projectaanpak). Deze laatste doelstelling werd goed gevolgd, want op het vlak van change management kende men weinig problemen. Volgend citaat uit een PowerPoint presentatie door SAP van 18 oktober 2005 die de kwaliteit van het lopende project bespreekt, toont dit aan:

“Acceptance by end user organization: Er is een positieve sfeer rond het project en de nieuwe toepassing.” (SAP HR UGent, Project Review, 18 oktober 2005, Gent) De implementatie van de financiële module had heel wat problemen met zich meegebracht op het vlak van acceptatie door de gebruikers. Daarom was men erg gehoed voor een gelijkaardige situatie. Zelfs in de voorstudie werd dit al benadrukt:

“…Invoering van een nieuw systeem en decentralisatie van de processen creëert automatisch weerstand bij de gebruikers. Dit facet mag zeker niet onderschat worden. Het is dan ook van groot belang om veel aandacht te besteden aan change management zodat de UGent organisatie optimaal wordt voorbereid op de nieuwe omgeving.” (SAP HR voorstudie) De belangrijkste maatregel die men genomen heeft om deze weerstand tegen te gaan, is de gebruikers van bij het begin betrekken bij de implementatie. Zelfs van bij de blauwdruk werd een groot deel van de eindgebruikers betrokken. In de volgende punten zal duidelijk blijken dat tijdens de gehele implementatie men zo veel mogelijk de gebruikers betrokken heeft om het enthousiasme aan te wakkeren.

5.5.2.2

Selectie

Voor alle duidelijkheid wordt de situatie van voor de implementatie van de HR module nogmaals geschetst. In 2002 werd het financiële gedeelte van het SAP-systeem effectief in gebruik genomen. Bijgevolg was het selectieproces voor de HR module vrij eenvoudig. Ofwel werd SAP HR geïmplementeerd ofwel werd gekozen voor een eigen ontwikkeling. Deze keuze was volgens de heer DE GEEST echter niet zo evident, want het implementatieproces van de financiële module had heel wat problemen met zich meegebracht. Of deze problemen te maken hadden met een gebrekkig

- 79 -

Tim Vermeersch


selectieproces en een niet perfect passend systeem kon de heer DE GEEST niet zeggen. Er was dus vrij grote weerstand tegenover de HR module. Daarom heeft de Universiteit Gent beslist een externe firma in te huren om een voorstudie te doen zodat een objectief beeld gecreëerd werd. Uit deze voorstudie, uitgevoerd door Emphasis Consulting, bleek duidelijk dat SAP HR een toegevoegde waarde te bieden had ten opzichte van maatwerk op het vlak van integratie, decentralisatie, uniformiteit, onderhoud en uitbreidbaarheid (SAP HR voorstudie):

“Uit de voorstudie blijkt dat er een reële behoefte bestaat aan automatisering van processen voortvloeiend uit het nieuw personeelsbeleid, met name evaluaties (ZAP en ATP), functieclassificaties, werving en selectie,… Er werd op dit ogenblik geen dringende behoefte aan automatisering van bijvoorbeeld competentiemanagement gedefinieerd. Verder dient gesteld dat de huidige personeelstoepassingen toe zijn aan een functionele upgrade. De voorstudie geeft aan dat de huidige personeelsprocessen, en tevens de nieuwe processen vrij standaard kunnen ondersteund worden met SAP HR. Er werden een 20-tal tekorten geïdentificeerd waarvan 2 grote. De inspanning vereist om met maatwerk de tekorten op te vangen wordt op 210 mandagen geraamd. Het efficiënt inzetten van SAP HR wordt niet belet door deze tekorten. SAP biedt de mogelijkheid om een aantal processen te decentraliseren en zo dubbele registratie van gegevens te vermijden. Dit kan op termijn de algemene werklast verminderen (voorbeeld: wijzigen door de werknemer van adres en/of bankrekeningnummer, het consulteren van de loonbrief zodat deze eventueel niet langer dient afgedrukt en verdeeld te worden, het invoeren van de evaluaties, aanvraag van verlof, registratie van ziekte…). Invoering van een nieuw systeem en decentralisatie van de processen creëert automatisch weerstand bij de gebruikers. Dit facet mag zeker niet onderschat worden. Het is dan ook van groot belang om veel aandacht te besteden aan change management zodat de UGent organisatie optimaal wordt voorbereid op de nieuwe omgeving…”

“…Gelet op de strategische keuze voor SAP als ERP-pakket enerzijds, en de hierboven aangehaalde elementen anderzijds wordt een SAP HR implementatie aanbevolen.” (Bron: SAP HR voorstudie) De UGent heeft getracht deze beslissing op een zo objectief mogelijke manier door te voeren. Er kan dus besloten worden dat het selectieproces van de SAP HR module grondig verlopen is met een sterke betrokkenheid van de projectleider.

- 80 -

Tim Vermeersch

5.5.2.3


Implementatieteam

De structuur van het implementatieteam in de UGent is vrij gelijkaardig aan deze voorgesteld in het theoretische gedeelte. Helemaal bovenaan de hiërarchische ladder staat de stuurgroep met daarin de rector en de verschillende directeurs van de directies. Daaronder staat de beslissingsgroep. Deze bestaat uit de 2 projectleiders (één aangesteld door de UGent, één door het consultancybedrijf), een ontwikkelingsmanager en de directeurs van de directie personeel en organisaties en de directie ICT. Helemaal onderaan staan dan de verschillende implementatieteams. Zoals vermeld deed de UGent beroep op externe consultants van het bedrijf Arinso (ook SAP was kandidaat) die de teams bijstonden (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Op deze structuur is weinig aan te merken. De samenwerking bleek echter minder optimaal. Zo kwam de stuurgroep slechts heel sporadisch samen:

“…Het is een beetje irritant als je met je project vooruit wil gaan zonder dat er nog veel bijsturing is door de top. Dit moet natuurlijk gerelativeerd worden. De stuurgroep heeft nauwelijks gefunctioneerd. Daaronder stond echter wel de beslissingsgroep waar onder andere 2 directeurs in zaten…” (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). In het theoretische gedeelte werd aangeraden het implementatieteam zo veel mogelijk samen in één en dezelfde ruimte te plaatsen. Ook dit werd door de UGent geprobeerd. Zo werden een aantal lokalen vrijgemaakt met de bedoeling de consultants en de leden van de implementatieteams samen te zetten. Het probleem was dat deze leden, behorende tot de HR afdeling nog steeds hun andere taken moesten doen en daarvoor in een ander, verafgelegen gebouw werkten. Bijgevolg werden deze lokalen weinig gebruikt en verliep de communicatie niet optimaal, aldus de heer DE GEEST (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Een laatste moeilijkheid bij het implementatieteam was het grote verloop van de externe consultants. Zo moest tussen de SAP HR en de salarisberekening een vrij complexe interface gebouwd worden. Het grote verloop van de consultants heeft er echter voor gezorgd dat de bouw van deze interface heel wat langer geduurd heeft dan volgens de planning voorzien was. Zoals vermeld heeft de volledige implementatie heel wat vertraging opgelopen. De heer DE GEEST zag het grote verloop als 1 van de oorzaken van deze vertraging (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Ook SAP, in de hoedanigheid als kwaliteitscontroleur, zag het grote verloop als een probleem:

“ARINSO: De instabiliteit van de ploeg heeft tot minder productkennis geleid. Gelukkig is er de motivatie … en de stabiliteit van de jonge nieuwe consultants. Die wordt beter gewaardeerd dan de vroegere instabiliteit en discontinuïteit!” (SAP HR UGent, Project Review, 18 oktober 2005, Gent)

- 81 -

Tim Vermeersch

5.5.2.4


Implementatie

Ook de implementatie zelf is vrij vlot verlopen. Opvallend is wel de keuze die de UGent gemaakt heeft op het vlak van BPR. Men heeft er bewust voor gekozen de bestaande processen vooraf niet door te lichten om op zoek te gaan naar efficiëntieverbeteringen. Men heeft daarentegen beslist het ERP-systeem zo veel mogelijk aan te passen aan de bestaande processen. Dit werd gemotiveerd door te vermelden dat de bestaande manier van werken uiteraard niet zomaar uit de lucht gegrepen is, maar rationeel tot stand gekomen is.

“…Het was de bedoeling van de eerste fase in hoofdzaak de oude toepassing over te brengen naar SAP HR. In grote lijnen was de belangrijkste doelstelling het oude systeem door het nieuwe systeem met dezelfde manier van werken te vervangen…” (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). De heer DE GEEST gaf echter wel toe dat door het vele maatwerk de implementatie vrij sterk uitgelopen is. Een andere kritieke factor tijdens deze fase is de integratie met andere systemen. Ook bij de UGent waren er nog een aantal andere systemen waarmee SAP HR moest samenwerken. Dit was volgens de heer DE GEEST één van de grote uitdagingen. Toch verliep dit vrij vlot, rekening houdend met de reeds vermelde vertragingen. Tijdens de implementatiefase is de samenwerking met consultants erg belangrijk, zeker op het vlak van BPR. Dit bleek bij de UGent geen probleem, uit de project reviews van SAP blijkt namelijk het volgende:

“De medewerking tussen de ARINSO en UGENT is zeer positief.” (SAP HR UGent, Project Review, 24 februari 2005, Gent) In het theoretisch gedeelte werd sterk benadrukt dat de implementatie van een ERP-systeem niet gezien mag worden als de installatie van een standaard softwarepakket. Ook dit werd door de heer DE GEEST sterk beklemtoond. Het is volgens hem veel meer een ontwikkelingsproject waarbij er vooral op moet toegezien worden dat er geen wildgroei ontstaat van allerhande ontwikkelingen en maatwerk.

5.5.2.5

Gewenning & Routine

Tijdens deze fase is het volgens de theorie erg belangrijk dat gebruikers goed opgeleid en getraind worden. Bij de UGent werden naast de gebruikelijke handleidingen, workshops… een aantal maatregelen genomen zodat deze opleidingen zo vlot mogelijk zouden verlopen. Zo werd in de blauwdrukfase al bijna de helft van de gebruikers van de HR module betrokken. Dit was enerzijds noodzakelijk door hun

- 82 -

Tim Vermeersch


specifieke kennis in de complexe personeelsmaterie. Anderzijds had dit een positief effect op de betrokkenheid waardoor de gebruikers snel wisten wat op til was. Een andere maatregel die getroffen werd, was de aanstelling van acht werknemers van de personeelsdienst die dan intensief betrokken werden bij de implementatie. Zij kregen daarenboven bijkomende workshops, opleidingen… waardoor ze een meerwaarde betekenden om de rest van de werkvloer mee te krijgen. Gebruikers konden dan steeds bij hen terecht met eventuele problemen (gesprek met de heer DE GEEST P., 3 mei 2007, Gent).

5.5.2.6

Continuous improvement

Met enige vertraging werd de SAP HR module in gebruik genomen op 1 mei 2006. Hierop startte een fase van 1 jaar waarbij fouten gecorrigeerd werden. Zo kunnen gebruikers steeds problemen melden die dan zo goed mogelijk opgelost worden. Ook SAP en Arinso werken hieraan mee. Er werken nog steeds een aantal consultants aan de verdere verbeteringen. SAP zorgt dan weer voor verdere updates. Er kan dus gesteld worden dat in het algemeen de relaties met de ERP-verkoper en de consultancy firma vrij goed zijn, ook op lange termijn (gesprek met de heer DE GEEST P., 3 mei 2007, Gent). Zwak punt tijdens deze fase is wellicht evaluatie van de performance. Zo wordt de mate van succes van de implementatie slechts heel beperkt gemeten. Het volgende punt gaat hier dieper op in.

5.5.3

Het meten van succes

De UGent had zoals vermeld vooraf, voor de implementatie van HR module, een aantal doelstellingen gedefinieerd. Deze doelen waren echter niet gekwantificeerd in een aantal maatstaven zodat het onmogelijk is achteraf succes te meten aan de hand van deze doelstellingen. Bovendien was de voornaamste doelstelling van de eerste fase van de implementatie volgens de heer DE GEEST het bestaande systeem te vervangen door SAP HR zonder veel aan de functionaliteiten te komen. De enige kwantitatieve maatstaven die de heer DE GEEST kon opnoemen waren de mate waarin binnen budget gebleven is en de mate van continuïteit. Op de vraag of hij persoonlijk de implementatie een succes vond, antwoordde de heer DE GEEST als volgt:

“…Ik denk dat de implementatie een succes is. Het personeelsbeheer is verder blijven functioneren en veel mensen hebben niet gemerkt dat er iets concreet veranderd was.” (gesprek met de heer DE GEEST P., 3 mei 2007, Gent)

- 83 -

Tim Vermeersch


Hij baseert zich dus vooral op continuïteit. Het feit dat de ingebruikname heel wat vertraging opgelopen heeft, noch de gebrekkige samenwerking met de directie… lijken dus mee te spelen in de bepaling van succes. Een multidimensionele techniek zoals de balanced scorecard werd dus helemaal niet gebruikt. Eén van de bevindingen uit de theorie luidt dat succes relatief is ten opzichte van de doelstellingen. Indien we dit in dit specifieke geval toepassen krijgen we volgend beeld:

Tabel 11

Succes relatief ten opzicht van de doelstellingen

Doelstelling

Succes?

Integratie, decentralisatie, uniformiteit, onderhoud, uitbreidbaarheid

Succes

Gebruik best practices

Geen succes

Acceptatie door eindgebruikers

Succes

Tijd

Geen succes

Budget

Succes

Continuïteit

Succes


Over het algemeen kan dus gesteld worden dat de implementatie vrij succesvol verlopen is. Enkel op het vlak van de planning liep niet alles perfect. Ook het gebruik van de best practices werd niet gevolgd, maar de heer DE GEEST bevestigde dat dit de bedoeling van de eerste fase van de implementatie was (gesprek met de heer DE GEEST P., 3 mei 2007, Gent).

5.6

ONDERZOEKSRESULTATEN

Uit de case study kunnen een aantal besluiten getrokken worden. Eerst en vooral is gebleken dat aan het implementatieproces zoals in de theorie voorgesteld eventueel een fase toegevoegd kan worden. De blauwdrukfase, die tussen het implementatieteam en de implementatie zou komen, lijkt belangrijk genoeg om als aparte fase te gelden. Bij de implementatie aan de UGent werd namelijk heel veel aandacht besteed aan de blauwdruk. Bovendien worden de eindgebruikers tijdens dit stadium sterk betrokken zodat problemen op het vlak van weerstand om het nieuwe systeem te gebruiken geminimaliseerd worden.

BESLUIT 1: EVENTUEEL KAN EEN FASE TOEGEVOEGD WORDEN AAN HET IMPLEMENTATIEPROCES, NAMELIJK DE BLAUWDRUKFASE Een aantal conclusies op het vlak van kritieke succesfactoren uit de theorie werden bevestigd in het praktijkonderzoek. Zo bleek onder andere dat de factoren die als belangrijk bestempeld werden doorheen

- 84 -

Tim Vermeersch


het hele implementatieproces ook in de praktijk erg beduidend zijn. Zo werd de steun en medewerking van het topmanagement door de heer DE GEEST als onvoldoende beschouwd. Gelukkig werd dit gebrek opgevangen door de beslissingsgroep. Daarnaast bleek dat een goed change management doorheen de verschillende fases de acceptatie sterk bevordert. Uit de verschillende documenten bleek dan weer dat de planning uit de voorstudie erg grondig was, terwijl ze verder in de implementatie minder gedetailleerd durfde te zijn. Onder andere hierdoor heeft de implementatie heel wat vertraging opgelopen. De doelen ten slotte werden reeds van in de voorstudie duidelijk gemaakt, toch bestond hierover enige onduidelijkheid, bijvoorbeeld op het vlak van de implementatie van de best practices.

BESLUIT 2: DE ALGEMENE FACTOREN ZIJN BELANGRIJK DOORHEEN HET HELE IMPLEMENTATIEPROCES De implementatie was al bij al vrij succesvol, toch waren er enkele problemen met betrekking tot de kritieke succesfactoren in de afzonderlijke fases. De selectiefase verliep vrij vlot, zo werd objectief tot de beslissing gekomen om in SAP HR te investeren en niet zelf te ontwikkelen. Ook op de vorming van het implementatieteam was weinig aan te merken. De structuur zag er uit zoals in de theorie werd aangeraden. De werking kende echter enkele mankementen. Zo verliep de communicatie soms stroef als gevolg van het feit dat de medewerkers van de UGent en de externe consultants ver van elkaar verwijderd waren. Bovendien was er bij de consultants een groot verloop merkbaar. Ook de communicatie met de directie verliep soms moeilijk doordat de stuurgroep slechts sporadisch samenkwam. Al deze problemen werkten mee aan de vertraging in de implementatie. Daaruit blijkt opnieuw dat de communicatie een erg belangrijke factor is doorheen het hele proces. Bij de implementatie zelf was een duidelijke tegenstrijdigheid. Zo stond formeel in de voorstudie dat de best practices van het systeem gebruikt zouden worden, terwijl de projectleider, de heer DE GEEST, duidelijk zei dat het niet de bedoeling was de processen aan te passen. Uiteindelijk leidden deze aanpassingen tot heel wat vertraging. Daaruit kan besloten worden dat minimale aanpassing, duidelijke BPR… kritieke factoren zijn tijdens deze fase. De gewenning & routine fase kende weinig problemen. Gebruikers werden goed opgeleid en getraind aan de hand van presentaties, handleidingen, workshops… De laatste fase ten slotte, continuous improvement, kan moeilijk beoordeeld worden aangezien dit stadium nog steeds loopt. Doordat de gebruikers hierbij sterk betrokken worden, kan echter besloten worden dat ook op deze fase weinig opgemerkt kan worden. Enig pijnpunt hier is de evaluatie van de performance. Tot nu toe werd de implementatie niet getoetst aan enige maatstaf om succes te meten. Men is dit bovendien evenmin van plan. Niet alleen de onduidelijkheid over het succes van de huidige implementatie is een probleem, ook voor verdere implementaties kan dit een probleem opleveren. Zo kan men onmogelijk op een objectieve manier meedelen of de doelstellingen die vooraf opgesteld werden wel degelijk voldaan zijn. Wat zijn bijvoorbeeld de concrete oorzaken van de vertraging en hoe kan dit in de toekomst vermeden worden?

- 85 -

Tim Vermeersch


BESLUIT 3: ZONDER ENIGE OBJECTIEVE METING VAN SUCCES IS ER ONDUIDELIJKHEID OVER HET AL DAN NIET SUCCESVOLLE KARAKTER VAN DE IMPLEMENTATIE

5.7

BESLUIT

Het praktijkonderzoek leverde een drietal besluiten op:

Besluit 1:

Eventueel kan een fase toegevoegd worden aan het implementatieproces, namelijk de blauwdrukfase.

Besluit 2:

De algemene factoren zijn belangrijk doorheen het hele implementatieproces.

Besluit 3:

Zonder enige objectieve meting van succes is er onduidelijkheid over het al dan niet succesvolle karakter van de implementatie.

Vooraf werd echter vermeld dat gevalstudies aan de hand van één case minder zekerheid opleveren dan aan de hand van meerdere cases. Bijgevolg is het gevaarlijk deze besluiten onmiddellijk te veralgemenen. Er zijn dus een aantal zaken waarvan bijkomend onderzoek nuttig zou zijn. Zo zou het wel de moeite lonen na te gaan of de blauwdrukfase ook in andere implementaties een dergelijke belangrijke functie gespeeld heeft om als aparte fase te beschouwd te worden. Daarnaast bleek in de theorie dat er heel wat “kritieke succesfactoren” zijn. Heel wat factoren blijken elkaar echter te overlappen zodat het misschien nuttig zou zijn onderzoek te doen om een beter kader te vormen met duidelijk afgebakende kritieke factoren.

- 86 -

Tim Vermeersch

Algemeen besluit

ALGEMEEN BESLUIT

Deze thesis doet een onderzoek naar de determinanten die een succesvolle implementatie van een ERPsysteem garanderen. In het inleidende hoofdstuk werd een beeld geschetst van de belangrijkste kenmerken. Het tweede hoofdstuk gaf een overzicht van het selectie- en het implementatieproces. In hoofdstuk 3 werden dan een aantal kritieke succesfactoren overlopen. Deze 2 hoofdstukken werden in het daaropvolgende met elkaar gecombineerd waardoor per fase van de implementatie enkele determinanten naar voren komen die een succesvolle implementatie kunnen waarborgen. Deze theorie werd in het afsluitende hoofdstuk verder verfijnd aan de hand van een praktijkonderzoek, meer bepaald een case study. Hoofdstuk 1. Een ERP-systeem is een softwareprogramma dat bestaat uit verschillende geïntegreerde modules die aan te passen zijn aan de kenmerken van de onderneming. Aan de hand van de gemeenschappelijke database beschikt elke afdeling over real-time informatie zodat de bedrijfsprocessen en administratieve functies sterk geïntegreerd zijn; aldus de definitie van een ERP-systeem. De meeste ERP-systemen bestaan uit verschillende modules. Op deze manier kunnen ondernemingen kiezen welke functies ze wensen te verwezenlijken met het ERP-systeem. Kenmerkend voor de manier waarop de verschillende modules bij een ERP-systeem geïntegreerd zijn, is de wijze waarop de data opgeslagen wordt. Alle informatie van de verschillende modules wordt namelijk opgeslagen in één relationele database. Aangezien ERP-systemen volgens de best practice methodes opgevat zijn, moeten vaak de processen en de organisatie gewijzigd worden (BPR), eerder dan het systeem. ERP-systemen hebben reeds een lange evolutie achter de rug. De oorsprong is te situeren in de jaren ’60, met name bij het ontstaan van voorraadcontrolesystemen. Dit leidde in de jaren ’70 geleidelijk tot de ontwikkeling van ‘material requirements planning’ (MRP) systemen. In de jaren ‘80 evolueerde MRP van een plannings- en controlesysteem tot een systeem dat in staat was zowat alle middelen van de onderneming te plannen. Op die manier ontstond manufacturing resource planning, kortweg MRP II. Hoewel MRP II een significante verbetering betekende ten opzichte van de vorige systemen, bleef als gevolg van de dynamische ontwikkelingen bij de ondernemingen de vraag bestaan naar meer geïntegreerde systemen, aldus ontstond Enterprise Resource Planning (ERP). Terwijl MRP II zich traditioneel focuste op de planning van de interne middelen van de onderneming, streeft ERP ernaar ook de middelen van de leveranciers te plannen, gebaseerd op de dynamische vraag van de klanten. De huidige ERP-systemen zijn al vrij omvangrijk qua functionaliteiten, toch blijven er nog enkele problemen, zoals supply chain planning, customer management en marketing. De recente ontwikkelingen liggen dan ook op het vlak van supply chain management (SCM) en customer relationship management (CRM) waarbij men de front office diensten (marketing, klantendiensten…) sterker tracht te integreren met de back office (logistieke diensten, financiële diensten, productieplanning…). Deze evolutie heeft geleid tot de naam “ERP II”.

- 87 -

Tim Vermeersch

Algemeen besluit

Hoofdstuk 2. Geen enkel ERP-systeem voldoet aan alle vereisten die een onderneming stelt. Daarom is het aan te raden dat ondernemingen kiezen voor een flexibel systeem en een ERP-verkoper die bereid is samen te werken met de klant en luistert naar zijn noden. Het gebeurt echter al te vaak dat ondernemingen zonder enig systematisch selectieproces een ERP-systeem aanschaffen. Daarom wordt in deze thesis het AHP-model (analytic hierarchy process) voorgesteld. Het is erg gestructureerd en gedetailleerd en omvat 7 stappen:

Stap 1:

het vormen van een projectteam en het verzamelen van alle mogelijke informatie over ERP-verkopers en -systemen.

Stap 2:

identificeer de noodzakelijke karakteristieken

Stap 3:

maak een structuur van de verschillende doelstellingen

Stap 4:

bepaal de attributen nodig voor de evaluatie van de ERP-systemen

Stap 5:

verwijder de ongeschikte ERP-verkopers door het informeren naar specifieke zaken die te maken hebben met de noodzakelijke karakteristieken

Stap 6:

evalueer de ERP-systemen door middel van de AHP-methode

Stap 7:

discussieer over de resultaten en maak de uiteindelijke beslissing

Er is een duidelijk verschil in het selectieproces tussen grote ondernemingen en kmo’s. De analyse van een prototype, het gebruik van consultants, het extern aankopen van studies zijn methoden die enkel door grote ondernemingen worden toegepast. Kmo’s proberen de duurdere methodes te mijden. Ook het beslissingsproces zelf toont heel wat verschillen. Terwijl kmo’s vooral statische investeringstechnieken gaan gebruiken, zullen grote ondernemingen vaak grijpen naar dynamische procédés, bijvoorbeeld optietheorieën. Het implementatieproces werd in deze thesis veel grondiger besproken. De meest belangrijke implementatiemodellen werden dan ook uitvoerig besproken: het 5-fasen model van Ross en Vitale, de process-theorie van Markus en Tanis, het Project Phase Model (PPM) en het 6-fasen model van Cooper en Zmud. Elk model legt bepaalde klemtonen en heeft zowel sterke als zwakke punten. Daarom werd uit al deze modellen een samenvattend model opgebouwd dat beantwoordt aan alle kritieken die op voorgaande modellen gegeven werd. Het implementatieproces is erg overzichtelijk weergegeven (zie Figuur 9

Samenvattend implementatiemodel).

De eerste fase in dit model is de selectie van een ERP-systeem. Zoals hierboven vermeld mag het belang van een goed selectieproces niet onderschat worden. Ook de andere modellen benadrukken dit, maar wat ontbreekt, is een duidelijke omschrijving van hoe het selectieproces moet geschieden. In deze thesis wordt het AHP selectiemodel aangeraden. Een goed gebalanceerd selectieteam is hierbij niet te onderschatten. Bovendien worden tijdens dit stadium de eisen en karakteristieken die van het systeem verwacht worden al vastgelegd. De optimale uitkomst van deze fase kan als volgt omschreven worden: de onderneming heeft beslist te investeren in een gepast ERP-systeem dat voldoet aan de gestelde eisen.

- 88 -

Tim Vermeersch

Algemeen besluit

Eenmaal deze beslissing genomen is, moet het implementatieteam gevormd worden. Het selectieteam kan als basis dienen voor het implementatieteam. Wat erg belangrijk is, is dat deze groep goed samengesteld is met enerzijds teamleden met technische bagage als met teamleden die eerder een commerciële functie hebben. Hierbij is communicatie essentieel. Aan het hoofd staat een bekwame project champion die over goede leiderscapaciteiten beschikt. Naast het implementatieteam zelf is de steun van een stuurgroep van groot belang. Ten slotte zijn er nog de externe consultants die met hun specifieke ervaring de implementatie vlotter kunnen laten verlopen. Dit is meteen het optimale resultaat dat tijdens deze fase bereikt kan worden. Nadat de projectplanning opgesteld is, kan gestart worden met de eigenlijke implementatie. Deze fase wordt onderverdeeld in drie subfases: BPR, de installatie van het systeem en ten slotte moet het nog getest worden. Indien men een grondig selectieproces gevolgd heeft, zou al duidelijk gebleken moeten zijn welke wijzigingen de organisatiestructuur en de processen zullen ondergaan. Deze aanpassingen worden nu in de praktijk omgezet moeten worden (BPR). Er kan dan ook gestart worden met de installatie van het systeem op de computers. De werkelijke processen en het systeem zullen op elkaar afgestemd worden. Dit is eveneens het ogenblik om de noodzakelijke hardware te installeren. De laatste fase omvat het testen van het systeem (interfaces testen, reële data invoeren…). Heeft men een ERPsysteem met een minimum aan fouten, dan kan het systeem daadwerkelijk in de praktijk toegepast worden. Een volgende vereiste voor een succesvolle implementatie is een correct gebruik door de gebruikers. Het is met name erg belangrijk dat de eindgebruikers een goede opleiding en training genieten zodat ze snel overweg kunnen met het nieuwe systeem. Ook de zogenaamde “resistance to change” dient aangepakt te worden. De optimale uitkomst is een systeem dat algemeen gebruikt wordt in de hele onderneming zonder dat men teruggrijpt naar de oude manier van werken of naar de oude systemen. Het laatste stadium heeft als doel de efficiëntie van de onderneming te verhogen aan de hand van continuous improvement. De prestaties van het systeem moeten dus geoptimaliseerd worden. Upgrades, het wegwerken van kleine fouten zijn hiervan enkele voorbeelden. Eventueel kunnen later bijkomende modules aan het bestaande systeem toegevoegd worden. Optimaal resultaat is een perfect werkend systeem dat zo veel mogelijk up to date blijft. Het voorgaande implementatiemodel geeft een voorbeeld van hoe een succesvolle implementatie kan verlopen. Succes is echter geen eenduidig begrip. Verifiëren of de implementatie op tijd of binnen budget gebeurd is, volstaat niet. In deze thesis werden twee methodes aangereikt om succes te meten. De eerste manier is het succesmodel van Delone en McLean. Als basis neemt men de kwaliteit van de gegenereerde informatie, het systeem en de ondersteuning. Deze factoren zullen hun invloed hebben op de intentie tot gebruik van het systeem (zie resistance to change) en de gebruikerstevredenheid. Bovendien zullen deze laatste twee ook elkaar beïnvloeden. Aan de hand van deze maatstaven is het dan mogelijk de netto voordelen van het systeem te meten.

- 89 -

Tim Vermeersch

Algemeen besluit

De balanced scorecard is de tweede manier waarop succes gemeten kan worden. Succes wordt hier gemeten vanuit vier dimensies: de interne bedrijfsprocessen, de klanten, de financiële resultaten en ten slotte de leer- en groeimogelijkheden. Hieraan worden nog drie andere dimensies toegevoegd: de mate waarin het systeem automatiseert (verhogen van efficiëntie), informeert (door eenvormige data) en transformeert (flexibiliteit van de onderneming). Aldus ontstaat een nuttig kader waarbij succes gemeten wordt vanuit 12 opzichten. De balanced scorecard heeft als bijkomend voordeel dat ook de factor tijd geïntegreerd is bij het meten van succes, want de mate van succes is afhankelijk van het tijdstip waarop men meet. Hoofdstuk 3. In de literatuur zijn heel wat kritieke succesfactoren te vinden. Vaak spreekt men in verschillende termen over dezelfde fenomenen of overlappen bepaalde factoren elkaar. Toch werd geprobeerd een duidelijk overzicht te geven waarbij de factoren ingedeeld werden naar organisatie, gebruiker, systeem en verkoper. De volgende factoren hebben te maken met de organisatie. Gewoonlijk duurt een volledig implementatieproces van een ERP-systeem 1 tot 2 jaar. Bijgevolg is een goed bedrijfsplan noodzakelijk met duidelijk gestelde doelen en een welbepaalde visie. Naast de strategie worden hierin de tastbare voordelen, middelen, kosten, risico’s… uit de doeken gedaan. De geformuleerde doelstellingen moeten duidelijk en transparant zijn, maar toch specifiek genoeg om een indicatie te geven over de globale richting van het project. Wegens de lange duur is ook een gedetailleerde projectplanning noodzakelijk. Ondernemingen hebben nood aan een degelijke projectplanning om voldoende controle te hebben over het implementatieproces, het budget niet te overschrijden en binnen het vooropgestelde tijdsschema te blijven. Wat in de literatuur als erg belangrijk gezien wordt, is onvoorwaardelijke steun en medewerking van het topmanagement. Zoals eerder vermeld brengt de implementatie van een ERP-systeem vaak hervormingen in de bedrijfsprocessen met zich mee. Wegens de enorme impact op de competitiviteit die dit tot gevolg kan hebben, is de steun en medewerking van het topmanagement onontbeerlijk. De leiding over het implementatieteam en -proces wordt gedragen door de project champion. Hij heeft eveneens de cruciale opdracht het implementatieproces vlotter te laten verlopen en de gebruikers van het nut van het nieuwe systeem te overtuigen. De implementatie van een ERP-systeem brengt duidelijk grote veranderingen met zich mee. Van groot belang is dat deze veranderingen door een goed change management programma ondersteund worden, want al te vaak is de weerstand van de eindgebruikers tegenover veranderingen het grootste obstakel. Change management kan op verschillende manieren aangepakt worden: sterk leiderschap, communicatie, training, planning en een aanmoedigingssysteem (‘incentives’). Daarnaast is communicatie een erg belangrijke determinant. Niet enkel tussen de leden van het implementatieteam onderling, maar ook tussen het implementatieteam en de rest van de onderneming. De bedoeling van ERP-systemen is namelijk de verschillende ondernemingsfuncties met elkaar te integreren. Daarom is samenwerking en communicatie tussen de verschillende departementen en het implementatieteam onderling van cruciaal belang voor de vooruitgang van het implementatieproject. Business process reengineering (BPR) is wellicht het proces dat ERP-implementaties het meest

- 90 -

Tim Vermeersch

Algemeen besluit

onderscheidt van andere software-implementaties. Een ERP-implementatie betekent niet enkel de installatie van een software programma, maar omvat ook het herontwerpen van de bestaande bedrijfsprocessen tot de beste standaarden die er bestaan. Alle processen in een bedrijf moeten conform het ERP-model zijn of omgekeerd het ERP-model moet conform de gebruikte processen zijn. Op die manier is de gegenereerde data accuraat. Ondernemingen moeten dus beslissen om ofwel het systeem, ofwel de processen te wijzigen. Een tussenoplossing is natuurlijk ook mogelijk. BPR komt op 4 vlakken in de onderneming voor: de processen, de methodes en procedures, de organisatie en de IT. Ook de evaluatie van de performance mag niet vergeten worden. Aan de ene kant is er de evaluatie van het project zelf. Aan de andere kant kan performance ook opgevat worden als de efficiëntie van de bedrijfsprocessen. Men moet dus evalueren of deze processen al dan niet efficiënter geworden zijn. De technieken om dit te doen werden in hoofdstuk 2 overlopen. Indien een onderneming meerdere sites heeft, zal het ERP-systeem in al deze sites geïmplementeerd moeten worden. Zogenaamde multi-site implementaties zorgen uiteraard voor bijkomende problemen. Er moet bijvoorbeeld een beslissing genomen worden omtrent de graad van autonomie van de verschillende sites. Ook cultuurverschillen tussen de verschillende sites kunnen moeilijkheden met zich meebrengen en natuurlijk stelt zich de vraag hoe de implementatie aan te pakken: gefaseerd, big bang… Op het vlak van de gebruiker zijn er eveneens een aantal belangrijke factoren die een succesvolle implementatie

determineren.

Een

voorbeeld

daarvan

is

een

goed

implementatieteam.

Het

implementatieteam is van enorm belang omdat het verantwoordelijk is voor het initiële ontwerp, de planning… Het team moet evenwichtig samengesteld zijn met enerzijds technisch geschoolde mensen en anderzijds mensen met een goede bedrijfseconomische achtergrond. Daarnaast bevat het vaak een aantal externe consultants die de interne medewerkers bijstaan met hun technische kennis over de implementatie. De externe consultants kunnen de onderneming bijstaan op het vlak van bedrijfseconomische kennis, technische bagage… De mate van interactie tussen deze consultants en de interne medewerkers staat in rechtstreeks verband tot de kans op slagen van de implementatie. Een duidelijk beeld van de optimale structuur van de betrokken personen is weergegeven in een overzichtelijke figuur (zie Figuur 10

De structuur van het volledige implementatieteam).

Opleiding en training van de gebruikers is wellicht de meest geciteerde kritieke succesfactor (CSF). Opleiding is hier een synoniem voor het aanleren van de algemene theoretische concepten en logica van een ERP-systeem. De training die aan de systeemgebruikers aangeboden wordt, handelt in het ideale geval over alle aspecten van het systeem en is continu. Het topmanagement durft al eens de kosten hiervan te onderschatten. Op het vlak van het systeem zelf zijn er een aantal zaken die in het oog gehouden moeten worden om kans op slagen te verhogen. Een mogelijk voorbeeld is de minimale aanpassing van de ERP-software, dit betekent dat een onderneming best zo weinig mogelijk aan de oorspronkelijke broncode van de verkoper raakt, zelfs al gaat dit gepaard met een verlies aan functionaliteit. Wijzigingen aan het systeem zouden enkel mogen aangebracht worden indien deze echt noodzakelijk zijn, of indien ze een competitief voordeel brengen. Integratie met andere systemen is vaak noodzakelijk. Indien ondernemingen voor

- 91 -

Tim Vermeersch

Algemeen besluit

middleware kiezen, is het aan te raden de ERP-verkoper om een lijst van gecertificeerde verkopers te vragen. Jaarlijks publiceren alle grote ERP-verkopers namelijk een lijst van middleware-verkopers waarmee ze samenwerken. Indien de oude systemen die voorheen in de onderneming aanwezig waren, niet vervangen worden, is een goede integratie met de oude systemen eveneens onontbeerlijk. Alvorens het ERP-systeem definitief geïntroduceerd kan worden, moet het voldoende getest worden. Het testen van het systeem is enerzijds noodzakelijk om te controleren of technisch alles in orde is, anderzijds om te zien of de bedrijfprocessen correct geconfigureerd zijn in het systeem. Ten slotte moet opgelet worden bij de keuze van de verkoper. De selectie van het ERP-pakket moet op een dusdanige manier gebeuren dat het systeem gekozen wordt dat het beste aansluit bij de bedrijfsprocessen en de nood aan informatie. Naast het ERP-pakket zelf is ook de situatie van de verkoper van belang. Het opbouwen van een lange termijn relatie met de ERP-verkoper is een must. De kwaliteit van de verkoper op het vlak van de implementatie kan in 3 dimensies onderverdeeld worden. De eerste dimensie is de tijd die de verkoper nodig heeft om problemen op te lossen. Een tweede is het voorhanden zijn van gekwalificeerde consultants met zowel kennis van IT als van de productieprocessen in de onderneming. De laatste dimensie ten slotte is de mate van participatie van de ERP-verkoper tijdens de implementatie. Het is duidelijk dat er heel wat kritieke succesfactoren zijn en dat het dus erg moeilijk is om een klaar inzicht te behouden. Dit wordt geprobeerd in het volgende hoofdstuk door de determinanten te combineren met het implementatieproces. Hoofdstuk 4. In een drietal modellen die in hoofdstuk 2 onder de loep genomen zijn, werd geprobeerd om bepaalde kritieke succesfactoren aan verschillende fases van de implementatie te koppelen: de process-theorie, het project phase model, het 6-fasen model van Cooper en Zmud. Opnieuw werd geprobeerd hieruit een samenvattend model te puren dat de sterke punten van elk model bevat en de zwakke punten zo veel mogelijk weert. Dit bleek echter veel moeilijker dan verwacht, want in het algemeen was er in de literatuur weinig eensgezindheid. Heel wat factoren komen namelijk tijdens het hele implementatieproces terug en zijn dus continu belangrijk. Een mogelijke oplossing is een onderscheid maken tussen factoren die constant belangrijk zijn en de overige factoren die slechts in enkele fases naar voren komen. Een ander probleem is het feit dat het ene model een factor citeert tijdens een bepaalde fase, terwijl een ander model deze factor tijdens een gelijkaardige fase helemaal niet belangrijk vindt. Toch werd geprobeerd een lijn te vinden in de verschillende factoren per fase. De combinatie van het implementatieproces met de kritieke succesfactoren, rekening houdend met voorgaande moeilijkheden heeft geleid tot een overzichtelijk model (zie Figuur 14

Kritieke

succesfactoren tijdens het samenvattende model). Volgende algemene factoren zijn doorheen het volledige implementatieproces van groot belang. Het topmanagement initieert niet enkel het project, maar blijft ook het hele proces aandachtig volgen. Aan de hand van een goed bedrijfsplan kan het implementatieteam, onder leiding van de project champion, de projectplanning nauwgezet volgen zodat

- 92 -

Tim Vermeersch

Algemeen besluit

de implementatie zo vlot mogelijk verloopt. De manier waarop men al deze wijzigingen overbrengt aan het personeel en de gebruikers zou wel eens de meest cruciale factor kunnen zijn. De manier waarop het change management aangepakt moet worden, zal afhankelijk zijn van hoe groot de “resistance to change “ is. Daarnaast zijn er de factoren die in bepaalde fases erg belangrijk zijn. Zo zal tijdens de selectie uiteraard een grondig selectieproces noodzakelijk zijn. Een bekwame project champion die het selectieteam samenstelt zorgt voor een meerwaarde. Met BPR wordt tijdens dit stadium bedoeld dat de onderneming al moet weten welke veranderingen de processen zullen doormaken. Tijdens de daaropvolgende fase is het erg belangrijk dat het implementatieteam goed samengesteld wordt op de manier die al eerder vermeld werd. Het team moet bovendien opgeleid worden zodat de leden duidelijk weten wat van hen verwacht wordt en capabel zijn hun opdrachten tot een goed einde te brengen. De implementatiefase bevat vooral factoren van technologische aard, behalve dan BPR. Dit is dan ook het moment waarop het systeem daadwerkelijk geïmplementeerd wordt. De elementen die hier aangehaald worden, zijn vrij gelijkaardig aan de elementen die men terugvindt in de literatuur over de implementatie van meer standaard softwareprogramma’s. De enige uitzondering hierop is wederom BPR. De voorziene wijzigingen in de processen en structuur worden hier effectief doorgevoerd. Tijdens de laatste 2 fases is het vooral van belang dat de eindgebruikers goed opgeleid en getraind worden. Het systeem wordt verder up-to-date gehouden met behulp van een goede verstandhouding met de ERP-verkoper.

Hoofdstuk 5. In dit hoofdstuk werd de voorgaande theorie aan de praktijk getoetst. De theorie maakte het mogelijk een aantal bevindingen te formuleren. Daaruit was het mogelijk een tweetal algemene onderzoeksvragen op te stellen:

• Zijn de geciteerde factoren in het samenvattende model kritiek bij de implementatie van een ERPsysteem? • Hoe wordt bij de implementatie van een ERP-systeem succes gemeten? Deze 2 vragen werden onderzocht aan de hand van één grondige case study. Gevalstudies zijn namelijk erg geschikt voor onderzoek naar de ontwikkeling, de implementatie en het gebruik van informatiesystemen. Hierbij is het belangrijk bewijs van 2 of meer verschillende bronnen te verzamelen die de besluiten kunnen staven. Deze data kan zowel kwalitatief als kwantitatief zijn. Voor deze case werd beroep gedaan op Universiteit Gent. In 2001 startte de UGent immers met de implementatie van SAP. In 2003 werd gestart met de implementatie van de human resources (HR) module voor de

- 93 -

Tim Vermeersch

Algemeen besluit

personeelsadministratie. Het is dit implementatieproces dat grondig besproken wordt. De bereidheid tot medewerking bij de human resources afdeling was erg groot. Om informatie te verkrijgen, werden verschillende bronnen aangesproken. Er werd bijvoorbeeld een interview gedaan met de heer DE GEEST, projectleider tijdens de SAP HR implementatie. Daarnaast werden heel wat schriftelijke bronnen geraadpleegd om een objectief beeld te kunnen vormen. Eerst en vooral werd het implementatiemodel uit hoofdstuk 2 aan de realiteit getoetst. Uit het interview met de heer DE GEEST bleek dat het model dat in deze thesis geconstrueerd werd vrij sterk met de realiteit overeenkomt. Eventueel kan een fase toegevoegd worden aan het implementatieproces. De heer DE GEEST benadrukte namelijk dat het erg moeilijk is reeds van in de selectiefase een gedetailleerd beeld te hebben van de BPR die doorgevoerd zal moeten worden. Daarom zou in het model tussen het implementatieteam en de implementatie een fase toegevoegd kunnen worden: “blauwdrukfase”. Door de beperkte omvang is het echter aan te raden dat verder onderzoek duidelijk maakt of deze fase ook in andere implementaties zo’n belangrijke functie toebedeeld krijgt.

BESLUIT 1: EVENTUEEL KAN EEN FASE TOEGEVOEGD WORDEN AAN HET IMPLEMENTATIEPROCES, NAMELIJK DE BLAUWDRUKFASE Vervolgens werd het belang van de algemene factoren tijdens de implementatie nagegaan. Uit allerhande bronnen bleek dat alle geciteerde factoren erg belangrijk zijn doorheen het hele proces. Zo zorgden een gebrekkige projectplanning, onvoldoende steun van het topmanagement en moeilijke communicatie er voor dat de implementatie heel wat vertraging kende. Aan de overige algemene factoren werden dan weer heel goed aandacht geschonken. De doelstellingen bijvoorbeeld werden reeds in de voorstudie duidelijk bekend gemaakt. Daarenboven was er als gevolg van de goede manier waarop het change management aangepakt werd, geen enkele weerstand van de eindgebruikers tegenover het nieuwe systeem. Ook het implementatieteam werd samengesteld zoals het in de theorie optimaal bevonden werd.

BESLUIT 2: DE ALGEMENE FACTOREN ZIJN BELANGRIJK DOORHEEN HET HELE IMPLEMENTATIEPROCES Bij de fase-specifieke factoren was het erg moeilijk om besluiten te trekken. Aan zowat alle factoren werd voldoende aandacht geschonken. Bovendien kende men weinig problemen op het vlak van deze determinanten. Vandaar dat het ook erg moeilijk was om eventueel na te gaan of bepaalde factoren nu echt determinerend zijn. Slechts tijdens 2 fases waren noemenswaardige problemen te vermelden. Het eerste geval ging om BPR en de minimale aanpassing van het systeem tijdens de implementatiefase. In de doelstellingen stond duidelijk te lezen dat de processen aangepast zouden worden aan het systeem. In de praktijk, en volgens de heer DE GEEST was dit ook de bedoeling, werd echter het systeem aangepast aan de processen. Gevolg was dat het vele maatwerk dat hierbij te pas kwam er

- 94 -

Tim Vermeersch

Algemeen besluit

mede voor gezorgd heeft dat de implementatie heel wat vertraging opliep. Het tweede probleem had te maken met de evaluatie van de performance. De doelstellingen die vooraf geformuleerd waren, werden niet gekwantificeerd in een aantal maatstaven zodat het onmogelijk is achteraf succes te meten. Bovendien was de doelstelling in verband met BPR duidelijk tegenstrijdig met wat werkelijk plaatsgevonden heeft. Nader onderzoek toonde aan dat de UGent op geen enkele manier de mate van succes van de implementatie onderzocht heeft. Niet alleen de onduidelijkheid over het succes van de huidige implementatie is een probleem, ook voor eventuele verdere implementaties kan dit een probleem opleveren. Zo kan men onmogelijk op een objectieve manier nagaan of wel voldaan is aan de vooraf gestelde doelstellingen. Dit zorgt er voor dat fouten eventueel in de toekomst opnieuw gemaakt kunnen worden.

BESLUIT 3: ZONDER ENIGE OBJECTIEVE METING VAN SUCCES IS ER ONDUIDELIJKHEID OVER HET AL DAN NIET SUCCESVOLLE KARAKTER VAN DE IMPLEMENTATIE Ten slotte dient nog opgemerkt te worden dat in de theorie er heel wat “kritieke succesfactoren” opgesomd word. Opvallend is echter dat heel wat factoren elkaar overlappen zodat het misschien nuttig zou zijn onderzoek te doen om een beter kader te vormen met duidelijk afgebakende kritieke factoren.

- 95 -

Tim Vermeersch

Lijst van geraadpleegde werken

LIJST VAN GERAADPLEEGDE WERKEN

BOEKEN, ARTIKELS EN VERZAMELWERKEN: ABDINNOUR-HELM S., LENGNICK-HALL M. en LENGNICK-HALL C., 2003, Pre-implementation attitudes and organizational readiness for implementing an Enterprise Resource Planning system, European Journal of Operational Research, volume 146, nummer 2, blz. 258-273. AKKERMANS H. en VAN HELDEN K, 2002, Vicious and virtuous cycles in ERP implementation: a case study of interrelations between critical success factors, European Journal of Information Systems, volume 11, nummer 1, blz. 35-46. AL-MASHARI M., AL-MUDIGMIGH A. en ZAIRI M., 2003, Enterprise resource planning: A taxonomy of critical factors, European Journal of Operational Research, volume 146, nummer 2, blz. 352-364. AL-MUDIGMIGH A., ZAIRI M. en AL-MASHARI M., 2001, ERP software implementation: an integrative framework, European Journal of Information Systems, volume 10, nummer 4, blz. 216-226. BEATH C.A., 1991, Supporting the information technology champion, MIS Quarterly, volume 15, nummer 3, blz. 355-372. BANCROFT N., SEIP H. en SPRENGEL A., 1998, Implementing SAP R/3: How to introduce a large system into a large organization, Manning Publication Co., Greenwich, 312 blz. BENBASAT I., GOLDSTEIN D. en MEAD M., 1987, The case research strategy in studies of information systems, MIS Quarterly, volume 11, nummer 3, blz. 369-386. BERNROIDER E. en KOCH S., 2001, ERP selection process in midsize an large organizations, Business Process Management Journal, volume 7, nummer 3, blz. 251-257. BINGI P., SHARMA M.K. en GODLA J.K., 1999, Critical issues affecting an ERP implementation, Information Systems Management, volume 16, nummer 3, zomer, blz. 7-14. BOND B., GENOVESE Y., MIKLOVIC D., WOOD N., ZRIMSEK B. en RAYNER N., 2000, ERP is dead – Long live ERP II, Research note, Gartner Group, 4 oktober 2000.

- VII -

Tim Vermeersch


BURNS O.M., TURNIPSEED D., RIGGS W.E., 1991, Critical success factors in manufacturing resource planning implementation, International Journal of Operations and Production Management, volume 11, nummer 4, blz. 5-19. CHAND C., HACHEY C., HUNTON J., OWHOSO V. en VASUDEVAN S., 2005, A balanced scorecard based framework for assessing the strategic impacts of ERP systems, Computers in Industry, volume 56, nummer 6, blz. 558-572. CHEN I.J., 2001, Planning for ERP systems: analysis and future trend, Business Process Management Journal, volume 7, nummer 5, blz. 374-386. COOKE D. en PETERSON W., 1998, SAP implementation: strategies and results, The Conference Board, New York. DARKE P., SHANKS G. en BROADBENT M., 1998, Successfully completing case study research: combining rigour, relevance and pragmatism, Information Systems Journal, volume 8, nummer 4, blz. 273- 289. DAVENPORT H., 1998, Putting the enterprise into the enterprise system, Harvard Business Review, volume 76, nummer 4, blz. 121-131. DELONE W.H. en MCLEAN E. R., 1992, Information systems succes: The quest for the dependent variable, Information Systems Research, volume 3, nummer 1, blz. 60-95. th

DELONE W.H. en MCLEAN E. R, 2002, Information systems success revisited, Proceedings of the 35 Hawaii International Conference on System Sciences, blz. 1-11.

EHIE I. en MADSEN M., 2005, Identifying critical issues in enterprise resource planning (ERP) implementation, Computers in Industry, volume 56, nummer 6, blz. 545-557. EISENHARDT K., 1989, Building Theories from case study research, The Academy of Management Revieuw, volume 14, nummer 4, blz. 532-550. EVERDINGEN Y.V., HILLERGERSBERG J.V. en WAARTS E., 2000, ERP adoption by European midsize companies, Communications of the ACM, volume 43, nummer 4, blz. 27-31. GABLE G., 1998, Large package software: a neglected technology, Journal of Global Information Management, volume 6, nummer 3, blz. 3-4.

- VIII -

Tim Vermeersch


HAMMER M. en CHAMPY J., 2001, Reengineering the corporation : A manifesto for business revolution, Harper Business, New York. HOLLAND P., LIGHT B., 1999, A critical success factors model for ERP implementation, IEEE software, volume 16, nummer 3, Mei/Juni, blz. 30-35. IVES B., HAMILTON S., DAVIS G.B., 1980, A framework for research in computer-based management information systems, Management Science, volume 26, nummer 9, blz. 910-934. JARRAR Y., AL-MUDIMIGH A. en ZAIRI M., 2000, ERP implementation critical success factors: the role and impact of business process management, proceedings of the 2000 IEEE international conference on management of innovation and technology, 12-15 november, Singapore. JIANG J.J., KLEIN G. en BALLOUN J., 1996, Ranking of system implementation success factors, Project Management Journal, volume 27, blz 49-53. KAPLAN R. en Norton D., 1992, The balanced scorecard – measures that drive performance, Harvard Business Review, volume 70, nummer 1, blz. 71-79. KOEDIJK A. en VERSTELLE A., 1998, ERP in bedrijf, Uitgeverij Tutein Nolthenius, Den Bosch, 320 blz. KRAEMMERAND P., MOLLER C. en BOER H., 2003, ERP implementation: an integrated process of radical change and continuous learning, Production Planning & Control, volume 14, nummer 4, blz. 338348. KUMAR K. en HILLEGERSBERG J.V., 2000, ERP experiences and evolution, Communications of the ACM, volume 43, nummer 4, blz. 22-26. KUMAR V., MASHESHWARI B. en KUMAR U., 2002, Enterprise resource planning systems adoption process: a survey of Canadian organizations, International Journal of Production Research, volume 40, nummer 3, blz. 509-523. LAUGHLIN S., 1999, An ERP game plan, Journal of Business Strategy, volume 20, nummer 1, januari/februari, blz. 32-37. LOH T. C., KOH S.C.L., 2004, Critical elements for a successful enterprise resource planning implementation in small- and medium-sized enterprises, International Journal of Production Research, volume 42, nummer 17, blz. 3433-3455.

- IX -

Tim Vermeersch


MABERT V., ASHOK S. en VENKATARAMANAN M.A., 2001, Enterprise resource planning: common myths versus evolving reality, Business Horizons, volume 44, nummer 3, Mei-Juni, blz. 71-78. MARKUS M. en TANIS C., 2000, The enterprise systems experience – from adoption to success, Framing the domains of IT research: glimpsing the future through the past, Pinnaflex Educational Resources, Cincinnati, blz. 173-207. MARKUS M., AXLINE S., PETRIE D. en TANIS C., 2000, Learning from adopters’ experiences with ERP: problems encountered and success achieved, Journal of Information Technology, volume 15, nummer 4, blz. 245-265. MARKUS M., TANIS C., VAN FENEMA P., 2000b, Multisite ERP implementations, Communications of the ACM, April, volume 43, nummer 4, blz. 42-46. MICHEL R., 2001, ERP gets redefined, Manufacturing Systems, volume 19, nummer 2, blz. 36-44. MOLLER C., 2005, ERP II – next generation extended enterprise resource planning, Journal of Enterprise Information Management, volume 18, nummer 4, blz. 483-497. MURRAY M. en COFFIN G., 2001, A case study analysis of factors for success in ERP system implementations, Proceedings of the Seventh Americas Conference on Information Systems, Boston, blz. 1012-1018. NAH F., ZUCKWEILER K. en LAU J., 2003, ERP implementation: chief information officers’ perceptions of critical success factors, International Journal of Human-Computer Interaction, volume 16, nummer 1, blz. 5-22. O’LEARY D., 2000, Enterprise resource planning systems: systems, life cycle, electronic commerce, and risk, Cambridge University Press, Cambridge, 232 blz. OOGHE H., DELOOF M. en MANIGART S., 2003, Handboek bedrijfsfinanciering, Intersentia, Antwerpen, 588 blz. PARR A. en SHANKS G., 2000, A model of ERP project implementation, Journal of Information Technology, volume 15, nummer 4, blz. 289-303. PAWLOWSKI S. en BOUDREAU M., 1999, Constraints and flexibility in enterprise systems: a dialectic of system and job, Proceedings of the Americans conference on informations systems (AMICS).

-X-

Tim Vermeersch


RAJAGOPAL P., 2002, An innovation-diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model, Information & Management, volume 40, nummer 2, blz. 87-114. RAJAGOPAL P., TYLER F., 2000, Enhancing manufacturing performance with ERP systems, Information Systems Management, volume 17, nummer 3, zomer, blz. 43-55. RASHID M.A., HOSSAIN L. en PATRICK J.D., 2002, The evolution of ERP Systems: A historical perspective, Enterprise Resource Planning: Global opportunities & challenges, Hershey, PA: Idea Group Publishing, blz 1-16. ROBERTS H.J. en BARRAR P.R., 1992, MRP II implementation: key factors for success, Computer Integrated Manufacturing Systems, volume 5, nummer 1, blz. 31-38. th

ROSEMANN M., 1999, ERP-software-characteristics and consequences, Proceedings of the 7 European Conference on Information Systems, Kopenhagen, Denemarken.

ROSEMANN M. en WIESE J., 1999, Measuring the performance of ERP software – a balanced scorecard approach, Proceedings of the 10th Australasian Conference on Information Systems, blz. 773784. ROSS J. en VITALE M., 2000, The ERP revolution: surviving vs. Thriving, Information Systems Frontiers, volume 2, nummer 2, blz. 233-241. SAP HR voorstudie, Consolidatie, Emphasis Consulting, juni 2003, 51 blz. SAP HR Ugent, Findings Presentation, Project Review Final Preparation, Annick Vandueren, 18 oktober 2005. SAP HR Ugent, Project Review Blauwdruk Fase Rapport, Annick Vandueren, 24 februari 2005. SAP Human Resources, Beschrijving vereiste functionaliteit en projectaanpak (bijlage aan bestek ICT/2003/0802 betreffende de opdracht voor aanneming van diensten inzake de implementatie van SAP Human Resources voor de ondersteuning van de werking van de Directie Personeel en Organisatie van de Universiteit Gent, 122 blz. SCHNITT D., 1993, Reengineering the organization using information technology, Journal of Systems Management, volume 44, nummer 1, blz. 14-20.

- XI -

Tim Vermeersch


SHANG S. en SEDDON P., 2000, A comprehensive framework for classifying the benefits of ERP systems, Proceedings of Americas Conference on Information Systems. SLATER D., 1999, What is ERP?, CIO Magazine, volume 12, nummer 15, blz. 86. SLEVIN D. en PINTO J., 1987, Balancing strategy and tactics in project implementation, Sloan Management Review, volume 29, nummer 1, herfst, blz. 33-44. SOMERS T. en NELSON K., 2001, The impact of critical success factors across the stages of enterprise th

resource planning implementations, Proceedings of the 34 Hawaii conference on system sciences. SOMERS T. en NELSON K., 2004, A taxonomy of players and activities across the ERP project life cycle, Information & Management, volume 41, nummer 3, blz. 257-278. SPINNER M., 1997, Project management: principles and practices, Prentice Hall, New Jersey, 308 blz. TADJER R., 1998, Enterprise resource planning, Internetweek, Manhasset, 13 April. UMBLE E., HAFT R. en UMBLE M., 2003, Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research, volume 146, nummer 2, blz. 241-257. WEI C., CHIEN C. en WANG M., 2005, An AHP-based approach to ERP system selection, International Journal of Production Economics, volume 96, nummer 1, blz. 47-62. WELTI N., 1999, Successful SAP R/3 implementation: practical management of ERP projects, AddisonWesley Longman Publishing Co., Boston, 185 blz. WESTON F.C., 2003, ERP II: the extended enterprise system, Business Horizons, volume 46, nummer 6, November-December, blz. 49-55. WIGHT O., 1993, The executive’s guide to successful MRP II, John Wiley & Sons Inc, New York, USA, 143 blz. YUSUF Y., GUNASEKARAN A., ABTHORPE M.K., 2004, Enterprise information systems project implementation: A case study of ERP in Rolls-Royce, International Journal of Production Economics, volume 87, nummer 3, blz. 251-266. ZHANG Z., LEE M., HUANG P., ZHANG L. en HUANG X., 2005, A framework of ERP systems implementation success in China: An empirical study, International Journal of Production Economics, volume 98, nummer 1, blz. 56-80.

- XII -

Tim Vermeersch


???, 2001, Taking the pulse of ERP, Modern Materials Handling, volume 56, nummer 2, blz. 44-49.

INTERNETREFERENTIES: ICH ARCHITECTURE RESOURCE CENTER, 2004, Interoperability clearinghouse glossary of terms, URL: . (16/02/2007). FITZGERALD B., 2006b, AMR Research Report Finds U.S. Companies will Increase their Enterprise Resource

Planning

Budgets

by

12.3%

in

2006,

AMR

Research,

URL:

. (06/04/2007). REILLY K., 2005, AMR Research Releases ERP Market Report Showing Overall Market Growth of 14% in

2004,

AMR

Research,

URL:

.

(06/04/2007). REILLY K., 2005, AMR Research Releases Report Showing Overall European Market for ERP Vendors to

Grow

7%

Annually

Through

2009,

AMR

Research,

URL:

. (06/04/2007). REILLY K., 2006, Enterprise Resource Planning Software Will Grow to $29 Billion in 2006, AMR Research, URL: . (05/02/2007). THE

INSTITUTE

OF

INTERNAL

AUDITORS,

Definition

of

internal

auditing,

URL:

. (06/02/2007). THE

JOINT

COMMISSION,

2006,

Sentinel

Event

Glossary

. (06/02/2007).

- XIII -

of

Terms,

URL:

Tim Vermeersch

Bijlagen

BIJLAGEN

Bijlage 1

SAP HR MODULE

Module

Korte omschrijving

Personeelsadministratie

Binnen

de

module

personeelsadministratie

worden

alle

persoonsgebonden gegevens beheerd. Voorbeelden: adres, uurrooster, bedrijfsvoorheffing, basisverloning, echtgeno(o)t(e) en kinderen. Deze gegevens kunnen rechtstreeks worden beheerd (voorbeeld: wijziging van bankrekeningnummer) of ze kunnen worden beheerd via acties (voorbeeld: ‘in dienst’, ‘mutatie’…) Tijdbeheer

Met de module tijdbeheer is het mogelijk positieve registratie of negatieve registratie van tijdgegevens te doen. Bij positieve registratie worden alle details in SAP HR ingevoerd (meestal via een systeem van tikklokken). Bij negatieve registratie worden enkel de uitzonderingen op het standaard uurrooster ingevoerd. Na registratie van de tijdgegevens worden deze geëvalueerd om te worden doorgestuurd naar de salaristoepassing. Binnen UGent zal enkel gebruik worden gemaakt van negatieve tijdregistratie.

Organisatiebeheer

De module organisatiebeheer laat toe om alle organisatiegebonden structuren te beheren. Hieronder vallen de organisatorische structuren (voorbeeld:

faculteiten

met

daarbinnen

vakgroepen),

de

rapporteringstructuren, de functiebeschrijvingen… Kwalificatiebeheer

Kwalificatiebeheer maakt gebruik van een basiscatalogus waarin alle UGent kwalificaties kunnen worden beheerd. Indien deze kwalificaties worden gekoppeld aan de organisatie, dan gaat het om de vereisten van de organisatie. Indien ze worden gekoppeld aan een persoon, dan bezit die persoon de kwalificatie.

Opleidingsbeheer

Binnen opleidingsbeheer kunnen alle opleidingen worden beheerd, en kan het volledige administratieve proces met betrekking tot opleidingen worden

afgehandeld.

Dit

proces

annuleringen, facturatie… omvatten.

- 1-1 -

kan

taken

zoals

boekingen,

Tim Vermeersch

Personeelskostenplanning

Bijlagen

Het begrotingsproces en de reserveringen kunnen worden verwerkt met de module personeelskostenplanning. Binnen deze module kunnen de basisverloningen van de medewerkers, de werkelijke loonkosten van de medewerkers, en de verwachte loonkost van vacatures, als basis gebruikt worden. Hieraan kunnen vervolgens diverse wijzigingen worden aangebracht (index, loonsverhoging…).

Werving en selectie

Binnen werving en selectie kan het wervingsproces worden beheerd, inclusief uitnodigingen voor interviews, registratie van resultaten, afnemen van testen… Ook kan via deze module een wervingsreserve worden beheerd.

Evaluatiesystemen

Evaluaties kunnen worden beheerd via de module evaluatiesystemen. Het kan hierbij gaan om evaluaties van opleidingen, van lesgevers, van deelnemers aan opleidingen, van prestaties van medewerkers. Naar keuze kunnen evaluaties ook leiden tot een andere verloning.

Employee selfservice

Via employee selfservice kunnen medewerkers rechtstreeks hun eigen gegevens raadplegen of wijzigen. Voorbeelden: raadplegen loonbrief, wijzigen bankrekening, aanvraag verlof.

Bron: SAP HR, beschrijving vereiste functionaliteit en projectaanpak.

- 1-2 -

Tim Vermeersch

Bijlage 2

Bijlagen

PROJECTPLANNING VAN DE IMPLEMENTATIE VAN SAP HR AAN DE UGENT

UGent SAP HR Fase 1

Begin

Project Voorbereiding Opleiding projectploeg Change Management

Einde

Doorlooptij d in kalender- Consultant dagen dagen

UGent dagen

1/okt/04 31/okt/04 1/okt/04 31/okt/04 1/okt/04 30/sep/05

30 30 364 Subtotaal

40 10,5 80 130,5

48 42 60 150

1/nov/04 1/jan/05 1/jul/05 1/okt/05

31/dec/04 30/jun/05 30/sep/05 30/nov/05

60 180 91 60 Subtotaal

20 100 27 22 169

41 124 51 43 259

Business Blueprint Realisatie Finale Voorbereiding Go Live en Ondersteuning

1/nov/04 1/jan/05 1/jul/05 1/okt/05

31/dec/04 30/jun/05 30/sep/05 30/nov/05


21 119 36 24 200

34 100 44 37 215

Organisatiebeheer Business Blueprint Realisatie Finale Voorbereiding Go Live en Ondersteuning

1/nov/04 1/jan/05 1/jul/05 1/okt/05

31/dec/04 30/jun/05 30/sep/05 30/nov/05


11 47 23 13 94

23 62 39 28 152

Personeelskostenplanning Business Blueprint Realisatie Finale Voorbereiding Go Live en Ondersteuning

1/nov/04 1/jan/05 1/jul/05 1/okt/05

31/dec/04 30/jun/05 30/sep/05 30/nov/05


12 41 18 13 84

19 50 34 28 131

1/nov/04 1/jan/05 1/jul/05 1/okt/05

31/dec/04 30/jun/05 30/sep/05 30/nov/05


12 30 18 13 73

23 49 37 28 137

60 180 91 60 Subtotaal TOTAAL

12 35 17 13 77 817

19 43 30 24 116 1118

Personeelsadministratie Business Blueprint Realisatie Finale Voorbereiding Go Live en Ondersteuning Tijdbeheer

Evaluaties Business Blueprint Realisatie Finale Voorbereiding Go Live en Ondersteuning

Integratie SAP HR Oracle (master data) Business Blueprint 1/nov/04 31/dec/04 Realisatie 1/jan/05 30/jun/05 Finale Voorbereiding 1/jul/05 30/sep/05 Go Live en Ondersteuning 1/okt/05 30/nov/05

- 2-1 -

Onderzoek naar de determinanten voor een succesvolle implementatie van een ERP-systeem

Recommend Documents