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
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
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
I
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
II
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
III
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.1. Ontvangen van de antwoorden ...................................................................................................... 24 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.1. Ontvangen van de antwoorden ...................................................................................................... 26 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
IV
Afkortingen ERP
Enterprise Resource Planning
MRP
Manufacturing Requirements Planning
MRP II
Manufacturing Resources Planning
BPR
Business Process Re-engineering
OOTB
Out-Of-The-Box
V
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
VI
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
VII
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 ERPsysteem, 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
1
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.
2
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 ERPsysteem 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.
3
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 ERPsysteem 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.
4
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).
5
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)
6
Voordeel
Dankzij…
Zichtbare, up to date en niet-redundante informatie Verbeterde doorlooptijd van orders Verkorte tijd die nodig is om financiële periodes af te sluiten Verlaging operationele kosten (inventaris, werkkrachten, materialen) Sneller kunnen reageren op vragen van klanten Standaardisatie van processen Aanbod-vraagketen
De centrale database die live update De integratie over departementen heen
Gedeeltelijke of volledige automatisatie
Het vastleggen van de processen 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 ERPleverancier. 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 ERPsysteem. De kosten voor het bedrijf stijgen dus samen met de duurtijd van de implementatie (4). Nadeel Kostprijs Sterke afhankelijkheid van de leverancier Implementatietijd
Doordat… Licentie-, implementatieen onderhoudskosten. De kostprijs te groot is om snel te veranderen Bijvoorbeeld werknemers nog getraind moeten worden
Tabel 2: Nadelen van ERP
7
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.
8
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.
9
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.
10
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
11
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 ERPsysteem 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).
12
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 13
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 klant- en 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: 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?
Ter herinnering, Odoo is het Belgische Open Source ERP-pakket waarrond dit onderzoek wordt opgezet.
14
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.
15
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). Janeen-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 16
experten namelijk de mogelijkheid om te reflecteren op de door hun gegeven antwoorden in een eerdere ronde van het onderzoek (52).
Bevragingsron de
Nieuwe bevraging opstellen
Antwoorden ontvangen
Antwoorden verwerken en synthetiseren
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.
17
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 Odoosysteem. 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
18
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. 19
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.
20
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 2 e 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. 21
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
22
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 23
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.
3.5.1. Ontvangen van de antwoorden 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). Aantal
Partners (N)
Partners (%)
Landen (N)
Landen (%)
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.
24
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 2 e fase kan nu gegeven worden. In deze fase van de Ranking Delphi studie wordt de belangrijkheidsgraad van 25
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%.
3.6.1. Ontvangen van de antwoorden 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. Aantal
Partners (N)
Partners (%)
Landen (N)
Landen (%)
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.
26
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: 21
1 𝐺𝑗 = ∗ ∑ 𝐺𝑖𝑗 21 𝑖=1
𝐺𝑗 = Gemiddelde finaal gewicht voor factor j 𝐺𝑖𝑗 = Gewicht gegeven door expert i aan factor j
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
27
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.
28
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 29
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 30
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.
31
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. ).
32
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 Odooimplementator 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.
33
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 Odoopakket 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
34
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: 35
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 Odoosysteem 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.
36
Verdeling Factor
Scope
People
Schaal
Aanleiding
GAP Size GAP Importance Number of NEW software connections to be created Impotance of NEW connections Difficulty level of creating those connections
In % [1 – 5] In Numbers
d,j f,q o
[1 – 5] [1 – 5]
n
Number of employees Percentage of Odoo users
In Numbers % of employees
p p
Kind of business Processes Maturity of company Number of Physically separated settlements Number of different departments Budget Time
Production, service, h retail, distribution In ages (r,s) In Numbers i In Numbers
k
Maximum budget
In €
a
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-
37
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 Odoogebruikers 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.
38
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.
39
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…”.
40
Verdeling Factor
Scope
People
Akkoord
Opmerking
Niet akkoord
GAP Size GAP Importance Number of NEW software connections to be created Impotance of NEW connections Difficulty level of creating those connections
100% 100%
0% 0%
0% 0%
89%
7%
4%
93%
7%
0%
93%
7%
0%
Number of employees Percentage of Odoo users
67% 63%
22% 26%
11% 11%
89% 74%
0% 19%
11% 7%
89%
0%
11%
85%
4%
11%
Maximum budget
89%
7%
4%
Maximum time frame
93%
7%
0%
Kind of business Maturity of company Processes Number of Physically separated settlements Number of different departments Budget Time
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). 41
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 Odoosysteem 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 42
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 43
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
Gap
Finale Factoren
Recht evenredig met
GAP Size
Customization
GAP Importance
Customization
Gap Complexity
OOTB
(=Scope)
Budget
Maximum budget
Customization
Time
Maximum time frame
Customization
Factoren die hierin vervat zitten - Number of NEW software connections to be created - Importance of NEW connections - Number of employees - Percentage of Odoo users - Kind of business - Maturity of company - Difficulty level of creating NEW connections - Number of Physically separated settlements - Number of different departments
Tabel 14: Finale factorenlijst
44
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 1 e 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 45
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.
Gap Complexity
Gewichten (%) Figuur 2: Gewichtenverdeling Gap Size
]90-100]
]80-90]
]70-80]
]60-70]
]50-60]
]40-50]
]30-40]
]20-30]
]0-10]
8 7 6 5 4 3 2 1 0
]10-20]
]80-90]
]90-100]
]70-80]
]60-70]
]50-60]
]40-50]
]30-40]
]20-30]
]10-20]
Aantal antworoden
8 7 6 5 4 3 2 1 0
]0-10]
Aantal antwoorden
Gap Size
Gewichten (%) 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 46
Budget
Gewichten (%)
]90-100]
]80-90]
]70-80]
]60-70]
]50-60]
]40-50]
]30-40]
]20-30]
]0-10]
]10-20]
]80-90]
8 7 6 5 4 3 2 1 0
]90-100]
]70-80]
]60-70]
]50-60]
]40-50]
]30-40]
]20-30]
]10-20]
Aatnal antwoorden
8 7 6 5 4 3 2 1 0
]0-10]
Aantal antwoorden
Gap Importance
Gewichten (%)
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.
]90-100]
]80-90]
]70-80]
]60-70]
]50-60]
]40-50]
]30-40]
]20-30]
]10-20]
8 7 6 5 4 3 2 1 0
]0-10]
Aantal antwoorden
Time
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). 47
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: 48
18,6 % ∗
[𝐺𝑆]−50
[𝐺𝐼 ]−3
√
[𝐵]−33.200 11.066,67
+ 22,40 % ∗ 833,25
+ 17,04% ∗
[𝑇 ]−3,21 1,07
√2
− 19,21 % ∗
[𝐺𝐶 ]−3 √2
+ 22,84 % ∗
=𝑊
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 GAP Size GAP Importance Gap Complexity Maximum budget Maximum time frame
Recht evenredig met
Schaling
Customization Customization OOTB Customization
0 - 100 1 (= onbelangrijk) – 5 (=zeer belangrijk) 1 (=zeer gemakkelijk) – 5 (=zeer complex) €0 - …
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-Odooimplementatie 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.
49
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: 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? 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. 50
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 51
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.
52
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-shareupdate-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%2Fcorporateen%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. I
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.
II
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/thelong-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.
III
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. IV
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.
V
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]
VI
Bijlage 2: Herinneringsmail Fase 1: Ronde 1 Dear OpenERP expert,
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]
VII
Bijlage 3: Bevragingsmail Fase 1: Ronde 2 Dear OpenERP expert,
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] VIII
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]
IX
Bijlage 4: Herinneringsmail Fase 1: Ronde 2 Dear OpenERP expert,
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 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]
X
Bijlage 5: Bevragingsmail Fase 2 Dear OpenERP expert, 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-ofthe-box" OpenERP implementation. Weight :
b. Gap importance: The gravity of the client's required functions missing in an "outof-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:
XI
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]
XII
Bijlage 6: Herinneringsmail Fase 2 Dear OpenERP expert, 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 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]
XIII
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 ... ) XIV
o o o o
o
o o o
(custom) Point of Sale multiple (custom) Company on several sites (custom)Be able to customized process and reports (flexibility) (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. 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. 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 The businesses for which we have customized the application usually have very specific requirements. 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 reencoding. 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
XV
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-thebox. 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
XVI
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)
XVII
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]
4.
c.
The number of physically separated settlements of the company? [in numbers]
d.
The number of different departments of the company? [in numbers]
Budget a.
5.
The client’s maximum budget. [in euros]
Time a.
The client’s maximum time frame for implementation. [in days]
XVIII
Bijlage 10: Synthese van de Antwoorden uit ronde 2 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 (% from above) in business value. [in where 1 = ‘totally ‘very important’]
of the GAP-percentage function of the client’s a scale from 1 to 5 unimportant’ and 5 =
Totaal
ok
%
27
27
100%
maybe
%
0%
27
27
100%
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%
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%
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%
delete
0%
2
7%
1
%
Extra
0%
Data Migration (2)
0%
Schaal tot aan mandatory Strategic objectives quality (clear) of software requirements specifications (2) Local laws
4%
naam: Interfaces
0%
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
(Vervolg op de volgende pagina)
XIX
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]
27
27
18
17
67%
63%
6
7
22%
26%
3
3
11%
Maybe, if: 10,100,1000 Experience level of employees (category) (2) behavioural type of entrepreneur
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
(Vervolg op de volgende pagina)
XX
3.
Processes
a. Kind of business. [retail, distribution, production or service]
b. Maturity of age. [in years]
company. The company
27
24
89%
11%
Customers' industry' Areas of business that need to have OpenERP applied, what modules to be used and the maturity of each
19%
2
7%
0%
3
11%
1 or many, and than?
1
4%
3
11%
89%
2
7%
1
4%
Client doesn't provide this indirect
93%
2
7%
0%
Indirect
20
74%
c. The number of physically separated settlements of the company. [in numbers]
27
24
89%
d. The number of different departments of the company. [in numbers]
27
23
85%
27
24
27
25
5
Budget
a. The euros] 5.
3
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.
27
4.
0%
client’s
maximum
budget.
[in
Time
a. The client’s maximum time frame for implementation. [in days]
XXI
Bijlage 11: Finale factorenlijst (ronde 2)
1. Gap: a. Gap size: The magnitude of the client's required functions missing in an "out-ofthe-box" OpenERP implementation. [ in %]
b. Gap importance: The gravity of the client's required functions missing in an "outof-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]
XXII
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% ∗ 100% = 18,6% 320%
𝐵(%) =
71,67% ∗ 100% = 22,40% 320%
𝐶 (%) =
61,19% ∗ 100% = 19,21% 320%
𝐷(%) =
73,10% ∗ 100% = 22,84% 320%
𝐸 (%) =
54,52% ∗ 100% = 17,04% 320%
XXIII
Bijlage 13: Schalen normaliseren Normalisatie formule [𝐹𝑎𝑐𝑡𝑜𝑟]′ =
[𝐹𝑎𝑐𝑡𝑜𝑟] − 𝑋̅ 𝑠
̅ en 𝒔 voor de factoren GAP size, GAP importance en GAP complexity : 𝑿
𝑋̅ = -
𝑠= √
𝑛2 − 1 12
Gap Size (in %):
𝑋̅ = -
𝑦+𝑧 2
0 + 100 = 50 2
𝑠= √
1002 − 1 9999 =√ = √833,25 12 12
Gap Importance & Gap Complexity (hebben beide een Likert-schaal van 1 – 5)
𝑋̅ =
1+5 =3 2
𝑠= √
52 − 1 24 = √ = √2 12 12
̅ en 𝒔 voor de factoren Budget en Time : 𝑿 𝑋̅ = -
𝑠=
𝑧−𝑦 6
Budget (In Euro): 𝑋̅ =
-
𝑧−𝑦 2
70.000 − 3.600 = 33.200 2
𝑠=
70.000 − 3.600 = 11.066,67 6
Time (In maanden): 𝑋̅ =
7 − 0,58 = 3,21 2
𝑠=
7 − 0,58 = 1,07 6
XXIV
