to customize odoo or not? a decision support...

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE

ACADEMIEJAAR 2013 – 2014

To Customize Odoo or not? A decision support tool.

Masterproef voorgedragen tot het bekomen van de graad van

Master of Science in de Handelswetenschappen

Timothy Verellen

onder leiding van

Prof. dr. ir. ing. Gert Loterman

I

Permission

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en

delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder

de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de

bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

Timothy Verellen

II

Dankwoord

Het schrijven van een masterproef is een werk van lange adem. Tijd die normaal geïnvesteerd

werd in familie en vrienden ging nu op in de masterproef.

Op de eerste plaats bedankt ik mijn ouders die mij te allen tijde gesteund hebben in mijn

studies. Het is door hun aanhoudende stimulans dat ik doorheen mijn studies steeds beter

wou presteren.

Daarnaast bedank ik mijn vriendin, Julie, voor haar begrip en steun in deze periode.

Ook dank u aan mijn goede vriend en toeverlaat, Christophe voor de nodige feedback alsook

het nalezen van de masterproef.

Ten laatste wil ik ook zeker mijn promotor Prof. dr. ir. ing. Gert Loterman bedanken voor de

vele feedbackmomenten en waardevolle discussies. Ik wil Meneer Loterman tevens bedanken

voor het interessante onderwerp van de masterproef.

Mei 2014,

Timothy Verellen

III

Inhoudstabel

PERMISSION ........................................................................................................................................................ I

DANKWOORD ..................................................................................................................................................... II

INHOUDSTABEL ................................................................................................................................................. III

AFKORTINGEN .................................................................................................................................................... V

LIJST MET TABELLEN .......................................................................................................................................... VI

LIJST MET FIGUREN .......................................................................................................................................... VII

HOOFDSTUK 1: INTRODUCTIE ............................................................................................................................ 1

HOOFDSTUK 2: LITERATUURONDERZOEK .......................................................................................................... 3

2.1. ERP .......................................................................................................................................................... 4

2.1.1. Definitie en eigenschappen .............................................................................................................. 4

2.1.2. Geschiedenis .................................................................................................................................... 5

2.1.3. Voordelen van ERP ........................................................................................................................... 6

2.1.4. Nadelen van ERP .............................................................................................................................. 7

2.1.5. Odoo ................................................................................................................................................ 8

2.2. ERP IMPLEMENTATIE .................................................................................................................................... 8

2.2.1. Fasen van implementatie ................................................................................................................. 9

2.2.2. Ook ERP implementaties falen.......................................................................................................... 9

2.2.3. Kritieke falingsfactoren voor ERP implementaties. ......................................................................... 10

2.2.4. Customization ................................................................................................................................ 11

2.2.5. Customization Vs. Out-Of-The-Box ................................................................................................. 11

2.2.6. Voor- en nadelen van ERP customization ........................................................................................ 11

2.2.7. Iedereen wil customization ............................................................................................................. 12

2.2.8. Conclusie ........................................................................................................................................ 13

2.3. BUSINESS VALUE ........................................................................................................................................ 13

2.4. ONDERZOEKSVRAGEN .................................................................................................................................. 14

HOOFDSTUK 3: METHODES .............................................................................................................................. 15

3.1. DELPHI METHODE ....................................................................................................................................... 16

3.2. RANKING DELPHI METHODE .......................................................................................................................... 18

3.3. KEUZE VAN DE EXPERTENPANEL ...................................................................................................................... 18

3.4. FASE 1 – RONDE 1: IDENTIFICATIE VAN DE DRIJVENDE FACTOREN. .......................................................................... 19

3.4.1. Ontvangen van de antwoorden ...................................................................................................... 20

3.4.2. Verwerken van de antwoorden ...................................................................................................... 21

3.4.3. Factoren samengebracht................................................................................................................ 21

IV

3.4.4. Vereenvoudiging van het aantal factoren ...................................................................................... 22

3.4.5. Vernieuwde indeling ....................................................................................................................... 22

3.4.6. De gesynthetiseerde factorenlijst ................................................................................................... 22

3.4.7. Conclusie ........................................................................................................................................ 23

3.5. FASE 1 – RONDE 2: VALIDATIE VAN DE DRIJVENDE FACTOREN ................................................................................ 23


3.5.2. Verwerken van de antwoorden....................................................................................................... 25

3.5.3. Conclusie ........................................................................................................................................ 25

3.6. FASE 2: WEGING VAN DE DRIJVENDE FACTOREN ................................................................................................. 25


3.6.2. Verwerken van de antwoorden ...................................................................................................... 27

3.6.3. Conclusie ........................................................................................................................................ 27

3.7. OPSTELLEN DECISION SUPPORT TOOL .............................................................................................................. 27

3.7.1. Gewichten herschalen .................................................................................................................... 29

3.7.2. Schalen normaliseren ..................................................................................................................... 29

HOOFDSTUK 4: RESULTATEN EN DISCUSSIES.................................................................................................... 32

4.1. FASE 1 - RONDE 1: IDENTIFICATIE VAN DE DRIJVENDE FACTOREN ........................................................................... 33

4.1.1. Analyse van de aangebrachte factoren........................................................................................... 33

4.1.2. De gesynthetiseerde factorenlijst ................................................................................................... 36

4.1.3. Conclusie ........................................................................................................................................ 40

4.2. FASE 1 - RONDE 2: VALIDATIE VAN DE DRIJVENDE FACTOREN ................................................................................ 40

4.2.1. Analyse van de antwoorden ........................................................................................................... 41

4.2.2. De finale factorenlijst ..................................................................................................................... 44

4.2.3. Conclusie ........................................................................................................................................ 45

4.3. FASE 2: WEGING VAN DE DRIJVENDE FACTOREN ................................................................................................. 46

4.3.1. Analyse van de antwoorden ........................................................................................................... 46

4.3.2. Het finaal gewicht per factor .......................................................................................................... 47

4.4. OPSTELLEN DECISION SUPPORT TOOL .............................................................................................................. 48

HOOFDSTUK 5: CONCLUSIE .............................................................................................................................. 50

5.1. ALGEMEEN BESLUIT ..................................................................................................................................... 50

5.2. IMPLICATIES EN BEPERKINGEN ....................................................................................................................... 50

5.3. SUGGESTIES VOOR VERDER ONDERZOEK ........................................................................................................... 51

LITERATUURLIJST ................................................................................................................................................. I

BIJLAGEN ........................................................................................................................................................... VI

V

Afkortingen

ERP Enterprise Resource Planning

MRP Manufacturing Requirements Planning

MRP II Manufacturing Resources Planning

BPR Business Process Re-engineering

OOTB Out-Of-The-Box

VI

Lijst met tabellen

Tabel 1: Voordelen van ERP ....................................................................................................... 7

Tabel 2: Nadelen van ERP ........................................................................................................... 7

Tabel 3: Kritieke factoren tot het falen van ERP-implementaties ........................................... 10

Tabel 4: Customizationredenen voor bedrijven....................................................................... 13

Tabel 5: Samenstelling Experten Panel op basis van Participatiegraad ................................... 19

Tabel 6: Response rates ronde 1 .............................................................................................. 20

Tabel 7: Verdelingsgraad antwoorden ronde 1 ....................................................................... 21

Tabel 8: Response rates ronde 2 .............................................................................................. 24

Tabel 9: Verdelingsgraad antwoorden ronde 2 ....................................................................... 25

Tabel 10: Response rates Fase 2 .............................................................................................. 26

Tabel 11: Verdelingsgraad antwoorden Fase 2 ........................................................................ 27

Tabel 12: De gesynthetiseerde factorenlijst ............................................................................ 37

Tabel 13: Synthese Antwoorden Ronde 2 ................................................................................ 41

Tabel 14: Finale factorenlijst .................................................................................................... 44

Tabel 15: Het finaal gewicht per factor .................................................................................... 48

Tabel 16: Input per finale factor............................................................................................... 49

VII

Lijst met figuren

Figuur 1: Delphi methode: iteratief proces .............................................................................. 17

Figuur 2: Gewichtenverdeling Gap Size ................................................................................... 46

Figuur 3: Gewichtenverdeling Gap Complexity........................................................................ 46

Figuur 4: Gewichtenverdeling Gap Importance ....................................................................... 47

Figuur 5: Gewichtenverdeling Budget ...................................................................................... 47

Figuur 6: Gewichtenverdeling Time ......................................................................................... 47

1

HOOFDSTUK 1: Introductie

ERP neemt als groeiende markt een steeds belangrijkere plaats in binnen de bedrijfswereld.

Bedrijven worden namelijk steeds groter en complexer en hebben daarom nood aan

informatiesystemen zoals ERP die het overzicht kunnen bewaren over een bedrijf.

Tegenwoordig kan de volledig administratieve verwerking van zowel de front als de back office

gedaan worden in ERP.

Om een ERP-systeem operationeel te maken voor een bedrijf moet de ERP eerst

geïmplementeerd worden. In dit proces dient tevens de keuze gemaakt te worden tussen een

gecustomizede implementatie, waarbij het ERP-systeem volledig wordt aangepast aan de

noden van klant of een Out-Of-The-Box implementatie, waarbij niks veranderd wordt aan het

ERP-systeem en deze in standaardvorm worden geïmplementeerd.

Hoewel de literatuur vele nadelen naar voor schuift met betrekking tot de gecustomizede

oplossing, blijken nog steeds 99% van de bedrijven een voorkeur te hebben voor

customization. Hun beslissing is echter niet altijd economisch onderbouwd. Vele bedrijven

blijken een blindelingse voorkeur te hebben voor customization (Hoofdstuk 2).

Vandaar dat volgende onderzoekvragen naar voor worden geschoven:

1) Welke zijn – in het geval van een Odoo-implementatie – de drijvende factoren in de

keuze tussen een out-of-the-box implementatie en een gecustomizede implementatie

teneinde de business value van de klant te maximaliseren?

2) Hoe groot is de rol van elke drijvende factoren in deze beslissing?

Zoals gezien kan worden richt ons onderzoek zich specifiek op een Belgische Open Source ERP-

systeem, genaamd ‘Odoo’.

De werkelijke focus van dit onderzoek ligt op de onderzoeksmethode en het verwerken van

de resultaten.

Om de onderzoeksvragen op te lossen wordt de Delhpi methode toegepast. Daarin worden

experten bevraagd in een interatief proces dat telkens onderbroken wordt door

gecontroleerde feedback. In de eerste fase van de Delphi studie wordt een antwoord

geformuleerd op de eerste onderzoeksvraag, terwijl de tweede fase hetzelfde doet voor de

2

tweede onderzoeksvraag. Hoe het onderzoek is verlopen en welke methoden verder

toegepast worden kan teruggevonden worden in Hoofdstuk 3.

De resultaten van het Delphionderzoek worden samengevat en bediscussieerd in Hoofdstuk

4. Op basis van die resultaten zal een decision support tool opgesteld worden ter

ondersteuning van zowel de klant als de implementator in de beslissing tot het al dan niet

customizen van het ERP-systeem met als doel het maximaliseren van de business value bij de

klant.

We sluiten de masterproef af met Hoofstuk 5, waarin een algemeen besluit wordt getrokken.

In dit hoofdstuk worden tevens de implicaties en beperkingen van het onderzoek aangehaald.

Helemaal afsluiten doen we met de voorstellen voor verder onderzoek.

3

HOOFDSTUK 2: Literatuuronderzoek

In hoofdstuk 2 bespreken we de volgende drie belangrijke termen

aangaande deze masterproef: ERP, ERP implementatie en Business

Value. Deze drie delen vormen de basis van het onderzoekveld.Aan elke

term wordt een apart deel gewijd.

Om ERP-systemen volledig te begrijpen beginnen we met een definitie

gevolgd door een korte geschiedenis. De voor- en nadelen van een ERP-

systeem worden aangekaart, waarna een klein overzicht wordt gegeven

van de huidige markt en hoe Odoo hierin past. (eerste deel)

In het tweede deel onderzoeken we ERP-implementaties. We starten

vanuit de verschillende fases van een ERP implementie, om daarna in te

gaan op het falen van ERP implementaties. We gaan dieper in op de

customization-stap en daarmee ook op de tweedeling tussen

customization en Out-of-the-box. We besluiten met de voor- en nadelen

van customization en waarom iedereen uiteindelijk toch wil customizen.

Het derde deel, business value, vormt de focus van dit onderzoek. We

definiëren business value en zijn bepalende factoren. Binnen deze

masterproef wordt gekeken hoe business value kan beïnvloed worden

door ERP-systemen.

Het hoofdstuk sluiten we af met het komen tot de onderzoeksvragen.

4

2.1. ERP

Om een idee te krijgen van wat Enterprise Resource Planning juist inhoud, gaan we van start

met een definitie die kort wordt toegelicht (2.1.1. . Daarna wordt een kleine

ontstaansgeschiedenis gegeven (2.1.2. om uiteindelijke te komen tot de opbouw die een ERP-

systeem net zo specifiek maakt (Error! Reference source not found.. Vervolgens wordt

gekeken naar de voor- en nadelen. Teneinde een overzicht te krijgen van de huidige ERP-markt

bespreken we de grootste spelers ervan en kijken we hoe Odoo hierin past (Error! Reference

source not found..

2.1.1. Definitie en eigenschappen

We beginnen met het geven van een definitie en bespreken daarna de algemene

eigenschappen van ERP-systemen.

Een ERP is een computergebaseerd en flexibel informatiesysteem dat enerzijds

bedrijfsprocessen zoveel als mogelijk integreert en automatiseert en anderzijds realtime

bedrijfsinformatie centraliseert in een database door te werken met geïntegreerde modules

per functionele bedrijfseenheid. (1) (2)

Een van de belangrijkste kenmerken van een ERP-systeem is zijn gecentraliseerde database.

Het biedt de mogelijkheid om vanuit elk functioneel bedrijfsdepartement alle bestaande

informatie op te vragen en te bewerken alsook nieuwe informatie toe te voegen. Door

informatie centraal op te slaan voorkomt men tevens informatieredundantie.

Rond de centrale database geniet een ERP-systeem van een modulaire opbouw. Aan de

database worden de functionele modules gekoppeld die de bedrijfsfuncties ondersteunen. De

meest bekende modules zijn: Accounting, Financial management, Manufacturing, Production,

Transportation en Sales & distribution, HR management. De modulaire opbouw zorgt voor een

flexibel systeem waarbij de klant kan kiezen welke modules hij wel of niet wenst te gebruiken.

Elke module is opgebouwd naar de best-practices binnen zijn functioneel gebied. Wil de klant

echter de modules gaan aanpassen naar zijn eigen practices – zijn eigen processen en

workflows – dan spreekt men van customizen. De term wordt verderop besproken. Wel kan

al meegegeven worden dat dit een kostelijk en tijdslovend proces is.

5

2.1.2. Geschiedenis

Het ontstaan van ERP wordt toegeschreven aan twee grote oorzaken. De eerst oorzaak is de

ontwikkeling van informatie- en communicatietechnologieën (ICT) die de basis vormden voor

latere ERP-ontwikkelingen.

Een tweede ontstaansreden komt vanuit de bedrijfswereld zelf. Door het steeds complexer

worden van de bedrijfsstructuren en –processen, hadden bedrijven steeds meer nood aan

tools die functie-overschrijdende informatie konden beheren. De informatie kon dan gebruikt

worden ter ondersteuning van het maken van departementoverschrijdende beslissingen .

De twee bovenstaande ontstaansredenen zorgden voor de geleidelijke evolutie in de richting

van de huidige ERP-systemen te beginnen in de jaren 1960. Grote bedrijven implementeerden

toen voor het eerst ‘centralized computing systems’. Deze werden gebruikt voor het

automatiseren van de inventarissystemen (3).

In de jaren 1970 gaat men nog een stap verder met de Manufacturing Requirements Planning

(MRP). Op basis van gedefinieerde productieprocessen kon vanaf nu de aankoop van

materialen aangestuurd worden. Met de komst van MRP worden productieprocessen voor

het eerst vastgelegd in informatiesystemen (3).

Vanaf 1980 krijgen we een belangrijke verschuiving van MRP naar MRP II (Manufacturing

Resources Planning). De materialenaankoop is niet langer enkel afhankelijk van het

productieproces, maar kan vanaf nu ook afhankelijk gemaakt worden van het verkoopproces.

Naast het verkoopproces worden tevens Finance, HR, Engineering en Project Management

geïntegreerd. (3)

In 1990 ontstonden dan de eerste ERP-systemen waarin werkelijk het hele bedrijfsproces

werd geïntegreerd. De ERP-systemen doen daarmee ere aan de E(nterprise) in ‘ERP’. (3).

Naarmate het gebruik van ERP-systemen toenam, voegde de ontwikkelaars tegen het jaar

2000 steeds meer extra modules toe aan hun systemen. De toepassingsmogelijkheden van en

het aantal modules in een ERP-systeem namen sterk toe. Deze systemen werden en worden

nog steeds Extended ERP’s genoemd (3).

6

Vanaf 2000 zien we ook een verschuiving in de markt. ERP-ontwikkelaars begonnen zich te

focussen op het herverpakken van hun ERP-systemen voor KMO’s. Voordien waren de ERP’s

te groot, te complex en te duur om door KMO’s gekocht te kunnen worden (3) (4).

Sinds het ontstaan ervan is de ERP-markt, een groeiende markt. Dat blijkt uit cijfers die

gevonden werden in de literatuur. In 1998 werd wereldwijd US$ 17 miljard uitgegeven aan

ERP-systemen. In 2000 was dit al US$ 21.5 miljard, wat overeenkomt met een groei van 13,1%

ten opzichten van het jaar ervoor. Deze groei was uiteraard ook te danken aan de steeds

bijkomende functionaliteiten binnen ERP-systemen (5).

Volgens Forbes is in 2013 de marktgrootte van ERP gestegen tot US$ 25,4 miljard. Dat zou

overeenkomen met een groei van 3.8% procent ten opzichte van 2012 (6).

2.1.3. Voordelen van ERP

Het implementeren van een ERP-systeem kan voor een bedrijf heel wat voordelen te bieden

hebben. De voordelen worden weergegeven in Tabel 1, waarvan we de belangrijkste even

toelichten. (4)

Het verbeteren van de doorlooptijd van de orders en de verlaging van de operationele kosten

zijn vormen waarschijnlijk de meest waardevolle voordelen aangezien zij direct inspelen op de

bedrijfsinkomsten en –kosten. (4)

Doordat de volledige werking van een bedrijf geïntegreerd zit in de ERP, kunnen klantenorders

efficiënt en digitaal doorgegeven over de departementen heen. Dit resulteert in het sneller

verwerken van klantenorders. (4)

De verlaging van de operationele kosten wordt veroorzaakt door de automatisering van de

processen in ERP. Dankzij de automatisering kunnen werkkrachten vervangen worden door

systemen die op lange termijn goedkoper zijn. (4)

7

Voordeel Dankzij…

Zichtbare, up to date en niet-redundante

informatie

De centrale database die live update

Verbeterde doorlooptijd van orders De integratie over departementen heen

Verkorte tijd die nodig is om financiële

periodes af te sluiten

Verlaging operationele kosten (inventaris,

werkkrachten, materialen)

Gedeeltelijke of volledige automatisatie

Sneller kunnen reageren op vragen van

klanten

Standaardisatie van processen Het vastleggen van de processen

Aanbod-vraagketen De integratie over departementen heen Tabel 1: Voordelen van ERP

2.1.4. Nadelen van ERP

Naast de voordelen zijn er echter ook enkele nadelen verbonden aan ERP-systemen. De

nadelen zitten hieronder vervat in Tabel 2, samen met hun oorzaken (4).

De hoge kostprijs van een ERP-systeem vormt de grootste barrière voor bedrijven om over te

stappen op een ERP-systeem. De totale kostprijs omvat licentiekosten voor het gebruik van

het ERP-systeem, implementatiekosten om het systeem operationeel te krijgen en

onderhoudskosten om het systeem up to date te houden (4).

De hoge initiële investering zorgt tevens voor een sterke afhankelijkheid van de gekozen ERP-

leverancier. De baten zouden dan niet meer opwegen tegen de kosten (4).

Een laatste nadeel is de soms wel erg lange duurtijd van een ERP-implementatie. Tijdens de

implementatieperiode zijn er wel al kosten maar nog geen (of weinig) baten van het ERP-

systeem. De kosten voor het bedrijf stijgen dus samen met de duurtijd van de implementatie

(4).

Nadeel Doordat…

Kostprijs Licentie-, implementatie- en

onderhoudskosten.

Sterke afhankelijkheid van de leverancier De kostprijs te groot is om snel te

veranderen

Implementatietijd Bijvoorbeeld werknemers nog getraind

moeten worden Tabel 2: Nadelen van ERP

8

2.1.5. Odoo

Odoo is een Belgisch ERP-systeem dat zich vooral focust op KMO’s. Aangezien ons onderzoek

handelt over Odoo, wordt het hier even toegelicht. Alvorens we Odoo echter bespreken,

geven we een kleine update van de huidige ERP marktsituatie.

Momenteel zijn de grootste spelers op de ERP-markt: SAP met 24% marktaandeel, gevolgd

door Oracle met 12% en Sage met 6%. Respectievelijk verkochten zijn vorig jaar voor US$ 6,1

miljard, US$ 3,117 miljard en US$1,5 miljard (6).

In vergelijking met SAP die tegen 2015 zijn 1.000.000.000e gebruiker wil hebben (7), is Odoo

met zijn huidige 2.000.000 gebruikers dus eerder een kleinere speler op de markt (8). De focus

van beide bedrijven ligt ook anders. Daar waar SAP vooral focust op de grote bedrijven, focust

Odoo eerder op de KMO’s.

In 2005 startte Fabien Pinckaers met de ontwikkeling van een Open Source ERP-systeem,

genaamd TinyERP. Doordat het systeem Open Source is, valt de licentiekost voor de klant weg.

Om marketingredenen werd de naam drie jaar later veranderd in OpenERP.

Met de naam veranderde ook het business model. OpenERP zou vanaf nu niet meer zelf zijn

ERP-systeem verkopen aan de klant en het gaan implementeren. Ze stapten over op een

partnermodel. Vanaf toen en tot op heden zijn het de partners die de ERP-contracten

verkopen aan klanten en er de implementatie van doen.

In Juni 2014 werd de laatste naamsverwisseling doorgevoerd naar het huidige ‘Odoo’. Naar

eigen zeggen was OpenERP reeds te ver gevorderd voorbij de traditionele ERP-systemen om

nog vast te houden aan de term. Zo omvat Odoo nu ook een eigen eCommerce-module, een

Point of Sale (=kassasysteem) en nog veel meer (9).

2.2. ERP Implementatie

We beginnen met het bespreken van de fasen van een ERP-implementatie. Daarna lichten we

toe waarom vele ERP-implementaties falen. Vervolgens gaan we dieper in op customization

Vs. Out-of-the-box en geven de voor- en nadelen van beide. We besluiten met enkele redenen

waarom ‘iedereen’ steeds opteert voor ERP-customization.

9

2.2.1. Fasen van implementatie

Een ERP implementatieproces verloopt volgens een viertal fases. De eerste fase wordt de

Adoption Decision genoemd. In deze fase identificeert het bedrijf zijn eigen noden en de reden

waarom hij een ERP-systeem zou nodig hebben.

De tweede fase is de Acquisition. Het bedrijf kiest dan het ERP-systeem dat het beste

overkomt met de noden van het bedrijf (4).

Vervolgens komt de feitelijke implementatiefase. In deze fase wordt het ERP-systeem

geïnstalleerd en indien nodig gecustomized. In deze fase kan er eventueel een business

process re-engineering plaatsvidnen. Dat wil zoveel zeggen als het hertekenen van de huidige

bedrijfsprocessen (4).

De laatste fase omvat het live gaan van het ERP-systeem, alsook het latere onderhoud ervan.

De kosten voor het onderhoud worden initieel door veel bedrijven over het hoofd gezien (4).

2.2.2. Ook ERP implementaties falen

Uit onderzoek is gebleken dat organisaties over het algemeen behoorlijk tevreden zijn met

hun ERP. Uit een steekproef bij 117 bedrijven uit 17 landen concludeert men dat 34 % van de

organisaties tevreden is met hun ERP, 58 % is enigszins tevreden, 7 % is dat enigszins niet en

slechts 1% is ontevreden (10)

Toch is een aandeel van 66% licht tot zeer ontevreden klanten niet gering. Om deze 66% te

verklaren kunnen twee oorzaken gevonden worden. Het grote aandeel van implementaties

die falen kan gezien worden als de eerste oorzaak. De tweede oorzaak stelt zich in het hoger

zijn van de werkelijke kosten in vergelijking met de vooraf geplande kosten van van de

implementatie.

Een gefaalde ERP implementatie wordt in de literatuur gedefinieerd als een implementatie die

niet voldoet aan de verwachte voordelen ervan (11). Het kan bijvoorbeeld zijn dat de behaalde

ROI niet hoog genoeg wordt bevonden door het bedrijf (12). Gebruikmakend van deze

definitie beschrijft de meeste literatuur een aandeel gefaalde ERP implementatiesrond de 60%

tot 90% (13). Met andere woorden, de overgrote meerderheid van de ERP-implementaties

slaagt er niet in de beloofde meerwaarde te generen.

10

Het falen van ERP-systeem implementaties heeft al tot verscheidene problemen geleid zoals

het volledig moeten uitschakelen van het systeem, het ERP-systeem enkel gedeelte kunnen

gebruiken, het lijden van bedrijfsverliezen, het dalen van de waarde van de aandelen, het

verliezen van een concurrentieel voordeel, tot zelfs het failliet draaien van bedrijven (2) (14)

(15) (16).

Een tweede oorzaak voor de 66% ontevreden ERP-klanten werd gevonden in het hoger

uitkomen van het werkelijk gespendeerde implementatiebudget in vergelijking met het

budget dat vooropgesteld werd. Johansson et al. schrijven in hun onderzoek dat 74,2% van de

bedrijven op het vooropgestelde budget bleef. De overige 25% ging erover. Het bracht het

gemiddelde gespendeerde budget over het gehele onderzoek op 104,3% van het initieel

geplande budget (17).

2.2.3. Kritieke falingsfactoren voor ERP implementaties.

De factoren waardoor zovele ERP-implementaties falen worden hieronder samengevat in

Tabel 3 (18) (13) (19) (20).

Kritieke falingsfactoren voor ERP implementaties

Inadequate definition of requirements Inherent complexity of ERP implementation

Resistance to change Inadequate training

Inadequate resources Proccess risk and process barriers

Poor Top Management Support Over-customization of software (4)

Unrealistic Expectations of Benefits and ROI Infrastructure Issues

To tight project schedule Poor Consultant effectiveness

Poor Communication Poor quality of Business Process

Reengineering (BRP)

Poor ERP Package Selection Poor quality of testing

Tabel 3: Kritieke factoren tot het falen van ERP-implementaties

Het is opmerkelijk dat in alle vier de geciteerde werken ‘Over-customization van de software’

naar voor kwam als kritieke factor. Laten we daarom even dieper ingaan op customization.

Deze term speelt tevens een grote rol in ons onderzoek.

11

2.2.4. Customization

Onder customization wordt zowel verstaan het toevoegen van add-on’s aan een ERP-systeem

als het veranderen van de broncode ervan ten einde te voldoen aan de eisen van de klant(ERP

system implementation in Small and Medium-Sized enterprises) (21) .

Daar waar de eisen van de klant verschillen met de mogelijkheden van het ERP-pakket moet

customization toegepast worden, om op die manier toch nog te voldoen aan de wensen van

de klant. In de literatuur wordt zo’n verschil een Misfit genoemd (22). In dit onderzoek zullen

we spreken over een Gap.

2.2.5. Customization Vs. Out-Of-The-Box

Wordt de Gap niet gedicht door customization, dan zal het bedrijf zijn processen moeten

aanpassen aan het ERP-systeem. Dit wordt business process re-engineering (BPR) genoemd.

Hoewel in veel gevallen er bij customization toch ook een zekere vorm van BPR nodig is, komt

het veel meer en veel groter voor bij een Out-of-the-box (OOTB) implementatie (23) (3).

Een OOTB implementatie is de tegenhanger van customization. In een OOTB implementatie –

ook wel vanilla implementatie genoemd – wordt het ERP-systeem geïnstalleerd bij de klant

zonder enige vorm van customization.

2.2.6. Voor- en nadelen van ERP customization

Het grote voordeel van customization is het verkrijgen van een perfect afgesteld systeem aan

de noden, processen en de worklflow van de klant (24). Zo werd reeds bewezen dat het

afstellen van de ERP zorgt voor een grotere user voldoening (25) (26). Users zijn blij dat het

systeem wordt afgesteld op hun manier van werken en krijgen er daarom ook meer

voldoening uit.

Het kiezen voor customization heeft echter ook enkele belangrijke nadelen. Zo komen bij het

aanpassen van de broncode steeds enkel bugs of onvoorziene problemen kijken (14). Dat

heeft niet alleen een effect op kostprijs maar ook op het tijdschema (21) (19). Door het stijgen

van tijd en kost kan het project in gevaar komen of zelfs falen (19) (27).

Een uitgesteld tijdschema kan ook nog een ander nadelig gevolg hebben. Met de huidige

snelheid waarmee nieuwe technologieën zich ontwikkelen kan het zich voordoen dat wanneer

12

een implementatie zeer lang duurt, het systeem eigenlijk al voorbijgestreefd is tegen de tijd

dat het klaar is (24).

Customization van het ERP-systeem kan zelfs tot lang na de implementatie nadelige effecten

hebben. We hebben het hier dan over het verdere onderhoud van het gecustomizede ERP-

systeem en het uitvoeren van updates erop. Customization maakt de software complexer

waardoor het onderhoud ervan ook complexer wordt (21) (24) (27) (21). Tegelijker tijd kan

het zijn dat uitgebrachte updates niet meer kunnen toegepast worden het ERP-systeem door

de vele veranderingen aan de hand van customization (21) (28).

In extreme termen spreekt een paper zelfs over voordelen van een ERP-systeem die door

customization omgezet worden in nadelen (28).

Een OOTB-implementatie resulteert dus in een oplossing die over het algemeen minder kost,

minder tijd in beslag neemt en meer kans heeft op slagen (21). Daartegenover staat wel dat

de Gaps die er initieel waren ook zullen blijven bestaan. Het is aan het bedrijf om zelf interne

aanpassingen (BPR) te doen om de Gaps te overbruggen.

Door slechts in geringe mate of zelfs niet af te wijken van de standaarduitvoering wordt het

eenvoudiger om de ERP-software te upgraden wanneer nieuwe versies en updates uitkomen

(23).

2.2.7. Iedereen wil customization

Niettegenstaande de vele nadelen verkiezen zo goed als alle bedrijven de customization-optie

voor hun ERP-systeem. Voor vele bedrijven houdt die keuze een extra gevaar in vanwege het

groeipotentieel van de customizations. Het begint meestal met een kleine vereiste die

uiteindelijk doorgroeit tot een zeer technische uitdaging. De kosten lopen dan al snel op. (19)

De hoofdredenen waarom ‘iedereen’ uiteindelijk toch customization kiest werden

samengevat in Tabel 4 (21) (29) (4) (30).

13

Customizationredenen voor bedrijven

Resistance to change Maturity level of company

Unique business processes Characteristics of selected ERP systems

Functional misfit Flexibiliteit bedrijfsprocessen

Ownership type Market and customers

Motivation for the ERP implementation Uncertainty

Tabel 4: Customizationredenen voor bedrijven

2.2.8. Conclusie

We onthouden dus dat er voor een bedrijf behoorlijk wat voordelen zijn verbonden aan het

implementeren van een ERP-systeem. Echter de keuze tussen een gecustomizede oplossing

of een OOTB-oplossing gebeurt niet altijd even beredeneerd. Hoewel de literatuur wel spreekt

over de vele nadelen van customization houden bedrijven hier geen rekening mee. Nog steeds

willen alle bedrijven customization hebben. Hieruit stelt zich dan ook het belang van het

onderzoek dan hier volgt.

2.3. Business Value

Business value wordt binnen de bedrijfswereld gebruikt om de waarde van een bedrijf, project

of individueel proces uit te drukken. Business value bestaat uit de index van de gegenereerde

waarde, global branding en marktleiderschap (31).

De waarde van Informatie Technologiën (IT) wordt gemeten op basis van interne en externe

factoren (32). IT heeft namelijk een externe invloed op de klanten en de concurrentie, maar

ook een interne invloed op de gebruikers van het system en daarmee ook op de

organisatorische prestaties (32) .

De business value uit customization wordt bepaald door de kwaliteit van de ontwikkelde

software. Hoe hoger de kwaliteit, hoe hoger de business value zal zijn. De business value moet

hier wel afgewogen worden ten opzichte van de kostprijs ervan (33).

Het was uiteindelijk Rosemann M. die een balanced scorecard opstelde om de prestaties van

ERP software te kunnen meten. Hiervoor hield hij ook rekening met zowel interne als externe

factoren. De eerste factor is de kostprijs van de ontwikkeling. De tweede factor duidt op de

winst die ermee kan gecreëerd worden via de klanten. Een derde factor houdt rekening met

de performantie van de interne processen en de laatste factor kijkt naar hoelang de huidige

14

ontwikkeling zal kunnen meegaan binnen de huidige snel evoluerende technologische

omgeving (34).

In dit onderzoek definiëren we de business value van een project als de directe en indirecte

meerwaarde die het genereert mits aftrek van de uitvoeringskosten.

2.4. Onderzoeksvragen

Uit het literatuuronderzoek is gebleken dat ruim gesteld alle bedrijven in de keuze tot het al

dan niet customizen van hun ERP, gaan voor de eerste optie van customization. Ze maken

deze keuze echter niet op basis van de business value die beide implementatiemogelijkheden

bieden, maar op basis van andere factoren waaronder: persoonlijke keuze en gewoon uit

onzekerheid.

Tevens is gebleken dat customization lang niet altijd meer business value oplevert voor de

klant in vergelijking met een OOTB-implementatie.

Anno 2014 wordt echter bevonden dat het tijd wordt om niet meer blindelings te kiezen voor

customization – zowel niet door de klant als de implementatoren – en de keuze laten afhangen

van de business value die voort wordt gebracht uit beide implementiemoglijkheden.

Hiervoor proberen we in deze masterproef een decision support tool te ontwikkelen die op

basis van enkele klanten projectafhankelijke inputs bepaalt welke van beide

implementatiemogelijkheden het meeste business value zal opleveren voor die klant.

Om tot een decision support tool te komen worden gezocht naar een antwoord op de

volgende twee onderzoeksvragen:





Ter herinnering, Odoo is het Belgische Open Source ERP-pakket waarrond dit onderzoek

wordt opgezet.

15

HOOFDSTUK 3: Methodes

De onderzoeksvragen worden dan wel geëxtraheerd uit het

literatuuronderzoek, toch kan de literatuur zelf de onderzoeksvragen

niet oplossen. Om een antwoord te kunnen formuleren op de

onderzoeksvragen moet gekeken worden naar een

onderzoeksmethode. In dit geval wordt gekozen voor de Delphi

methode.

Het hoofdstuk begint met de Delphi methode (deel 1) toe te lichten

alsook de afgeleide vorm ervan die hier toegepast zal worden.

Het onderzoek verloopt in twee grote fasen waarvan de eerst fase

bestaat uit twee opeenvolgende ronden. In chronologische volgorde zal

de methodologie van elke stap in het onderzoek besproken worden.

We beginnen met de eerste fase (deel 2 en 3) waarin gezocht wordt naar

de drijvende factoren voor al dan niet een gecustomizede

implementatie. Daarna wordt overgegaan naar de tweede fase (deel 4)

in welke de gewichten van elke drijvende factor wordt onderzocht.

In het laatste deel (deel 5) wordt beschreven hoe de resultaten van

beide fasen verwerkt worden tot een decision support tool voor Odoo

customization.

In het volgende hoofdstuk zullen de resultaten van elke fase worden

besproken, alsook de decision support tool.

16

3.1. Delphi methode

De Delphi methode tracht complexe onderzoeksmaterie op te lossen door een iteratief

bevragingsproces toe te passen op een panel van experten waarbij elke ronde wordt

onderbroken door een synthesestap waarin gecontroleerde anonieme feedback wordt

gegenereerd voor de volgende bevragingsronde.

De methode werd ontworpen in de jaren ’50 van de vorige eeuw door de RAND-groep (35). In

hun zoektocht naar een techniek om de meest betrouwbare consensus te verkrijgen binnen

een groep van experten, kwamen zij uiteindelijk tot de Delphi techniek (36). Het wordt

sindsdien voornamelijk gebruikt om langetermijnvoorspellingen te doen (37) (38) (39) (40).

De methode kreeg echter door de jaren heen een breder toepassingsgebied. Zo werd bewijs

gevonden dat de Delphi techniek reeds eerder werd toegepast in onderzoek naar

informatiesystemen (37) (41) (42) (43) (44) (45) (46) (47).

Een Delphi onderzoek start met het samenstellen van een expertenpanel. In een traditioneel

Delphi onderzoek zoekt men eerst naar experten binnen het gepaste onderzoeksgebied die

willen meewerken aan het volledige onderzoek. Uit de pool van potentiële experten wordt

dan enkel verder gewerkt met de bereidwillige experten (48) (49) (50).

In dit onderzoek wijken we daar licht vanaf door niet eerst opzoek te gaan naar bereidwillige

experten. Hier zullen in elke ronde van het Delphi onderzoek steeds alle potentiële experten

bevraagd worden. Zo zal een expert – ongeacht het feit of hij deelneemt aan ronde 1, toch

opnieuw de kans krijgen om deel te nemen aan ronde 2.

In de meeste Delphi studies bestaat zo’n vast experten panel uit een 10 tot 18 experten (49).

Naar de validiteit van het Delphi onderzoek hier is het belangrijk dat elke bevragingsronde

voldoet aan dit gebruikelijk aantal experten.

Eenmaal het expertenpanel is gekend, wordt overgegaan op de eerste bevraging van de

experten. De eerste bevraging mag enkel bestaan uit een of meerdere open vragen (51). Ja-

neen-vragen worden hiermee uitgesloten.

Wanneer uiteindelijk alle antwoorden van de experten zijn ontvangen, dienen deze

gesynthetiseerd te worden tot een samenvatting. De anonieme samenvatting wordt dan

teruggestuurd naar de experten. Het terugkoppelend effect van deze methode geeft de

17

experten namelijk de mogelijkheid om te reflecteren op de door hun gegeven antwoorden in

een eerdere ronde van het onderzoek (52).

Figuur 1: Delphi methode: iteratief proces

Dit proces wordt herhaald tot er een aanvaardbare consensus blijkt tussen de experten met

betrekking tot de gestelde onderzoeksvraag (49) (53).

Met een anonieme samenvatting wordt bedoeld dat de synthese in geen geval mag vermelden

wie er welk antwoord heeft gegeven. Het anoniem terugkoppelen van de synthese voorkomt

de mogelijke invloed van experten op elkaar (48) (49). De antwoorden van de zogenaamde

‘sterkere’ experten zouden een invloed kunnen hebben op de ‘zwakkere’ experten indien de

antwoorden niet anoniem worden teruggekoppeld.

Uiteindelijk dienen evenveel rondes te worden doorlopen als er nodig zijn om met de experten

tot een consensus te geraken met betrekking tot de onderzoeksvraag.

We onthouden dus dat een Delphi methode zoekt naar een consensus door een vast experten

panel verschillende vragenrondes te laten doorlopen waarbij elke ronde wordt onderbroken

door gecontroleerde feedback en waarin de anonimiteit van elke expert moet gewaarborgd

worden.

Bevragingsronde

Antwoorden ontvangen

Antwoorden verwerken en synthetiseren

Nieuwe bevraging opstellen

18

3.2. Ranking Delphi methode

Het type Delphi methode dat van toepassing is op dit onderzoek wordt door de literatuur

geklasseerd onder ‘Ranking type’ (49).

Een ranking type Delphi studie doorloopt twee sequentiële fasen. In een eerste fase wordt

aan de experten gevraagd de factoren te identificeren die een invloed kunnen hebben op een

bepaalde stelling. Er dienen evenveel bevragingsrondes te worden doorlopen als er nodig zijn

om de experten tot een consensus te krijgen over de bekomen factorenlijst.

De tweede fase kan pas van start gaan nadat de eerste fase in een consensus resulteerde. In

de tweede ronde worden de gevonden factoren uit de eerste fase gerangschikt. Wederom is

een consensus noodzakelijk.

Vergelijkbaar met de Ranking Delphi methode gaan we in dit onderzoek in een eerst opzoek

naar de drijvende factoren met betrekking tot de onderzoeksvraag. In de tweede fase zullen

de gevonden factoren echter niet gerangschikt worden door de experten, maar zal de expert

gevraagd worden om een gewicht toe te kennen aan de factoren. De gewichten dienen

uiteindelijk om tot een decision support tool te komen.

3.3. Keuze van de expertenpanel

Alvorens het onderzoek effectief van start kan gaan, moet een expertenpanel samengesteld

worden. Aangezien het onderzoek handelt over Odoo-implementaties bij klanten, moet

gezocht worden naar experten die ervaring hebben met deze materie.

Zoals in het literatuuronderzoek reeds werd vermeld, wordt Odoo wereldwijd bij bedrijven

geïmplementeerd door Odoo-partners. Deze Odoo-partners bezitten zowel de kennis over

Odoo-implementaties bij de klant alsook de kennis omtrent de customization van een Odoo-

systeem. Zij zijn met andere woorden de perfecte experten voor dit onderzoek.

De Odoo partners zijn allemaal terug te vinden op de Odoo-website. Op deze website wordt

er een onderscheid gemaakt tussen partners op basis van nationaliteit en op basis van

waarderingsgraad (54).

Er zijn 3 niveaus van waarderingsgraad in opgaande volgorde: Ready, Silver en Gold. Naar

gelang partners meer en grotere Odoo-projecten doen komen ze in een hogere

19

waarderingsgraad te zitten (55). Gold en Silver partners krijgen op die manier een zekere

erkenning voor hun bijdrage en kennis.

In totaal worden vanop de website 509 experten (Odoo partners) opgenomen in het

expertenpanel. Zij komen uit 106 verschillende landen wereldwijd. De partnerverdeling op

basis van waarderingsgraad wordt hieronder weergegeven in Tabel 55.

Waarderingsgraad Partners (N) Partners (%)

Gold 35 7%

Silver 48 9%

Ready 426 84%

Totaal 509 100%

Tabel 5: Samenstelling Experten Panel op basis van Participatiegraad

In een standaard Delphi onderzoek wordt een expertenpanel samengesteld door alle

potentiële experten eerst te vragen of ze willen participeren. Daarna wordt enkel verder

gewerkt met de experten die positief antwoordden. In dit onderzoek daarentegen wordt deze

stap niet toegepast. Hier wordt geopteerd om steeds het volledige panel van 509 experten te

gebruiken en dit gedurende het gehele onderzoek.

Daardoor zal enerzijds de response rate in dit onderzoek significant lager liggen in vergelijking

met onderzoeken waar wel op de traditionele manier wordt gewerkt (49). Anderzijds komt dit

ten goede aan de validiteit van het onderzoek. In vergelijking met een traditionele Delphi

studie - waar in elke ronde steeds dezelfde experten een antwoord formuleren – zullen hier

wel in elke ronde nieuwe ideeën naar boven komen door nieuwe experten die nog niet eerder

hadden deelgenomen aan een bevragingsronde.

Met het expertenpanel samengesteld en gedefinieerd kan overgegaan worden op de

werkelijke bevraging van de experten.

3.4. Fase 1 – ronde 1: Identificatie van de drijvende factoren.

In fase 1 van het onderzoek wordt gezocht naar de potentiële factoren die een invloed hebben

op ‘de keuze tussen het al dan niet customizen van een Odoo-systeem met als doel het

maximaliseren van de business value bij de klant’. De potentiële factoren worden verkregen

door een eerste bevraging te doen bij de experten. Er werd hun gevraagd welke factoren zij

als cruciaal zagen om bovenvermelde keuze te maken.

20

De vraag om potentiële factoren op te lijsten is een open vraag. Hiermee wordt voldaan aan

de voorwaarden van een Delphi onderzoek waarbij moet uitgegaan worden van een open

vraag (cfr. Infra).

De bevraging wordt gedaan per mail. Dit wordt mogelijk gemaakt

waarop niet alleen de experten werden teruggevonden, maar ook

De eerste bevragingsmail is terug te vinden in BIJLAGEN Bijlage 1: Bevragingsmail Fase 1: Ronde 1.

Om de response rate van deze ronde te bevorderen wordt ervoor gekozen om een

herinneringsmail te versturen. Literatuur bevestigt namelijk stijging van de response rate met

na het versturen van een herinnering (50). De herinneringsmail die in deze ronde wordt

gebruikt, zit in Bijlage 2: Herinneringsmail Fase 1: Ronde 1.

3.4.1. Ontvangen van de antwoorden

Uit de eerste bevragingsronde worden 43 bruikbare antwoorden verkregen. Dit komt overeen

met een relatief lage response rate van 8% ten opzichte van de meeste andere Delphi studies

(Cfr. Supra). Met 43 participerende experten wordt echter het gangbare aantal van 10 tot 18

experten in een Delphi studie ver overstegen (cfr. Supra).

De 43 antwoorden kwamen uit 27 van de 106 verschillende landen, wat neerkomt op een

nationale response rate van 25%. Tabel 6 hieronder geeft een mooi overzicht van het aantal

antwoorden en de response rates.

Aantal Partners (N) Partners (%) Landen (N) Landen (%)

Ronde 1 43 8% 27 25%

Wereld (Totaal) 509 100% 106 100%

Tabel 6: Response rates ronde 1

Zoals gezien kan worden in Tabel 7, komt de verdelingsgraad (in %) van de 43 participerende

experten niet overeen met de reële verdelingsgraad. In een Delphi studie vormt dit geen

probleem aangezien het in een Delphi studie niet de bedoeling om een statistische

representatie van de populatiegroep te verkrijgen (49). Daarentegen maakt de relatief hogere

vertegenwoordiging van Odoo Silver partners deze ronde wel sterker.

21

Experts Wereld (N) Wereld (%) Ronde 1 (N) Ronde 1 (%)

Gold 35 7% 4 9%

Silver 48 9% 10 23%

Ready 426 84% 29 67%

Totaal 509 100% 43 100%

Tabel 7: Verdelingsgraad antwoorden ronde 1

3.4.2. Verwerken van de antwoorden

Zoals een delphi onderzoek het gebied, moeten de antwoorden uit de eerste ronde sterk

geanalyseerd en gesynthetiseerd worden alvorens te kunnen overgaan naar de 2e ronde. De

gesynthetiseerde lijst wordt dan uiteindelijk in de 2e ronde teruggekoppeld aan de experten

ter reflectie (crf. Supra).

Naar aanleiding van het groot aantal verkregen antwoorden in deze ronde gebeurt de

verwerking hier in drie stappen. In een eerste stap worden alle potentiële factoren – die de

experten aanhaalden – samengebracht in een lijst.

In een tweede stap wordt gekeken welke factoren kunnen samengenomen worden om de lijst

korter en overzichtelijker te maken.

In de laatste en waarschijnlijk ook belangrijkste stap wordt er overwogen welke factoren

uiteindelijk zullen meegaan naar de volgende bevragingsronde. De resultatenverwerking in

deze stap komt uitvoerig aanbod in Hoofdstuk 4: .

Alle drie de stappen worden hieronder meer in detail besproken.

3.4.3. Factoren samengebracht

In een eerste verwerkingstap worden alle potentiële factoren uit de antwoorden van de

experten gehaald en samengebracht. De factoren worden ondergebracht in een eerste ad-hoc

verdeling, met de volgende onderdelen: Analysis, Processes, Business or company, OpenERP,

Other software, People , Budget, Time.

De lijst – die kan teruggevonden worden in Bijlage 7: Antwoorden ronde 1: Samengebracht –

brengt enkel en alleen de factoren uit de antwoorden van de experten samen. Er dient nu

nog verder gesynthetiseerd worden alvorens naar de volgende ronde kan gegaan worden.

22

3.4.4. Vereenvoudiging van het aantal factoren

Vervolgens wordt gekeken welke factoren samengenomen kunnen worden. Dit zijn factoren

die expliciet of impliciet dezelfde invloed uitdrukken en daardoor elkaar overlappen. Er moet

duidelijk gemaakt worden dat enkel de meest voor de hand liggende factoren hier reeds

worden samengenomen. Het einddoel van deze verwerkingstap is een meer overzichtelijke

lijst en dus nog niet een volledig vereenvoudigde lijst.

In dit proces wordt nog steeds vastgehouden aan dezelfde ad-hoc indeling die spontaan

voortkwam uit de vorige stap.

Het samennemen van de meest gelijkaardige factoren leidt tot de meer verstaanbare lijst in

Bijlage 8: Antwoorden ronde 1: Samengevat.

3.4.5. Vernieuwde indeling

Alvorens tot de gesynthetiseerde factorenlijst te komen, wordt ter vervanging van de ad-hoc

verdeling gezocht naar een meer algemeen aanvaarde indeling voor de factoren. De nieuwe

gekozen indeling resulteert uit de gangbare onderverdeling binnen een business architecture.

Een business wordt daarin namelijk gezien als een driedelige structuur bestaande uit: People,

Processes en Projects.

Projects wordt op zijn beurt verder opgesplitst volgens de Project Management triangle

waarin een project wordt onderverdeeld in zijn drie facetten: Scope, Budget en Time (56)

Door beide onderverdelingen te combineren wordt gekomen tot de beoogde indeling voor de

factoren, bestaande uit: Scope, People, Processes, Budget en Time.

3.4.6. De gesynthetiseerde factorenlijst

Het uiteindelijk doel van deze ronde is het samenvatten van de potentiële drijvende factoren

in een gesynthetiseerde factorenlijst, die op zijn beurt kan teruggekoppeld worden aan de

experten. Daartoe dient nog een laatste stap te worden ondernomen. Er moet nu per factor

uit de vereenvoudigde lijst (vorige stap) beslist worden of deze al dan niet wordt meegenomen

in de gesynthetiseerde factorenlijst naar de volgende ronde.

Hierbij wordt per factor gekeken of ze wel degelijk een invloed kunnen spelen in de

customization-beslissing. Indien dit positief wordt bevonden, wordt er gekeken of de factor

23

impliciet of expliciet vervat zit in een andere factor in de lijst. Het is namelijk van groot belang

dat de factoren die worden meegenomen elkaar in geen zin overlappen.

Elke factor die uiteindelijk wordt meegenomen in de gesynthetiseerde factorenlijst wordt ook

nog voorzien van een definitie en een meetschaal. De definitie moet voorkomen dat factoren

op verschillende manieren kunnen geïnterpreteerd worden. De meetschaal zijn van belang

voor het uiteindelijke gebruik van de decision tool waarnaar wordt gewerkt in dit onderzoek.

De feitelijke bespreking per potentiële factor hoort thuis onder het volgende hoofdstuk waarin

de resultaten per ronde worden toegelicht en bediscussieerd.

3.4.7. Conclusie

Ronde 1 moet met behulp van een eerste bevraging komen tot een lijst van potentieel

drijvende factoren in de beslissing tot het al dan niet customizen van een Odoo-systeem met

als doel het maximaliseren van de business value van de klant. Deze lijst wordt de

gesynthetiseerde factorenlijst genoemd.

Hiertoe worden 509 OpenERP partners (experten) gecontacteerd per mail.

Uit de antwoorden worden vervolgens de factoren opgelijst. De lijst gaat vervolgens door een

vereenvoudigingsproces en krijgt een nieuwe gevalideerde onderverdeling.

Daarna wordt per factor beslist of deze al dan niet wordt in de gesynthetiseerde lijst van

potentiële factoren. Deze lijst wordt in ronde 2 ter validatie teruggekoppeld aan de experten.

Hierbij moeten de anonimiteitsregels gerespecteerd worden (Cfr. Supra)

3.5. Fase 1 – ronde 2: Validatie van de drijvende factoren

In de tweede ronde van de eerste fase wordt de gesynthetiseerde factorenlijst uit de eerste

ronde opnieuw naar de experten gestuurd ter validatie. De experten krijgen op die manier een

algemeen beeld van de factoren die aangehaald worden in de eerste ronde. Zij kunnen dan

hun kritieken leveren op de lijst. Indien blijkt dat er nog teveel discussie is over bepaalde

factoren uit de lijst dienen deze factoren herbekeken te worden alvorens een finale

factorenlijst samengesteld kan worden.

In deze ronde worden opnieuw alle 509 experten aanschreven (Cfr. Supra). De participerende

experten uit de 1e ronde kunnen de door hun aangehaalde factoren nu verifiëren met de

gesynthetiseerde factorenlijst. De nieuwe experten kunnen gewoon hun kritiek uiten op de

24

factorenlijst. Dit resulteert in een finale lijst met een sterkere validatie dan wanneer enkel

gewerkt werd met de reeds participerende experten – zoals dit het geval is in een traditionele

Delphi studie.

De tweede bevragingsmail kan teruggevonden worden in Bijlage 3: Bevragingsmail Fase 1:

Ronde 2. Deze herinneringsmail die ook hier gebruikt wordt om de response rate te

bevorderen zit tevens vervat in Bijlage 4: Herinneringsmail Fase 1: Ronde 2

De expert beslist vervolgens per factor of hij ermee akkoord gaat. Gaat hij niet akkoord met

een bepaalde factor, dan kan hij deze verwijderen uit de lijst. Het kan ook echter zijn dat de

expert slechts gedeeltelijk niet akkoord is met een factor. In dat geval zal hij dit duidelijk

maken in de vorm van een kritiek op die factor. Het is ook echter mogelijk dat de expert een

extra factor toevoegt aan de lijst indien hij dit nodig acht.


In totaal worden 27 bruikbare antwoorden verkregen van de experten. Dit brengt de response

rate van deze ronde op 5%. De 27 experten vertegenwoordigden wel opnieuw een mooi

aantal landen. In totaal worden 20 van de 106 landen vertegenwoordigd in deze ronde.

Hoewel in Tabel 8 kan gezien worden dat de response rates relatief kleiner zijn ten opzichte

van ronde 1, zitten we met 27 participerende experten nog steeds ruim boven het

aanvaardbare gemiddelde van 10 tot 18 experten (cfr. Supra).


Ronde 1 43 8% 27 25%

Ronde 2 27 5% 20 19%

Wereld (Totaal) 509 100% 106 100%

Tabel 8: Response rates ronde 2

Naar verdelingsgraad toe daalde ten opzichte van ronde 1 het aandeel van de Silver partners

in het voordeel van de Ready partners. De evolutie van de experten op basis van

waarderingsgraad zit vervat in Tabel 9.

25

Experts Wereld (N) Wereld (%) Ronde 1 (N) Ronde 1 (%) Ronde 2 (N) Ronde 2 (%)

Gold 35 7% 4 9% 3 11%

Silver 48 9% 10 23% 3 11%

Ready 426 84% 29 67% 21 78%

Totaal 509 100% 43 100% 27 100%

Tabel 9: Verdelingsgraad antwoorden ronde 2

Verder komen 18 van de 27 antwoorden van experten die reeds participeerden aan de eerste

ronde. Er zijn met andere woorden in deze tweede ronde 9 nieuwe experten die ook hun

mening hebben kunnen om tot de finale drijvende factoren te komen.

3.5.2. Verwerken van de antwoorden.

In consistentie met de eerste ronde wordt ook hier opnieuw elke factor apart bekeken. Per

factor worden zowel de positieve als de negatieve kritieken opgelijst. Dit resulteert in een

duidelijk overzicht waarbij de aanvaardingsgraad alsook de opmerkingen per factor in een

oogopslag kunnen bemerkt worden (Bijlage 10: Synthese van de Antwoorden uit ronde 2). De

aanvaardingsgraad is het percentage van de experten dat akkoord ging met de factor in de

gesynthetiseerde lijst.

Nadat het lot van elke factor is besproken, kan gekomen worden tot de finale factorenlijst.

Het is deze lijst die meegenomen wordt naar de 2e fase. In deze fase wordt aan de experten

gevraagd om gewichten te hangen aan de gevonden factoren.

De werkelijke bespreking van de resultaten van deze ronde behoren toe aan het volgende

hoofdstuk.

3.5.3. Conclusie

In ronde 2 van de eerste fase wordt aan het expertenpanel gevraagd om kritieken te leveren

op de gesynthetiseerde factorenlijst uit ronde 1. Deze ronde dient ter validatie van die lijst.

De kritieken van de experten worden verwerkt tot een finale factorenlijst. De factoren dienen

in een volgende fase te worden voorzien van gewichten.

3.6. Fase 2: Weging van de drijvende factoren

De 1e fase werd afgesloten met een finale factorenlijst. Het startsein voor de 2e fase kan nu

gegeven worden. In deze fase van de Ranking Delphi studie wordt de belangrijkheidsgraad van

26

de gevonden factoren onderzocht. Er wordt aan de experten gevraagd om aan elke factor een

gewicht te hangen. Hoe groter het gewicht van de factor, hoe groter zijn invloed zal zijn op de

beslissing tot het al dan niet customizen van het Odoo-systeem bij een klant ten einde hem

de grootste business value op te leveren.

Om tot juiste gewichten per factor te komen wordt opnieuw gebruik gemaakt van alle 509

experten. Ze worden wederom bevraagd via mail (Bijlage 5: Bevragingsmail Fase 2), gevolgd

door een herinneringsmail (Bijlage 6: Herinneringsmail Fase 2).

De mail vraagt elke expert afzonderlijk om een gewicht toe te kennen aan elke factor uit de

finale factorlijst (resultaat ronde 1). De expert mag aan elke factor een percentage van 0% tot

100% hangen dat de belangrijkheidsgraad van elke factor symboliseert. De som van de

gewichten hoeft niet uit te komen op 100%. Een factor met een gewicht dichter bij 0%

betekent dat deze factor minder doorslaggevend zal zijn in de uiteindelijke beslissing dan een

factor met een gewicht dichter bij 100%.


Aan deze laatste fase van het Delphi onderzoek nemen 21 experten deel. De 21 experten

vertegenwoordigen 17 verschillende landen. Dat brengt de response rate op 4% en de

nationale response rate op 16%. In Tabel 10 wordt een duidelijk overzicht gegeven van de

response rates doorheen het gehele Delphi onderzoek.


Ronde 1 43 8% 27 25%

Ronde 2 27 5% 20 19%

Ronde 3 21 4% 17 4%

Wereld (Totaal) 509 100% 106 100%

Tabel 10: Response rates Fase 2

Zoals kan gezien worden in Tabel 11 stijgt het aandeel van de participerende Ready partners

opnieuw ter compensatie van het aantal Silver en Gold partners. Dit betekent niet dat de

verkregen antwoorden minder betrouwbaar zijn. Daarentegen zou een hoger aantal Silver en

Gold partners het resultaat van het onderzoek wel versterken aangezien zij beschouwd

worden meer ervaring te hebben met Odoo.

27

Experts Ronde 1 (N) Ronde 1 (%) Ronde 2 (N) Ronde 2 (%) Fase 2 (N) Fase 2 (%)

Gold 4 9% 3 11% 2 10%

Silver 10 23% 3 11% 2 10%

Ready 29 67% 21 78% 17 81%

Totaal 43 100% 27 100% 21 100%

Tabel 11: Verdelingsgraad antwoorden Fase 2

3.6.2. Verwerken van de antwoorden

Aangezien 21 experten aan elke factor een gewicht hebben toegekend, heeft elke factor nu

21 gewichten die moeten herleid worden tot één finaal gewicht. Hiertoe wordt per factor het

gemiddelde genomen van alle gewichten die hem toegekend worden. De formule ziet dan er

als volgt uit:

𝐺𝑗 =1

21∗ ∑ 𝐺𝑖𝑗

21

𝑖=1

3.6.3. Conclusie

In fase 1 werden de drijvende factoren gezocht in de beslissing om een Odoo-systeem te

customizen of het OOTB te implementeren bij een klant met als doel het maximaliseren van

zijn de business value.

In fase 2 werd gezocht naar de juiste gewichten voor de drijvende factoren. Het finale gewicht

per factor werd uiteindelijke gevonden door het gemiddelde te nemen van de gewichten die

door de experten gesuggereerd werden voor elke factor.

De resultaten van deze fase is terug te vinden in het volgende hoofdstuk onder de titel ‘Error!

Reference source not found.’.

Met het afwerken van fase 1 en 2 betekent dit ook het einde van het Delphi onderzoek. Nu

rest enkel nog de taak om de decision tool op te stellen op basis van de gegevens uit het Delphi

onderzoek.

3.7. Opstellen Decision Support tool

Een decision support tool moet de gebruiker ervan helpen in het nemen van een beslissing. In

dit geval is de gebruiker een Odoo implementator. Het dilemma of de ‘decision’ zit vervat in

𝐺𝑗 = Gemiddelde finaal gewicht voor factor j

𝐺𝑖𝑗 = Gewicht gegeven door expert i aan factor j

28

de keuze om het Odoo-pakket al dan niet te gaan customizen voor een bepaalde klant

teneinde voor deze klant de hoogste business value te generen.

De decision support tool werkt op basis van een beslissingsformule. De formule combineert

de finaal gevonden factoren uit de 1e ronde met de bijhorende gewichten uit de 2e fase. De

uitkomst van de formule is een getal dat duidt op de waarde wanneer voor customization zou

gekozen worden. Hoe groter de uitkomt in positieve richting, hoe meer waarde voor de klant

kan gegenereerd worden door te kiezen voor customization. Het omgekeerde geldt voor een

OOTB-implementatie.

Om tot de relatieve invloed van elke input te komen, moeten de factoren vermenigvuldigd

worden met hun gewichten uit de 2e fase. Vervolgens dienen de factoren opgeteld te worden

die recht evenredig zijn met het belang van customization. Van deze som moeten de factoren

worden afgetrokken die een negatieve invloed hebben op het belang van customization.

Uit Hoofdstuk 4 zal blijken dat er vijf factoren voorkomen uit de finale factorenlijst: Gap Size

[GS], Gap Importance [GI], Gap Complexity [GC], Budget [B] en Time [T]. Enkel Gap Complexity

speelt een negatieve rol in de beslissing tot customization. Enkel die factor krijgt dus een

minteken voor zich.

De beslissingsformule ziet er dan als volgt uit:

𝑎 ∗ [𝐺𝑆] + 𝑏 ∗ [𝐺𝐼] − 𝑐 ∗ [𝐺𝐶] + 𝑑 ∗ [𝐵𝐺] + 𝑒 ∗ [𝑇] = 𝑤 (1)

Hierbij zijn de letter tussen [haken] de afkortingen voor de finale drijvende factoren en

vormen ‘a,b,c,d en e’ hun respectievelijke gewichten. De som van het geheel geeft een getal

‘w’ dat symbool staat voor de waarde van customization. Hoe groter ‘w’ wordt in positieve

zin, hoe meer de decision support tool zal aanraden om het Odoo-systeem te customizen.

Omgekeerd zal het eerder opteren voor een OOTB-implementatie.

Op de formule in zijn huidige vorm moeten echter nog twee bewerkingen worden uitgevoerd,

wil ze werkelijk toepasbaar zijn. In een eerste bewerkingstap moeten de gewichten op een

gemeenschappelijke noemer te komen staan zodat hun som gelijk is aan 100%. In een tweede

stap moeten vervolgens de schalen van de factoren genormaliseerd worden.

29

3.7.1. Gewichten herschalen

De gewichten a,b,c,d en e zitten elk ergens tussen 0% en 100%. De som van deze gewichten

komt dan ook ver boven 100% uit. Zie hiervoor Hoofdstuk 4. In een decision support tool moet

de som van de gewichten 100% zijn. Elke gewicht dient hiervoor gewogen te worden ten

opzichte van de som van alle gewichten samen. Dit is de voorbeeldformule om van het

originele gewicht ‘a’ te gaan naar zijn gewogen gewicht ‘A’.

𝐴(%) =𝑎

𝑎 + 𝑏 + 𝑐 + 𝑑 + 𝑒∗ 100%

Dezelfde berekening dient gedaan te worden voor B, C, D en E door de teller respectievelijk te

veranderen in b, c, d en e.

De beslissingsformule wordt vervolgens aangepast door de gewogen gewichten in te vullen:

𝐴 ∗ [𝐺𝑆] + 𝐵 ∗ [𝐺𝐼] − 𝐶 ∗ [𝐺𝐶] + 𝐷 ∗ [𝐵𝐺] + 𝐸 ∗ [𝑇] = 𝑋 (2)

3.7.2. Schalen normaliseren

Zoals eerder vermeld in hoofdstuk 3 wordt aan elke factor een schaal toegekend. De schaal

bepaalt per factor wat de gebruiker als input kan geven aan de decision support tool. De

schalen verschillen echter sterk in grote. Zo zal Gap Importance enkel waarden kunnen

aannemen van 1 tot 5, terwijl budget in euro’s theoretisch gezien oneindig groot kan worden.

Om de schalen ‘even groot’ te maken moeten ze genormaliseerd worden.

Om van een [Factor] met originele schaal te gaan naar een [Factor]’ met genormaliseerde

schaal wordt de volgende formule gebruikt:

[𝐹𝑎𝑐𝑡𝑜𝑟]′ =[𝐹𝑎𝑐𝑡𝑜𝑟] − �̅�

𝑠

De genormaliseerde schaalwaarde van een factor [Factor]’ wordt bekomen door het

gemiddelde van de factorschaal �̅� af te trekken van de ingegeven schaalwaarde [Factor] en

dit geheel te delen door de standaardafwijking van de schaal 𝑠.

De ontbrekende waarden per factor zijn nu nog het gemiddelde �̅� en de standaardafwijking 𝑠

van hun schaal.

Voor de factoren GAP size, GAP importance en GAP complexity gelden dezelfde formules om

tot hun �̅� en 𝑠 te komen. Alle drie hun schalen zijn namelijk uniforme verdelingen. Dat wil

30

zeggen dat er wordt van uitgegaan dat elke waarde van hun schaal evenveel kans heeft om

voor te komen. Om tot hun gemiddelde en standaardafwijking te komen worden

respectievelijk volgende formules gebruikt:

�̅� =𝑦 + 𝑧

2 𝑠 = √

𝑛2 − 1

12

Hierbij stelt 𝑦 de minimum schaalwaarde van de factor voor en 𝑧 de maximum schaalwaarde.

Het aantal mogelijke waarden van een schaal wordt voorgesteld door 𝑛.

Voor de factoren Budget en Time moet een andere methoden toegepast worden. Deze

factoren zijn namelijk niet uniform, maar worden verondersteld normaal verdeeld te zijn. Om

tot hun gemiddelde schaalwaarde te komen moet deze formule gebruikt worden.

�̅� =z − y

2

Hun maximum (z) en minimum (y) schaalwaarde is echter niet gekend. We maken hiervoor

gebruik van een extra steekproef onder de Odoo experten. De experten wordt gevraagd om

het minimum en maximum budget te geven dat ze ooit al van een klant gekregen hebben om

een Odoo-implementatie uit te voeren. Dezelfde vraag wordt hen gesteld met betrekking tot

Time.

De resulterende lijsten van minimum en maximum budgetten en tijdsspannen heeft

opmerkelijke uitschieters die het nemen van gemiddeldes significant zou vertekenen.

Vanwege de uitschieters en de grote spreiding van de bekomen lijsten wordt daarom de

mediaan genomen om tot wetenschappelijk aanvaardbare z en y te komen. De formule

wordt:

�̅� =Med(Max) − Med(Min)

2

Om tot de standaardafwijking van Budget en Time te komen wordt er beroep gedaan op de

eigenschappen van een normale verdeling. Een normale verdeling bestaat bij benadering uit

zes even grote delen waarbij elke deel de grootte heeft van één standaardafwijking. In dat

opzicht wordt de standaardafwijking van Budget en Time bekomen op volgende wijze:

𝑠 =Med(Max) − Med(Min)

6

31

De schaal van Time krijgt daarbovenop een extra aanpassing. Tot nu toe werd tijd uitgedrukt

in aantal dagen. De steekproef wijst er echter op dat het gebruik van maanden in plaats van

dagen gebruiksvriendelijker zal zijn voor de decision support tool.

32

HOOFDSTUK 4: Resultaten en discussies

In hoofdstuk 3 worden de methodes beschreven op basis van welke het

onderzoek wordt uitgevoerd: het gebruik en de samenstelling van het

expertenpanel, het gebruik van bevragingsmails, de analyses die

uitgevoerd worden en de formules die nodig zijn om tot de resultaten

te kunnen komen.

Dit hoofdstuk focust zich op de resultaten die verkregen worden uit elke

fase en elke ronde van het onderzoek. In dit hoofdstuk wordt per

fase/ronde duidelijk gesteld wat het verhaal is achter de bekomen

resultaten.

Het hoofdstuk verwerkt de resultaten van het onderzoek in

chronologisch volgorde. Eerst wordt gekeken naar welke potentiële

factoren de experten identificeren (4.1. ). Daarna kijken we naar hun

meningen op de gesynthetiseerde factorenlijst (4.2. ), met als

eindresultaat de finale factorenlijst.

Vervolgens worden de gewichten besproken die aan elke drijvende

factor worden toegekend (4.3. ). We sluiten af met de uiteindelijke

decision supporting tool die de beslissing om Odoo al dan niet te

customizen in functie van de business value van de klant zal gaan

ondersteunen (4.4. ).

33

4.1. Fase 1 - Ronde 1: Identificatie van de drijvende factoren

In fase 1 van het onderzoek wordt gezocht naar de potentiële factoren die een invloed hebben

op ‘de keuze tussen het al dan niet customizen van een Odoo-pakket met als doel het

maximaliseren van de business value bij de klant’. De experten brachten echter zeer veel

potentiële factoren naar boven.

Per factor moet eerst uitgemaakt worden of deze ook daadwerkelijk een invloed heeft op de

beslissing uit de onderzoeksvraag. Deze drijvende factoren worden vervolgens samengevat in

een gesynthetiseerde factorenlijst. Deze lijst vormt het eindresultaat van deze ronde en zal in

ronde 2 ter validatie teruggestuurd worden naar de experten.

4.1.1. Analyse van de aangebrachte factoren.

De vereenvoudigde factoren die door de experten aangebracht worden zijn terug te vinden in

Bijlage 8: Antwoorden ronde 1: Samengevat. Per potentiële factor die door de experten wordt

aangebracht moet uitgemaakt worden of deze daadwerkelijk erkend worden als drijvende

factor in functie van de onderzoeksvraag.

Naast elke factor staat of de potentiële factor als ‘Drijvende factor’ of ‘Geen drijvende factor’

wordt aanzien. Daarna volgt telkens een beknopte verklarende uitleg.

Budget:

a) The client’s budget – Drijvende factor: Het customizen van een Odoo is een kostelijk zaak.

Hoe meer budget de klant heeft, hoe groter de kans tot customization en hoe beter deze kan

uitgevoerd worden.

b) The cost-benefit – Geen drijvende factor: De cost-benefit-afweging zit reeds vervat in de

business value. Aangezien dit onderzoek juist opzoek gaat naar de implementatieoptie die de

hoogste business value oplevert, mag deze factor geen input zijn van het model.

Time

c) The client’s time frame for implementation – Drijvende factor: Klanten geven hun Odoo-

implementator een maximum tijdsspanne waarbinnen hij het Odoo-pakket wenst

geïmplementeerd te zien. Aangezien customization een tijdsintensieve taak is kan de kwaliteit

van de customization lijden onder een relatief te korte tijdsspanne.

34

Analysis:

d) Gap-analysis – Drijvende factor: Niet per se de analyse van de GAP, maar wel de GAP zelf

speelt een rol. De GAP wordt gezien als het ‘gat’ dat zich stelt tussen de functionaliteiten van

een OOTB Odoo-pakket en de wensen van de klant. De GAP zijn de ontbrekende

functionaliteiten in een OOTB Odoo-pakket die wel gewenst zijn door de klant. Om de GAP te

dichten moet gecustomized worden.

e) Is the client willing to pay for an analysis or not? – Geen drijvende factor: Indien de klant

geen analyse wil laten uitvoeren kan de Gap nooit gedefinieerd worden. De keuze om te

customizen is dan ook meteen uitgesloten. Deze keuze vormt echter wel het onderwerp van

dit onderzoek. De factor zorgt echter voor een eenzijdige beslissing zonder rekening te houden

met business value en wordt daarom niet erkend als drijvende factor.

f) How important is the GAP? – Drijvende factor: Hoe belangrijker de GAP is voor de klant,

ongeacht de grootte van de GAP, hoe meer business value er kan gegenereerd worden door

te kiezen voor customization.

Business and processes:

g) No clear processes defined – Geen drijvende factor: Wanneer de processen in een bedrijf

niet duidelijk kunnen beschreven worden, vervalt de optie tot customization. (Vergelijkbare

sitautie met factor e)

h) Productiebedrijven – Drijvende factor: Een productiebedrijf hangt voor zijn process work

flow vast aan zijn machines. Zou de workflow van Odoo verschillen met deze binnen het

productiebedrijf, dan zal het gemakkelijker en goedkoper zijn om de workflow van het Odoo-

pakket aan te passen (=customization) aan de workflow van het bedrijf. De workflow van het

bedrijf aanpassen aan dat van het Odoo-pakket (OOTB) vormt hier de duurdere optie.

i) Company structure (mutiple sites) – Drijvende factor: Vanaf het moment dat een bedrijf

vestigingen heeft op meerdere locaties, moet er in het Odoo-pakket rekening gehouden

worden met verscheidene complexe instellingen. Meerdere vestigingen zorgen dus voor

complexere instellingen en verhogen de complexiteit in geval van customization.

j) Andere – Drijvende factoren: Alle andere factoren onder ‘Business and processes’

beschrijven ontbrekende functionaliteiten die er kunnen zijn in een OOTB Odoo-pakket ten

35

opzichte van de eisen van de klant, of dus een Gap. Deze factoren komen overeen met factor

d) Gap-analysis.

OpenERP

k) Number of modules to be installed – Drijvende factor: hoe meer Odoo modules er dienen

geïnstalleerd te worden bij een klant, hoe complexer de eventuele customization wordt

achteraf. Een verandering in een module kan een impact hebben op een andere.

L) Complex modules – Geen drijvende factor: Experten suggereren dat complexe modules

aanleiding zouden geven tot customization. Het is echter mogelijk dat een complexe module

perfect aansluit bij de eisen van de klant waardoor OOTB perfect mogelijk is.

m) Availability of community modules – Geen drijvende factor: Odoo heeft een eigen

community website waarop Odoo partners eigen gecustomizede modules kunnen uploaden.

Indien een Odoo community module de GAP bij een klant kan oplossen dient er niet meer

gecustomized te worden. De keuze wordt dan echter niet gemaakt op basis van business

value. Hiermee vervalt opnieuw de keuze vergelijkbaar met factor e).

Other software

Other software duidt op andere software waarmee het Odoo-pakket na de implementatie zal

moeten communiceren. Om deze communicatie mogelijk te maken zal een connectie moeten

ontwikkeld worden tussen Odoo en de andere software in kwestie. Het maken van de

connectie wordt aanzien als customization.

n) Outdated software - Drijvende factor: Hoe ouder de software is waarmee een connectie

dient gemaakt te worden, hoe moeilijker het is om deze connectie te ontwikkelen.

o) Andere factoren – Drijvende factoren: beide resterende factoren kunnen samengevat

worden als het aantal ‘andere software’ waarvoor connecties moeten ontwikkeld worden.

Hoe groter het aantal, hoe meer werk en tijd de implementatie zal innemen, hoe lager de

business value.

People

p) Number of company users – Drijvende factor: Hoe meer Odoo-gebruikers een bedrijf zal

hebben na implementatie, hoe moeilijker en duurder het zal zijn om de workflow van de

gebruikers aan te passen aan de workflow van een OOTB Odoo-pakket. Met andere woorden:

36

hoe meer gebruikers, hoe meer business value kan verkregen worden uit het aanpassen van

het Odoo-systeem aan de gebruikers (=customization).

q) User skills – Drijvende factor: Naarmate de Odoo-gebruikers beperktere vaardigheden

hebben met betrekking tot computers en ERP-pakketten, dan zal het belangrijker worden om

het ERP-pakket aan te passen aan hun. Dit speelt in het voordeel van customization.

r) Change willingness of people – Geen drijvende factor: Wanneer de werknemers bij de klant

absoluut tegen verandering zijn en daarmee dus ook tegen de overstap zijn naar een Odoo-

systeem vervalt ook de implementatiekeuze. Vergelijkbaar met factor e).

s) Place (country) – Geen drijvende factor: De vestigingsplaats van de klant of met andere

woorden de heersende cultuur bij de klant bepaalt hoe gewillig werknemers omgaan met

verandering. Deze factor komt indirect overeen met de vorige factor r).

t) Customer’s decision – Geen drijvende factor: Indien de klant zelf kiest tussen customization

of OOTB is de keuze tussen beide reeds gemaakt en wordt dit niet gedaan op basis van

business value waardoor dit onderzoek niet meer van toepassing is. Ook deze factor zal geen

verdere rol spelen. Vergelijkbaar met factor e)

4.1.2. De gesynthetiseerde factorenlijst

De factoren die net drijvend werden bevonden, worden vervolgens samengevat in een

gesynthetiseerde factorenlijst. Hoewel het belangrijk is dat deze lijst allesomvattend is, dient

er ook op gelet te worden dat elke factor volledig exclusief is. In de gesynthetiseerde

factorenlijst zouden geen factoren mogen voorkomen die eigenlijk al vervat zitten in een

andere factor uit de lijst.

Zoals ook gezien kan worden in Tabel 12: De gesynthetiseerde factorenlijst wordt hier de

overstap gemaakt van de ad-hoc indeling naar de business architecture verdeling (Cfr. 3.4.5.

). De tabel geeft een overzicht van de gesynthetiseerde drijvende factoren. Per factor wordt

tevens de schaal gegeven die een rol zal spelen in de decision support tool. In de derde kolom

‘aanleiding’ zitten de factoren op basis van welke de drijvende factor tot stand is gekomen.

37

Verdeling Factor Schaal Aanleiding

Scope

GAP Size In % d,j

GAP Importance [1 – 5] f,q

Number of NEW software

connections to be created

In Numbers o

Impotance of NEW connections [1 – 5]

Difficulty level of creating those

connections

[1 – 5] n

People Number of employees In Numbers p

Percentage of Odoo users % of employees p

Processes

Kind of business Production, service,

retail, distribution

h

Maturity of company In ages (r,s)

Number of Physically separated

settlements

In Numbers i

Number of different departments In Numbers k

Budget Maximum budget In € a

Time Maximum time frame In days c

Tabel 12: De gesynthetiseerde factorenlijst

We bespreken hieronder de gesynthetiseerde drijvende factoren. Per factor wordt besproken

waarop hij gebaseerd is en wat zijn invloed is op de business value van customization. Elke

factor krijgt ook een schaal toegewezen. De schaal zal een belangrijke rol spelen in de decision

support tool.

Scope

Gap Size – De grootte van de GAP wordt uitgedrukt in een percentage. Het duidt op het

percentage van de vereisten van de klant die niet vervat zitten in een OOTB Odoo-pakket. Of

met andere woorden, hoeveel percentage van de vereisten van de klant vragen om

customization. Des te groter de GAP wordt, des groter de resulterende business value zal zijn

door middel van customization.

Gap importance – Hoe belangrijk de GAP uiteindelijk is voor de klant wordt uitgedrukt op een

Likert-schaal van 1 tot 5, waarbij 1 gelijk staat aan ‘totaal onbelangrijk’ en 5 gelijk staat aan

‘zeer belangrijk’ [bronvermelding] . Het belang van de GAP was niet alleen letterlijk gegeven

in factor f), maar kwam ook voort uit de factor q) User skills. Het aanpassen van het Odoo-

38

systeem aan de gebruikers (=customization) wordt namelijk belangrijker naarmate de

gebruikers minder ervaring hebben met computers en ERP-pakketten.

De drie volgende drijvende factoren onder scope hebben te maken met de zeer specifieke

softwareconnecties (cfr. Supra).

Number of NEW connections – Deze drijvende factor resulteerde uit de overblijvende

factoren onder ‘other software ‘, o) Andere factoren. Naarmate er meer nieuwe connecties

dienen gemaakt te worden, wordt het belang van customization groter. Zoals de factor het

omschrijft, gaat het enkel over nieuw te ontwikkelen connecties.

Importance of NEW connections – Het belang van de nieuw te ontwikkelen connecties kwam

voort uit GAP Importance. Daar waar GAP Importance het belang moet aanduiden van de GAP,

moet deze nieuwe factor het belang aanduiden van de nieuwe connecties. De factor gebruikt

dat ook dezelfde Likert-schaal als GAP Importance.

Difficulty level of creating those connections – Hoe moeilijker het is om de nieuwe connecties

te maken, hoe meer tijd en geld hierin moet geïnvesteerd worden. De business value van het

creëren van de connecties daalt met het toenemen van de ontwikkelingscomplexiteit ervan.

De complexiteit wordt gemeten op een Likert-schaal van 1 tot 5, waarbij 1 gelijk staat aan

‘zeer gemakkelijk’ en 5 gelijk staat aan ‘zeer moeilijk’. Deze drijvende factor wordt afgeleid

van de meer specifiekere factor ‘Outdated Software’ die een suggestie gaf in de richting van

ontwikkelingsmoeilijkheid (cfr. Supra).

People

Number of employees – Zoals eerder vermeld bij de potentiële factor p) Number of company

users, bepaalt het aantal users de gemakkelijkheidsgraad waarmee een bedrijf zijn workflow

kan aanpassen aan de workflow in Odoo. De gemakkelijkheidsgraad daalt bij een stijgend

aantal werknemers en doet de business value van customization stijgen.

Percentage of Odoo users – Hoeveel van het aantal werknemers ook werkelijk Odoo-

gebruikers zullen zijn na de implementatie is zelfs nog belangrijker. Daar waar non-gebruikers

enkel een invloed hebben op de bedrijfsprocessen, hebben de gebruikers ook nog eens een

extra invloed op de werkwijze van Odoo zelf. Het is met andere woorden nog belangrijker om

rekening te houden met de gebruikers.

39

Processes

De eerste twee drijvende factoren met onder ‘Processes’ duiden op de flexibiliteit van het

bedrijf betreffende zijn processen. Hoe minder flexibel het bedrijf, hoe moeilijker ze hun

processen/workflow kunnen veranderen of aanpassen aan de processen/workflow in Odoo

én hoe meer business value er gegenereerd wordt door customization (Cfr. Supra).

Kind of business – Deze factor is een uitbreiding op factor h) ‘Productiebedrijven waar

gesproken werd over het gebrek aan flexibiliteit om hun workflows te veranderen. Bovenop

‘production’ breidt de schaal zich uit met drie extra keuzes: service, retail en distibution.

Aangezien de gesynthetiseerde lijst uiteindelijk toch nog teruggaat naar de experten, wordt

op deze manier onderzocht of de drie extra keuzes ook een invloed kunnen spelen op de

customization-beslissing.

Maturity of company – Hoewel de factor ‘change willingness of people’ niet wordt aanzien

als een drijvende factor inspireerde het wel om tot de factor bedrijfsmaturiteit te komen. Hoe

ouder een bedrijf is in jaren, hoe meer ze vergroeid zit in haar processen en workflows. Oudere

bedrijven zullen dus meer belang hechten aan customization zodat zij zelf ongewijzigd kunnen

blijven.

De laatste 2 factoren onder processes spelen in op de structuur van het bedrijf van de klant.

Number of Physically separated settlements – Deze factor werd reeds besproken hierboven

en kan teruggevonden worden onder i). Hoe meer vestigingen er zijn, hoe complexer de

customization wordt en hoe minder business value het genereert.

Number of different departments – Eerder werd de factor k) Number of modules als

belangrijk bevonden. Daarop gebaseerd komt deze factor tot stand. Het is namelijk niet zozeer

van belang hoeveel modules er worden gebruikt in een Odoo-implementatie, maar wel het

aantal verschillende modules. Dat hangt op zich dan weer samen met het aantal verschillende

departementen er zijn binnen een bedrijf. Hoe meer verschillende modules, hoe complexer

een eventuele customization zal worden, wat negatief werkt op de business value.

Budget

Maximum budget – Voor de bespreking hiervan wordt verwezen naar factor a). Deze

drijvende factor wordt gemeten in euro’s.

40

Time

Maximum time frame – Voor de bespreking hiervan wordt verwezen naar factor c). Deze

drijvende factor zal gemeten worden op een schaal van aantal dagen.

4.1.3. Conclusie

Ronde 1 zoekt naar de drijvende factoren in de beslissing tot het al dan niet customizen van

een Odoo-pakket waarbij het maximaliseren van de business value van de klant centraal staat.

De zoektocht resulteert in 13 drijvende factoren die samengebracht worden in een

gesynthetiseerde factorenlijst. De factoren hebben invloed op 5 toepassingsgebieden: Scope,

People, Processes, Budget en Time.

De gesynthetiseerde lijst dient nu teruggestuurd te worden naar het expertenpanel. Zie

dienen een oordeel te vellen over factorenlijst.

4.2. Fase 1 - Ronde 2: Validatie van de drijvende factoren

In ronde 2 wordt de gesynthetiseerde factorenlijst uit ronde 1 teruggekoppeld aan de

experten ter validatie. Hiermee wordt het normale verloop van een Delphi studie gevolgd (Cfr.

Supra). De experten wordt de vraag gesteld of ze al dan niet akkoord gaan met de factoren uit

de lijst. De experten hebben vervolgens de mogelijk om factoren uit de lijst te verwijderen,

toe te voegen of om extra kritiek te uiten over bepaalde factoren.

Het samenbrengen van deze antwoorden resulteerde in de samenvattende Tabel 13

hieronder.

Tabel 13 geeft per factor weer hoe groot het percentage is van experten die akkoord gaan met

de gegeven factor, het percentage die niet akkoord gaan met de gegeven factor en het

percentage die wel akkoord gaan met de gegeven factor, maar hier toch een belangrijke

opmerking bij hebben. Deze laatste zijn antwoorden in de vorm van: “Ja, maar…”.

41

Tabel 13: Synthese Antwoorden Ronde 2

Overeenkomstig met verwerkingsmethode van de vorige ronde zal factor per factor

besproken worden op basis van Tabel 13. Bijlage 10: Synthese van de Antwoorden uit ronde

2 is de meer uitgebreide versie van deze tabel waarin ook de opmerkingen van de experten

zitten verwerkt.

4.2.1. Analyse van de antwoorden

Naast elke factor zal ‘Gevalideerd’ of ‘Niet gevalideerd’ komen te staan. Gevalideerd wil

zeggen dat het de factor in kwestie onveranderd wordt opgenomen in de finale factorenlijst.

‘Niet gevalideerd’ kan overeenkomen met de uitsluiting van de factor of met het toch

opnemen van de factor, maar mits belangrijke aanpassingen. Deze resultatenbespreking

resulteert in een de finale factorlijst (zie 4.2.2. ).De finale factorenlijst

Scope

Gap Size – ‘Gevalideerd’: Alle experten gaan unaniem akkoord met deze factor. Een expert

suggereert om Data migratie op te nemen als extra factor. Data migratie zit echter reeds

vervat in GAP Size. De klant wil namelijk dat zijn huidige data in het Odoo-systeem komt te

zitten en dat is een vereiste van de klant die niet in een OOTB Odoo-systeem zit (=Gap).

Verdeling Factor Akkoord Opmerking Niet akkoord

Scope

GAP Size 100% 0% 0%

GAP Importance 100% 0% 0%

Number of NEW software

connections to be created 89% 7% 4%

Impotance of NEW connections 93% 7% 0%

Difficulty level of creating those

connections 93% 7% 0%

People Number of employees 67% 22% 11%

Percentage of Odoo users 63% 26% 11%

Processes

Kind of business 89% 0% 11%

Maturity of company 74% 19% 7%

Number of Physically separated

settlements 89% 0% 11%

Number of different

departments 85% 4% 11%

Budget Maximum budget 89% 7% 4%

Time Maximum time frame 93% 7% 0%

42

Gap importance – ‘Gevalideerd’: Ook deze factor wordt unaniem positief ontvangen door de

experten. Toch wordt het voorstel gegeven om het hoogste niveau van de Likert-schaal te

veranderen.

Niveau 5 zou niet moeten overeenkomen met ‘Zeer belangrijk’, maar met ‘Verplicht’

(Mandatory). Experten duiden erop dat bepaalde vereisten van de klant verplicht kunnen zijn

door de wet. Het verplichte karakter zou er echter weer voor zorgen dat de keuze om al dan

niet te gaan customizen wegvalt, het is dan verplicht. Zoals eerder gezegd onder 4.2.1. zou

daarmee de opzet van dit onderzoek vervallen.

Number of NEW sofware connections – ‘Niet gevalideerd’: De factor kan met 83%

aanvaardinggraad uiteraard niet verwijderd worden uit de lijst. De factor zal echter opgaan in

de factor GAP Size. Een connectie dient gemaakt te worden aangezien de klant zijn Odoo-

systeem wil laten communiceren met andere software. Dit is een vereiste van de klant die niet

in een standaard OOTB Odoo-pakket zit en valt dus onder GAP Size.

Importance of NEW software connections – ‘Niet gevalideerd’: Aangezien het aantal nieuwe

software connecties onder GAP Size komt te zitten, zal het belang van die nieuwe

softwareconnecties onder GAP Importance worden opgenomen.

Difficulty level of the NEW software connections – ‘Niet gevalideerd’: Met het impliciet

wegvallen van de vorige factoren. Betekent deze factor op zich ook niet veel. Daarentegen

moet toch gekeken worden om de factor in de finale lijst te laten terugkomen onder een

andere vorm. De factor krijgt namelijk 93% appreciatie en geen enkele expert wil de factor

verwijderen.

People

Beide factoren onder people krijgen veel kritiek te verduren van de experten. Slecht om en bij

de 65% van de experten geven groen licht voor beide. Iets meer dan 20% hebben belangrijke

opmerkingen en een kritieke 11% erkennen de invloed van beide factoren op de

onderzoekvraag niet. Vooral de 11% is een cruciale aanwijzing dat de factor heruitgevonden

moet worden.

Op basis van de redenering die eerder werd gemaakt voor de potentiële factor ‘q) User skills’

en de opmerkingen van de experten, zal de sectie People opgenomen worden onder GAP

importance. Hoe meer gebruikers en/of Odoo users er zijn in een bedrijf, hoe belangrijker het

43

wordt om het Odoo-systeem aan te passen aan hun workflow en niet omgekeerd. Processen

kunnen in een bedrijf met 5 werknemers gemakkelijker aangepast worden ten opzichte van

een bedrijf met 100 werknemers.

Processes

Kind of business – ‘Niet gevalideerd’: Dit is de factor waarbij uitgeprobeerd werd om bovenop

Production, ook nog Service, Distribution en Retail toe te voegen aan de schaal (Cfr. Supra).

Het merendeel van de experten (89%) erkent dat servicebedrijven flexibeler zijn in hun

processen dan productiebedrijven. Ze zie echter niet het belang van Distribution en Retail.

Bijkomend kreeg ook deze factor een kritieke 11% aan tegenstand.

De factor bezit met andere woorden een zekere waarde, maar niet in de vorm zoals die hier

gegeven staat. Het gemak of dus de flexibiliteit waarmee bedrijven hun processen zelf kunnen

aanpassen kwam reeds ter sprake onder ‘People’. Het is dan ook vanzelfsprekend dat ‘Kind of

business’ hetzelfde lot ondergaat en onder GAP importance komt te zitten.

Maturity of company – ‘Niet gevalideerd’: De bedrijfsmaturiteit beduidt de mate waarin een

bedrijf vasthangt aan zijn processen en workflows of met andere woorden het gemak

waarmee ze hun processen en workflows kunnen aanpassen. Voor bedrijfmaturiteit kan met

andere woorden dezelfde redernering gevolgd worden als voor ‘Kind of business’. Het komt

ook te zitten onder Gap Importance.

Number of Physically separated settlements – ‘Niet gevalideerd’: De factor heeft 11% van

experten tegen zich. De factor kan echter niet verwijderd worden aangezien de overige 89%

wel het belang van deze factor erkennen. Wederom blijkt een factor die van waarde kan zijn,

maar niet onder deze vorm.

Number of Different departments – ‘Niet gevalideerd’: Deze factor komt in net dezelfde

situatie te zitten als de vorige factor. De factor zal tevens opgenomen moeten worden onder

een andere vorm.

Budget

The client’s maximum budget – ‘Gevalideerd’: Hoewel 89% van de experten meteen het

belang van deze factor bevestigen, hebben 11% van de experten hier toch hun bedenkingen

bij, waarvan zelfs 4% de factor uit de lijst zouden nemen. De meeste twijfel omtrent deze

factor ontstond uit het feit dat de klant bijna nooit zijn maximum budget vrijgeeft. Deze kritiek

44

neemt echter niet weg dat de factor wel een rol speelt in de onderzoeksvraag. Het is dan ook

vanzelfsprekend dat de factor meegaat naar de finale factorenlijst.

Time

The client’s maximum time frame – ‘Gevalideerd’: De factor wordt vrijwel ten volle positief

geëvalueerd door de experten. De factor zal dus terug moeten komen in de finale factorenlijst.

4.2.2. De finale factorenlijst

Uit de analyse van de antwoorden van de experten blijkt dat sommige factoren uit de

gesynthetiseerde factorenlijst rechtstreeks kunnen overgenomen worden in de finale

factorenlijst. Er zijn ook factoren die dienen opgenomen te worden in andere factoren. De

overblijvende factoren worden wel als waardevol beschouwd, maar niet in de vorm waarin ze

voorkwamen.

Tabel 14 geeft een overzicht van de finale factorenlijst. Indien van toepassing, worden naast

elke finale factor de gesynthetiseerde factoren opgelijst die onder deze factor opgenomen

worden. De opgenomen factoren zullen niet meer visueel voorkomen in de lijst maar zitten

vanwege hun gelijkenis met de finale factor er wel in vervat.

Verdeling Finale Factoren Recht

evenredig met Factoren die hierin vervat zitten

Gap

(=Scope)

GAP Size Customization - Number of NEW software connections

to be created

GAP Importance Customization

- Importance of NEW connections

- Number of employees

- Percentage of Odoo users

- Kind of business

- Maturity of company

Gap Complexity OOTB

- Difficulty level of creating

NEW connections

- Number of Physically separated

settlements

- Number of different departments

Budget Maximum budget Customization

Time Maximum time

frame Customization

Tabel 14: Finale factorenlijst

45

De meest opvallende veranderingen zijn het volledig verdwijnen van de onderverdelingen

‘Processes’ en ‘People’, maar ook het toevoegen van de nieuwe factor ‘GAP complexity’. Deze

veranderingen worden hieronder kort besproken samen met het overlopen van de finale

factorenlijst.

Scope

Gap Size – De factor bleek al belangrijk te worden bevonden in de gesynthetiseerde lijst en

dat wordt hier bevestigd door de experten. Zoals besproken hierboven wordt ‘het aantal

nieuw te ontwikkelen softwareconnecties’ hieronder opgenomen. Dat wil zeggen dat de

factor niet meer visueel zal voorkomen in de lijst maar impliciet wel vervat zit onder GAP Size.

Gap Importance – De factor die duidt op de belangrijkheidsgraad van de Gap Size zal vanaf

heden meerdere factoren op zich nemen dan eerst gedacht. Alle vijf deze factoren duiden

namelijk op de mate waarin het belangrijk zou kunnen zijn om de Gap te dichten.

Gap Complexity – Bij de bespreking van de resultaten hierboven, werden drie factoren

gevonden enerzijds waardevol waren, maar anderzijds onder een andere vorm moeten komen

te staan. De drie factoren (zie Tabel 14) bemoeilijken elk op hun manier de mogelijke

customization. Hieruit ontstaat de nieuwe factor Gap Complexity, waaronder de drie factoren

worden opgenomen.

Budget

Maximum Budget – Het maximum budget dat de klant uittrekt voor de Odoo-implementatie

wordt rechtstreeks overgenomen vanuit de gesynthetiseerde lijst.

Time

Maxim Time Frame – Hetzelfde wordt ook gedaan voor de maximum tijd dat de klant hiervoor

voorziet.

4.2.3. Conclusie

Een 2e ronde bleek genoeg te zijn om tot een gevalideerde lijst te komen. Moest dit niet het

geval geweest zijn, was een 3e ronde tevens nodig.

De finale factorenlijst die voorkomt uit de afgesloten 1e fase van de Delphi studie is een lijst

bestaande uit vijf factoren: Gap Size, Gap Importance, Gap Complexity, The client’s maximum

budget en The client’s maximum time frame. In vergelijking met de gesynthetiseerde

46

factorenlijst uit de 1e ronde verkleint de onderverdeling zich hiermee tot slechts 3 niveau’s:

Gap (=Scope), Budget en Time.

4.3. Fase 2: Weging van de drijvende factoren

De finale factorenlijst die wordt gevonden in fase 1, dient in deze 2e fase voorzien te worden

van gewichten. De gewichten moeten het belang uitdrukken dat elke factor heeft op de

onderzoeksvraag. Een factor met een groter gewicht zal een grotere invloed spelen op de

beslissing om al dan niet over te gaan tot het customizen van het Odoo-systeem teneinde de

grootste business value op te leveren voor de klant.

Om tot deze gewichten te komen wordt de experten gevraagd om aan elke factor uit de finale

factorenlijst een gewicht te hangen tussen 0% en 100%. De antwoorden worden hieronder

geanalyseerd.

4.3.1. Analyse van de antwoorden

Om aan te duiden hoe de verkregen gewichten per factor verdeeld zijn, worden deze

besproken aan de hand grafieken. De verticale as geeft aan hoeveel keer een bepaald gewicht

wordt gegeven aan de factor. Op de horizontale as worden de mogelijke gewichten

samengenomen per 10 om het overzicht te bewaren.

Figuur 2: Gewichtenverdeling Gap Size

Figuur 3: Gewichtenverdeling Gap Complexity

De verkregen gewichten voor Gap Size en Complexity zijn wijd verdeeld. Er kan geen duidelijke

trend gevonden worden in beide grafieken. Bij Gap Complexity valt het op dat er geen enkele

expert een gewicht geeft tussen 30-40 en tussen 50-60, maar dat wel drie experten een

gewicht geveen tussen 40-50

012345678

]0-1

0]

]10-

20

]

]20-

30

]

]30-

40

]

]40-

50

]

]50-

60

]

]60-

70

]

]70-

80

]

]80-

90

]

]90-

10

0]

Aan

tal a

ntw

oo

rde

n

Gewichten (%)

Gap Size

012345678

]0-1

0]

]10-

20

]

]20-

30

]

]30-

40

]

]40-

50

]

]50-

60

]

]60-

70

]

]70-

80

]

]80-

90

]

]90-

10

0]

Aan

tal a

ntw

oro

de

n

Gewichten (%)

Gap Complexity

47

Figuur 4: Gewichtenverdeling Gap Importance

Figuur 5: Gewichtenverdeling Budget

Voor de factoren Gap Importance en Budget zien we een meer duidelijke trendlijn die stijgt in

positieve zin. Experten kennen aan beide factoren eerder een hoger gewicht toe, dan een

lager. We concluderen dat deze gewichten over het algemeen belangrijker worden bevonden

dan de vorige twee gewichten.

Figuur 6: Gewichtenverdeling Time

De laatste onbesproken factor is Time. Het is de enige van de vijf factoren met in zeker zin een

normale verdeling. De verdeling heeft zijn hoogtepunt ronde 40-50 met een piek van acht

antwoorden van de experten.

4.3.2. Het finaal gewicht per factor

Om tot de finale gewichten per factor te komen wordt voor elke factor het gemiddelde

genomen van alle gewichten die hem toegewezen worden door de experten (Cfr. Hoofstuk 3).

012345678

]0-1

0]

]10-

20

]

]20-

30

]

]30-

40

]

]40-

50

]

]50-

60

]

]60-

70

]

]70-

80

]

]80-

90

]

]90-

10

0]

Aan

tal a

ntw

oo

rde

n

Gewichten (%)

Gap Importance

012345678

]0-1

0]

]10-

20

]

]20-

30

]

]30-

40

]

]40-

50

]

]50-

60

]

]60-

70

]

]70-

80

]

]80-

90

]

]90-

10

0]

Aat

nal

an

two

ord

en

Gewichten (%)

Budget

012345678

]0-1

0]

]10-

20

]

]20-

30

]

]30-

40

]

]40-

50

]

]50-

60

]

]60-

70

]

]70-

80

]

]80-

90

]

]90-

10

0]

Aan

tal a

ntw

oo

rde

n

Gewichten (%)

Time

48

Tabel 15 vat de gemiddelde gewichten per factor samen. In een extra kolom wordt het finaal

gewicht afgerond om de vergelijking tussen de gewichten visueel eenvoudiger te maken.

Factor Gemiddeld finaal gewicht Afgerond gewicht

Gap Size 59,52 % 60 %

Gap Importance 71,67 % 72 %

Gap Complexity 61,19 % 61 %

Budget 73,10 % 73 %

Time 54,52 % 55 %

Tabel 15: Het finaal gewicht per factor

Uit de tabel blijkt dat budget als belangrijkste factor wordt aanzien en time als minst

belangrijkste. De impact van het budget op de onderzoeksvraag zal met andere woorden het

grootste zijn van alle factoren.

Tussen beide uitersten zit een afgerond verschil van 17% in belangrijkheidsgraad. Op 5

factoren geeft dat slechts een gemiddelde afstand van 3%. De gewichten liggen met andere

woorden relatief dicht op elkaar.

De factor Budget wordt in belangrijkheidsgraad meteen opgevolgd door Gap Importance met

72%. Gap Complexity zit dan weer 10% lager met vlak daarna Gap Size op 1% verschil.

4.4. Opstellen Decision Support tool

De laatste stap van het onderzoek is het opstellen van de Decision Support tool. De werking

van de tool zit vervat in de beslissingsformule die reeds in Hoofdstuk 3 een sterke toelichting

kreeg. Ook de stappen en formules die hierbij toegepast moeten worden zijn terug te vinden

in Hoofdstuk 3.

Om tot een beslissingsformule te komen die toegepast kan worden, moesten er nog twee

bewerkingen gebeuren. Op de eerste plaats worden de gewichten uit de 2e fase van het

onderzoek herschaald zodat hun som uitkomt op 100%. Ten tweede worden de schalen van

de factoren genormaliseerd. De werkelijke berekeningen met de juiste getallen per factor

zitten in Bijlage 12: Gewichten en Bijlage 13: Schalen normaliseren.

Worden de berekeningen toegepast en de schalen genormaliseerd, wordt de volgende

beslissingsformule of –tool verkregen:

49

18,6 % ∗[𝐺𝑆]−50

√833,25+ 22,40 % ∗

[𝐺𝐼]−3

√2− 19,21 % ∗

[𝐺𝐶]−3

√2+ 22,84 % ∗

[𝐵]−33.200

11.066,67+ 17,04% ∗

[𝑇]−3,21

1,07= 𝑊

De afkortingen tussen haken staan voor de finale drijvende factoren: Gap Size, Gap

Importance, Gap Complexity, Budget en Time. Door de factoren in te vullen wordt uiteindelijk

een getal 𝑊 bekomen. Hoe groter de waarde van W, hoe meer de decision support tool

aanstuurt om het Odoo-systeem te gaan customizen. De grootte van W staat namelijk

symbool voor de business waarde die verkregen kan worden uit customization.

De input voor elke factor moet wel voldoen aan de vooropgestelde schalen. In Tabel 16 wordt

nogmaals kort samengevat welke getallen ingevuld kunnen worden voor iedere factor.

Finale Factoren Recht

evenredig met Schaling

GAP Size Customization 0 - 100

GAP Importance Customization 1 (= onbelangrijk) – 5 (=zeer belangrijk)

Gap Complexity OOTB 1 (=zeer gemakkelijk) – 5 (=zeer complex)

Maximum budget Customization €0 - …

Maximum time

frame Customization 0 Maanden - …

Tabel 16: Input per finale factor

De waarde 𝑊 varieert van -2,11 tot in principe +∞ aangezien Budget en Time oneindig groot

mogen worden. Bij een negatieve 𝑊 is het aan te raden om voor een OOTB-Odoo-

implementatie te gaan, met als doel het maximaliseren van de business value bij de klant. Het

omgekeerde geldt voor een positieve waarde van 𝑊. Een 𝑊 = 0 is volledig onverschillig ten

aanstaande van de beslissing.

50

HOOFDSTUK 5: Conclusie

5.1. Algemeen besluit

We zijn vertrokken van het feit dat zowel de klanten als de implementatoren steeds voor een

ERP-implementatie steeds voor customization kiezen.

Daaruit werden volgende onderzoeksvragen naar voor geschoven:





Het uiteindelijke doel was het opmaken van een decision support tool op basis van de

gevonden antwoorden op de onderzoeksvragen. Die antwoorden werden verkregen dankzij

het uitvoeren van een Delphi studie.

In een eerste fase van de Delphi studie werden, aan de hand van bevragingen bij experten, de

drijvende factoren met betrekking tot de eerste onderzoeksvraag gevonden: Gap Size, Gap

Importance, Gap Complexity, Budget en Time. Alle factoren behalve Gap Complexity hebben

een positieve invloed op customization.

In een tweede fase van de Delphi studie gingen we opzoek naar de gewichten bij elke factor.

Budget werd uiteindelijke gemiddeld gezien het belangrijkste gevonden, gevolgd door Gap

Importance, Gap Complexity, Gap Size en Time.

Op basis van deze gegevens kon mits het uitvoeren van enkele bewerkingen een

beslissingsformule opgesteld worden. Deze formule zal in de praktijk als decision support tool

gebruikt kunnen worden door klanten en implementatoren om te beslissen over het al dan

niet customizen van Odoo met als doel het maximaliseren van de business value van de klant.

5.2. Implicaties en Beperkingen

Een eerste beperking stelt zich omtrent de anonimiteitsregel van het Delphi onderzoek. Deze

werd toegepast om enige invloed van de experten onderling uit te schakelen. Er kon echter

niet gecontroleerd worden of de experten buiten het onderzoek om toch met elkaar contact

hebben gehad over het verloop van het onderzoek.

51

De lijst met experten werd opgemaakt op 10 April 2014. Hiervoor werden de gegevens

gebruikt van de toen nog genaamde OpenERP-website. Na 10 April werd de lijst niet meer

geupdate met nieuwe Odoo partners.

Vele experten die deelgenomen hebben aan het onderzoek lieten hun antwoord vooral

afhangen van de tweestrijd tussen wel of niet customizen. Veel van de experten hielden hierbij

geen rekening dat het uiteindelijk doel de business value van de klant was. Bepaalde

antwoorden of bepaalde delen van antwoorden werden zoveel mogelijk uit het onderzoek

gefilterd indien dit het geval bleek te zijn. Er kan echter niet gegarandeerd worden dat alle

foute invloeden uit het onderzoek gefilterd werden.

De decision support tool houdt in dit onderzoek geen rekening met de afhankelijkheden en de

invloeden van de factoren onderling op elkaar. Dit werd ook niet onderzocht

Elke ronde in een Delphi onderzoek vraagt normaal een maand de tijd. Aangezien er voor dit

onderzoek niet zoveel tijd voor handen was werd deze periode ingekort tot ongeveer twee

weken per ronde.

Nog door tijdsgebrek werd de tweede fase – waarin tot de gewichten per factor werd

gekomen – niet meer gevalideerd met de experten.

De steekproef die werd gehouden tot het vinden van de minimum en maximum

implementatiebudgetten en –tijd had slechts 11 waardevolle antwoorden. Door gebrek aan

verdere informatie moest we ons hier wel op baseren. Om te kunnen veralgemenen heeft

men echter normaal nood aan 30 antwoorden of meer.

5.3. Suggesties voor verder onderzoek

Het onderzoek heeft zich toegespitst op Odoo-implementaties. Het kan echter interessant zijn

om hetzelfde onderzoek uit te voeren voor een andere ERP. Aangezien Odoo zich vooral richt

op KMO’s, kunnen van hieruit twee pistes belopen worden.

Enerzijds kan het onderzoek opnieuw gedaan worden voor een ander ERP-pakket dat zich

tevens richt op KMO’s. Zo kan de decision support tool uit dit onderzoek gevalideerd worden.

Anderzijds kan het ook gedaan worden voor een ERP-pakket met een focus op grote bedrijven.

Een tweede mogelijk verder onderzoek volgt uit de beperkingen van dit onderzoek. Zoals

vermeld werden de onderlinge afhankelijkheden tussen de factoren niet onderzocht. Er zou

52

van de gevonden factoren hier kunnen vertrokken worden en aan de hand van experten en

cases gaan onderzoeken hoe de factoren in relatie staan ten opzichte van elkaar.

Valideren van de methode uit dit onderzoek. Wij hebben namelijk een afgeleide delphi

methode gebruikt. Het kan interessant zijn om te onderzoeken of deze volledig correct is

verlopen.

Het kan ook interessant zijn om het onderzoek opnieuw uit te voeren maar dit maal om de

verschillen te ontdekken tussen de continenten. De decision support tool uit dit onderzoek

werd opgesteld met Odoo-experten van over de hele wereld. Door de experten op te delen

volgens continent en de antwoorden vervolgens apart te verwerken kan gekomen worden tot

een decision support tool per continent. Er kan waardevolle informatie ontstaan uit de

verschillen en gelijkenissen tussen de verschillende continentale decision support tools.

Ten laatste zou de ontbrekende validatie van de tweede fase nog gedaan kunnen worden. De

experten moeten hiertoe opnieuw gecontacteerd worden. Er wordt hun de gevonden

gewichten door gestuurd met de vraag of ze hiermee akkoord gaan. Een derde en vierde ronde

kunnen ook nog van toepassing zijn indien de gewichten nog veel verschuiven door de

feedback van de experten.

I

LITERATUURLIJST

1. Tadjer, R. Enterprise resource planning. Manhasset : Internetweek, 1998.

2. Davenport, T. Putting the Enterprise into the Enterprise System. Harvard : Harvard Business

Review, 1998.

3. Mohammad, A.R., Hossain, L. and Partick, J.D. The evolution of ERP Systems: A Historical

Perspective. s.l. : Idea Group Publishing, 2002.

4. Haddara, M. and Zach, O. ERP Systems in SMEs: A Literature Review. Kristiansand, Norway :

IEEE, 2011. 978-1-4244-9618-1.

5. Broatch, M. Making the ERP connection. New Zealand : Computerworld, 2001.

6. Louis, Columbus. Gartner's ERP Market Share Update Shows The Future Of Cloud ERP Is

Now. Forbes. [Online] Forbes, 12 05 2014. [Cited: 22 05 2014.]

http://www.forbes.com/sites/louiscolumbus/2014/05/12/gartners-erp-market-share-

update-shows-the-future-of-cloud-erp-is-now/.

7. Brandt, W. SAP presentation from the European TMT Conference . SAP. [Online] 10 09 2010.

[Cited: 22 05 2014.]

http://www.google.be/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ve

d=0CDoQFjAB&url=http%3A%2F%2Fglobal.sap.com%2Fcorporate-

en%2Finvestors%2Fpresentations%2Fpdf%2FWB_DB_London_8Sep2010.pdf&ei=zR6DU_-

fN-qw7AaHrIGwDw&usg=AFQjCNGZmucndtr41B3cs6rds.

8. Odoo. About-us. Odoo. [Online] Odoo, 2014. [Cited: 22 05 2014.]

https://www.odoo.com/page/about-us.

9. Pinkaers, Fabien. The OpenERP Story. Odoo. [Online] Odoo, 06 2014. [Cited: 24 05 2014.]

https://www.odoo.com/blog/Odoo-Blog-1/post/The-OpenERP-Story-56#blog_content.

10. McNurlin, Barbara. Will users of ERP stay satisfied? s.l. : MITSloan, 2001.

11. Enterprise-Wide Information Systems: The Case of SAP R/3 Application. Majed, A. 2000.

12. Ptak, C. and Schragenheim, E. ERP: tools, techniques and applications for integrating the

suppy chain, Second Edition (Resource Management). London : St. Lucie Press, 2000.

II

13. Wong, A., et al. Critical Failure Factors in ERP Implementation. 2006.

14. Markus, M., et al. Learning from adopters’ experiences with ERP:. s.l. : Journal of

Information Technology 15, 2000.

15. Deutsch, C. Software that can make a grown company cry. New York : The New York Times

51, 1998.

16. Nelson, E. and Ramstad, E. Hershey's Biggest Dud Is Its New Computer System. The Wall

street journal. [Online] The Wall street journal, 29 10 1999. [Cited: 23 05 2014.]

http://online.wsj.com/news/articles/SB941156105920533040.

17. Actual vs. Planned ERP Systems Implementation Costs in European SMEs. Johansson, B.

and Sudzina, F. 2009.

18. Barton, Patricia. Enterprise Resource Planning: Factors Affecting Success and Failure. 2001.

19. Bista Solutions. 10 reasons for ERP Implementation failures. blogs.bistasolutions.com.

[Online] Bista Solutions, 24 04 2013. [Cited: 25 05 2014.]

http://blogs.bistasolutions.com/2013/04/24/10-reasons-for-erp-implementations-failures/.

20. Leon, A. Challenges to successful ERP implementations. Enterprise Resource Planning -

Second Edition. New Delhi : Tata McGraw-Hill Publishing Company, 2008.

21. ERP Customization impacts on strategic alignment and system agility. Davis, Ashley.

Georgia : University of Georgia, 2005.

22. Enterprise resource planning: cultural fits and misfits: is ERP a universal solution? Soh, C.,

Kien, S. and Tay-Yap, J. 4, New York : Communications of the ACM, 2000, Vol. 43.

23. Sumner, Mary. Enterprise Resource Planning. Amsterdam : Pearson Education Benelux,

2007. ISBN: 978-90-430-1241-6.

24. Szyperski, C., Gruntz, D. and Murer, S. Components - Custom-made versus standard

software. [book auth.] C. Szyperski. Component software: beyond object-oriented

programming. Lodon : Addison-Wesley, 2003.

III

25. See-Pui, C. A Case Study on the Impact of Customization, Fitness, and Operational

Characteristics on Enterprise-Wide System Success, User Satisfaction, and System Use. s.l. :

Journal of global Information Management, 2021.

26. Noyes, J. The ERP Dilemma: "Plain Vanilla" Versus customer Satisfaction. San Antonio :

University of Texas, 2003.

27. Kimberling, Eric. The Long-Term Effects of Heavy ERP System Customization. Panorama

consulting. [Online] 05 06 2013. [Cited: 20 05 2014.] http://panorama-consulting.com/the-

long-term-effects-of-heavy-erp-system-customization/.

28. Marshall, Phill. ERP Implementation: Customizing. ERP FOCUS. [Online] 10 02 2012. [Cited:

2014 05 20.] http://www.erpfocus.com/erp-implementation-customizing-590.html.

29. Zach, O. and Munkvold, B.E. Identifying reasons for ERP system customization in SMEs: A

multiple case study. Journal of Enterprise Information Management. 2012, Vol. 25, 5.

30. Zach, O. ERP system implementation in small and medium-sized enterprises. Agder :

University of Agder, 2012.

31. How IT creates business value: a process theory synthesis. Soh, C. and Markus, M.L. s.l. :

ICIS, 1995.

32. Review: information technology and organizational performance: an integrative model of

it business value. Melville, N., Kraemer, K. and Gurbaxani, V. 2, Michigan : MIS Quarterly,

2004, Vol. 28.

33. Chappel, D. The business value of software quality. David Chappell. [Online] [Cited: 05 23

2014.] http://www.davidchappell.com/writing/white_papers.php.

34. Rosemann, M. Measuring the Performance of ERP Software - a Balanced Scorecard

Approach. Brisbane : Queensland University of Technology, 1999.

35. Fink, A., et al. Consensus Methodes: Characteristics and Guidelines for Use. Santa Monica :

RAND, 1991.

36. Dalkey, N. and Helmer, O. An experimental application of the Delphi method to the use of

experts. 1963.

IV

37. Brancheau, J.C., Janz, B.D. and Wetherbe, J.C. Key issues in information systems

management. 1996.

38. Czikota, M.R. and Ronkainen, L.A. International business and trade in the next decade:

report from a Delphi study. 1997.

39. Kendall, J.E., et al. SEER: A divergent methodology applied to forecasting the future rules

of the systems analyst. 1992.

40. Viehland, D. and Hughes, J. The future of the wireless application protocol. Dallas : s.n.,

2002.

41. Cegielski, C.G. A model of the factors that affect the integration of ermerging information

technology into coporate strategy. s.l. : University of Mississipi, 2001.

42. Hayne, S. and Pollard, C. A comparative analysis of critival issues facing Canadian

information systems personnel: a national and global perspective. 2000.

43. Holsapple, P. and Joshi, K. Knwoledge manipulation activities: results of a Delphi study.

2002.

44. Lai, V. and Chung, W. Managing international data communications. 2002.

45. Mulligan, P. Specificatino of a capability-based IT classification framework. 2002.

46. Nambisan, S., Agarwal, R. and Tanniru, M. Organizational mechanisms for enhancing user

innovation in information technology. 1999.

47. Schmidt, R.C., et al. Identifying software project risks: an international Delphi study. 2001.

48. Grisham, T. The Delphi technique: a method for testing complex and multifaceted topics.

St. Pete Beach : Emerald Group , 2008.

49. Okoli, C. and Pawlowski, S.D. The Delphi Method as a research tool: an example, design

considerations and applications. s.l. : Elsevier, 2004.

50. Hsu, C. and Sandford, B.A. Minimizing Non-Response in The Delphi Process: How to

Respond to Non-Response. Oklahoma : Oklahoma State University, 2007.

51. Van Looy, A. Business process maturity: A comparative study on a sample of business

process maturity models. Ghent : Ghent University, 2012.

V

52. Rayens, Mary Kay. Building Consensus Using the Policy Delphi Method. s.l. : Sage, 2000.

53. Indentifying software project risks: an international delphi study. Schmidt, R., et al. 4,

Armond : Journal of Management Information Systems, 2001, Vol. 17.

54. OpenERP. Partners. OpenERP. [Online] 2014. [Cited: 15 04 2014.]

https://www.openerp.com/partners/directory.

55. De Greave, Jos. OpenERP. Gent, 10 03 2014.

56. An optimization method for selecting project risk response strategies. Zhang, Y. and Fan,

ZP. 3, Oxford : ELSEVIER SCI LTD, 2014, Vol. 32.

VI

BIJLAGEN

Bijlage 1: Bevragingsmail Fase 1: Ronde 1

Dear OpenERP expert,

In the context of my master's thesis, I am developing a support tool for OpenERP experts to decide whether or not it is valuable to customize an "out-of-the-box" OpenERP instance. In order to identify the depending factors for such a decision, the Delphi method is used which relies on a panel of anonymous OpenERP experts like yourself in two or more rounds. May I ask a few minutes of your time to have your opinion on the following open question: Which factors do you find crucial as an OpenERP expert to decide whether one of your SME clients should choose for either an "out-of-the-box" implementation or a customized implementation in order to maximize their business value? Note that the results of this study will be presented at the forthcoming Open Days of OpenERP. Unless stated otherwise, I would like to mention you as an expert contributor in the final report. Thanks in advance for a fast and thought-out reponse! Best regards, Timothy Verellen Master in Commercial Sciences - Management and IT Faculty of Economics and Business Administration Ghent University [email protected]

https://webmail.ugent.be/horde/imp/

VII

Bijlage 2: Herinneringsmail Fase 1: Ronde 1


Your opinion as OpenERP expert is very important for my research.

However I haven't had the honour yet to receive an answer from you on my research question.

May I please ask a few minutes of your time to answer the original message bellow?

In 2 days from now I will have to close this round and move on to the second round of my research.

---------------------------------------------------- ORIGINAL MESSAGE -------------------------------------------

[Bevragingsmail Fase 1: Ronde 1]

VIII

Bijlage 3: Bevragingsmail Fase 1: Ronde 2


I would like to thank you very much for your valuable input to identify the factors which may

drive the decision to choose for either an “out-of-the-box” implementation or a customized

implementation in order to maximize the client’s business value.

In summary, the list of potential drivers below was put forward by a panel of OpenERP experts

as yourself. May I ask a few minutes of your time to have your opinion on this list of jointly

identified factors as a way of validation.

Do you agree with this list or would you add/delete/modify specific factors?

1. Scope

a. GAP-percentage. The magnitude of the functional GAP between the client’s

work flow and the work flow in OpenERP. [ in %]

b. The importance of the GAP-percentage (% from above) in function of the

client’s business value. [in a scale from 1 to 5 where 1 = ‘totally unimportant’

and 5 = ‘very important’]

c. The number of NEW software connections that has to be made in order to have

the OpenERP communicating with other software. [in numbers]

d. The importance of those new connections to the client in function of his

business value? [on a scale from 1 to 5, where 1 = ‘totally not important’ and 5

= ‘very important’]

e. The difficulty level of creating these new software connections [on a scale from

1 to 5, where 1 = ‘very easy’ and 5 = ‘very hard’]

2. People

a. Number of employees. The number of people working in the company. [in

numbers]

IX

b. Percentage of employees that are actual OpenERP users. [in % of the total

employees]

3. Processes

a. Kind of business. [retail, distribution, production or service]

b. Maturity of company. The company age. [in years]

c. The number of physically separated settlements of the company. [in numbers]

d. The number of different departments of the company. [in numbers]

4. Budget

a. The client’s maximum budget. [in euros]

5. Time

a. The client’s maximum time frame for implementation. [in days]

Kind Regards,

Timothy Verellen

Master in Commercial Sciences - Management and IT

Faculty of Economics and Business Administration

Ghent University - Belgium

[email protected]

X

Bijlage 4: Herinneringsmail Fase 1: Ronde 2



However I haven't had the honour yet to receive an answer from you on the list of factors.

May I please ask a few minutes of your time to answer the original message bellow?

In 2 days from now I will have to close this round so I'm able to analyze all the valuable feedback from you, OpenERP experts.

--------------------------------------------------- ORIGINAL MESSAGE --------------------------------------------

[Bevragingsmail Fase 1: Ronde 2]

XI

Bijlage 5: Bevragingsmail Fase 2


In the former two rounds of the research we respectively identified and validated the factors

which may drive the decision to choose for either an "out-of-the-box" implementation or a

customized implementation in order to maximize the client's business value.

In this final round we would very much like you to prioritize the resulting set of drivers

below by giving each driver a weight between 0% and 100%. A weight more towards 0%

indicates the driver is less important while a weight more towards 100% means the driver

is more important to decide whether or not to customize in function of the client's business

value.

1. Gap:

a. Gap size: The magnitude of the client's required functions missing in an "out-of-

the-box" OpenERP implementation.

Weight :

b. Gap importance: The gravity of the client's required functions missing in an "out-

of-the-box" OpenERP implementation.

Weight :

c. Gap complexity: The difficulty to customize OpenERP to meet the client's

required functions.

Weight :

2. Budget:

The client's maximum budget willing to spend to implement the required

functions.

Weight :

3. Time:

XII

The client's maximum time frame willing to wait for the implementation of the

required functions.

Weight :

I hope to hear from you soon.

Kind regards,

Timothy Verellen

Master in Commercial Sciences - Management and IT

Faculty of Economics and Business Administration

Ghent University - Belgium

[email protected]

mailto:[email protected]

XIII

Bijlage 6: Herinneringsmail Fase 2



However I haven't had the honour yet to receive an answer from you on this final round.

As the subject suggests, this is the last round of the research and won't take long to fill in.

Could you please fill in the orginal message given below?

In a few days from now I will have to close this round to be able to finish my research.

------------------------------------------------ ORIGINAL MESSAGE -----------------------------------------------

[Bevragingsmail Fase 2]

XIV

Bijlage 7: Antwoorden ronde 1: Samengebracht

- Analysis : o (box) if the customer doesn't have a complete analysis, and/or is not willing to

pay for it o What we do is match how much the client requirement is near the openerp

features. o Only a gap analysis should determine whether to perform or not an "out of the

box" or a customized implementation. o For every project we do a gap analysis to see what customizations are needed.

We try to keep customizations to the minimum and do them only when absolutely needed.

o This is collected through analysis and entered in to a road-mapping document which allows us to objectively determine if the client needs to adjust their business to work with OpenERP or if OpenERP should be customised to fit the customer. Our preference is to direct the customer to have an out of the box OpenERP, but create customisations on the outside and connect via the API.

o I would consider how close the business functions are to what OpenERP offers o In fact we believe the best market for OpenERP is the A$5,000K++ turnover

customer that has unique requirements since the entry barrier is very low thus leaving room for the customer to get an ERP system with 100% requirements fit.

o required functionality o After conducting detailed analysis of their requirements we usually establish

that the need for customization is linked to the look and feel rather than the actual functionality.

- Processes :

o (box) if no clear process is defined in the company, it will be difficult to reproduce all of them (with too many exceptions for example).

o (box) The flow of business are simple (purchase, sale , delivery, accounting,... )

- Business or company : o (box) for a complete new business, it easier to adapt the new process to the

one's already implemented into the software o (custom) In specifieke niche bedrijven waar de functionaliteiten binnen

OpenERP ontoereikend zijn (en dat zijn er toch heel wat) en waar maatwerk moet ontwikkeld worden

o (custom) In productie bedrijven; OpenERP heeft een beperkte functionaliteit op gebied van productie (o.a. geen forecasting, geen kostrpijscalcualtie) en daar moet dan maatwerk voor gemaakt worden

o (custom) Mainly OpenERP standard functions are still too basic and community is not enough organized for expert functions (some exceptions for Magento or Finance).

o (box) very small structure o (box) The field of business is simple (no biotech , medical , production, ... ) food

industry. FIFO zit ook niet in OpenERP o (custom) Company size medium -large ( 5 to ... )

XV

o (custom) Point of Sale multiple o (custom) Company on several sites o (custom)Be able to customized process and reports (flexibility) o (1) And although you say about SME companies, rather than the size of it, (2)

more important thing is what industry the customer is in. (hij is voorstander van box omdat customization enorm veel kost. Zeker naar latere updates toe, kan je opnieuw van scratch beginnen.

o if they have a low budget and their business is simple enough, we install OpenERP as is, and maybe add some small customization later when they can afford it.

o Only if the request is found out to be the industry’s specific requirements and worthwhile making it as to be a new module in OpenERP

o The businesses for which we have customized the application usually have very specific requirements.

o Business priority of functional requirement that needs significant technical configuration or software development

- OpenERP

o (custom) If some complex modules are implemented as the output module lot

, tracking, accounting, asset management , cost accounting , ....

o The initial question is to see how far the out-of-the-box features in OpenERP

can fit the customer needs. Verder is het niet omdat een module bestaat dat

deze 100% coverage heft. De vraag is dan in hoeverre de klant zich kan

aanpassen aan de OpenERP. Kan hij dat dan gaan we voor box. Latere add-ons

kunnen dan nog gedaan worden. Gradaties van customization: als klant de

mogelijkheid heeft zich eerst zelf aan te passen en enkele kleine add-ons later

te doen.

o Availability of community modules similar to the clients functional requirement

in order to decrease software development effort and time

o For me, it’s mandatory to do some customization about reporting, template

of document, dashboard, …

- Other software

o (box) The management of the company is made in Office tools (Excel, .... ) o (box) The company is managed in several different software and requires re-

encoding. o (box) The management of the company is made in outdated software (no

possibilty of changing it, thechnologie exceeded ...). o (custom) If it is necessary to interface with the erp with hardware or other

software. o (custom) Integratie met diverse randsystemen (scanningsystemen,

tikkloksysteem, etc…)

- People

XVI

o (box) The user skills are average ( not an expert by area then the applications

will become more complex, it is in direct relation to the size of the company).

o ( box) Second factor: Easyness for the organization (because it is all standard

and easier to teach/support people) (niet opgenomen)

o I would consider how close the business functions are to what OpenERP offers.

If close enough, then whether employees are willing to change their

procedures to fit with OpenERP methodology. If not, then customize, If yet,

then use out of the box.

o The major factor in deciding the type of implementation is client's adaptation

level. Some clients change their business process flow in order to adapt to the

chosen system and this is where you do a "vanilla setup".

o Even If some requests for customization from the customer, try to rather make

the business process of customer’s to adjust to the system.

o They are usually more willing to adapt their business processes to OpenERP

because of that rather than the other way round.

o it's the customer's decision.

- Budget : o (box )if the customer doesn't have a budget above 20k, you have no chance to

proceed with a project. He'll beter go for a QuickStart approach, or out-of-the-box.

o haalt ook budget aan, maar niet zozeer als beslissende factor. Hij zegt enkel iets over de gemiddelde grootte. (meestal budget van several hundreds thousand euros)

o (box) Most important: basically budget. We can implement workable OOB for trading companies for 5000 euros

o we base this on customer budget o the main factor is the client's budget o Budget (very small business cannot afford customisations) o Cost-benefit, ie the cost to do the customisation versus the resultant

efficiency gains and therefore pay-back period. (In fact we believe the best market for OpenERP is the A$5,000K++ turnover customer that has unique requirements since the entry barrier is very low thus leaving room for the customer to get an ERP system with 100% requirements fit.)

o The cost. o Two factors discourage SMEs from going with the customized solution.

Cost of customization and support. Hosting and availability of support.

o Client's budget for implementation (#1 factor)

- Time o (box) Third factor: speed of implementation

o Client's time frame for implementation

XVII

Bijlage 8: Antwoorden ronde 1: Samengevat

1. Budget:

a. The client’s budget

b. The cost-benefit

2. Time:

a. The client’s time frame for implementation

3. Analysis:

a. If the customer doesn’t have a complete analysis, and/or is not willing to pay

for it, an out-of-the-box implementation is the better option

b. Gap-analysis

c. How important is the GAP?

4. Business and processes

a. No clear processes defined => OOB

b. The flow of the business is simple (purchase, sale, delivery, accounting,…)

c. Uniques business processes

d. Complete new businesses: OOB

e. Niche bedrijven (Custom)

f. Productie bedrijven (custom)

g. Very small structure (box)

h. Company structure (multiple sites) (Custom)

5. OpenERP

a. Number of modules

b. (custom) If some complex modules are implemented as the output module lot

, tracking, accounting, asset management , cost accounting , ....

c. Availability of community modules similar to the clients functional

requirement

6. Other software

a. Managed in several different software and requires reencoding (box)

b. Outdated software (box)

c. ERP needs to interface with hardware or other software (of randsystemen)

(custom)

7. People

a. Company users (less then 5 and less then 10)

b. Experience of client’s team with project implementation and with ERP

projects

c. User skills are average (box)

d. Change willingness of people (client’s adaptation level.)

e. Customer decision (what does the customer want: quick en small

implementation or an implementation that is relevant, effective and efficient

that can cost a bit => customization)

f. Place…(Belgium, India, France)

XVIII

Bijlage 9: De gesynthetiseerde factorenlijst (Ronde 1)

1. Scope

a. GAP-percentage. The magnitude of the functional GAP between the client’s

work flow and the work flow in OpenERP. [ in %]

b. The importance of the GAP-percentage (% from above) in function of the

client’s business value. [in a scale from 1 to 5 where 1 = ‘totally unimportant’

and 5 = ‘very important’]

c. The number of NEW software connections that has to be made in order to have

the OpenERP communicating with other software. [in numbers]

d. The importance of those new connections to the client in function of his

business value? [on a scale from 1 to 5, where 1 = ‘totally not important’ and 5

= ‘very important’]

e. The difficulty level of creating these new software connections [on a scale from

1 to 5, where 1 = ‘very easy’ and 5 = ‘very hard’]

2. People

a. Number of employees. The number of people working in the company. [in

numbers]

b. Percentage of employees that are actual OpenERP users. [in % of the total

employees]

3. Processes

a. Kind of business. [retail, distribution, production or service]

b. Maturity of company. How long does the company exists? [company ages in

years]

c. The number of physically separated settlements of the company? [in numbers]

d. The number of different departments of the company? [in numbers]

4. Budget

a. The client’s maximum budget. [in euros]

5. Time

a. The client’s maximum time frame for implementation. [in days]

XIX

Bijlage 10: Synthese van de Antwoorden uit ronde 2

(Vervolg op de volgende pagina)

1. Scope Totaal ok % maybe % delete % Extra

a. GAP-percentage. The magnitude of the

functional GAP between the client’s work

flow and the work flow in OpenERP. [ in %]

27 27 100% 0% 0% Data Migration (2)

b. The importance of the GAP-percentage

(% from above) in function of the client’s

business value. [in a scale from 1 to 5

where 1 = ‘totally unimportant’ and 5 =

‘very important’]

27 27 100% 0% 0%

Schaal tot aan mandatory

Strategic objectives

quality (clear) of software requirements specifications (2)

Local laws

c. The number of NEW software

connections that has to be made in order

to have the OpenERP communicating with

other software. [in numbers]

27 24 89% 2 7% 1 4% naam: Interfaces

d. The importance of those new

connections to the client in function of his

business value? [on a scale from 1 to 5,

where 1 = ‘totally not important’ and 5 =

‘very important’]

27 25 93% 2 7% 0%

e. The difficulty level of creating these

new software connections [on a scale from

1 to 5, where 1 = ‘very easy’ and 5 = ‘very

hard’]

27 25 93% 2 7% 0%

The level of willingness of the other legacy solution providers

Infr run on-premise, cloud, cloud local + customer equipements

Priority of objective: Q,T,C

Complexity of customization

Key factor: availability of APIs or at least documentation for the 3rd party

software integration

XX

(Vervolg op de volgende pagina)

2. People

a. Number of employees. The number of

people working in the company. [in

numbers]

27 18 67% 6 22% 3 11%

Maybe, if: 10,100,1000

Experience level of employees (category) (2)

behavioural type of entrepreneur

b. Percentage of employees that are actual

OpenERP users. [in % of the total

employees]

27 17 63% 7 26% 3 11%

Maybe: heeft eerder te maken met workflow

education level of OpenERP users

Client culture (resustance to change)

in combination: # of modules to be used (2)

4 classes of users: employee - full user, employee - occasional user -

employee - not user, portal/limited user - occasional user

Different type of users

XXI

3. Processes

a. Kind of business. [retail, distribution,

production or service]27 24 89% 0% 3 11%

Customers' industry'

Areas of business that need to have OpenERP applied, what modules to

be used and the maturity of each

b. Maturity of company. The company

age. [in years]27 20 74% 5 19% 2 7%

How strict and established are the processes

ISO certified? (2)

Flexibility/adaptation

Matrity of the process

Sophistication of business processes

Methodology implementation like cascade or scrum for example

Management style: mgt by project, non profit, etc.

c. The number of physically separated

settlements of the company. [in

numbers]

27 24 89% 0% 3 11% 1 or many, and than?

d. The number of different departments

of the company. [in numbers]27 23 85% 1 4% 3 11%

4. Budget

a. The client’s maximum budget. [in

euros]27 24 89% 2 7% 1 4%

Client doesn't provide this

indirect

5. Time

a. The client’s maximum time frame for

implementation. [in days]27 25 93% 2 7% 0% Indirect

XXII

Bijlage 11: Finale factorenlijst (ronde 2)

1. Gap:

a. Gap size: The magnitude of the client's required functions missing in an "out-of-

the-box" OpenERP implementation. [ in %]

b. Gap importance: The gravity of the client's required functions missing in an "out-

of-the-box" OpenERP implementation. [in a scale from 1 to 5 where 1 = ‘totally

unimportant’ and 5 = ‘very important’]

c. Gap complexity: The difficulty to customize OpenERP to meet the client's

required functions. [on a scale from 1 to 5, where 1 = ‘very easy’ and 5 = ‘very

hard’]

2. Budget:

The client's maximum budget willing to spend to implement the required

functions. [in euros]

3. Time:

The client's maximum time frame willing to wait for the implementation of the

required functions. [in days]

XXIII

Bijlage 12: Gewichten herschalen

Voorbeeldformule voor a : 𝐴(%) =𝑎

𝑎+𝑏+𝑐+𝑑+𝑒∗ 100%

1) De som van de gewichten op basis van Tabel 15: Het finaal gewicht per factor

𝑎 + 𝑏 + 𝑐 + 𝑑 + 𝑒 =

59,52% + 71,67% + 61,19% + 73,10% + 54,52% = 320%

2) Gewichten normaliseren

𝐴(%) =59,52%

320%∗ 100% = 18,6%

𝐵(%) =71,67%

320%∗ 100% = 22,40%

𝐶(%) =61,19%

320%∗ 100% = 19,21%

𝐷(%) =73,10%

320%∗ 100% = 22,84%

𝐸(%) =54,52%

320%∗ 100% = 17,04%

XXIV

Bijlage 13: Schalen normaliseren

Normalisatie formule

[𝐹𝑎𝑐𝑡𝑜𝑟]′ =[𝐹𝑎𝑐𝑡𝑜𝑟] − �̅�

𝑠

�̅� en 𝒔 voor de factoren GAP size, GAP importance en GAP complexity :

�̅� =𝑦 + 𝑧

2 𝑠 = √

𝑛2 − 1

12

- Gap Size (in %):

�̅� =0 + 100

2= 50 𝑠 = √

1002 − 1

12= √

9999

12= √833,25

- Gap Importance & Gap Complexity (hebben beide een Likert-schaal van 1 – 5)

�̅� =1 + 5

2= 3 𝑠 = √

52 − 1

12= √

24

12= √2

�̅� en 𝒔 voor de factoren Budget en Time :

�̅� =𝑧 − 𝑦

2 𝑠 =

𝑧 − 𝑦

6

- Budget (In Euro):

�̅� =70.000 − 3.600

2= 33.200 𝑠 =

70.000 − 3.600

6= 11.066,67

- Time (In maanden):

�̅� =7 − 0,58

2= 3,21 𝑠 =

7 − 0,58

6= 1,07

to customize odoo or not? a decision support...

Documents