Met een ERP-pakket gedoemd tot inflexibiliteit?

Met een ERP-pakket gedoemd tot inflexibiliteit? Joep Hautus 5648386 Thesis Master Informatiekunde Programma Business Information Systems

Universiteit van Amsterdam Faculteit Natuurwetenschappen, Wiskunde en Informatica en Faculteit Economie en Bedrijfskunde

De ERP-pakket route: van een flexibele Barbapapa tot de solide steen

Eindversie: 3 maart 2009 Begeleider: Jan Truijens

Fotoverantwoording voorpagina: Delen van de foto op de voorpagina zijn afkomstig van: http://www.blueballoon.dk/site/images/images/barbapapa_sparebøsse.jpg Barbapapa is een copyright trademark van A.T. .

2

Voorwoord Het laatste onderdeel van de master Informatiekunde aan de Universiteit van Amsterdam is het schrijven van een masterthesis. Door de ervaring tijdens stages kwam ik in aanraking met ERPpakketten. Een stukje “wondersoftware”, aangezien het de hele organisatie weet te automatiseren. De claim dat deze software flexibel zou zijn heeft mij op het idee gebracht om hier onderzoek naar te doen. In de praktijk bleek namelijk dat er vele haken en ogen aan het ERP-pakket zitten. Het veranderen gaat helemaal niet zo eenvoudig als de leverancier beweert. Helaas komt de organisatie hier pas achter als het ERP-pakket al voor een lange tijd geïmplementeerd is. De “flexibele Barbapapa”, wat het ERP-pakket door al haar mogelijkheden ooit was, is nu een “solide steen” geworden die maar zeer moeilijk uit de organisatie te verwijderen is. Ik wil allereerst mijn begeleider, de heer Jan Truijens, bedanken voor zijn begeleiding bij deze masterthesis. Daarnaast wil ik alle geïnterviewde personen bedanken voor hun bijdragen. De interviews hebben dit onderzoek verrijkt. Verder wil ik mijn ouders en mijn vriendin bedanken voor de steun en het vertrouwen die ik heb gekregen.

3

0. Samenvatting In deze masterthesis wordt onderzoek gedaan naar ERP-pakketten en de maatregelen voor het behoud van organisatorische flexibiliteit. De onderzoeksvraag van deze masterthesis luidt: " Welke maatregelen zijn noodzakelijk om een door legacy verouderd ERP-pakket te kunnen vervangen zodat de organisatorische flexibiliteit behouden blijft?". ERP-pakketten worden gebruikt om processen te automatiseren. ERP-pakketten bieden een meerwaarde, omdat er integratie wordt bereikt. Hierdoor kan men efficiënter werken en is er meer (management)informatie beschikbaar. Drie soorten ERP-pakketten worden in de thesis onderscheiden: speciaal ontwikkelde, branchespecifieke en generieke ERP-pakketten. De verschillen zitten met name in de businessmodellen die ondersteund worden. Naarmate de organisatie verandert, moet het ERP-pakket mee veranderen. Er worden losse modulen en applicaties op het ERP-pakket aangesloten. Omdat het ERP-pakket nog de oude processen en het oude businessmodel ondersteunt, worden deze in de organisatie bestendigd. Hierdoor ontstaat business-legacy en wordt het nastreven van nieuwe business-requirements zeer lastig. De organisatie is door beiden vormen van legacy dus minder flexibel. Zowel uit de literatuur als de praktijk blijkt dat de flexibiliteit van het ERP-pakket en de organisatie afneemt naarmate het ERP-pakket uitgebreider wordt. Door legacy te vermijden kan de organisatie flexibeler blijven. ICT-legacy kan voorkomen worden door de volgende punten in acht te nemen: vermijd “spaghetticode” (alleen bij zelfgebouwde ERP-pakketten), zorg voor goede documentatie, zorg voor voldoende gekwalificeerd personeel, zorg voor een goede performance en adaptatievermogen door het plegen van regelmatig onderhoud. Business-legacy kan niet zozeer voorkomen worden, aangezien er tijdens de implementatie van het ERP-pakket nu eenmaal gekozen moet worden voor een businessmodel en de daarbij behorende processen. Er kan echter wel achterhaald worden welke processen er op dit moment gebruikt worden door onder andere het gebruik van de huidige documentatie, program slicing en het evalueren met betrokken werknemers. Deze methoden zijn van toepassing voor zowel zelfontwikkelde ERP-pakketten als voor gekochte ERP-pakketten. Het nadeel van deze methoden is dat het zeer tijdrovend is om de methoden te doorlopen. Om het ERP-pakket en processen flexibel te houden kan er gebruik worden gemaakt van de variëteitbenadering. Het is echter tijdrovend om in te voeren en is vaak alleen mogelijk bij maatwerk ERP-pakketten. 4

Uit de cases komen de volgende adviezen om het ERP-pakket flexibel te houden: gebruik standaarden, gebruik een open databasestructuur, creëer schaalbaarheid, behoud de kennis van het systeem en maak gebruik van de Service Oriented Architecture.

5

Inhoud Voorwoord .............................................................................................................................................................. 3 0.

Samenvatting.................................................................................................................................................. 4

1.

Inleiding.......................................................................................................................................................... 8 1.1 ICT in de organisatie ..................................................................................................................................... 8 1.2 Software-integratie door middel van een ERP-pakket ................................................................................. 9 1.3 Standaard ERP-pakketten ........................................................................................................................... 11 1.4 Het uitbreiden van het ERP-pakket............................................................................................................. 13 1.5 Veroudering van het ERP-pakket................................................................................................................ 15 1.6 ERP-pakketten leiden tot inflexibiliteit ....................................................................................................... 18 1.7 Definities van belangrijkste begrippen ....................................................................................................... 20

2.

Probleemstelling........................................................................................................................................... 23 2.1 De aanleiding van het onderzoek ............................................................................................................... 23 2.2 Relevantie van het onderzoek .................................................................................................................... 24 2.3 Doelstelling ................................................................................................................................................. 24 2.4 Vraagstelling ............................................................................................................................................... 25 2.5 Type onderzoek .......................................................................................................................................... 27 2.6 Onderzoeksmodel....................................................................................................................................... 28 2.7 Onderzoeksmethode .................................................................................................................................. 28

3.

ERP-pakketten .............................................................................................................................................. 30 3.1 Oorsprong van ERP-pakketten.................................................................................................................... 30 3.2 Enkele definities van een ERP-pakket......................................................................................................... 33 3.3 Wanneer is het een pakket? ....................................................................................................................... 36 3.4 ERP-pakketten en het gebruik in organisaties ............................................................................................ 38

4.

ERP-pakketten in dit onderzoek ................................................................................................................... 40 4.1 Soorten ERP-pakketten............................................................................................................................... 40 4.2 Het doel van ERP-pakketten ....................................................................................................................... 43 4.3 Verschillende niveaus van ondersteuning .................................................................................................. 44 4.4 Gevolgen van de ondersteuningsniveaus ................................................................................................... 48

5.

Legacy........................................................................................................................................................... 50 5.1 ICT-legacy.................................................................................................................................................... 50 5.2 Volwassenheid ERP-pakketten en ICT-legacy ............................................................................................. 53 5.3 Maatregelen tegen ICT-legacy .................................................................................................................... 55 5.4 Business-legacy ........................................................................................................................................... 57 5.5 Maatregelen tegen business-legacy ........................................................................................................... 59

6

6.

Flexibiliteit .................................................................................................................................................... 62 6.1 Wat is flexibiliteit? ...................................................................................................................................... 62 6.2 Het belang van flexibiliteit voor de organisatie .......................................................................................... 64 6.3 Flexibiliteitbehoud ...................................................................................................................................... 66

7.

Het gebruik van ERP-pakketten in de praktijk.............................................................................................. 69 7.1 Interviewprotocol ....................................................................................................................................... 70 7.2 Case Paradigit ............................................................................................................................................. 71 7.3 Case Blackbox ............................................................................................................................................. 74 7.4 Case Schuitema........................................................................................................................................... 78 7.5 Case Kamer van Koophandel Nederland .................................................................................................... 81 7.6 Conclusies gebruik ERP-pakketten in de praktijk........................................................................................ 85

8.

Conclusie ...................................................................................................................................................... 87 8.1 Algehele conclusie ...................................................................................................................................... 87 8.2 Antwoord op de onderzoeksvraag.............................................................................................................. 91

9.

Vervolgonderzoek ........................................................................................................................................ 97

10.

Literatuuroverzicht .................................................................................................................................. 99

11.

Bijlagen................................................................................................................................................... 107

Bijlage A: Vragenlijst ....................................................................................................................................... 107 Bijlage B: Antwoorden Paradigit..................................................................................................................... 110 Bijlage C: Antwoorden Blackbox..................................................................................................................... 115 Bijlage D: Antwoorden Schuitema .................................................................................................................. 120 Bijlage E: Antwoorden Kamer van Koophandel Nederland ............................................................................ 125

Lijst met afbeeldingen Afbeelding 1: Het model van Koop et al. (2003) ............................................................................................ 8 Afbeelding 2: Type onderzoek...................................................................................................................... 27 Afbeelding 3: Onderzoeksmodel .................................................................................................................. 28 Afbeelding 4: Value-chain van Porter (1985) ............................................................................................... 31 Afbeelding 5: Schematische weergave businessrules extraction................................................................. 60 Afbeelding 6: Weergave ERP-omgeving Blackbox........................................................................................ 75 Afbeelding 7: ERP-omgeving Kamer van Koophandel Nederland ................................................................ 82

7

1. Inleiding 1.1 ICT in de organisatie

De visie, een missie en een strategie binnen organisaties worden gedragen door middel van de organisatiedoelen (Koop et al., 2003). De auteurs zeggen dat deze organisatiedoelen opgesplitst kunnen worden in processen. Deze processen worden in het model (zie afbeelding 1) onderverdeeld in een organisatiecomponent en een ICT-component. Het onderstaand model geeft de samenhang weer tussen de visie, de strategie, de organisatiedoelstellingen, de organisatie en ICT.

Afbeelding 1: Het model van Koop et al. (2003)

Zoals het model aangeeft, biedt ICT ondersteuning aan de processen van een organisatie. Zonder informatie en communicatie is het niet of slechts ten dele mogelijk om een proces te volgen, te besturen of te optimaliseren. Software kan deze informatie en communicatie voor processen ondersteunen door procedures te automatiseren. Volgens Brun et al. (2006) is technologie de enabler voor snelle verandering. Alhoewel technologie handmatige acties kan versnellen, hoeft dit nog niets te zeggen over de snelheid waarmee er veranderd kan worden. ICT richt zich op de organisatieprocessen om de organisatiedoelstellingen te halen (Koop et al., 2003). De informatie die 8

zich in het ICT-component bevindt is van onschatbare waarde maar draagt niet direct toewijsbaar iets bij aan de waardecreatie van een organisatie. Huizing (2007) noemt dat een organisatie door deze informatie kwalitatieve doelstellingen kan hebben, maar deze niet tot zeer moeilijk kwantificeerbaar kan maken. De waarde van informatie is groot, maar is niet tot zeer moeilijk te bepalen. Een organisatie kan de software voor procesondersteuning zelf ontwikkelen of aanschaffen. Het zelf ontwikkelen van software heeft als voordeel dat de software exact op maat kan worden gemaakt. Specifieke wensen voor software kunnen op deze manier gehonoreerd worden. De kosten voor het maken van software zijn echter hoog. Daarnaast moet de technische kennis aanwezig zijn om software te kunnen ontwikkelen. Deze kennis inhuren behoort tot de mogelijkheden, maar leidt eveneens tot kosten. Reeds ontwikkelde software vereist eveneens voldoende kennis om het succesvol te kunnen gebruiken: alhoewel de software al ontwikkeld is, zal deze toch geconfigureerd moeten worden om het proces te kunnen ondersteunen (Vogt, 2002). Vanzelfsprekend zijn hier ook kosten mee gemoeid.

1.2 Software-integratie door middel van een ERP-pakket

Een softwareprogramma ter ondersteuning van een proces richt zich op één proces en houdt geen rekening met de ondersteuning door andere softwareprogramma’s van andere procedures of processen. Het aanschaffen van meerdere softwareprogramma's die andere procedures ondersteunen leidt eveneens niet vanzelf tot integratie (Koop et al., 2003). Integratie is wenselijk, omdat de integratie leidt tot een efficiëntere afhandeling van processen. De software kan "rekening houden" met de staat van andere processen. Hierdoor kunnen andere taken of processen uitgevoerd worden die afhankelijk van elkaar zijn, zonder tussenkomst van een medewerker. Integratie kan worden omschreven als (Barrett et al., 1996): een proces waarbij meerdere softwaremodules (programma’s, subprogramma’s, collecties van subprogramma’s) gemaakt zijn om samen te werken. Een voorbeeld is de koppeling tussen een administratieve procedure en een verkoopprocedure: bij een nieuwe verkoop kan de software constateren dat de klant een te hoog bedrag open heeft staan, zodat de verkoop niet door kan gaan tot de klant het bedrag betaald heeft. Zonder integratie moet iedere verkoper handmatig controleren of een klant een te hoog bedrag open heeft staan. Het is dan een medewerker die de coördinatie heeft over beide processen en hierbij akkoord geeft voor de transactie. 9

Integratie moet een vorm van coördinatie bevatten om een afweging te kunnen maken. Coördinatie wordt gedefinieerd als (Malone et al., 1994) “Het managen van afhankelijkheden tussen activiteiten”. Het gebruik van software leidt op zichzelf natuurlijk niet automatisch tot integratie en coördinatie. De volgende hypothese geeft dit weer. H1: Software leidt niet automatisch tot integratie en coördinatie In het bovenstaande voorbeeld blijkt dat de software processen nog beter kan ondersteunen indien er integratie plaats vindt. De foutmarge van controles en invoer wordt lager, doordat de software zonder tussenkomst controles kan uitvoeren. De efficiëntie wordt hierdoor groter (Poston et al., 2000). De rapportagemogelijkheden van geïntegreerde software zijn eveneens hoger, doordat er over meerdere processen tegelijk en in samenhang gerapporteerd kan worden in plaats van over een enkel proces (Poston et al., 2000). Manufacturing resource planning (MRP) pakketten bieden integratie door onder andere fabricageprocessen en inkoopprocessen aan elkaar te koppelen. Alhoewel dit een goede stap is naar business-procesintegratie, is het streven om alle processen te integreren om zodoende meer integratie te verkrijgen. De logische opvolger van MRP is een pakket dat nog meer businessprocessen kan betrekken door middel van modules die samenwerken. Enterprise resource planning (ERP) pakketten bieden de mogelijkheid om business-procesintegratie toe te passen binnen de organisatie (Ragowski et al., 2002). Een organisatie die producten fabriceert, heeft nu naast businessprocesintegratie van fabricage- en inkoopprocessen eveneens business-procesintegratie bereikt van administratieve processen en logistieke processen. De mate van integratie is overigens afhankelijk van de keuze die het management maakt. Het management kan bepalen tot in welk detail dit gebeurd. Eveneens belangrijk is wat de mogelijkheden zijn. Niet alles wat het management wil is te bewerkstelligen. Daarnaast is de mate afhankelijk van integratie afhankelijk van het gekozen pakket. Ragowski et al. (2002) noemt dat ERP-gebruikers een hogere performancewinst behalen dan niet ERP-gebruikers. Deze performancewinst wordt behaald doordat handmatige controles van bijvoorbeeld debiteuren niet meer uitgevoerd hoeven te worden. Dit onderzoek richt zich op ERPpakketten en niet op MRP-pakketten. H2: geïntegreerde software leidt tot meer functionaliteit ten opzichte van niet geïntegreerde software Een ERP-pakket kan worden gedefinieerd als (Bakry et al., 2005): ‘integrated information system software comprised of several modules that share a central database, designed to automate business processes across the enterprise’. 10

ERP wordt om verschillende redenen geïmplementeerd. Bakry et al. (2005) en Poston et al. (2000) noemen allen dat een ERP-pakket leidt tot integratie om een hogere efficiëntie te bereiken. Door deze hogere efficiëntie noemen de auteurs dat de kosten gereduceerd worden. Alle auteurs noemen dat een ERP-pakket de mogelijkheid biedt om E-business activiteiten te ondersteunen. De vraag hierbij is of een organisatie hier wel geschikt voor is. Indien de bedrijfsprocessen dit niet toelaten, dan kan het ERP-pakket dit niet ineens bewerkstelligen. Een andere reden voor de implementatie van een ERP-pakket is volgens Bakry et al. (2005) de ondersteuning van modulaire architecturen. Hiermee wordt het eenvoudig kunnen toevoegen van nieuwe functionaliteiten bedoeld. Poston et al. (2000) noemen dat de flexibiliteit verhoogd wordt, omdat nieuwe functionaliteiten snel aangeschaft kunnen worden. Op welke termijn wordt overigens niet genoemd in het artikel. De vraag is of het ERP-pakket over 20 jaar nog steeds uitgebreid kan worden. Poston et al. (2000) noemen dat een ERPpakket een betere besluitvorming oplevert, doordat er juiste en tijdige informatie beschikbaar is. De klanttevredenheid kan verhoogd worden, doordat er meer integratie en samenhang van de processen is. Nonaka et al. (1995) noemen dat een ERP-pakket de impliciete kennis van de organisatie expliciet maakt.

1.3 Standaard ERP-pakketten

Voor ERP-pakketten geldt dat ze zelf ontwikkeld kunnen worden, of als een standaardpakket aangeschaft kunnen worden. Een ERP-pakket moet meerdere processen en procedures ondersteunen en daarnaast integratie tussen deze processen en procedures bewerkstelligen. Een ERP-pakket is hierdoor complexer, waardoor er meer parameters ingesteld moeten worden om de modulen met elkaar samen te laten werken(Ragowski et al. 2002). Standaardpakketten bieden een oplossing die universeel inzetbaar is, zodat diverse branches er gebruik van kunnen maken (Vogt, 2002). Het omvat een scala aan standaardprocessen, zoals inkoop-, verkoop- en administratieve processen. Er zijn vele leveranciers van ERP-systemen, zodat de keuze niet eenvoudiger is. De brede toepasbaarheid van het standaardpakket heeft tot gevolg dat er vele parameters ingesteld moeten worden (Vogt, 2002). Deze parameterinstelling moet consistent zijn en aan de hand van een business-procesmodel gedaan worden. Het is geen kwestie van louter parametriseren tot het werkt. Een goed model van de business-processen is noodzakelijk aangezien het ERP-pakket dit moet ondersteunen en niet creëren. Als deze parameters ingesteld zijn, kunnen gegevens tussen verschillende processen uitgewisseld worden en is er op deze wijze een vorm van 11

integratie bereikt. De coördinatie tussen de verschillende modulen is veelal een interpretatie van de ERP-leverancier. Door te kiezen voor een bepaald pakket, wordt er dus vaak gekozen voor een manier van coördineren. Er wordt dus gekozen voor (de aanschaf van) een specifieke informatiearchitectuur. Pollock et al. (2003) noemt dat er weinig rekening wordt gehouden met zogenaamde "niet-standaard" organisaties, waar een standaardpakket lastig te implementeren is. De vraag is of een organisatie als "standaard" kan worden aangemerkt en of er überhaupt sprake is van een standaardorganisatie. Benders et al. (2006) voorzien dezelfde problemen. De auteurs noemen dat de organisatie zich aan moet passen aan de standaarden die zich in het ERP-pakket bevinden, anders zal het ERP-pakket tot problemen leiden. Als voorbeeld van een niet-standaard organisatie kan een school genoemd worden. Scholen hebben geen strak te plannen productieprocessen, maar moeten docenten inplannen om leerlingen te kunnen doceren. Over enkele jaren moeten de leerlingen met een diploma naar huis kunnen gaan. De planning van grondstoffen naar een eindproduct vereist een andere aanpak dan die van het behalen van een diploma. Loeffen et al. (2000) noemen dat Business-, Business Model-, Software-, en IT-Platform architectuur sterk verweven zijn en elkaar beïnvloeden. Een ERP-pakket dat niet gemaakt is voor bijvoorbeeld de dienstverlening gaat vroeg of laat tot problemen leiden. Er zijn vele leveranciers van ERP-systemen, zodat de keuze er niet eenvoudiger op wordt. Gefen (2004) noemt vijf leveranciersrelaties die de keuze voor de leverancier van een ERP-pakket kunnen beïnvloeden: - Vertrouwen in de ERP-leverancier; - Ervaring met de ERP-leverancier op het gebied van procesondersteuning; - Gedeelde culturele karakteristieken met de ERP-leverancier; - Het het in het bezit hebben van relevante certificeringen van de ERP-leverancier; - Het ervaren gebruikersgemak van het ERP-pakket. Naast de zojuist genoemde relaties noemen Wang et al. (2006) de afkomst van de ERP-leverancier. Dit onderzoek richt zich overigens niet op hoe de keuze tot stand komt voor een geschikt ERP-pakket.

12

1.4 Het uitbreiden van het ERP-pakket

Kelly et al. (1999) geven aan dat verandering veroorzaakt wordt door globalisatie, door de transformatie van industrieën naar een kennis- en informatie-economie en doordat de organisatiestructuur verandert van een hiërarchische naar een minder hiërarchische en meer gedecentraliseerde organisatie. Nieuwe technologieën of nieuwe mogelijkheden leiden tot de wens om nieuwe modulen toe te voegen (Rostambeik et al., 2007). Er is sprake van een technologiepush: doordat er nieuwe techniek beschikbaar is willen organisaties dit graag implementeren. Anderzijds is er een technologiepull: klanten vragen van organisaties om nieuwe technologie te gebruiken. Als voorbeeld kan een webshop-module genoemd worden, die real-time een voorraadcontrole moet kunnen uitvoeren. Extended ERP, een ERP-pakket dat interorganisationeel kan werken, maakt het mogelijk om gegevens elektronisch binnen onderdelen van organisaties uit te wisselen, zodat interne ERP-functionaliteiten zich kunnen richten op leveranciers en eindgebruikers (Bakry et al., 2005). Services kunnen op deze manier afgenomen en desgewenst aangepast worden, bijvoorbeeld door middel van webservices of door “user toolkits” (Jeppesen, 2005). De nieuwe technologieën kunnen leiden tot verdergaande integratie. Dit moet ook wel, aangezien de klant steeds kieskeuriger wordt (Ho et al., 2002). Real-time verwerking is cruciaal om functionaliteiten voor klanten aan te kunnen bieden, om over actuele gegevens te kunnen beschikken. De vraag naar systemen die tussen organisaties samenwerken, neemt steeds meer toe (Emmerich et al., 2007). Johne (1998) meent dat het hebben van een geschikte infrastructuur voor deze systemen cruciaal is. Heinhuis et al. (2007) noemen dat multichanneling de norm is in het leveren van services. Het mogelijk maken van het bereik van klanten via andere kanalen leidt tot het wisselen van kanalen. Multichanneling wordt gezien als een coördinatieprobleem (De Vries, 2005). Multichanneling biedt een op maat gemaakte service voor klanten. In het framework dat De Vries (2005) geeft, worden de drie dimensies kanaal, proces en markt getoond. Een klant kan via diverse kanalen op verschillende markten de verschillende processen van een verkoop doorlopen. Klantgedrag is hierdoor moeilijk te voorspellen, daar klanten via diverse kanalen diverse services kunnen afnemen. Een belangrijke reden voor het gebruik van multichanneling is onder andere dat de klant diverse verwachtingen heeft bij een kanaal (De Vries,2005). Het managen van deze verwachtingen per kanaal is daarom wenselijk. Een kanaal kan volledig gerepliceerd worden, zodat de service op beide kanalen exact hetzelfde is. Echter, niet ieder kanaal is geschikt voor volledige replicatie, waardoor managementkeuzes gemaakt moeten worden (De Vries 2005). Het kunnen leveren van diensten via meerdere kanalen vereist een ERP-pakket dat

13

betrouwbare en juiste informatie kan leveren. Dit onderzoek gaat in op generieke ERP-pakketten die interorganisationele functionaliteiten bieden, maar beperkt zich tot de gevolgen voor de interne organisatie en niet de gevolgen voor de externe partijen. Indien uitbreidbaarheid gewenst is voor een ERP-pakket, bijvoorbeeld voor het gebruik van meerdere kanalen, kan er overwogen worden om extra modulen aan te schaffen. Een voorbeeld hiervan is een CRM-module, die contactmomenten met klanten vastlegt. De CRM-module maakt gebruik van dezelfde database als de database die wordt gebruikt voor de andere processen, zodat informatie over bijvoorbeeld aankopen, serviceaanvragen en wanbetalingen gekoppeld wordt. Het CRM-pakket profiteert op deze wijze van de andere processen. In sommige gevallen blijkt dat het ERP-pakket niet meer uit te breiden is met de gewenste functionaliteit. Mogelijke oorzaken hiervan zijn: - De leverancier ondersteunt het pakket niet meer; - De leverancier bestaat niet meer; - De functionaliteit kan niet geïmplementeerd worden door technische/architecturale implicaties; - De functionaliteit bestaat (nog) niet voor het huidige ERP-pakket; - Het gekozen bedrijfsmodel verhindert het uitbreiden van het ERP-pakket. De organisatie kan ervoor kiezen om de verlangde functionaliteit te laten ontwikkelen door een softwaremaker. Door middel van tools en/of omzetters kan de gemaakte software communiceren met de gezamenlijke database, om een vorm van integratie te verkrijgen. Op deze wijze ontstaan losse applicaties naast het ERP-pakket, die afhankelijk zijn van de ERP-pakketdatabase. Applicaties kunnen verweven raken. De oorzaak hiervan is dat de afhankelijkheden deze applicaties met elkaar verbinden. Alhoewel applicaties in zekere mate geïntegreerd zijn doordat er gegevens uitgewisseld worden, wordt het aantal afhankelijkheden groter. H3: integratie leidt tot meer afhankelijkheden

14

1.5 Veroudering van het ERP-pakket

ERP-pakketten kunnen verouderd raken, bijvoorbeeld omdat de functionaliteiten ontoereikend zijn of omdat de software niet meer door updates actueel wordt gehouden door de leverancier (Beatty et al., 2006). In dat geval kan een organisatie overwegen om een nieuw ERP-pakket aan te schaffen. Dit is een kostbare, risicovolle en tijdrovende aangelegenheid, omdat het om vervanging van meerdere, geïntegreerde modulen gaat die geïntegreerd zijn in plaats van slechts een losse module of applicatie die niet geïntegreerd is. Het ERP-pakket bestaat immers niet meer alleen uit de oorspronkelijk aangeschafte modulen, maar is verweven geraakt met andere applicaties om extra functionaliteit te verkrijgen. Die applicaties zijn geschikt gemaakt om te kunnen werken in de huidige architectuur en de betreffende aanpassingen leiden tot extra afhankelijkheden van de architectuur. Het verwijderen van een module kan ertoe leiden dat een op die module geënte applicatie niet meer naar behoren werkt. Daarnaast dient zich een ander probleem aan: documentatie van het systeem is vaak niet bijgewerkt of in zijn geheel niet aanwezig (Kelly et al., 1999). Zelfs als documentatie beschikbaar is, geeft het nog geen totaalbeeld van alle afhankelijkheden. Het eenvoudig overboord gooien van de oude software is helaas ook niet mogelijk: de organisatie is afhankelijk geworden van de informatie die in de database zit (Vogt, 2002). Het model van Koop et al. (2003) geeft aan dat het ICT-component een onderdeel is van de bedrijfsvoering, en dus essentieel is. De organisatie krijgt te maken met legacy. Legacy wordt in dit onderzoek als volgt gedefinieerd: "Een onderdeel kan als ‘legacy’ worden beschouwd als het getracht wordt te veranderen maar door technische oorzaken en organisatorische afhankelijkheden moeilijk te veranderen is" Legacy blokkeert de migratie van een systeem, omdat oude applicaties data benaderen uit een database, waardoor het niet mogelijk is om de structuur van de data aan te passen zonder dat de logica van de applicaties veranderd wordt (Sneed et al., 2001). Een significante hoeveelheid programma's is gericht op de oude datamodellen, hetgeen de migratie naar nieuwe datamodellen bemoeilijkt (Sneed et al., 2001). Indien informatiesystemen gemigreerd worden naar een nieuwe informatiearchitectuur, dan moeten de business requirements gerepliceerd worden uit deze informatiearchitectuur (Sneed et al., 2001). Thiran et al. (2006) noemt legacy "een probleem van gemixte architecturen die lijden aan heterogeniteit". De oude architectuur en de nieuwe te implementeren architectuur verschillen te veel van elkaar. "De functionele architectuur van

15

verouderde applicaties past niet meer bij de mogelijkheden van de moderne technologie" (Thiran et al., 2006). Kenmerken van legacy zijn (Sommerville, 2000): - Legacy bestaat uit veel regels softwarecode; - Legacysystemen zijn vaak oud; - Legacysystemen maken gebruik van een legacy database, of gebruiken soms helemaal geen databasestructuur; - Legacysystemen werken autonoom en onafhankelijk van andere software. Legacy verhindert veranderingen van de informatievoorziening. Hierdoor staat het eveneens veranderingen in de business requirements in de weg, zoals bijvoorbeeld het gebruik van ebusinessvoorzieningen. Er is een noodzaak om te veranderen, maar diverse oorzaken verhinderen dat dit kan. Legacy kan eveneens ontstaan op metaniveau. Het gekozen bedrijfsmodel van een organisatie kan niet meer eenvoudig gewijzigd worden, bijvoorbeeld doordat processen verweven zijn. Het is in dat geval niet het ERP-pakket dat de legacy veroorzaakt, maar het bedrijfsmodel. Vanzelfsprekend leidt legacy op metaniveau eveneens tot inflexibiliteit. H4: Legacy leidt tot inflexibiliteit De technische oorzaken en organisatorische afhankelijkheden leiden tot complexe situaties. Iets is complex als het boven het cognitieve vermogen van de mens uitstijgt (Langefors, 1995). Indien iets complex is, wordt het overzicht verloren, waardoor niet duidelijk is wat er met het systeem gebeurt indien een component gewijzigd wordt. Complexiteit ontstaat (Backlund, 2002; Phippen et al., 2005): - indien een systeem uit veel componenten bestaan; - indien er veel relaties aanwezig zijn tussen componenten of subsystemen; - de relaties tussen de componenten onderling niet gelijk (asymmetrisch) zijn; - de samenstelling van de componenten verschillend is. Een ERP-pakket voldoet aan alle vier de eigenschappen van complexiteit. Door deze complexiteit ontstaat er legacy (Kelly et al., 1999). Op metaniveau wordt er eveneens voldaan aan de vier eigenschappen van complexiteit. 16

H5: een generiek ERP-pakket leidt tot legacy De oorzaken van de veroudering van een ERP-pakket hangen samen met de wensen voor het vervangen. Doordat businessactiviteiten vernieuwen veroudert de functionaliteit van het ERP-pakket. Een tweede oorzaak is vernieuwde technologie, waardoor de gebruikte technologie vanzelf veroudert. Een derde oorzaak van veroudering is structuurverandering van de informatievoorziening. Doordat applicatierelaties en technische relaties verweven raken, kunnen deze elkaar onder druk zetten (Jin et al., 2007). Dit onderzoek gaat nader in op alle drie de oorzaken van veroudering. Het vernieuwen van een ERP-systeem kan worden gezien als twee gescheiden werelden: enerzijds het legacy-ERP-pakket, anderzijds het nieuwe ERP-pakket dat geïmplementeerd moet worden (Thiran et al., 2006). Het ERP-pakket kan niet in één keer vervangen worden, omdat het ERP-pakket een IT-architectuur is geworden. Het ERP-pakket is immers geen losse applicatie, maar een conglomeraat aan applicaties die samenwerken. Een methode om een ERP-pakket te vervangen is door delen van dit ERP-pakket te isoleren en grondig te onderzoeken. Dit is geen eenvoudige opgave. Daarnaast bestaat de IT-architectuur, waar het legacy ERP-pakket onderdeel van is, niet louter uit softwarecomponenten. Interfaces zijn eveneens onderdeel van de IT-architectuur. De uitbreidingsmogelijkheid van het legacysysteem is eindig (Jacobs, 2005). Hierdoor kan er niet onbeperkt uitgebreid worden. Het ERP-pakket van een organisatie is tijdens de aanschaf geconfigureerd voor het gebruik met de op dat moment in gebruik zijnde business-processen. Als de business requirements wijzigen, worden de procedures en processen aangepast. Echter, het ERP-pakket ondersteunt nog de oude business requirements en dus de verouderde procedures en processen. Het management heeft destijds voor een organisatiemodel en de daarbij behorende instelparameters van het ERP-pakket gekozen. Een verandering van dit vernieuwde organisatiemodel is lastig te bewerkstelligen, aangezien andere instelparameters van het ERP-pakket, behorende bij een ander organisatiemodel, gevolgen kan hebben voor onderdelen die niet gewijzigd moeten worden. Ditzelfde geldt voor het toepassen van een onvoorziene situatie die niet vastgelegd is in het ERP-pakket. Deze situatie moet handmatig, buiten het ERP-pakket om, opgelost worden. De oorzaak hiervan is dat er een uniformiteitsbenadering wordt gehanteerd, waardoor gestandaardiseerde modellen gebruikt worden (Govers, 2003). Onvoorziene situaties worden dan niet ondersteund, want het ERP-pakket kent slechts standaardprocessen. De van oorsprong geboden flexibiliteit van het ERP-pakket wordt beperkt door de parameters. De organisatorische flexibiliteit van de organisatie wordt hierdoor ondermijnd (Govers, 2003). Flexibiliteit, het vermogen om aan te passen, kent volgens Govers (2006) in drie vormen: 17

- Operationele flexibiliteit, waarmee het volume en /of de mix van de output van een organisatie gemoeid is; - Structurele flexibiliteit, waarmee aanpassingen van de vorm (structuren en processen) van een organisatie gemoeid zijn; - Strategische flexibiliteit, waarmee de visie en doelstellingen van een organisatie gemoeid zijn. In dit onderzoek wordt er vooral gekeken naar de structurele en strategische flexibiliteit. Brun et al. (2006) stelt dat door het mogelijk maken van een snelle verandering in software en systemen ook de organisatie flexibeler wordt. Door legacy is een snelle verandering van software of hardware juist niet mogelijk. Er zijn enkele factoren te noemen die het aanpassen van een ERPpakket flexibeler maken, zoals de deskundigheid van beheerders, de gehanteerde beheertechniek en de hoogte van het beheerbudget. Deskundige beheerders maken het mogelijk om snel aanpassingen te kunnen doen, omdat zij de kennis hiervoor hebben. Een beheertechniek die snelle verandering toestaat, kan eveneens voor meer flexibiliteit zorgen dan een logge beheertechniek waarbij een verandering in het systeem veel tijd vraagt. Indien er een hoog beheerbudget is, kan er bijvoorbeeld kennis ingehuurd worden om het systeem te veranderen. Deze factoren leiden echter niet tot het verdwijnen van de genoemde problematiek. Want er blijft gelden dat het ERP-pakket niet eenvoudig aangepast worden, waardoor de flexibiliteit van een ERP-pakket laag is.

1.6 ERP-pakketten leiden tot inflexibiliteit

Door het aanschaffen van software wordt niet automatisch integratie bereikt. Deze integratie is wenselijk, omdat het een hogere performance, een lager foutpercentage en betere rapportagemogelijkheden biedt. Door het gebruik van een standaard ERP-pakket wordt een vorm van integratie door softwaremakers geboden. Het standaard ERP-pakket moet echter ingesteld worden aan de hand van het businessmodel, waardoor het ERP-pakket de business-processen ondersteund. Het businessmodel is op deze wijze verankerd in het ERP-pakket. Doordat er behoefte is om te veranderen (de wens om flexibel te zijn), is het ERP-pakket continu aan verandering onderhevig. Er worden in de loop der tijd extra modulen aangeschaft om nieuwe functionaliteiten te kunnen blijven ondersteunen en er worden nieuwe instellingen aangebracht. Dit kan echter niet oneindig. De integratie kan leiden tot een onoverzichtelijk geheel, omdat er extra

18

afhankelijkheden ontstaan. Het vervangen van het ERP-pakket komt in beeld, maar dit wordt bemoeilijkt door legacy. Indien alle obstakels van legacy overwonnen zijn en er een nieuw ERPpakket geïmplementeerd is, zal er vroeg of laat een nieuwe vorm van legacy ontstaan, doordat de cyclus implementatie/onderhoud - uitbreiding - vervanging opnieuw doorlopen wordt. Holland et al. (2001) stelt een model voor dat overeen komt met deze drie fasen. Holland et al. (2001) noemt kosten, hoeveelheid onduidelijkheid van het systeem, complexiteit, flexibiliteit en concurrentievoordeel als vijf belangrijkste items die veranderen in de drie fasen. Holland et al. (2001) geven aan dat zowel de technische als de organisatorische flexibiliteit het hoogst zijn juist na de implementatie van het ERP-pakket. Lindley et al. (2008) noemen in het onderzoek dat ERP-pakketten het implementeren van nieuwe technologie verhinderen en het duurder maken. Op deze wijze zorgt een ERP-pakket voor inflexibiliteit. De laatste hypothese is daarom: H6: Een gebruik van een ERP-pakket verlaagt de organisatorische flexibiliteit van een organisatie

19

1.7 Definities van belangrijkste begrippen

Business-legacy – Business-legacy is het geheel aan processen en taken dat volgens een oude visie wordt uitgevoerd en dat omgevormd moet worden naar taken en processen volgens een nieuwe visie, hetgeen door diverse verwevenheden niet eenvoudig is. Electronic Data Interchange (EDI) – EDI is een methode die het mogelijk maakt om documenten (zoals orders en facturen) tussen verschillende organisaties op een elektronische wijze te verhandelen in een compacte vorm (Medjahed et al., 2003). Een organisatie moet zich aan de strikte standaarden houden die voor EDI gelden, anders wordt het uitwisselen onmogelijk (Medjahed et al., 2003). EDI wordt voornamelijk gebruikt tussen organisaties en maakt Business-to-business uitwisseling op een elektronische methode mogelijk (Medjahed et al., 2003). ERP-pakket –Vogt (2002) definieert een ERP-pakket als volgt: “Ieder softwaresysteem dat ontworpen is om bedrijfsprocessen te ondersteunen van middelgrote tot grote organisaties”. Deze definitie is voor deze thesis te algemeen, doordat bijvoorbeeld een programma als een Excel sheet volgens deze definitie ook een ERP-pakket zou kunnen zijn. Het ondersteunt immers de bedrijfsprocessen. De samenhang van meerdere processen wordt echter niet in ogenschouw genomen. Een ERP-pakket wordt in deze thesis omschreven als een softwarepakket dat de organisationele processen in samenhang met andere processen en procedures, over verschillende organisatiedomeinen heen, kan ondersteunen en hier over kan rapporteren. Flexibiliteit - Flexibiliteit is de snelheid waarmee een verandering plaats kan vinden van een oude situatie naar een nieuwe situatie. Des te sneller er aangepast kan worden, des te hoger de flexibiliteit. Daarnaast dient er bij een beperkte verandering slechts een beperkte inspanning noodzakelijk te zijn om flexibel te zijn. Generiek ERP-pakket – Een generiek ERP-pakket is een softwarepakket dat breed kan worden ingezet in vele bedrijfstakken. Een generiek ERP-pakket kan ingezet worden in allerlei sectoren, zoals retail, dienstensector, enzovoorts. Dit komt omdat een generiek ERP-pakket een breed scala aan businessmodellen ondersteund .Er moet overigens wel dusdanig geconfigureerd worden zodat het ERP-pakket het juiste businessmodel ondersteund. Daarnaast moet dit juiste businessmodel “passend” gemaakt worden voor de organisatie.

20

ICT- legacy – ICT-legacy is een onderdeel van de informatievoorziening dat getracht wordt te veranderen maar technische oorzaken en organisatorische afhankelijkheden bemoeilijken dat. De definitie van ICT-legacy die in deze thesis gehanteerd wordt is: "ICT-legacy is een onderdeel van de informatievoorziening dat getracht wordt te veranderen maar dat wordt door technische oorzaken en organisatorische afhankelijkheden bemoeilijkt". ICT-ondersteuning – In deze thesis wordt ICT-ondersteuning als volgt gedefinieerd: ICTondersteuning is ondersteuning middels ICT van de bedrijfsprocessen van een organisatie. Daarnaast kan ICT-ondersteuning monitorings- en rapportages van deze bedrijfsprocessen geven. Legacy – Legacy is een hoofdthema van dit onderzoek, omdat het inflexibiliteit genereert. Legacy wordt door Lloyd et al. (1999) omschreven als: “Systemen die significante veranderingen omtrent business requirements in de weg staan, met een consequente negatieve invloed op het concurrentievermogen”. Dit suggereert dat legacy slechts invloed heeft op de business requirements. Alhoewel legacy wel degelijk invloed heeft op de verandering van business requirements, staat legacy eveneens verandering van ICT-componenten in de weg. In deze thesis wordt legacy als volgt omschreven: "Een onderdeel kan als ‘legacy’ worden beschouwd als het getracht wordt te veranderen maar door technische oorzaken en organisatorische afhankelijkheden moeilijk te veranderen is". De oorzaak voor het veranderen van een onderdeel van de informatievoorziening kunnen bijvoorbeeld veranderde business requirements zijn. Manufacturing Requirement Planning (MRP) - Een Manufacturing Requirement Planning (MRP) is een pakket dat gebruikt maakt van productdefinities, voorraad, open orders en een tijdsplanning om de benodigde materialen, componenten en halffabricaten te berekenen (Burns, 1993). Een MRPpakket kan herberekeningen maken als een bepaald product niet op voorraad is, of als het produceren niet volgens planning verloopt. Een MRP-pakket is gericht op producerende organisaties. Manufacturing Requirement Planning II (MRP-II) - Een Manufacturing Requirements Planning II pakket maakt bevat dezelfde functionaliteit als het MRP-pakket, maar uitgebreid is met de aspecten voorraad, geld en mankracht (Vogt, 2002). Door deze uitbreidingen kan een MRP-II-pakket gedetailleerder en completer plannen. Een MRP-II-pakket is gericht op producerende organisaties. Organisatorische flexibiliteit – Dit is de mate en de snelheid waarmee een organisatie van de oude visie en strategie naar de nieuwe visie en strategie kan veranderen. Ook hier geldt dat een snellere verandering een hogere organisatorische flexibiliteit betekent.

21

Proces - Een proces wordt getypeerd door een patroon van een vaste aaneenschakeling van taken in een vaste volgorde (Burmeister et al., 2008). Een proces kan geautomatiseerd worden, de mate hangt af van het proces (Burmeister et al. 2008). Specifiek ERP-pakket – Dit is de tegenhanger van het generieke ERP-pakket. Een specifiek ERP-pakket is slechts voor één bepaalde bedrijfstak bedoelt, en is daardoor niet breed inzetbaar. Vanzelfsprekend moet een specifiek ERP-pakket eveneens geconfigureerd worden om de organisationele processen te kunnen ondersteunen. De inrichtingsperiode van het ERP-pakket kan nu beperkter zijn ten opzichte van een generiek ERP-pakket, omdat de businessmodellen minder algemeen zijn. Value-chain – De value-chain is aaneenschakeling van activiteiten waardoor de waarde van een product wordt verhoogd (Porter, 1985). Porter (1985) beschouwt iedere activiteit als een stukje waardetoevoeging aan een product. Iedere afdeling draagt iets bij aan de uiteindelijke (verkoop)prijs. Porter (1985) onderscheidt de afdelingen inkomende logistiek, operaties, uitgaande logistiek, marketing & verkoop en service. Daarnaast onderscheid Porter (1985) ondersteunende processen. Voorbeelden zijn HRM en de infrastructuur van de organisatie. Deze processen dragen niet direct iets bij aan de waarde van het product, maar zijn wel essentieel voor de organisatie.

22

2. Probleemstelling

2.1 De aanleiding van het onderzoek

Uit onderzoek (Everdingen et al., 2000) blijkt dat in Nederland 70% van de organisaties gebruik maakt van een ERP-pakket. Door dit hoge gebruik is het zeer relevant om te weten wat een ERP-pakket tot gevolg heeft. Diverse auteurs noemen een ERP-pakket als een voordeel, bijvoorbeeld door een hogere efficiëntie en een hogere flexibiliteit. Het traject van de implementatie van een ERP-pakket is echter niet eenvoudig. De oorzaak hiervan ligt in de aanpassing van het ERP-pakket aan de bedrijfsprocessen, omdat het ERP-pakket deze moet ondersteunen. Als dit eenmaal voor elkaar is, werkt het ERP-pakket (in de regel) naar behoren. Zodra het management een andere strategie aan wil nemen moeten de processen en de ondersteuning hiervan gewijzigd worden. Nieuwe wensen, zoals het gebruik van E-business, moeten in de bedrijfsvoering ingevoerd worden. Als echter blijkt dat het ERP-pakket hier geen mogelijkheid voor biedt, zal het pakket uitgebreid moeten worden. Dit kan niet onbeperkt doorgaan en vroeg of laat zal er een eind komen aan het uitbreiden. De organisatie zal in dat geval het gehele ERP-pakket moeten vervangen. Het bedrijf is echter afhankelijk geworden van het ERP-pakket, omdat de processen er door ondersteund worden. Vervangen van een ERP-pakket brengt daardoor grote risico’s met zich mee. Daarnaast is het de vraag of vervangen wel zo’n gemakkelijke oplossing is: de extra’s die in de loop der jaren aan het pakket zijn toegevoegd zorgen voor extra afhankelijkheden. Dit maakt het geheel complex. Als de mogelijkheden van het ERP-pakket niet meer toereikend zijn, bevindt de organisatie zich in een spagaat: door te veranderen van ERP-pakket ontstaan er grote risico’s. De processen van de organisatie zijn immers afhankelijk van het ERP-pakket, omdat het ERP-pakket ondersteuning aan deze processen geeft. Wil de organisatie echter vooruit kunnen met de nieuwe visie, dan zal het vervangen van het ERP-pakket wel moeten. Als het ERP-pakket niet meer uit te breiden is, moet de organisatie dus grote risico’s nemen. De organisatie wordt zodoende belemmerd in het voeren van een nieuwe strategie. De organisationele flexibiliteit wordt hierdoor verlaagd. Er zijn enkele onderzoeken die de flexibiliteit na invoering van een ERP-pakket hebben getoetst. Hier is echter geen eenduidig beeld over.

23

2.2 Relevantie van het onderzoek

Er is veel literatuur over ERP-pakketten en de werking hiervan. Over legacy en ERP-pakketten is echter minder literatuur te vinden. Er worden enkele verbindingen gelegd tussen legacy in de informatievoorziening en een ERP-pakket. Enkele artikelen gaan specifiek in op de flexibiliteit en legacy. Er wordt echter vaak gesproken over de technische flexibiliteit en over de technische legacy. In diverse onderzoeken wordt er geen onderscheidt gemaakt tussen generieke en specifieke ERPpakketten (zie paragraaf 1.7). Daarnaast wordt er in diverse onderzoeken geen rekening gehouden met het doel van specifieke ERP-pakketten. Naast specifieke ERP-pakketten die gericht zijn op diverse branches, kan een organisatie er voor kiezen om een specifiek ERP-pakket te kiezen dat gericht is op een bepaalde functie, zoals logistieke besturing of managementinformatie. Dit onderzoek legt het verband tussen een generiek ERP-pakket en de organisationele flexibiliteit. Er zijn onderzoeken op het gebied van het gebruik van een ERP-pakket en organisationele flexibiliteit die met elkaar in tegenspraak zijn. ERP-pakketten kunnen volgens deze onderzoeken de organisationele flexibiliteit zowel positief als negatief beïnvloeden. Dit onderzoek moet een van beide conclusies versterken.

2.3 Doelstelling

Het doel van deze masterthesis is het aantonen van het verband tussen het gebruik van een ERPpakket en de verandering van de organisationele flexibiliteit. Daarnaast worden er maatregelen voorgesteld om organisationele flexibiliteit te behouden. Holland et al. (2001) toont een model waarin de volwassenheid van een ERP-pakket wordt weergegeven. De volwassenheid is in drie categorieën in te delen. In een volwassenheidsmodel wordt een volwassenheidsscore toegekend, waarna te bepalen is of een organisatie in fase 1, 2, of 3 valt. Iedere fase brengt een hoeveelheid onduidelijkheid in het systeem, complexiteit, flexibiliteit en concurrentievoordeel (of nadeel) mee. De auteurs noemen dat na de derde fase men verandert van ERP-pakket, doordat het ERP-pakket niet meer aan de wensen voldoet. Het gevolg is dat het ERP-pakket vervangen wordt. Een nieuw ERPpakket leidt ertoe dat de organisatie zich weer in de eerste fase bevindt, en tegen problemen aanloopt. Deze thesis biedt inzicht in de verandering van organisationele flexibiliteit. Daarnaast stelt deze thesis maatregelen voor om de organisationele flexibiliteit bij het gebruik van een ERP-pakket te behouden. 24

2.4 Vraagstelling

De hoofdvraag in deze thesis gaat over de relatie tussen een ERP-pakket en organisationele flexibiliteit. Zoals in paragraaf 2.2 is aangegeven, is er weinig onderzoek gedaan naar ERP-pakketten en organisationele flexibiliteit. Er is onduidelijkheid over deze relatie. De onderzoeksvraag binnen dit onderzoek is: " Welke maatregelen zijn noodzakelijk om een door legacy verouderd ERP-pakket te kunnen vervangen zodat de organisatorische flexibiliteit behouden blijft?" Om deze onderzoeksvraag te kunnen beantwoorden, worden er drie subonderzoeksvragen geformuleerd. Subonderzoeksvraag 1 De eerste subonderzoeksvraag zoomt in op het ERP-pakket. De sub-subonderzoeksvragen 1a en 1b zoomen verder in op de verschillende ERP-pakketten en de nadelen daarvan. 1. "Wat is een ERP-pakket?" 1a. "Welke verschillende ERP-pakketten zijn er?" 1b. "Wat zijn de voordelen en nadelen voor het gebruik van een ERP-pakket? Subonderzoeksvraag 2 Naast ERP-pakketten omvat de onderzoeksvraag de veroudering van een ERP-pakket door legacy. De tweede subonderzoeksvraag zoomt daarom in op legacy om dit element van de onderzoeksvraag te belichten. Legacy is een belangrijke factor in de organisatorische flexibiliteit: legacy kan ertoe leiden dat het toevoegen van een functionaliteit in het ERP-pakket niet (meer) mogelijk is. Legacy kan dus veranderingen in de weg staan. Dit komt de organisatorische flexibiliteit niet ten goede omdat de ondersteuning niet kan mee veranderen. Door te onderzoeken wat legacy is, kan er rekening worden gehouden met de eigenschappen hiervan. Naast het onderzoeken van de eigenschappen van legacy, is het interessant om te weten of legacy wellicht voorkomen kan worden, zodat de organisatorische flexibiliteit hier niet ten koste van hoeft te gaan. Sub-subonderzoeksvraag 2a gaat over de verschillende soorten legacy. De sub-subonderzoeksvraag 2b gaat in op het ontstaan van legacy. Indien er bekent is hoe legacy ontstaat, kan er wellicht ook beredeneerd worden hoe legacy

25

voorkomen kan worden. Het voorkomen van legacy wordt beantwoord in sub-subonderzoeksvraag 2c. 2. "Wat is legacy?" 2a “Welke soorten legacy zijn er?” 2b "Waardoor ontstaat legacy?" 2c “Hoe kan legacy voorkomen worden?” Subonderzoeksvraag 3 Nadat bekend is wat een ERP-pakket is en wat legacy precies is, is het belangrijk om de organisatorische flexibiliteit van een organisatie te onderzoeken. De derde subonderzoeksvraag beantwoordt wat organisationele flexibiliteit precies is. Zodra dit bekent is, kan er gekeken worden naar methoden om de organisationele flexibiliteit te behouden. Allereerst moet er bekend zijn wat deze organisatorische flexibiliteit beïnvloedt. Dit komt in sub-subonderzoeksvraag 3a aan de orde. Daarnaast wordt er in sub-subonderzoeksvraag 3b beantwoord hoe de organisatorische flexibiliteit behouden kan worden. 3. "Wat is organisationele flexibiliteit?" 3a "Wat beïnvloedt de organisatorische flexibiliteit?” 3b "Hoe kan organisationele flexibiliteit behouden worden?" Indien alle subonderzoeksvragen beantwoord zijn, kan er zowel vanuit de literatuur als vanuit de praktijk gezocht worden naar maatregelen om organisatorische flexibiliteit bij de inzet van een ERPpakket te behouden. De gevonden resultaten van de subonderzoeksvragen kunnen gebundeld worden, zodat het antwoord op de onderzoeksvraag gegeven kan worden. Dit antwoord zal worden getoetst in de praktijk door middel van een viertal cases. Het antwoord op de onderzoeksvraag bestaat uit maatregelen om de organisatorische flexibiliteit te kunnen behouden.

26

2.5 Type onderzoek In Verschuren et al. (2000) wordt een tweetal typen onderzoek genoemd. Een onderzoek kan theoretisch of empirisch georiënteerd zijn. Een theoretische studie ontwikkelt of onderzoekt een theorie. Een empirische studie richt zich op probleemidentificatie, interventie, evaluatie en ontwerp. De probleemidentificatie identificeert een probleem aan de hand van de literatuur. Een interventie is een veranderingstraject voor het oplossen van een probleem. De evaluatie wordt gebruikt om een oplossing van een probleem te evalueren. Het ontwerp is er op gericht om op basis van de probleemsignalering een interventie te ontwerpen. Naast het type onderzoek noemen Verschuren et al. (2000) beschrijvende, uitleggende en voorspellende typen onderzoek. Het beschrijvende onderzoek geeft een beschrijving van een vraagstuk en niet de oorzaak. Uitleggend onderzoek probeert verbanden te leggen tussen de oorzaak en het gevolg hiervan. Het voorspellend type onderzoek probeert te voorspellen wat er in een bepaalde situatie gebeurt als deze zich voordoet. Het onderzoekstype in deze masterthesis is empirisch en uitleggend. Het probleem van het ontstaan van legacy en organisatorische flexibiliteit wordt geïdentificeerd en verklaard indien er gebruik wordt gemaakt van een ERP-pakket. De in de literatuur gevonden resultaten worden aannemelijk gemaakt door een viertal cases.

Beschrijvend

Uitleggend

Voorspellend

Empirisch

Theoretisch

Afbeelding 2: Type onderzoek

27

2.6 Onderzoeksmodel In de masterthesis wordt het verband gezocht tussen het gebruik van een ERP-pakket en de verandering van organisationele flexibiliteit. Gebruik van een ERP-pakket leidt tot een verandering in de organisationele flexibiliteit, zoals Govers (2006) dat noemt. Dit onderzoek kijkt naar het ontstaan van organisationele flexibiliteit bij het gebruik van een ERP-pakket. Het onderstaande figuur geeft het onderzoeksmodel weer, zoals deze gebruikt wordt voor de masterthesis.

Afbeelding 3: Onderzoeksmodel Met het onderzoeksmodel wordt weergegeven dat een ERP-pakket de organisationele flexibiliteit beïnvloed. De verwachting is dat de organisationele flexibiliteit verlaagd wordt, doordat er niet snel gewisseld kan worden van ERP-pakketten. De maatregelen die in deze masterthesis voorgesteld worden, moeten de flexibiliteit juist verhogen.

2.7 Onderzoeksmethode

In deze paragraaf wordt besproken hoe er in de masterthesis onderzoek gedaan wordt. In Verschuren et al. (2000) worden vijf typen onderzoekstechnieken genoemd. Deze vijf typen zijn survey-onderzoek, experiment, casestudy, gefundeerde theoriebenadering en bureauonderzoek. Ieder onderzoekstype heeft een eigen focus. Een casestudy levert met name empirische data op, terwijl vragenlijsten juist kwantitatieve data oplevert. Dit is zeker het geval indien dit van het type multiple-choice is. In deze masterthesis worden twee typen onderzoek gebruikt, te weten het bureauonderzoek en de casestudy. Vervolgens worden de resultaten van beiden met elkaar geconfronteerd.

28

Het onderzoek wordt in drie delen opgesplitst. Het eerste deel van de masterthesis bestaat uit bureauonderzoek. Door bureauonderzoek te gebruiken wordt er een breed kader neergezet met daarin mogelijke verbanden tussen ERP en organisatorische flexibiliteit. Er wordt gebruik gemaakt van bestaande, wetenschappelijke literatuur die niet ouder is dan 20 jaar. Dit om te voorkomen dat er oude inzichten over de verbanden worden aangedragen. Tijdens het uitvoeren van het bureauonderzoek is er nog geen contact met organisaties, om de in de literatuur aangedragen verbanden niet bij voorbaat te hoeven verwerpen. Het tweede deel van de masterthesis bestaat uit het afnemen van een viertal diepte-interviews. De organisaties waar deze diepte-interviews worden afgenomen zijn middelgroot tot groot. De reden voor het afnemen van vier diepte-interviews is om kwalitatieve en empirische gegevens te vergaren van praktische aard. Er wordt door deze praktische gegevens geverifieerd of de resultaten uit het bureauonderzoek overeenkomen met de praktijk. Het is feitelijk een uitbreiding van het bureauonderzoek. Om tot de diepte-interviews te komen, zal per bedrijf een interview met een informatiemanager afgenomen worden van ongeveer één uur. Er is vooraf een vragenlijst met open vragen opgesteld om niet teveel van koers te raken tijdens het interview en om de meest noodzakelijke informatie te kunnen achterhalen. De vragenlijst is samengesteld nadat een redelijk deel van het bureauonderzoek gedaan is. De reden hiervoor is dat op deze wijze inzichten en verbanden die in de literatuur gevonden zijn geconfronteerd kunnen worden met de praktijk. De keuze voor een interview is gedaan om op antwoorden door te kunnen vragen, zodat er een rijker beeld ontstaat. Vragenlijsten zijn vaak kwantitatiever van aard, interviews kwalitatiever. De documentatie van het huidige ERP pakket dient als mogelijke input voor het genereren van een case. In het geval van een tegenspraak tussen interview en documentatie zal de informatiemanager benaderd worden voor nadere uitleg. Nadat het diepte-interview afgerond is, is deze ter verificatie voorgelegd aan de informatiemanager om misinterpretatie te voorkomen. Vervolgens is het diepte-interview en alle andere vergaarde informatie gebruikt om een case te maken. Indien er een verband gevonden is in de literatuurstudie, zullen de cases dit verband versterken. Het derde deel van de masterthesis confronteert het bureauonderzoek met de diepte-interviews en casestudies om tot de algehele conclusie te komen. Er wordt getracht tegenstrijdigheden in de cases te verklaren aan de hand van de literatuur. Indien er geen verklaring mogelijk is op basis van de gebruikte literatuur, dan zal er een aanbeveling worden gedaan voor vervolgonderzoek op dit punt. Dit is ligt voor de hand, aangezien een viertal cases niet representatief kunnen zijn voor het opstellen van een nieuwe theorie. 29

3. ERP-pakketten

Dit eerste hoofdstuk geeft een literatuuroverzicht over ERP-pakketten. De eerste paragraaf geeft de oorsprong weer van ERP-pakketten zoals dat in de literatuur omschreven staat. De tweede paragraaf gaat in op enkele definities zoals deze in de literatuur gevonden zijn. Door deze definities wordt het doel van ERP-pakketten achterhaald. De derde paragraaf gaat in op de vraag wanneer ERP een pakket is. De vierde paragraaf gaat in op het gebruik van ERP-pakketten binnen organisaties. Hierbij kan gedacht worden aan redenen voor implementatie van een ERP-pakket en het beoogde nut van het ERP-pakket voor de organisatie.

3.1 Oorsprong van ERP-pakketten

Porter (1985) stelt dat primaire activiteiten van een organisatie waarde toevoegen aan een product. Porter (1985) onderscheidt daarin de volgende activiteiten: -

Inkomende logistiek: Omvat de ontvangst, opslag, controle en transportplanning van goederen;

-

Operaties: Omvat de bewerkingen die op een product uitgevoerd worden, zoals het assembleren van onderdelen of het verwerken van grondstoffen;

-

Uitgaande logistiek: Omvat de orderafhandeling, opslag en verzending van het gereed product naar de klanten;

-

Marketing en verkoop: omvat de activiteiten om het product te verkopen, zoals het werven van klanten, adverteren, enzovoorts;

-

Service: omvat de activiteiten om de waarde van het product te verbeteren, zoals klantondersteuning en reparaties.

Daarnaast onderscheidt Porter (1985) ondersteunende activiteiten. Deze activiteiten worden onderverdeeld in: -

Verwerving: omvat de inkoop van grondstoffen, gebouwen en machines;

-

Technologieontwikkeling: omvat de activiteiten om de waardeketen te verbeteren. Onderzoek en ontwikkeling van nieuwe producten valt hier bijvoorbeeld onder;

-

Management van menselijk kapitaal: Omvat de activiteiten die verbonden zijn aan werving, ontwikkeling en behoud van het personeel van de organisatie;

-

Infrastructuur: Omvat het management, boekhouding, kwaliteitsmanagement, enzovoorts. 30

De onderstaande afbeelding geeft de value-chain value van Porter (1985) weer.

Afbeelding 4: Value-chain chain van Porter (1985) De value-chain chain is gericht op het maken of bewerken van producten en niet op het leveren van diensten. Echter, de dienstensector is de afgelopen 50 jaar sterk gegroeid. Er vind een verschuiving plaats van een agrarisch tijdperk naar een postagrarisch tijdperk (Chessbrough et al., 2006). Door dezee verschuiving wordt er meer en meer gebruik gemaakt van IT. Al voordat het internet bestond, werden er initiatieven gestart om elektronisch te kunnen handelen tussen organisaties (Medjahed, 2003). Hierbij valt te denken aan het kunnen doen van bestellingen bestellinge n of het opvragen van prijs prijs- en beschikbaarheidinformatie. Het uitwisselen van deze informatie werd door middel van Electronic Data Interexchange (EDI) gedaan. EDI leidde tot het ontstaan van interorganisationele systemen, doordat organisatieonderdelen, zoals zoals actuele hoeveelheden van voorraden, met elkaar ve verweven raakten (Alt et al., 2000). ). Kelly et al. (1999) noemen dat technologie een essentiële factor is voor het kunnen afvangen van complexiteit in een organisatie. De foutgevoeligheid bij elektronische verwerking is laag (Omelayenko,, 2000),, zodat dit de voorkeur verdient. In de jaren '60 ontstonden de eerste fabricagesystemen (Vogt, 2002). Deze fabricagesystemen werden gebruikt om de actuele stand van de voorraden weer te kunnen geven. Meer functionaliteit functionalit eit bood deze software nog niet. De fabricagesystemen hebben alleen betrekking op de inkomende logistiek. Vanaf de jaren '70 ontstonden de eerste material-requirement-planning material planning (MRP) pakketten (Rashid et al., 2002). Deze software kon voorraden bijhouden, maar maar eveneens planningen maken voor het productieproces (Vogt, 2002). Reden voor het ontstaan van het MRP-pakket MRP pakket was omdat organisaties zich niet de luxe konden veroorloven om grote voorraden aan te houden (Umble et al., 2003). De software diende als hulpmiddel ddel om de regie over het inkoopdeel van het productieproces te behouden (Burns, 1993). Voorraden konden dankzij het MRP-pakket MRP pakket efficiënter beheerd worden 31

zonder het risico te lopen op te hoge of te lage voorraden. Te hoge voorraden leiden tot kapitaalbeslag en prijsrisico's en eventueel het risico op bederven van voorraad. Een te lage voorraad leidt ertoe dat een organisatie niet optimaal gebruik kan maken van de machinale of personele middelen (Kotler et al., 2003). Door gebruik te maken van de hoeveelheden machinale of personele middelen is het mogelijk om de noodzakelijke hoeveelheid voorraad te berekenen. Daarnaast kan er per order berekend worden hoeveel voorraad er nodig is. Het MRP-pakket was dus een uitbreiding ten opzichte van een fabricagesysteem, omdat het gebruik kon maken van de primaire activiteiten inkomende logistiek en operaties. Een MRP-pakket richt zich louter op het berekenen van productiehoeveelheden en het bijhouden van voorraden. Bij een eventuele orderwijziging of tijdsoverschrijding van de te leveren nieuwe voorraad, kan het MRP-pakket automatisch een nieuwe planning maken. Het MRP-pakket is hierdoor een op tijd gebaseerde oplossing en gebruikt alleen het aspect voorraad (Vogt , 2002). De software werd krachtiger en veel omvattender, zodat de software het gehele productieproces onder de hoede kon nemen. Door gegevens elektronisch uit te wisselen kunnen bestellingen bij andere toeleveranciers gedaan worden. Deze bestellingen zijn aangepast op het aantal te produceren items. Een afnemer kan eveneens elektronisch een bestelling plaatsen voor een te produceren product. Alhoewel dit een goed principe was om de foutmarge te verlagen in vergelijking met handmatige bestellingen, koppelt het nog geen administratieve handelingen aan elkaar. Door deze manier van elektronisch bestellen worden uitsluitend leesfouten en invoerfouten in het systeem voorkomen. Een logische opvolger van het MRP-pakket is het MRP-II-pakket. De opkomst van deze MRP-IIpakketten begon in de jaren '80 (Vogt, 2002). Daar waar een MRP-pakket slechts gebruik kon maken van het aspect voorraad, kan het MRP-II-pakket gebruik maken van de aspecten voorraad, geld en mankracht (Vogt, 2002). Door gebruik te maken van deze drie aspecten werd het mogelijk om gedetailleerder en completer te plannen. Daarnaast werd de optimalisatie in dergelijke systemen sterk verbeterd (Basoglu et al., 2007). Verder werd het mogelijk om rapportages te kunnen maken. Het plannen met de drie aspecten geeft nog meer voordelen: er kunnen voorspellingen gedaan worden indien er wat veranderd. Een allocatievraagstuk kan bijvoorbeeld zijn: "Hoeveel levert het op als de organisatie 's nachts blijft produceren? ". De beschikbare hoeveelheid geld en de beschikbare hoeveelheid mankracht zijn leidend bij deze vraag. Het MRP-II-pakket heeft nog steeds alleen betrekking op de primaire activiteiten inkomende logistiek en operaties.

32

Alhoewel een MRP-II-pakket nog meer ondersteuning in de bedrijfsvoering biedt ten opzichte van een MRP-pakket, biedt het weinig tot geen ondersteuning voor organisaties die geen productieproces hebben. Het MRP-pakket en MRP-II-pakket bieden geen ondersteuning voor bijvoorbeeld de dienstensector of detailhandel. Een andere tekortkoming is dat bij organisaties die een MRP-II-pakket geïmplementeerd hebben alleen het productieproces geautomatiseerd is binnen één pakket. Een voorbeeld is de administratie: Er moet nog steeds handmatig gecontroleerd worden wat het maximale orderbedrag van de debiteur is, aangezien er geen koppeling tussen het bestelsysteem en de administratie is. Daarnaast moet er een controle plaatsvinden of de debiteur niet al reeds openstaande orders heeft. Vernieuwde technieken leidden ertoe dat MRP-II-pakketten verouderd raakten. Een MRP-III-pakket biedt geen oplossing voor de zojuist genoemde punten, omdat de ondersteuning alleen geboden wordt op het productieproces en/of het logistieke proces (Basoglu et al., 2007). Er ontstond de behoefte om meerdere processen te kunnen automatiseren. Daar waar in een MRP-II-pakket slechts het voorraadbeheer en een deel van het logistieke proces en de administratieve handeling hiervan afgehandeld worden, begonnen in de jaren ’90 Enterprise Resource Planning (ERP) pakketten in opmars te komen (McAdam et al., 2005). ERP-pakketten leggen de focus bij informatievoorziening, en de verspreiding van de informatie die zich in deze informatievoorziening bevindt. Het businesscomponent en het IT-component binnen organisaties die ERP-pakketten gebruiken is sterk met elkaar verweven (Gupta, 2000). Een groot voordeel ten opzichte van een MRP-II-pakket is dat een ERP-pakket toepasbaar is binnen vele bedrijfstakken (dus ook bij organisaties zonder productieproces), terwijl een MRP-II-pakket alleen goed toepasbaar is bij producerende organisaties (Everdingen et al., 2000). Een ERP-pakket kan alle primaire activiteiten in de value-chain ondersteunen. Daarnaast kan het de ondersteunende activiteiten omvatten. De mate van procesondersteuning is hoger in vergelijking met een MRP-pakket of een MRP-II-pakket.

3.2 Enkele definities van een ERP-pakket

De naamgeving van een ERP-pakket doet vermoeden dat het ERP-pakket louter voor het plannen van resources van een organisatie gebruikt wordt. ERP-pakketten worden in de literatuur op vele manieren gedefinieerd. Bakry et al. (2005) omschrijven een ERP-pakket als “geïntegreerde systeemsoftware bestaande uit diverse modulen, die een gezamenlijke database delen en 33

ontworpen zijn om businessprocessen van de gehele organisatie te automatiseren.” Gefen (2004) omschrijft een ERP-pakket als "ERP-systemen beheren de value-chain van de organisatie op een geïntegreerde manier, en kan daardoor voorraad, logistiek, orders, administratie, verzending, verkoop, klantenservice en vele andere aspecten afhandelden". Een derde definitie wordt door Muntslag (2001) gegeven: "Een ERP-systeem is een geïntegreerd standaard softwarepakket dat administratieve en bestuurlijke ondersteuning biedt voor een groot deel van de primaire en ondersteunde processen binnen een organisatie". Deze drie definities geven allen een mate van ondersteuning aan voor wat betreft de bedrijfsprocessen in verschillende organisatiedomeinen. De mate van ondersteuning is per definitie verschillend: Bakry et al. (2005) noemen dat de gehele organisatie geautomatiseerd wordt, terwijl Gefen (2004) en Muntslag (2001) beiden spreken over "een groot gedeelte van de organisatie" in plaats van te spreken over de gehele organisatie. De vraag is of het wenselijk is om alles te automatiseren. Een proces waarbij ondersteuning geboden moet worden aan klanten kan geautomatiseerd worden door er een kennissysteem aan te koppelen. Alhoewel dit voor veel klanten vaak goed zal werken, hebben klanten toch de behoefte om persoonlijk contact te hebben. Wellicht dat een ERP-pakket veel kan automatiseren, maar dat tevens het menselijk aspect in ogenschouw moet worden genomen. Volgens alle drie de definities is een ERP-pakket een (software)systeem. Dit impliceert dat een ERP-pakket niet uit slechts losse (software)componenten bestaat, maar dat er een gestructureerd geheel van deze componenten bestaat. Bakry et al. (2005) noemen dat modulen een componenten van het ERP-pakket zijn. Daarnaast bestaat het systeem uit een database dat data van de modulen algemeen beschikbaar houdt voor coördinatie en rapportage. Muntslag (2001) noemt dit "administratieve en bestuurlijke ondersteuning". Met andere woorden: Het ERP-pakket vertolkt een stuk management en legt enkele procedures in het ERP-pakket vast. Dit wordt eveneens beaamd door de definitie van Gefen (2004): “Het ERP-pakket beheert de processen in plaats van slechts te ondersteunen”. Een ERP-pakket is dus geen software dat zich richt op een enkel proces. In vergelijking met een MRPpakket of MRP-II-pakket kan een ERP-pakket aanzienlijk meer dan het berekenen van benodigde mankracht en voorraad. Er kunnen meer processen uit meer domeinen ondersteund worden, omdat het ERP-pakket eveneens vele andere aspecten kan afhandelen. Een groot voordeel is dat ERPpakketten ingezet kunnen worden in bijna ieder type organisatie (Beatty et al., 2006). Dit heeft geleid tot een grote adaptatie van ERP-pakketten in Europa. Maar liefst 70% van de organisaties maakt gebruik van een ERP-pakket (Everdingen et al., 2000).

34

Er zijn diverse redenen om een ERP-pakket te implementeren in een organisatie. Zoals uit de hierboven genoemde definities blijkt, is het beheren en ondersteunen van primaire en secundaire processen het hoofddoel van een ERP-pakket. Het ondersteunen van deze processen moet, net als bij een MRP-pakket en MRP-II-pakket, leiden tot een betere vorm van efficiëntie. Poston et al. (2000) noemen dat het gebruik van een ERP-pakket invloed heeft op de performance van de organisatie. Daarnaast noemen zij dat het maken van beslissingen eenvoudiger is, omdat er meer gegevens beschikbaar zijn over de gehele organisatie. Een ERP-pakket is volgens Gefen (2004) interorganisationeel. Het gaat volgens Gefen (2004) niet alleen om de besturing van een organisatie, maar eveneens om de value-chain van een organisatie. Bij een value-chain zijn vaak meerdere organisaties betrokken (Kotler et al., 2003). Het ERP-pakket biedt hierdoor een belangrijke schakel in de bedrijfsdoelstellingen: indien het ERP-pakket faalt, komt de werking van de value-chain van de organisatie in gevaar. De definities van Bakry et al. (2005) en Muntslag (2001) beschrijven een ERP-pakket dat alleen de organisatie beslaat. ERP-pakketten kunnen zowel intern georiënteerd zijn, zoals Bakry et al. (2005) en Muntslag (2001) beschrijven, als extern georiënteerd zijn zoals Gefen (2004) omschrijft. Alt et al. (2000) merken op dat een extern georiënteerd ERP-pakket weinig afwijkt van een intern georiënteerd ERP-pakket. Het enige kenmerkende verschil is de netwerkfunctionaliteit. De genoemde modulariteit in Bakry et al. (2005) lijkt een voordeel te zijn voor het gebruik van een ERP-pakket. Door losse modulen te gebruiken kan er per proces gebruik worden gemaakt van een afzonderlijke module, terwijl het ERP-pakket de controle houdt over het geheel door middel van de gedeelde database. De modulen van een ERP-pakket zijn door middel van de database gekoppeld. De gebruikte modulariteit biedt een aanzienlijk voordeel indien er gebruik gemaakt gaat worden van extra functionaliteiten, doordat deze als het ware "in het systeem"geklikt kunnen worden. Het voordeel hiervan is dat deze losse module eenvoudiger en sneller te implementeren is dan een aanpassing in het gehele systeem (Blume et al., 1999). Hetzelfde geldt voor het veranderen van een functionaliteit in een module: er kunnen aanpassingen in een module gedaan worden zonder dat het gehele systeem aangepast hoeft te worden. Sterker nog, men hoeft niet het gehele systeem te kennen om een functie in een module aan te passen (Blume et al., 1999). Het uitbreiden van een ERP-pakket lijkt door de gebruikte modulariteit een relatief eenvoudige taak om uit te voeren. Het toevoegen van module mag dan voor geen problemen zorgen, het verbinden van deze module met het ERP-pakket kan echter wel tot problemen leiden (hier wordt in hoofdstuk 5 op ingegaan).

35

Resumerend is het hoofddoel van een ERP-pakket om bedrijfsprocessen te automatiseren. De samenhang die tussen de bedrijfsprocessen kan worden geïmplementeerd leidt tot een hogere efficiëntie, waardoor tijd en geld bespaard kan worden (Vogt, 2002). Een ERP-pakket heeft naast automatiseren tot doel om de primaire en secundaire bedrijfsprocessen te coördineren. Dit kan een ERP-pakket doen, doordat het de informatie van de bedrijfsprocessen ordent en vervolgens de juiste actie onderneemt. Dit kan door het veranderen van een status in het systeem. Als voorbeeld kan een webshop gegeven worden, waarbij een klant eerst dient te betalen voordat de bestelde producten opgestuurd worden. Zodra de klant betaald heeft, zet het ERP-pakket de order op status "betaald", zodat het magazijn de gemaakte bestelling bij elkaar kan pakken. Vervolgens geeft een magazijnmedewerker aan dat de bestelling compleet is, waarna de afdeling logistiek in haar scherm te zien krijgt dat de bestelling verzonden kan worden. Ditzelfde geldt overigens ook voor het handelen tussen organisaties. Een fabrikant kan eveneens een order plaatsen, waardoor een ERP-pakket de status in de bedrijfsprocessen veranderd. Op deze manier wordt er inter-organisationeel gehandeld.

3.3 Wanneer is het een pakket? De vraag rijst wanneer een ERP-pakket ook daadwerkelijk een pakket is. Door losse modules aan te schaffen is er sprake van een verzameling van modulen, maar nog niet van een pakket. Losse modulen hebben geen samenhang. Indien er afzonderlijk software gebruikt wordt om een proces te automatiseren, dan is er eveneens geen samenhang tussen softwareoplossingen van andere processen. Op een bepaalde wijze zal deze samenhang bewerkstelligd moeten worden. Zoals al opgemerkt is in paragraaf 3.1, is er bij een ERP-pakket sprake van een gedeelde database. Daarnaast moet er coördinatie en meerwaarde geboden worden bij het gebruik van deze gedeelde database. Zonder deze meerwaarde werken de modulen nog steeds los van elkaar (zij het dat er een database gebruikt wordt, maar per module diverse, losstaande attributen) en is er nog geen sprake van integratie. Barrett et al. (1996) geven de volgende definitie van integratie: "integratie is een proces waarbij meerdere softwaremodulen (programma's, subprogramma's, collecties van subprogramma's) gemaakt zijn om samen te werken ". Een ERP-pakket is pas dan een pakket als het gebruik maakt van een gedeelde database om de losse modulen van het pakket samen te laten werken door middel van integratie. Als opmerking kan hierbij geplaatst worden dat de modulen van andere leveranciers afkomstig zouden kunnen zijn als de modulen maar samen werken. De praktijk is echter dat de modulen van slechts een enkele leverancier afkomstig zijn. Een Excel sheet dat gebruikt wordt om 36

een rapportage te generen maakt dus geen deel uit van het ERP-pakket: de Excel sheet gebruikt slechts de gegevens van de database en werkt niet samen met de andere modulen. Strikt genomen kan een organisatie een ERP-pakket aanschaffen zonder het als pakket te gebruiken. Dit kan het geval zijn indien het pakket niet op de juiste wijze ingesteld is, zodat er geen samenwerking tussen de modulen is (Poston et al., 2000). Extra aangeschafte of door de organisatie geprogrammeerde modulen kunnen deel van het ERP-pakket uit gaan maken, zolang er maar integratie ontstaat tussen het huidige ERP-pakket en de nieuwe modulen. De losse modulen maken geen deel uit van het ERP-pakket, omdat er geen afhankelijkheden zijn. Als de module afzonderlijk gekoppeld wordt aan een identieke database, maar dan op een andere locatie, dan kan die module nog exact hetzelfde uitvoeren, zonder de aanwezigheid van andere modulen. De staat van andere processen (die ondersteund worden door andere modulen) wordt zodoende niet meegenomen. Er wordt niet gecoördineerd waardoor er een lagere efficiëntie wordt behaald dan een organisatie dat gebruik maakt van een pakket met geïntegreerde modulen.

37

3.4 ERP-pakketten en het gebruik in organisaties Het doel van een ERP-pakket is in paragraaf 3.1 genoemd. ERP-pakketten worden veelvuldig gebruikt in organisaties (Everdingen et al., 2000). De vraag is of organisaties hetzelfde nut van een ERP-pakket ervaren als waarvoor het eigenlijk ontworpen is. ERP-pakketten zijn duur in aanschaf en kosten veel tijd en onderhoud om ze op de juiste manier te configureren (Poston et al., 2000; Vogt, 2002). Er worden in deze paragraaf een vijftal redenen uit de literatuur genoemd waarom organisaties gebruik maken van een ERP-pakket. De redenen voor het gebruik van een ERP-pakket zijn divers. Het meest voor de hand liggend zijn de efficiëntievoordelen die een ERP-pakket kan bieden. Deze efficiëntieverschillen leiden tot een hogere performance en een hogere winst voor de organisatie, al is een ERP-pakket hier geen garantie voor (Poston et al, 2000). De hogere performance wordt behaald doordat er minder tussenkomst van werknemers vereist is bij processen. Er is sprake van een verregaande automatisering. Deze automatisering is geavanceerder en complexer dan het eenvoudigere MRP-pakket, omdat er sprake is van integratie. De integratie biedt extra performancewinst, omdat gegevens tussen (deel)processen uitgewisseld kunnen worden. Naast extra performancewinst biedt integratie nog een ander voordeel: er is extra managementinformatie beschikbaar. Integratie leidt ertoe dat er informatie beschikbaar is die verder reikt dan de informatie over een enkele module. Poston et al. (2000) noemen dat organisaties ERP-pakketten gebruiken omwille van de geboden flexibiliteit. De door Bakry et al. (2005) genoemde modulariteit is voor organisaties een belangrijke reden om een ERP-pakket te gebruiken. Indien er extra functionaliteit gewenst is, kan de organisatie een extra module aanschaffen bij de leverancier van het ERP-pakket. Door deze modulariteit is de organisatie dus flexibel qua IT-behoefte. Daarnaast kunnen bestaande modulen vervangen worden door modulen met dezelfde functionaliteit maar een betere implementatie (Bakry et al. 2005). De flexibiliteit wordt ook vergroot als de leverancier uitbreidingen op het ERP-pakket aanbiedt. Door het aanschaffen en laten implementeren van een module hoeft de organisatie weinig te doen om nieuwe functionaliteiten te krijgen (Poston et al., 2000). Een derde belangrijke reden voor het gebruik van een ERP-pakket is omdat leveranciers en klanten een dergelijk ERP-pakket gebruiken. Omdat er van de organisatie vereist wordt elektronisch zaken te doen, moet de organisatie overstappen op dit soort software. Dit fenomeen wordt een technologypull genoemd: er wordt door afnemers van leveranciers verlangd een technologie binnen de organisatie te implementeren (Kotler et al., 2003). Een goed voorbeeld hiervan is het gebruik van Ebusiness-functionaliteiten. Een webwinkel moet naast het kunnen tonen van de artikelen het gehele 38

verkoopproces elektronisch kunnen uitvoeren. Te denken valt hierbij aan het kunnen weergeven van de voorraad, het kunnen doorvoeren van complete orders aan de logistieke afdeling en het voeren van de administratie. Het is niet wenselijk om een webwinkel niet-elektronisch te voeren: een handmatige voorraadcontrole, een handmatige controle op kredietwaardigheid en het handmatig doorvoeren van orders naar de afdeling logistiek zouden een aankoop via een webwinkel dagen kunnen laten duren. Omdat de processen de gegevens via een centrale database uitwisselen, is er bij een grote webwinkel alleen tussenkomst nodig indien het fysieke product verzonden moet worden, om het vervolgens (fysiek) aan te bieden bij de klant door de postbode. De webwinkel laat de mate van integratie dus zien. Nonaka et al. (2006) noemt een vierde reden waarom organisaties ERP-pakketten gebruiken. Omdat er een gezamenlijke database gebruikt wordt, is er sprake van het delen van kennis. De impliciete informatie die zich binnen de organisatie bestaat wordt expliciet gemaakt, doordat de informatie in de database wordt opgeslagen. Kennis is voor iedereen beschikbaar, mits zij daar toegang toe krijgen. Een goed voorbeeld van kennisdeling binnen een ERP-pakket is het gebruik van een Customer Relationship Management (CRM) module. Alle contactmomenten met een klant kunnen worden vastgelegd. Bij een volgend contactmoment (per telefoon, per email, enzovoorts) kan een medewerker de gehele geschiedenis van de klant zien om adequaat te kunnen helpen. De vijfde en laatste reden voor het gebruik van een ERP-pakket binnen organisaties is het kunnen vastleggen en afdwingen van procedures. Door het ERP-pakket op de juiste wijze te configureren biedt het geen ruimte voor een andere wijze van het afhandelen van taken en processen. Het geeft het management een vorm van macht: procedures kunnen alleen afgehandeld worden op de in het ERP-pakket vastgelegde wijze (Sia et al., 2002). Dit geeft enerzijds beperking aan de werknemers, maar anderzijds hebben werknemers alle ruimte om binnen de procedures die vastgelegd zijn in het ERP-pakket te opereren. Omdat alles vastgelegd wordt, kan het management in de gaten houden of alles op de juiste wijze gebeurt.

39

4. ERP-pakketten in dit onderzoek

Dit hoofdstuk beschrijft de betekenis en de rol van een ERP-pakket zoals dat in deze masterthesis gezien wordt. Zoals al in het vorige hoofdstuk beschreven is, kan een ERP-pakket voor meerdere toepassingen gebruikt worden. In de eerste paragraaf wordt ingegaan op de soorten ERP-pakketten die er zijn. Verder wordt er besproken wat de verschillen tussen deze soorten zijn en wat de voor- en nadelen zijn. In de tweede paragraaf wordt het doel en nut van de verschillende soorten ERPpakketten beschreven zoals dat in dit onderzoek aan bod komt. De derde paragraaf gaat in op de verschillende niveaus van ondersteuning op het gebied van bedrijfsprocessen. Er wordt hier onderscheid gemaakt in een drietal niveaus. De vierde paragraaf gaat in op de gevolgen van de ondersteuning per niveau.

4.1 Soorten ERP-pakketten

Er zijn diverse manieren waarop een organisatie aan een ERP-pakket kan komen. Een methode is het (laten) ontwikkelen van een ERP-pakket. Voor deze optie geldt dat er een gedegen hoeveelheid kennis in huis moet zijn: niet alleen programmeerkennis, maar eveneens kennis om de bedrijfsprocessen te kunnen inventariseren en te kunnen implementeren in de software. Het grote voordeel van het ontwikkelen van een ERP-pakket is dat ieder onderdeel naar eigen wens gemaakt kan worden. Een groot nadeel is dat de kosten voor ontwikkeling hoog zijn en dat de tijdsduur voor het ontwikkelen lang kan zijn. Daarnaast is er een grote onzekerheid bij de invoering van een dergelijk pakket. Het pakket is immers niet eerder getest in de werkelijkheid. Daar de bedrijfsvoering afhankelijk is van het pakket, is het beperkt mogelijk om versies in het echt te testen. Er schuilt dus een zeker risico bij het invoeren. Een andere, meest voor de hand liggende methode is een ERP-pakket aan te schaffen bij een softwareleverancier. Het ERP-pakket wordt aangeschaft, waarna de leverancier of een andere partij het pakket kan gaan implementeren. Het pakket is veelvuldig getest aangezien vele andere organisaties er al mee werken. De organisatie schaft een “bewezen zekerheid” aan omdat het ERPpakket al bij vele organisaties geïmplementeerd is en naar wens functioneert. De kosten voor de aanschaf van het pakket liggen in de meeste gevallen lager dan die voor het (laten) ontwikkelen van een ERP-pakket. Bekende leveranciers van ERP-pakketten zijn onder andere SAP, Oracle en Unit4Agresso. Een kenmerk van ERP-pakketten die gemaakt worden bij dergelijke leveranciers, is dat 40

de genericiteit van het ERP-pakket hoog is. Dit is noodzakelijk, aangezien een te specifiek pakket niet bij meerdere organisaties te implementeren valt. Vanzelfsprekend is het pakket na aanschaf nog niet direct geschikt om gebruikt te worden. Er dienen vele parameters ingesteld te worden om het pakket naar de wensen van de organisatie te laten werken (Vogt, 2002). Dit traject neemt gemakkelijk enkele maanden tot een jaar in beslag (Hau et al., 2008). De pakketten die ERP-pakketleveranciers leveren kunnen verschillend van aard zijn. Ze kunnen geschikt zijn voor een specifieke branche. Een voorbeeld hiervan is het ERP-pakket Level7, dat uitsluitend voor de verzekeringsbranche geschikt is1. Het ERP-pakket is in dat geval niet geschikt om te implementeren in bijvoorbeeld de bancaire sector. De reden van het niet kunnen ondersteunen van een andere branche, is te wijten aan het gebruikte businessmodel in het ERP-pakket. De businessmodellen komen niet overeen, waardoor het ERP-pakket niet de juiste procesondersteuning kan bieden voor een ander type organisatie. Een ERP-pakket kan ook specifiek gericht zijn op een specifiek onderdeel van de organisatie. Een voorbeeld hiervan is een ERP-pakket dat sterk gericht is op logistieke processen. Het andere type ERP-pakket dat ERP-pakketleveranciers kunnen leveren is een branchegenerieke oplossing. Hiermee wordt bedoeld dat het ERP-pakket in verschillende branches te gebruiken is. SAP is een voorbeeld van een dergelijk pakket2. Het deelt de keuze tussen een ERP-pakket in tussen het midden en kleinbedrijf en grote organisaties. Er wordt dus geen keuze gemaakt in welke branche de organisatie actief is. Dit betekent dat de genericiteit nog hoger moet zijn ten opzichte van een branchespecifiek pakket. Het ERP-pakket moet immers een grotere hoeveelheid businessmodellen ondersteunen. Beide typen ERP-pakketten zijn dus geschikt voor een organisatie indien er gekozen wordt voor de aanschaf van ERP-pakket. Waar met name het verschil in zit, is de ondersteuning van de businessmodellen. Jansen et al. (2003) typeren een businessmodel aan de hand van drie punten: "Een businessmodel is: - een raamwerk voor de product-, dienst- en informatiestromen waarin de rollen van de verschillende partijen in het netwerk beschreven zijn; - een beschrijving van de potentiële voordelen van de verschillende partijen in het netwerk; - een beschrijving van de bronnen van inkomsten (Timmers, 1998)." 1 2

Zie: http://www.ccs.nl Zie: http://www.sap.com

41

Ethiraj et al. (2000) geven de volgende definitie van het businessmodel: "een business model is een unieke configuratie van elementen die bestaat uit de strategie, processen, technologieën en de besturing van de organisatie. Deze configuratie is gevormd om de waarde te creëren voor de klanten en dus om succesvol te kunnen concurreren in een bepaalde markt." Het businessmodel is in feite de keuze van het management over hoe de organisatie haar doelstellingen kan behalen en met welke middelen dit moet gebeuren. De verschillen in branchespecifieke ERP-pakketten en branchegenerieke ERP-pakketten zitten zoals zojuist genoemd in de ondersteuning van de businessmodellen. Een branchespecifiek ERP-pakket is gericht op de ondersteuning voor een bepaald aantal businessmodellen gericht binnen een branche. Dergelijke pakketten schotelen een min of meer vaststaand businessmodel voor aan de organisatie. Indien de organisatie een ander, afwijkend businessmodel hanteert, zal de implementatie op problemen stuiten. Het gevolg hiervan is een ERP-pakket dat niet alle processen of alle producten op de juiste manier ondersteund, omdat het door de organisatie gehanteerde businessmodel niet gerepresenteerd wordt door het ERP-pakket (Soh et al., 2000). Het ERP-pakket is overigens te parametriseren, waardoor variaties in de door de leverancier opgelegde businessmodellen mogelijk zijn (Vogt, 2002). ERP-pakketten die branchegeneriek zijn, zijn breder inzetbaar. Alhoewel deze ERP-pakketten vaak een aantal basisbusinessmodellen meebrengen, moet het ERP-pakket voor implementatie uitvoerig ingesteld worden door middel van parameters. Het parametriseren hoeft minder te gebeuren naarmate het voorgedefinieerde businessmodel meer op dat van de organisatie lijkt (Hau et al., 2008). Het parametriseren vereist dat het businessmodel bekend is bij de organisatie en dat alle modulen geparameteriseerd kunnen worden in de betreffende domeinen. Alhoewel organisaties een missie, visie en strategie gedefinieerd hebben, kan er in de loop der jaren veel veranderd zijn waardoor er in werkelijkheid een ander businessmodel wordt gehanteerd. Dit oude businessmodel zit in dat geval impliciet in de door de organisatie gebruikte applicaties, maar is niet expliciet gemaakt (Govers, 2003). Er moet sprake zijn van een "strategic fit" tussen de organisatie en het ERPpakket ( Yen et al., 2004). Het is niet eenvoudig dit te bereiken, aangezien er vele belanghebbenden zijn, er technologie ingevoerd wordt dat niet uitvoerig getest wordt, of doordat een reeks van "bestpractices"niet werkt binnen de organisatie (Wang et al., 2006). Naast de keuze voor het zelf ontwikkelen van software of het aanschaffen van software is er eveneens een mix mogelijk: er kan een deel van het ERP-pakket zelf ontwikkeld worden, terwijl een ander deel van het ERP-pakket aangeschaft wordt bij een ERP-leverancier. Dit is een mogelijke oplossing indien er sprake is van een dusdanig specifieke organisatie met een specifiek 42

businessmodel dat niet voldoende te automatiseren is in het door de leverancier geleverde ERPpakket. Het ook mogelijk dat een ERP-pakket niet alle gewenste functionaliteiten bevat, zodat er door de organisatie software wordt ontwikkeld om deze functionaliteiten wel te ondersteunen.

4.2 Het doel van ERP-pakketten

Zowel de branchespecifieke als de branchegenerieke ERP-pakketten hebben tot doel om processen in samenhang te ondersteunen. Alhoewel de beschikbaarheid in businessmodellen van beide soorten pakketten verschilt, is het doel voor beide soorten ERP-pakketten om de bedrijfsvoering breed te automatiseren door middel van software. Dit wijkt niet af van de gevonden resultaten in het vorige hoofdstuk. In dit onderzoek wordt het automatiseren van bedrijfsprocessen in twee onderdelen opgesplitst: 1. Een ERP-pakket biedt ondersteuning aan bedrijfsprocessen doordat er per proces geautomatiseerd wordt; 2. Een ERP-pakket biedt coördinatie over bedrijfsprocessen, waardoor de som der processen een meerwaarde heeft boven het los ondersteunen per proces. De ondersteuning van bedrijfsprocessen is in het voorgaande hoofdstuk uitgebreid aan de orde geweest. De ondersteuning van bedrijfsprocessen is een vorm van automatiseren, waardoor er efficiënter gewerkt kan worden en er meer rapportagemogelijkheden zijn. De coördinatie over bedrijfsprocessen is het tweede voordeel van automatiseren door middel van een ERP-pakket. Door processen te coördineren en gegevens te bundelen, ontstaat er een vorm van integratie. Malone et al. (1994) geven de volgende definitie van coördinatie: "Coördinatie is het managen van afhankelijkheden tussen activiteiten". Deze afhankelijkheden zijn uitermate belangrijk om integratie te bereiken: zonder afhankelijkheden is er geen integratie, aangezien integratie processen van elkaar afhankelijk maakt. De combinatie van procesondersteuning en de coördinatie van de processen teneinde integratie mogelijk te maken worden in dit onderzoek gezien als de substantiële bijdragen van het ERP-pakket. Om procesondersteuning mogelijk te maken wordt software gebruikt. Zoals al genoemd in het voorgaande hoofdstuk leidt het aanschaffen van meerdere softwarepakketten niet automatisch tot een vorm van integratie. Het laten wegschrijven van gegevens in een gezamenlijke database leidt op zichzelf eveneens niet tot integratie. Om deze reden wordt coördinatie in dit onderzoek gezien als een vorm om integratie te bereiken. De coördinatiecapaciteit is ingebed in een

43

ERP-pakket, maar zal op de juiste wijze geconfigureerd moeten worden indien deze coördinatie tot integratie moet leiden. Een extra doel van een ERP-pakket zoals dat in dit onderzoek gebruikt wordt is de beschikbaarheid van managementinformatie. Dit heeft een tweetal oorzaken: 1. Doordat het proces geautomatiseerd is, kan er eenvoudig en elektronisch bijgehouden worden wat de status van het proces is, wat de statistieken zijn en waar het in het proces eventueel mis gaat; 2. Doordat er integratie bereikt wordt in een ERP-pakket, kan er niet alleen per proces worden bijgehouden waar de pijnpunten zitten, maar prestaties en statistieken tussen processen onderling kunnen eveneens worden bijgehouden. Door over managementinformatie te beschikken kan een goed beeld verkregen worden van processen die niet efficiënt, niet snel genoeg of met een te lage snelheid verlopen. Een proces kan teveel uitval hebben, waardoor dezelfde situatie ontstaat Er kunnen ook andere zaken aan het licht komen, bijvoorbeeld dat er structureel te weinig voorraad aanwezig is, waardoor een product niet gemaakt kan worden, zodat een klant (te) lang op zijn order moet wachten. Alhoewel dit soort toepassingen bij kunnen dragen aan het verkrijgen van een hogere uitvoeringskwaliteit, kan het leiden tot het verkrijgen van teveel informatie. Iedere status van een proces kan het management zien, wat wellicht kan leiden tot het overijverig gaan bijhouden van statistieken (Sia et al., 2002). Daarnaast moeten sommige processen herontworpen worden zodat er managementinformatie verkregen kan worden (Sumner, 2000). Het bedrijf wordt in dit geval aangepast aan het ERP-pakket, en niet andersom. Dit is vanzelfsprekend onwenselijk.

4.3 Verschillende niveaus van ondersteuning

Een ERP-pakket kan op verschillende niveaus ondersteuning bieden aan bedrijfsprocessen. Voor dit onderzoek worden drie niveaus onderscheiden. Het eerste niveau biedt louter ondersteuning op basisprocessen. Er is in het eerste niveau geen sprake van integratie en coördinatie. Taken die geautomatiseerd kunnen worden, zoals het aanbieden van artikelen via een webshop, reiken niet verder dan slechts het kunnen doen van een bestelling. Merk hierbij op dat gebruikelijke zaken als debiteurencontrole en voorraadcontrole dan achterwege blijven. Er moet in de situatie waarbij het eerste niveau van ondersteuning gehanteerd 44

wordt veel handmatig gebeuren. De gebruikte softwaremodulen functioneren als het ware los van elkaar: voor ieder proces zou andere, onafhankelijke softwarepakket gebruikt kunnen worden. Er wordt in het eerste niveau van ondersteunen geen gebruik gemaakt van een gedeelde database. Als er data wordt opgeslagen, dan wordt dit niet gebruikt door andere softwareondersteunende processen. Porter (1985) maakt in zijn value-chain framework een onderscheid tussen primaire processen en ondersteunende processen (zie paragraaf 3.1). De primaire processen zijn essentieel om de bedrijfsdoelstellingen te behalen. De ondersteunende processen zorgen dat de primaire processen uitgevoerd kunnen worden. Een ERP-pakket kan de zowel de primaire als de ondersteunende processen automatiseren. Een voorbeeld van is een Customer Relationship Management (CRM)module. Het gebruik van een CRM-module heeft pas volledig nut indien er integratie plaats vindt, omdat gegevens van aankopen en klantcontacten in andere modulen wordt geregeld. Er is in het eerste ondersteuningsniveau geen integratie, waardoor een module als CRM niet volledig benut kan worden. Een voordeel van het eerste ondersteuningsniveau is dat de software eenvoudig te vervangen is. Er is immers geen afhankelijkheid van andere processen en hun ondersteuning. Dit is tegelijkertijd ook het nadeel, omdat er geen totaaloverzicht kan ontstaan. Het tweede niveau van ondersteuning biedt aanzienlijk meer functionaliteiten, omdat er gegevens tussen processen uitgewisseld kunnen worden. Daarnaast kunnen de statussen van activiteiten bijgehouden worden, zodat andere activiteiten daarop in kunnen spelen. Er moet hier coördinatie plaatsvinden: zonder coördinatie is de verzameling van informatie over de procesondersteuning niet nuttig. Dit betekent dat verschillende pakketten gebruikt kunnen worden zoals dat in het eerste niveau mogelijk was, omdat de coördinatie lastig te bewerkstelligen is. Er moet één pakket gebruikt worden dat zowel de integratie als de coördinatie op zich neemt. Qua opslag wordt er gebruik gemaakt van een gezamenlijke database. Deze database maakt gegevensuitwisseling tussen activiteiten mogelijk. Daarnaast biedt deze database de mogelijkheid om managementinformatie te verkrijgen, omdat alle data in een database zit. Het is hierdoor mogelijk om verbanden te kunnen leggen en te kunnen constateren waar processen spaak lopen of een proces niet optimaal doorlopen wordt. Overigens moet er een voorziening in het softwarepakket ingebouwd zijn om dergelijke data goed te kunnen gebruiken. Het hebben van een database met data is niet zinnig indien deze data niet in de juiste context kan worden getoond. De mate van managementinformatie is dus sterk afhankelijk van het gekozen softwarepakket, en niet alleen van de opgeslagen data. 45

Merk op dat er twee methoden zijn om gegevens uit te wisselen: - Via processen of activiteiten onderling door middel van de status van een proces of activiteit. Indien een bepaalde staat bereikt is dan wordt dit door een ander proces of activiteit als een trigger gezien om te starten of stoppen. - Via de gezamenlijke database door middel van de opgeslagen data. Deze data kan als input dienen voor andere processen. Een voorbeeld hiervan zijn adresgegevens die opgeslagen zijn van een klant om een marketingactie te kunnen sturen. Een CRM-module zou hierbij kunnen ondersteunen. Het derde ondersteuningsniveau biedt voor de interne organisatie een vergelijkbare functionaliteit zoals dat in het tweede ondersteuningsniveau geldt. Er is echter een kenmerkend verschil tussen beiden. Het tweede ondersteuningsniveau is een gesloten systeem, dat alleen processen van de eigen organisatie betreft. Externe factoren worden niet meegenomen in de software, doordat er geen “contact” is met de buitenwereld. Dit type ondersteuningsniveau wordt door Bakry et al. (2005) en Muntslag (2001) aangeduid als een ERP-pakket. Het derde ondersteuningsniveau kan samenwerken met organisatieonderdelen van andere organisaties, zoals Gefen (2004) omschrijft. Hierdoor ontstaat de mogelijkheid om in te kunnen grijpen als een leverancier haar producten niet op tijd kan leveren. Anderzijds kunnen klanten op tijd te weten komen dat een besteld product niet op tijd geleverd kan gaan worden. De gehele keten wordt op deze manier beter geïnformeerd en kan betere service en kwaliteit bieden (Damen, 2005). Dit fenomeen staat bekent als ketenintegratie (Venkateswaran et al., 2002). Alt et al. (2000) geven aan dat er sprake is van netwerkfunctionaliteit. De keten kan als een netwerk gezien worden. Alhoewel er meer informatie beschikbaar is, maakt ketenintegratie gebruik van een ERP-pakket dat afhankelijkheden met de buitenwereld kent. Het ERP-pakket moet hiervoor geschikt zijn. Door de afhankelijkheden kan een onjuistheid in het ERPpakket enorme gevolgen hebben, omdat er meerdere organisaties van afhankelijk zijn. De angst kan ontstaan dat andere organisaties het voor het zeggen krijgen binnen de eigen organisatie. Het is de keuze van het management in hoeverre de integratie door werkt binnen de organisatie. Dit kan variëren van slechts informeren over de voorraadstatus, tot aan het automatisch aanpassen van orderhoeveelheden. Zoals Alt et al. (2000) al noemt, zit er weinig verschil tussen ondersteuningsniveau 2 en ondersteuningsniveau 3. Het enige grote verschil is de netwerkfunctionaliteit met andere organisaties. Porter (1985) zegt dat organisaties allen deel uitmaken van een grote value-chain: een geleverd product vormt de inkomende logistiek voor de organisatie die het product afneemt. Hoe

46

beter leveranciers en afnemers in de value-chain informatie uitwisselen, hoe efficiënter de valuechain kan werken (Porter, 1985). Organisaties die werken met een ERP-pakket dat ondersteuningsniveau 3 hanteert, moeten in ieder geval het tweede ondersteuningsniveau hanteren. Indien een organisatie dit niet hanteert, mist de integratie tussen de onderdelen. Het is niet zinnig om extern georiënteerd wel te integreren, terwijl dit intern niet gebeurt (Alt et al., 2000). Alle drie de ondersteuningsniveaus werken met softwareondersteuning, maar slechts bij ondersteuningsniveau twee en ondersteuningsniveau drie is er sprake van integratie. Alhoewel ERPpakketten gebruikt kunnen worden voor het automatiseren van een enkel proces, is het niet nuttig om dit te doen. ERP-pakketten zijn ervoor ontworpen om integratie te bereiken. Door ondersteuningsniveau 1 te gebruiken, is er alleen sprake van automatisering en wordt een groot gedeelte van de mogelijke efficiëntie niet bereikt. Overigens kan er niet altijd geïntegreerd worden, doordat technologie en de gebruikte systemen dit kunnen belemmeren (Henkel et al., 2004). Organisaties hoeven hier niet bewust voor te kiezen, het niet kunnen integreren kan achteraf pas blijken. Voor dit onderzoek wordt verondersteld dat een geïmplementeerd ERP-pakket minimaal ondersteuningsniveau 2 hanteert, waarbij er sprake is van integratie van bedrijfsonderdelen. De drie gevonden definities in het vorige hoofdstuk spreken allen ook van integratie bij een ERP-pakket.

47

4.4 Gevolgen van de ondersteuningsniveaus

De drie ondersteuningsniveaus verschillen enorm als er gekeken wordt naar de integratie. Des te meer integratie, des te meer de techniek en de business verweven zijn met elkaar (Hasselbring, 2000). Er is in de vorige paragraaf genoemd dat integratie een voordeel biedt als het gaat om gegevensuitwisseling en functionaliteit. Dit zou suggereren dat een ERP-pakket dat gebruik maakt van ondersteuningsniveau 2 of 3, altijd voordeel zou bieden ten opzichte van softwareondersteuning op ondersteuningsniveau 1. Ragowski et al. (2008) vinden hier geen bewijs voor. Wel staat vast dat er meer informatie beschikbaar is in het ERP-pakket indien er geïntegreerd en gecoördineerd wordt. Martinsons (2004) noemt dat een ERP-pakket door vele factoren niet zonder meer te implementeren is. Wellicht dat daarom niet iedere organisatie gebruik maakt van een ERP-pakket en er slechts losse processen geautomatiseerd worden met software. Complexiteit ontstaat indien een systeem uit veel componenten bestaat, er veel relaties zijn tussen componenten of subsystemen, de relaties tussen componenten niet gelijk zijn en de samenstelling van de componenten niet gelijk is (Backlund, 2002; Phippen, 2005). Ondersteuningsniveau 1 heeft de laagste hoeveelheid complexiteit, omdat er minder relaties zijn tussen componenten. Er is immers geen integratie aanwezig. De complexiteit is in het tweede ondersteuningsniveau aanzienlijk hoger dan de complexiteit van het eerste ondersteuningsniveau, aangezien het aantal relaties groter is. Het derde ondersteuningsniveau heeft de hoogste complexiteit. Er zijn immers nog meer asymmetrische relaties aanwezig door koppelingen met andere organisaties. Zoals zojuist genoemd is er bij een hogere mate van integratie een hogere businessverwevenheid met de techniek. Dit heeft invloed op de afhankelijkheid van de techniek. Door meer integratie wordt de afhankelijkheid van het ERP-pakket eveneens verhoogd. Een fout in het ERP-pakket werkt dan verder door in de organisatie (Stedman, 1998). Het vervangen van componenten in het ERP-pakket met ondersteuningsniveau 2 of 3 is een risicovolle onderneming: - Het ERP-pakket en de samenhangende componenten zijn complex; - De business is sterk afhankelijk van het ERP-pakket: als het mis gaat, gaat het goed mis. Het management van een organisatie kiest toch vaak voor een ERP-pakket dat gebruik maakt van integratie en coördinatie (Everdingen et al., 2000). Het zelf (laten) ontwikkelen van een ERP-pakket leidt er niet alleen toe dat er veel geïnvesteerd moet worden, maar leidt eveneens tot risico’s, omdat het ERP-pakket niet door en door getest is in de praktijk. Onder andere om deze reden kiezen

48

organisaties voor een generiek ERP-pakket. Veel organisaties gebruiken dit pakket reeds, waardoor er een vorm van "bewezen zekerheid" ontstaat (Kumar et al., 2000). Daarnaast kan een gedeelte van het risico afgekocht worden door middel van servicecontracten. Dit is niet mogelijk indien er zelf een ERP-pakket ontwikkeld wordt, omdat de leverancier van het pakket tegelijkertijd de afnemer is. Het veranderen van een ERP-pakket of van een gedeelte ervan blijft een riskante taak. Kennis is wellicht aanwezig bij de leverancier van het ERP-pakket, maar dit biedt geen garanties dat een verandering tot het gewenste resultaat leidt door de vele afhankelijkheden die er in het ERP-pakket aanwezig zijn. Daarnaast is de vraag hoever de service van de leverancier gaat, en welk risico de leverancier op zich wil nemen. "Even" een ERP-pakket aanpassen mondt vaak uit in ellenlange projecten, die in sommige gevallen zelfs falen (Markus et al.,2000). De organisatie zit in dat geval vast aan het verouderde ERP-pakket met verouderde functionaliteiten. De organisatie wil veranderen, maar het ERP-pakket laat dit slecht toe. Het niet veranderen van onderdelen van het ERP-pakket kan leiden tot nadelen, omdat nieuwe technieken niet te implementeren zijn (Kim, 1997). Hierdoor kan de organisatie moeilijker technologische vooruitgang boeken. De organisatie zit in een spagaat: Het ERP-pakket kan slechts veranderd worden door hoge kosten en met hoge risico's terwijl het handhaven van de huidige situatie met het oude ERP-pakket leidt tot (concurrentie)nadeel.

49

5. Legacy Zoals uit het vorige hoofdstuk bleek, kan het lastig zijn om een ERP-pakket te vervangen. Dit is te wijten aan de afhankelijkheden van de organisatie van het ERP-pakket. Dit hoofdstuk gaat in op het probleem van legacy. Dit hoofdstuk wordt ingedeeld in een tweetal delen: ICT -legacy en businesslegacy. Allereerst wordt er ingegaan op ICT-legacy. Hierin wordt uitgelegd wat ICT-legacy is en hoe het ontstaat. De tweede paragraaf gaat in op een model wat de volwassenheid van ERP-pakketten en ICT-legacy bespreekt. De derde paragraaf noemt enkele oplossingen uit de literatuur om ICT-legacy te voorkomen of om ICT-legacy op te ruimen, zodat het vervangen van ICT-componenten eenvoudiger is. De vierde paragraaf gaat in op business-legacy, waarin wordt uitgelegd wat businesslegacy is. Tot slot van dit hoofdstuk wordt er in de vijfde paragraaf gezocht naar oplossingen om business-legacy te voorkomen of op te ruimen.

5.1 ICT-legacy

ICT-legacy wordt in de literatuur op diverse manieren getypeerd. Thiran et al. (2006) omschrijft ICTlegacy als "een probleem van gemixte architecturen die lijden aan heterogeniteit". Sneed et al. (2001) omschrijft ICT-legacy als volgt: "Legacy blokkeert de migratie van een oud systeem, omdat oude applicaties data benaderen uit een database, waardoor het niet mogelijk is om de structuur van de data aan te passen zonder dat de logica van de applicaties veranderd wordt". Sommerville (2000) omschrijft ICT-legacy als "een oud systeem dan nog steeds essentiële bedrijfsfuncties vervuld". Vier belangrijke kenmerken komen hierbij naar boven: - er worden verschillende architecturen gebruikt die blijkbaar niet goed te combineren zijn; - er is sprake van een mate van afhankelijkheid; - migratie naar een nieuw systeem wordt door legacy bemoeilijkt; - het ICT-systeem vervult essentiële bedrijfsfuncties. In deze thesis wordt ICT-legacy als volgt gedefinieerd: "ICT-legacy is een onderdeel van de informatievoorziening dat getracht wordt te veranderen maar dat wordt door technische oorzaken en organisatorische afhankelijkheden bemoeilijkt". ICT-legacy is dus niet louter technisch van aard omdat organisatorische afhankelijkheden een grote rol spelen. ICT-legacy wordt gezien als een probleem, omdat het verandering van de ICT-voorziening 50

in de weg staat. Er kan zodoende geen nieuwe technologie geïmplementeerd worden, wat leidt tot concurrentienadeel (Lloyd et al., 1999). Indien de vereiste belasting van een systeem toeneemt terwijl dat aan ICT-legacy onderhevig is, dan is de verwerkingssnelheid slecht in te schatten (Jin et al., 2007). De uitbreidbaarheid van een ERP-pakket dat aan ICT-legacy onderhevig is, is helaas eindig (Jacobs, 2005). ICT-legacy belemmert dus de uitbreiding van de organisatie, omdat bij uitbreiding een verhoogde capaciteit benodigd is door meer gebruikers en meer data (Jin et al., 2007). Tegelijkertijd blijkt uit onderzoek (Themistocleous et al., 2001) dat slechts twee van de 67 organisaties ICT-legacy kan laten samenwerken met een nieuw ERP-pakket en dat ICT-legacy de integratie bemoeilijkt. ICTlegacy is dus een obstakel voor organisaties die van ERP-pakket willen veranderen. Kim (1997) wijt het ontstaan van ICT-legacy aan slechte documentatie, "spaghetticode" zonder duidelijke structuur, te weinig personeel met kennis van zaken en een gebrek van het ICT-systeem aan performance en adaptatievermogen. ICT-legacy kan zich overigens voordoen bij een zowel een zelfontwikkeld ERP-pakket als bij een aangeschaft en goed gedocumenteerd ERP-pakket, dat door de leverancier ondersteund wordt (Nah et al., 2001). De genoemde mogelijke soorten ERP-pakketten in het vorige hoofdstuk geven aan dat de ERP-pakketten een zekere mate van complexiteit bevatten: er wordt een standaardproduct (het ERP-pakket) geleverd, waarna er diverse parameters ingesteld moeten worden. Deze parameters leggen de functionaliteiten vast. Daarnaast wordt het pakket aangepast op de huidige IT-configuratie van de organisatie. Het ERP-pakket moet de huidige ITinfrastructuur van de organisatie respecteren. Na het testen van het ERP-pakket wordt er overgestapt op het nieuwe ERP-pakket (Beatty et al., 2006). Na verloop van tijd kunnen diverse zaken veranderen, bijvoorbeeld door een nieuwe strategie of door nieuwe functionaliteitwensen. Het businessmodel verandert in dat geval. Het businessmodel dat het ERP-pakket ondersteund, is dan niet meer de juiste. Dit kan inhouden dat de keuze gemaakt wordt om een nieuw ERP-pakket aan te schaffen, of dat er aanpassingen worden gedaan in het ERPpakket door middel van andere parameters. Een gedegen planning is noodzakelijk: het wijzigen of het veranderen van een ERP-pakket brengt een risico met zich mee omdat de organisatie sterk van het ERP-pakket afhankelijk is. Het aanpassen van het ERP-pakket is een gebeurtenis die vaak wenselijk kan zijn binnen organisaties. Het opstapelen van deze aanpassingen kan leiden tot niet bijgewerkte of onjuiste systeemdocumentatie. Daarnaast zijn de aanpassingen vaak gericht op een losse module en laten soms de werking van het gehele ERP-pakket buiten beschouwing. De parameters zijn wellicht niet terug te vinden in de documentatie, omdat deze door eerder uitgevoerde aanpassingen aan het ERP-pakket niet is bijgewerkt. Het kost in een dergelijk geval zeer veel tijd om de parameters en instellingen te achterhalen omdat ieder onderdeel van het ERP-pakket geanalyseerd moet worden (Earls et al., 2002). 51

Sommerville (2000) noemt een extra item dat het vervangen lastig maakt met betrekking tot de documentatie: zelfs al is de gehele configuratie bekend, dan is het vrijwel onmogelijk om een nieuw ERP-pakket aan te schaffen met exact dezelfde onderdelen,relaties en modellen, aangezien het niet om exact hetzelfde "oude" ERP-pakket gaat. Ontbrekende documentatie is niet de enige oorzaak van het ontstaan van ICT-legacy. Zoals Kim (1997) noemt is "spaghetticode" eveneens een oorzaak. Hier zou slechte documentatie de oorzaak van kunnen zijn: omdat er niet is bijgehouden hoe de applicaties in elkaar zitten, verliest men het geheel uit het oog. Dit wordt verergerd indien er sprake is van afhankelijkheden en integratie, omdat er dan relaties tussen de software ontstaan, zodat de complexiteit verhoogd wordt (Backlund, 2002; Phippen, 2005). Een andere reden voor het ontstaan van "spaghetticode" is de aanschaf van losse softwarepakketten of losse softwareapplicaties die op een bepaalde manier geïntegreerd moeten worden in de huidige ERP-pakketomgeving. Zeker indien er gebruik gemaakt moet worden van hulpsoftware om deze integratie te bereiken, is de complexiteit enorm. De reden voor het gebruik van deze hulpsoftware is bijvoorbeeld omdat de nieuwe te implementeren softwareapplicatie niet overweg kan met de gebruikte databasestructuur van het ERP-pakket (Thiran et al., 2006; Sneed, 2001). “Spaghetticode” is alleen te vermijden indien de programmacode van het ERP-pakket bekend is. Dit is bij gekochte ERP-pakket vaak niet het geval, omdat de leverancier deze code niet vrij geeft. Het niveau van het personeel dat het ERP-pakket moet onderhouden is essentieel voor het omgaan met ICT-legacy (Nah et al., 2001). Zonder goed gekwalificeerd personeel kan het ERP-pakket niet goed onderhouden worden, zodat de kans op slecht functionerende software toeneemt. De betrouwbaarheid en de verwerkingssnelheid van het ERP-pakket wordt hierdoor lager, of de foutmarge wordt hierdoor hoger. Het gevaar bestaat dat gekwalificeerd personeel de organisatie verlaat, zodat de kennis over het systeem verloren gaat (Dittrich et al. 2008). Indien er achterhaald moet worden hoe het ERP-pakket werkt, dan zal de organisatie terug moeten vallen op de documentatie. Deze is echter vaak incompleet, zoals hierboven al beschreven is. Het gebrek van het ERP-pakket aan performance en adaptatievermogen zoals Kim (1997) dat omschrijft, is zowel een oorzaak als een gevolg van ICT-legacy. Omdat het ERP-pakket een slecht adaptatievermogen heeft, wordt er gekozen voor het gebruik van hulpsoftware om nieuwe modulen te kunnen integreren. Deze leiden weer tot extra afhankelijkheden en gaan ten koste van de performance. Het systeem kan immers niet sneller zijn dan het langzaamste component. Dit leidt tot een voedingsbodem van ICT-legacy, omdat het veranderen bemoeilijkt wordt en de capaciteit beperkt wordt. Anderzijds worden er door organisaties die niet meer eenvoudig van ERP-pakket kunnen wisselen juist uitgeweken naar lapmiddelen doordat er extra converters "tussen" nieuwe 52

functionaliteit en de ICT-legacy wordt gelegd. De organisatie kan niet eenvoudig veranderen van ERPpakket (of kan slecht nieuwe functionaliteiten toevoegen), en ziet als enige mogelijkheid om extra software te gebruiken om nieuwe functionaliteiten toe te kunnen voegen (Sneed, 2001). Vanzelfsprekend geldt ook hier weer dat de performance achteruit gaat door meer afhankelijkheden en meer componenten.

5.2 Volwassenheid ERP-pakketten en ICT-legacy Holland et al. (2001) hebben een volwassenheidsmodel ontwikkeld waarbij de staat van het ERPpakket bepaald kan worden aan de hand van de fase waarin dit ERP-pakket zich bevind. Het volwassenheidsmodel bestaat uit een drietal fasen. - In de eerste fase heeft de organisatie te maken met ICT-legacy en heeft de het behoefte om te veranderen. In de eerste fase wordt een ERP-pakket gezocht dat het best bij de organisatie past. De huidige ICT-legacy wordt in kaart gebracht om een mogelijk scenario te bedenken om ICT-legacy te bestrijden. - In de tweede fase van het volwassenheidsmodel wordt het ERP-pakket geïmplementeerd en geconfigureerd in de organisatie. De functionaliteiten worden in de organisatie uitgerold en het personeel wordt getraind om het ERP-pakket te kunnen gebruiken. - In de derde fase is het pakket volledig geïmplementeerd en benut de organisatie de voordelen van het ERP-pakket ten volle. De investeringen die in het verleden gedaan zijn worden nu terugverdiend. Ook wordt het ERP-pakket uitgebreid met extra functionaliteiten (zoals CRM) die extra winst kunnen genereren. De bepaling van de fasen gebeurt op basis van de hoogte van de kosten, de hoeveelheid onduidelijkheid van het ERP-pakket, het complexiteitsniveau, de flexibiliteit en de concurrentievoordelen. Opvallend is dat in de eerste fase, waarbij de organisatie te maken heeft met ICT-legacy, de kosten het hoogst zijn. Dit is vanzelfsprekend niet volledig toe te schrijven aan ICTlegacy, omdat de kosten voor het ERP-pakket eveneens aanzienlijk zijn. Toch wordt er in het onderzoek genoemd dat bijvoorbeeld de consultancykosten hoog zijn, omdat de ICT-legacy in kaart moet worden gebracht. Als er gekeken wordt naar de hoeveelheid onduidelijkheden in het ERPpakket, dan is dit in de eerste fase het hoogst. Naarmate de organisatie meer naar de derde fase gaat wordt de onduidelijkheid in het ERP-pakket lager. De complexiteit is in de eerste fase het hoogst,

53

mede doordat ICT-legacy moeilijk te doorgronden is. Het aantal afhankelijkheden en het aantal componenten in het ERP-pakket is bepalend voor de hoeveelheid complexiteit. De complexiteit wordt in de tweede fase lager, maar neemt in de derde fase weer toe doordat er nieuwe mogelijkheden en functionaliteiten in het ERP-pakket worden geïmplementeerd, wat weer leidt tot extra afhankelijkheden. De flexibiliteit is in de eerste fase laag. Holland et al. (2001) noemen dat de flexibiliteit een groot probleem is, omdat er sprake is van ICT-legacy in de eerste fase. In de tweede fase is de flexibiliteit beter door een gestandaardiseerd ERP-pakket, maar in de derde fase neemt deze flexibiliteit juist weer af. Dit is te wijten aan de verhoogde afhankelijkheden die ontstaan door de extra functionaliteiten. Tot slot zijn de concurrentievoordelen in de eerste fase het laagst. In de tweede fase is dit al iets hoger, terwijl de derde fase het hoogste niveau laat zien omdat er nieuwe technologieën in het ERP-pakket ingebed zijn. Zoals duidelijk terugkomt in het onderzoek van Holland et al. (2001) is ICT-legacy een probleem voor het vervangen van een ERP-pakket. Wat opvalt, is dat er in de derde fase alweer een nieuwe voedingsbodem ontstaat voor ICT-legacy. Dit is te wijten aan het feit dat een organisatie die aan het eind van de derde fase haar ERP-pakket wil vervangen, zich feitelijk weer in de eerste fase bevind. Omdat er ICT-legacy bestaat binnen de organisatie, gaat de flexibiliteit omlaag en de hoeveelheid onduidelijkheid in het ERP-pakket, de complexiteit en de concurrentienadelen omhoog. Opvallend in het onderzoek van Holland et al. (2001) is dat er van de 24 onderzochte organisaties er slechts drie zich in de derde fase bevinden. 21 van de onderzochte organisaties bevinden zich dus in de eerste of tweede fase. Beide fasen hebben te maken met de verschuiving van het oude ERPpakket naar een nieuw ERP-pakket. De hoge kosten die een migratie van een ERP-pakket met zich mee brengt doordat er sprake is van ICT-legacy kunnen een obstakel zijn om te vervangen. Voor het implementeren van een nieuw ERPpakket is het oplossen van het ICT-legacy probleem een kritieke factor voor het slagen van de implementatie (Nah et al., 2001). Indien het ICT-legacyprobleem niet opgelost wordt, is het lastig om te migreren naar een nieuw ERP-pakket. Omdat de organisatie concurrentienadeel ondervindt, wil het graag overstappen naar een nieuw ERP-pakket. De afhankelijkheden en risico's die kleven aan het vervangen zijn hoog. De organisatie begeeft zich in een spagaat: Moet het ERP-pakket vervangen worden, en zo ja, tegen welke risico's en welke kosten?

54

5.3 Maatregelen tegen ICT-legacy Vanzelfsprekend hoeven organisaties zich niet als verloren te beschouwen indien er ICT-legacy ontstaat. Alhoewel ICT-legacy een probleem is, zijn er diverse maatregelen om ICT-legacy te voorkomen. Enkele maatregelen zijn genoemd in de door Kim (1997) aangedragen oorzaken: - Zorg dat de documentatie op orde blijft, zodat de exacte werking van het systeem altijd na te gaan is; - Vermijd "spaghetticode" zodat er een heldere structuur blijft (dit geldt overigens alleen voor zelfgebouwde software, omdat er bij de aanschaf van een ERP-pakket louter parameters ingesteld dienen te worden); - Zorg dat er voldoende gekwalificeerd personeel beschikbaar is; - Zorg dat de performance van het systeem en het adaptatievermogen op orde blijven. Alhoewel er door de organisatie gezorgd kan worden voor een up-to-date documentatie, worden de andere drie maatregelen vaak door externe factoren beïnvloed, zodat de organisatie daar nauwelijks invloed op kan uitoefenen. Het vermijden van “spaghetticode” kan alleen door het bedrijf dat de software implementeert bewerkstelligd worden. Indien de organisatie zelf de softwaremaker is, dan ligt de verantwoording bij haarzelf. Ditzelfde geldt voor de maatregel om de systeemperformance en het adaptatievermogen van het ERP-pakket op orde te houden. De organisatie zou er wel voor kunnen kiezen om voldoende budget beschikbaar te stellen voor het onderhoud voor een dergelijk pakket. Indien er sprake is van achterstallig onderhoud aan het ERP-pakket dan kan dit leiden tot performanceproblemen en beveiligingsproblemen, bijvoorbeeld omdat dat laatste updates niet geïnstalleerd zijn. Des te langer een ERP-pakket werkt en er onderhoud aan gepleegd is, des te hoger de betrouwbaarheid wordt (Suresh et al., 1996). Diverse artikelen schrijven over het succes van Service Oriented Architecture (SOA) (Papazoglou et al., 2007; O'brien et al., 2008). Dit is een IT-architectuur dat gebruik maakt van een zogenaamde service bus waarover data verzonden wordt. De service bus levert de data af bij de juiste module(n). Het in de artikelen beschreven voordeel is dat de modulen onafhankelijk van elkaar werken, zodat een module eenvoudig toegevoegd, gewijzigd of verwijderd kan worden. O'Brien et al. (2008) noemen dat een tekort aan performance een bekend probleem is van SOA. SOA moet zichzelf dus nog bewijzen als effectief middel tegen ICT-legacy (Schepers et al., 2008).

55

Indien een organisatie te maken krijgt met ICT legacy, dan zijn er diverse methoden om de ICT-legacy te doorgronden. Een methode is door onderdelen van het ERP-pakket te isoleren. Vervolgens wordt dit geïsoleerde deel grondig onderzocht op de werking (Kim, 1997). Dit wordt "reverse engineering" genoemd. De vraag rijst of een dergelijke aanpak een goed overzicht geeft van de afhankelijkheden die onderling tussen de geïsoleerde onderdelen bestaan. Met andere woorden: het overzicht over het geheel dreigt uit het oog verloren te worden indien er gekeken wordt naar geïsoleerde onderdelen. Een andere methode om ICT-legacy te bestrijden is door de ICT-legacyonderdelen die ongewenst zijn om te zetten in onderdelen die hergebruikt kunnen worden (Sneed, 2001). Dit leidt echter tot dezelfde risico’s als voor het opruimen van ICT-legacy, aangezien er in dit proces onderzocht moet worden wat de gevolgen zijn bij het verwijderen of veranderen van de ICT-legacy. Een andere methode is door ICT-legacy als het ware te negeren, en voort te boorduren op de huidige ICT-legacy. Dit kan bewerkstelligd worden door extra converters in te zetten zodat gegevens en de staat van een proces in een nieuwe ICT-omgeving te gebruiken zijn. Zoals al genoemd wordt in de vorige paragraaf is de performance en de uitbreidingscapaciteit beperkt. Door extra software "bovenop" het aan ICT-legacy onderhevige ERP-pakket te draaien worden de uitbreidingsmogelijkheden en de performance alleen maar lager (Jin et al., 2007). Deze methode is dus eigenlijk niet geschikt als uitbreidingsmethode. Zeker niet indien de betrouwbaarheid hoog moet zijn. De complexiteit wordt hierdoor verhoogd en het probleem van ICT-legacy neemt alleen maar toe. Een stijgende complexiteit leidt bovendien tot hogere ICT-kosten (Kumar et al., 1999). Een organisatie die wil veranderen kan het best ervoor kiezen om de ICT-legacy te voorkomen door de componenten te vervangen door nieuwe software of door de gebruikte ICT-legacycomponenten aan te passen aan wenselijke componenten. ICT-legacy blijft hoe dan ook een probleem dat gepaard gaat met hoge risico's voor de continuïteit van de ICT-omgeving, hoge kosten om ICT-legacy uit te bannen en een slechte mogelijkheid om de functionaliteiten van het ERP-pakket uit te breiden. Indien er veranderd wordt, dan gebeurt deze verandering met een lager tempo dan bij organisaties die niet te maken hebben met ICT-legacy. De organisaties die lijden aan ICT-legacy hebben een minder snel aanpassingsvermogen en zijn hierdoor minder flexibel.

56

5.4 Business-legacy

De tweede vorm van legacy die kan ontstaan binnen de organisatie is business-legacy. Businesslegacy wordt veroorzaakt door een drietal aspecten (Kelly et al., 1999): - er is sprake van globalisatie; - er vindt een transformatie plaats van industriële organisaties en economieën naar kennis- en informatiegebaseerde economieën, waardoor de product-life-cycle wordt verkort; - er vindt een verandering plaats van hiërarchisch georganiseerde organisaties naar gedecentraliseerde en minder hiërarchische organisaties. Business-legacy systemen worden door Lloyd et al. (1999) gedefinieerd als: "systemen die veranderingen en evolutie significant in de weg staan om aan de business-requirements te voldoen, met een consequente negatieve impact op het concurrentievermogen." Hierbij kan opgemerkt worden dat het bij business-legacy niet om het veranderen van ICT gaat, maar juist om het veranderen van business-requirements. Business-legacy wordt in dit onderzoek als volgt gedefinieerd: " Business-legacy is het geheel aan processen en taken dat volgens een oude visie wordt uitgevoerd en dat omgevormd moet worden naar taken en processen volgens een nieuwe visie, hetgeen door diverse verwevenheden niet eenvoudig is” Hierbij moet in ogenschouw genomen worden dat er bewust gekozen is voor een bredere definitie dan een definitie die louter geënt is op concurrentie. Zelfs als een organisatie om andere redenen van bedrijfsdoelstellingen wil veranderen, kan het te maken krijgen met business-legacy. Componenten van business-legacy bestaan uit (Kelly et al., 1999) de manier waarop organisaties de bedrijfsvoering zien, de manier waarop organisaties de organisatiestructuur zien en hoe de organisaties de markt zien waarin zij opereren. Een "oude" visie waarbij de markt niet juist ingeschat wordt kan leiden tot klantverlies of concurrentienadeel. Veranderen naar een nieuwe visie lijkt eenvoudig: pas de processen aan op de hernieuwde visie, zodat deze eenvoudig toe te passen is. Er zijn echter diverse problemen om te veranderen. Giaglis (1999) noemt dat het veranderen van processen tegenwoordig veranderd is ten opzichte van hoe dat in het verleden gebeurde. Organisaties moeten volgens Giaglis (1999) niet geanalyseerd worden in termen van voort te brengen producten, maar eerder in termen van business processen die uitgevoerd moeten worden. 57

Daarnaast dient er rekening gehouden te worden met rol die informatiesystemen tegenwoordig spelen. Davenport (1993) noemt zelfs dat "geen enkele businessresource beter gepositioneerd is dan informatietechnologie om radicale verbeteringen aan te brengen in businessprocessen". Informatietechnologie en gelieerde componenten zoals een ERP-pakket zijn volgens Davenport (1993) een enabler voor verbeteringen. Hier zit hem nu juist de crux: door ICT-legacy kan het ERPpakket niet eenvoudig veranderen. Tegelijkertijd is een nieuw ERP-pakket essentieel voor het kunnen toepassen van veranderingen binnen de organisatie. Het probleem met business-legacy is dat het net als ICT-legacy verweven zit in de gehele organisatie. Door het beleid aan te passen zijn er niet automatisch andere processen. In de literatuur worden diverse zaken genoemd waarin de oude processen nog steeds ingebed zitten. Een zeer belangrijk aspect is het menselijke aspect. Veranderingen stuiten op verzet, dat leidt tot weerstand bij een nieuwe werkwijze (Lievers et al., 2001). De mensen zijn gewend aan een bepaalde werkwijze en laten dit niet snel los. Hierdoor kan het management een nieuwe werkwijze opleggen, maar als de werknemers dit naast zich neerleggen en de oude werkwijzen hanteren, dan werkt het alsnog niet. Een tweede item waar business-legacy in verweven zit is in het ERP-pakket en de ICT-omgeving. De oorzaak hiervoor is dat er in het verleden processen met het ERP-pakket zijn geautomatiseerd en door parameters zijn "vastgezet" (Govers, 2003). De processen zijn ingebed in het ERP-pakket. Alhoewel er afgeweken kan worden van het proces door handmatig (een deel van) het proces af te handelen, is dit onwenselijk, omdat dit vaak meer tijd in beslag neemt en wellicht registraties niet op de juiste manier afhandelt. Het veranderen van het ingebedde proces gaat zeer moeizaam, omdat het veranderen van het ingebedde proces het noodzakelijk maakt om het ERP-pakket aan te passen door middel van parameters. Dit kan riskant zijn, doordat het ERP-pakket wellicht lijdt aan ICT-legacy. Een verandering van een parameter heeft dan ongewenste gevolgen. De vraag is of de organisatie kan volstaan met het veranderen van een parameter. Wellicht moet het gehele businessmodel dat in het ERP-pakket verankerd is veranderen. Overigens is de exacte werking van het ERP-pakket niet altijd bekend, bijvoorbeeld omdat het aan ICT-legacy onderhevig is. Hierdoor zijn de businessrules ingebed in het ERP-pakket, maar is het onduidelijk hoe deze businessrules uit het ERP-pakket verwijderd moeten worden. Alhoewel documentatie van een ERP-pakket in veel gevallen kan tonen hoe parameters zijn vastgezet om processen op een specifieke manier te ondersteunen, is deze documentatie soms karig, niet bijgewerkt of zelfs niet aanwezig (Kim, 1997). De derde verschijningsvorm van business-legacy is een combinatie van de bovenstaande twee vormen. Het ERP-pakket heeft parameters die de bedrijfsprocessen ondersteunen. De bedrijfsprocessen zijn echter veranderd, waardoor het personeel een extra handeling uitvoert of 58

"trucks" uithaalt om de processen om de vernieuwde wijze uit te voeren. Deze vernieuwde wijze hoeft overigens niet te betekenen dat de oude wijze niet meer voldoet; Wellicht heeft het personeel een methode gevonden om efficiënter of eenvoudiger te werken, zodat het proces sneller gaat of gemakkelijker uit te voeren is. Business-legacy houdt sterk verband met ICT-legacy: Het is vaak niet duidelijk welke processen en taken er werkelijk uitgevoerd worden en welke het ERP-pakket exact ondersteund. Daarnaast zijn deze processen en taken ingebed bij de mensen, maar eveneens in het ERP-pakket. Indien er processen of taken gewijzigd moeten worden, dan moet dit in het ERP-pakket aangepast worden. Omdat ICT-legacy het aanpassen van het ERP-pakket bemoeilijkt, wordt het nog lastiger om processen en taken te veranderen.

5.5 Maatregelen tegen business-legacy

Om business-legacy in kaart te brengen is de meest voor de hand liggende methode om documentatie goed op orde te hebben , zodat ieder proces en iedere taak te herleiden zijn (Wang et al., 2004). Zoals al in de vorige paragraaf genoemd is, zijn organisaties soms afhankelijk van externe partijen die wellicht de documentatie niet goed op orde hebben, of is de documentatie door vele veranderingen niet op orde. Huang et al. (1996) stelt voor om variabelen in het ERP-pakket te classificeren door de betreffende (software)programmaonderdelen in stukken te hakken. Vervolgens vindt er hiërarchische abstractie plaats. Dit is een zeer tijdrovende onderneming. Sneed et al. (1996) stellen voor om de output van (software)programma's te kiezen als basis. Vervolgens wordt er teruggeredeneerd via de programmacode om de businessrules te achterhalen. Ook deze methode kent een lang traject. De zojuist genoemde methoden zijn minder geschikt voor grote en logge ERP-pakketten, omdat grote systemen de volgende kenmerken hebben (Wang et al., 2004): - er is sprake van een grote hoeveelheid code zodat het in stukken hakken van het systeem leidt tot het verliezen van het overzicht over het geheel; - er zijn vele domeinvariabelen, waardoor er zeer lang onderzocht moet worden; - er zijn vele synoniemvariabelen, waardoor het lastig is om deze uit elkaar te houden. Wang et al. (2004) hebben een framework ontwikkeld waardoor businessrules uit de business-legacy gehaald kunnen worden. Dit framework omvat vijf stappen:

59

-

“program slicing”, waarbij een onderdeel van een (software)programma in stukken wordt gehakt;

-

domain variabelen onderscheiden, zodat deze per programma geïdentificeerd worden;

-

data analyse van de input en output van het (software)programma;

-

businessrules opstellen aan de hand van de voorgaande stappen;

-

businessrules valideren.

De onderstaande afbeelding geeft de stappen in een schematische weergave weer.

Afbeelding 5: Schematische weergave businessrules extraction

Het framework is in feite een combinatie van de twee methoden van Sneed et al. (1996) en Huang et al. (1996). Alhoewel het framework succesvol is toegepast bij een grote complexe financiële organisatie die veel last had van legacy (Wang et al., 2004), is het de vraag of het framework de oplossing is om business legacy de kop in te drukken. De methode leidt tot een zeer tijdrovend proces, omdat iedere “program slice” uitvoerig onderzocht moet worden (Dor et al., 2008). Daarnaast vinden er diverse iteraties plaats bij het valideren van een businessrule. Des te groter de in gebruik zijnde ERP-pakketten, des te langer is de organisatie bezig om de business-legacy te ontrafelen. Zoals in de vorige paragraaf is aangehaald, moet het menselijk aspect eveneens in ogenschouw worden genomen. De business-legacy strekt verder dan louter de software. Gewoonten en gebruiken in een organisatie zijn wellicht net zo belangrijk en verhullen een belangrijk deel van de businessdoelstellingen zoals ze in de organisatie leven (Wenger, 1998). Het personeel van een organisatie weet exact wat zij dagelijks uitvoeren. Het achterhalen van businessrules en de businessdoelstellingen zou moeten beginnen met het uitgebreid interviewen van het personeel van de organisatie. 60

Kort gezegd dient business-legacy tot een minimum beperkt te worden, omdat het veel tijd kost om het probleem op te lossen. Alhoewel de genoemde mogelijke methoden die in deze paragraaf besproken zijn een lichtpunt bieden om het probleem op te lossen, blijven ze zeer tijdrovend. Een langdurig veranderingstraject naar nieuwe businessmodellen leidt tot nadelen ten opzichte van de concurrentie, omdat de concurrent wel snel in staat is om te veranderen.

61

6. Flexibiliteit Zoals bleek uit het vorige hoofdstuk neemt de flexibiliteit af indien het ERP-pakket aan ICT-legacy onderhevig is. Daarnaast neemt de flexibiliteit af indien het ERP-pakket onderhevig is aan businesslegacy. De eerste paragraaf van dit hoofdstuk beschrijft wat flexibiliteit is. De tweede paragraaf gaat in op het belang van flexibiliteit voor de organisatie. In deze paragraaf wordt behandeld wat de gevolgen zijn van een hoge of juist een lage flexibiliteit. De derde paragraaf gaat in op de mogelijkheden om zo flexibel mogelijk te zijn. Er worden maatregelen en adviezen uit de literatuur genoemd waardoor de flexibiliteit kan worden verhoogd.

6.1 Wat is flexibiliteit? Zoals uit het vorige hoofdstuk naar voren kwam hebben ICT-legacy en business-legacy een negatieve invloed op de flexibiliteit. Dit is te wijten aan het feit dat een organisatie niet eenvoudig kan veranderen van ERP-pakket. Brun et al. (2006) noemen dat door het mogelijk maken van een snelle verandering in software en systemen de organisatie flexibeler wordt. Michelis et al. (1998) bevestigen dit, en noemen dat inflexibele systemen serieuze obstakels zijn voor de effectiviteit en het succes van de organisatie. Hiermee wordt het verband tussen het ERP-pakket en flexibiliteit nogmaals onderstreept. Als het ERP-pakket aan een vorm van legacy leidt is een snelle verandering van software of hardware juist niet mogelijk. Bij flexibiliteit gaat het dus om het veranderen van een oude naar een nieuwe situatie. Hall (1983) definieert flexibiliteit als “de mogelijkheid om snel te kunnen schakelen van een product of dienst naar een ander product of dienst, of van een onderdeel naar een ander onderdeel”. Deze definitie is gericht op een producerende organisatie. Om deze reden wordt de definitie van flexibiliteit breder getrokken door de volgende definitie te hanteren: “Flexibiliteit is de snelheid waarmee een verandering plaats kan vinden van een oude situatie naar een nieuwe situatie” Een organisatie die niet flexibel is kan wel degelijk veranderen. De tijdsduur waarmee deze veranderingen gaan zijn echter aanzienlijk hoger indien dit vergeleken wordt met een flexibele organisatie die tracht te veranderen. Flexibiliteit, het vermogen om aan te passen, is volgens Govers (2006) in drie gradaties onder te verdelen: - Operationele flexibiliteit, waarmee het volume en /of de mix van de output van een organisatie gemoeid is; 62

- Structurele flexibiliteit, waarmee aanpassingen van de vorm (structuren en processen) van een organisatie gemoeid zijn; - Strategische flexibiliteit, waarmee de visie en doelstellingen van een organisatie gemoeid zijn. Alle drie de vormen van flexibiliteit spelen een rol indien de organisatie te maken heeft met een ERPpakket dat aan ICT-legacy of business-legacy lijdt: -

De operationele flexibiliteit wordt aangetast, omdat het volume of de capaciteit van het ERPpakket ontoereikend is geworden (een capaciteitsprobleem), of de gewenste output wordt niet bereikt doordat het ERP-pakket dat aan ICT-legacy en business-legacy onderhevig is slecht aangepast kan worden op de gewenste output.

-

De structurele flexibiliteit wordt aangetast, omdat processen die door het ERP-pakket ondersteund worden niet eenvoudig zijn aan te passen. Het veranderen van processen vereist dat er aanpassingen worden gedaan aan de parameters van het ERP-pakket. Dit kan een risicovolle onderneming zijn.

-

De strategische flexibiliteit wordt beïnvloed door het ERP-pakket dat aan ICT-legacy en business-legacy onderhevig is, omdat de visie en doelstellingen niet eenvoudig doorgevoerd kunnen worden in de processen. Dit komt omdat de processen een verandering in de parameters van het ERP-pakket vereisen, wat risicovol kan zijn. Daarnaast is het niet eenvoudig te achterhalen welke visie en welke processen er nu direct nageleefd worden, doordat er in de loop der tijd veel veranderd is. Business-legacy leidt ertoe dat een verouderde visie “opgesloten” zit in bijvoorbeeld het ERP-pakket, zodat dit de strategische flexibiliteit op een tweede (nadelige) manier beïnvloedt.

Het volwassenheidsmodel van Holland et al. (2001), zoals dat in het vorige hoofdstuk besproken is, geeft aan dat de flexibiliteit in de eerste fase het laagst is. Dit komt onder andere omdat het te vervangen ERP-pakket aan legacy onderhevig is. In de tweede fase is de organisatie het meest flexibel. Dit is te wijten aan de gestandaardiseerde manier waarop het ERP-pakket ingevoerd is. Uitbreidingen zijn eenvoudig te bewerkstelligen, aangezien ervan weinig tot geen legacy sprake is. In de derde fase is de flexibiliteit lager dan in de tweede fase, en is weer op zijn laagst indien de eerste fase wordt bereikt, waarbij het ERP-pakket vervangen gaat worden en de hoeveelheid legacy het hoogst is. Op het moment dat het ERP-pakket geïmplementeerd is, is de flexibiliteit het hoogst. Naarmate het ERP-pakket meer uitgebreid wordt, wordt de flexibiliteit steeds lager. Poston et al. (2000) claimen dat de flexibiliteit hoger wordt door een ERP-pakket te implementeren. Dit klopt 63

indien het ERP-pakket pas onlangs geïmplementeerd is, omdat het ERP-pakket zich dan in de tweede fase van het volwassenheidsmodel bevindt. Naarmate de ERP-implementatie ouder wordt zal er volgens dit volwassenheidsmodel minder flexibiliteit ontstaan. Het onderzoek van Poston et al. (2000) is geen studie op langere termijn. Uit de resultaten blijkt slechts 9% een grotere hoeveelheid flexibiliteit te ervaren. Er komt niet naar voren in hoeverre de flexibiliteit afneemt naarmate het ERPpakket ouder is of vervangen moet worden. Aangezien het op dit moment flexibele ERP-pakket in de toekomst waarschijnlijk uitgebreid gaat worden, neigt het flexibele ERP-pakket vroeg of laat meer en meer naar de derde fase van het volwassenheidsmodel, waarbij er minder flexibiliteit ontstaat. Uitbreidingen kunnen tot een toename van legacy leiden, hetgeen de flexibiliteit weer kan beïnvloeden. Er is echter nog een andere reden te noemen waardoor de flexibiliteit afneemt. Govers (2006) noemt de uniformiteitsbenadering, waarbij gestandaardiseerde businessmodellen gekozen zijn om een niet-standaard organisatie te automatiseren. De gekozen businessmodellen “hebben veel weg” van de visie en strategie van de organisatie, maar passen niet voor de volle honderd procent (Dittrich et al. 2008). Een businessmodel van een organisatie dat exact gerepresenteerd wordt in het businessmodel van het ERP-pakket zal alleen in maatwerk voor komen. Zoals al genoemd is in het vierde hoofdstuk, zijn generieke ERP-pakketten uitgerust met generieke businessmodellen, waarbij het businessmodel wordt gekozen dat het best past. De processen worden vervolgens door de instelparameters vastgezet, waardoor er een abstractie ontstaat van het businessmodel. Situaties die niet voorzien zijn, bijvoorbeeld omdat ze wel passen bij het businessmodel van de organisatie, maar niet bij het businessmodel van het ERP-pakket, zijn niet of zeer moeilijk te automatiseren door het ERP-pakket. Ditzelfde geldt voor een organisatie die verandert van visie en het businessmodel: Het businessmodel van de organisatie past niet meer bij dat van het ERP-pakket. Veranderen van het businessmodel leidt ertoe dat het ERP-pakket aangepast moet worden aan het nieuwe businessmodel, omdat het businessmodel in het ERP-pakket niet meer voldoet aan de werkelijkheid.

6.2 Het belang van flexibiliteit voor de organisatie De vraagt rijst in hoeverre het belangrijk is om flexibel te zijn voor een organisatie. Chung et al. (2005) hebben onderzoek gedaan naar de relatie tussen businessperformance en flexibiliteit. Er is een verband tussen beiden gevonden. Zodra de flexibiliteit afneemt, neemt de businessperformance eveneens af.

64

Een tweede negatieve invloed voor de organisatie is de concurrentie. Zoals er in het hoofdstuk legacy al genoemd is, leidt het niet kunnen implementeren van nieuwe technologie of een nieuw informatiesysteem tot concurrentienadeel (Lloyd et al., 1999). Omdat de organisatie niet de vereiste flexibiliteit heeft om deze nieuwe technologie te implementeren, leidt dit tot concurrentienadeel. Concurrenten beschikken mogelijkerwijs wel over deze flexibiliteit, zodat zij in staat zijn processen op een efficiëntere of innovatieve manier te laten verlopen. Innovaties kunnen door het gebrek aan flexibiliteit nauwelijks worden doorgevoerd, wat eveneens tot concurrentienadeel leidt. Het is mogelijk dat klanten een andere aanbieder kiezen, omdat die wel de nieuwe technologie ondersteunt waar de klanten om vragen (Ho et al., 2002). Een voorbeeld hiervan is multichanneling (zie paragraaf 1.4). Bij multichanneling worden er meerdere kanalen gebruikt om klanten een op maat gemaakte service te bieden, wat voor de klant de voorkeur verdient boven een standaardservice. De bovenstaande genoemde negatieve invloeden hebben beiden betrekking op de operationele en de structurele flexibiliteit. Kelly et al. (1999) zegt dat de wereld veranderd. Dit wordt veroorzaakt door globalisatie, de transformatie van industrieën naar een kennis- en informatie-economie en doordat de organisatiestructuur verandert van een hiërarchische organisatie naar minder hiërarchische en meer gedecentraliseerde organisaties. De omgeving is continu aan het veranderen, waardoor de visie van een organisatie niet eindeloos meegaat. Om deze visie te kunnen veranderen, moet er een zekere mate van strategische flexibiliteit aanwezig zijn. Door de aanwezigheid van business-legacy wordt het veranderen van visie een lastige taak, omdat de verouderde visie deels geworteld zit in het businessmodel van het ERP-pakket en de processen die dit ERP-pakket ondersteund. Indien de strategische flexibiliteit laag is, is het voor de organisatie beperkt mogelijk om de hernieuwde visie te kunnen doorvoeren in de rest van de organisatie. Het snel kunnen veranderen op operationeel, structureel en strategisch vlak vereist flexibiliteit. Het niet kunnen veranderen kan leiden tot het niet kunnen veranderen van de visie van de organisatie, waardoor het bestaansrecht van de organisatie in gevaar komt.

65

6.3 Flexibiliteitbehoud Organisaties die te maken hebben met een inflexibele organisatie kunnen diverse handelingen uitvoeren om de organisatie flexibel te houden nadat hun ERP-pakket vervangen is. Zoals al opgemerkt is, is de flexibiliteit het hoogst nadat het ERP-pakket is ingevoerd (Poston et al., 2000). Een tweetal belangrijke oorzaken van inflexibiliteit zijn ICT-legacy en business-legacy. Door zowel ICTlegacy als business-legacy te beheersen en beperken behoudt het ERP-pakket haar flexibiliteit. In het voorgaande hoofdstuk over legacy zijn diverse methoden genoemd waarmee zowel ICT-legacy als business-legacy bestreden kunnen worden. Dit vormt overigens geen garantie voor een flexibele organisatie, omdat het ERP-pakket in de loop der tijd veranderd wordt om te kunnen voldoen aan de nieuwe eisen. Door de aangedragen methoden te hanteren kan de levensduur (en daarmee de flexibiliteit) van het ERP-pakket wel gerekt worden. Het volwassenheidsmodel geeft dit eveneens aan: hoe langer het ERP-pakket in gebruik is, hoe meer legacy er zal ontstaan, en hoe minder flexibiliteit het ERP-pakket bezit (Holland et al., 2001). De overgang van de tweede volwassenheidsfase naar de derde volwassenheidsfase is hier kenmerkend voor. Hoe langer de overgang van de tweede naar de derde fase uitgesteld kan worden, des te langer kan het ERP-pakket gebruikt worden. Hierdoor kan men de overgang naar de eerste fase, waarbij het ERP-pakket vervangen dient te worden, zo lang mogelijk vermijden. Een mogelijke andere methode om flexibiliteit te behouden is al kort genoemd in het vorige hoofdstuk. Deze methode is de Service Oriented Architecture (SOA). De organisatie zou flexibeler zijn door deze methode, omdat het snelle verandering mogelijk maakt door nieuwe functionaliteiten in het systeem “te klikken”. Opvallend genoeg is er niet veel wetenschappelijke literatuur over SOA. Er zijn enkele succesvolle implementaties met SOA (Papazoglou et al., 2007; O'Brien et al., 2008), maar deze succesvolle implementaties worden in andere literatuur weer bekritiseerd (Schepers et al., 2008), omdat SOA slechts voor een korte periode gebruikt wordt. SOA is dus nog niet het kant-enklare antwoord voor een flexibele ERP-omgeving. SOA werkt met een service bus die zorg draagt voor het verzenden van berichten tussen modulen. Deze service bus bevat geen functionaliteiten. De gebruikte modulen bezitten de functionaliteiten en de “intelligentie” om berichten met andere modulen uit te wisselen (Papazoglou et al. 2007). Dit maakt het veranderen van functionaliteiten eenvoudiger (O’Brien et al., 2008) Stabiliteit en capaciteit zijn voor een organisatie redenen om een systeem te onderhouden. Door het uitvoeren van updates en het plegen van onderhoud aan het ERP-pakket wordt de software betrouwbaarder en stabieler, onder andere omdat bekende fouten uit het systeem verwijderd 66

worden (Gabriel et al., 2006). De capaciteit van het ERP-pakket neemt hierdoor toe, omdat fouten minder vaak optreden (Gabriel et al., 2006). Het up-to-date houden van het systeem kan overigens niet voorkomen dat er bij zeer grote druk op het ERP-pakket niet uitgeweken hoeft te worden naar andere software of hardware: de capaciteit is eindig. Het op orde hebben van de documentatie van het ERP-pakket is essentieel voor het kunnen uitvoeren van onderhoud (Souza et al., 2005). Dit onderhoud is weer essentieel om het ERP-pakket stabiel te laten werken. Daarnaast biedt inzicht in het ERP-pakket door middel van de documentatie een snellere mogelijkheid om te kunnen veranderen: er is immers exact bekend hoe het systeem werkt. De resources om veranderingen te bewerkstelligen, zoals geld en gekwalificeerd personeel, zijn cruciaal om een verandering überhaupt te laten gebeuren. Hoe meer personeel er beschikbaar is, des te sneller kan een migratie plaats vinden. Het is lastig (zo niet: onmogelijk) om de toekomstige eisen en wensen van een organisatie te voorspellen. Daarom is het onmogelijk om vooraf te weten welke processen er in de toekomst ondersteund moeten gaan worden. Al bij de keuze van het ERP-pakket wordt een beslissing gemaakt over hoe het businessmodel door dit ERP-pakket ondersteund moet worden. Tijdens en door de implementatie van het gekozen ERP-pakket wordt het businessmodel verankerd: processen worden aan de hand van dit businessmodel vastgelegd. Zodra het businessmodel verandert, moeten deze processen die bij het businessmodel horen eveneens veranderen, omdat deze processen niet met onvoorziene situaties kunnen omgaan. Met andere woorden: de processen zijn te specifiek geformuleerd. Govers (2006) geeft als oplossing de variëteitbenadering: -

Alleen dezelfde variëteit in een proces heeft dezelfde besturing nodig;

-

Alleen dezelfde variëteit reageert hetzelfde op verandering.

Hierdoor wordt een proces niet als een proces met verschillende mogelijkheden gezien, maar als een proces met verschillende variëteiten. De werking van het proces is de verzameling van de variëteiten van het proces. Indien er zich een onvoorziene situatie voordoet, kan er een nieuwe variëteit gecreëerd worden. Een proces wordt op deze manier op een uitzonderlijke wijze gestandaardiseerd: iedere mogelijk detail is immers vastgelegd in de variëteit van het proces. Dit leidt tot een zeer hoge mate van flexibiliteit: indien een variëteit niet bestaat, dan kan deze eenvoudig gecreëerd worden. De vraag is of deze hoge mate van flexibiliteit opweegt tegen de kosten en de hoeveelheid werk die hiermee gepaard gaan. Het uitvoerig standaardiseren van processen, om deze vervolgens tot op detail te specificeren per variëteit, gaat gepaard met veel werk. Het ERP-pakket dat door leveranciers geleverd wordt, bevat weliswaar standaardprocessen, maar is niet dusdanig gestandaardiseerd dat 67

het om kan gaan met verschillende variëteiten per proces. Het gebruik van deze methode is eigenlijk alleen weggelegd indien het ERP-pakket ontwikkeld wordt door de organisatie. Daarnaast dient zich een andere vraag aan: de procesflexibiliteit kan weliswaar hoog zijn, maar hoe is het gesteld met de uitbreidbaarheid en de platformonafhankelijkheid van het ERP-pakket? Het zou vervelend zijn indien het ERP-pakket vervangen moet worden na een aantal jaren, omdat er niet meer uitgebreid kan worden. Het creëren van flexibiliteit blijft een lastige issue. Indien een ERP-pakket langer flexibel blijft, kan het langer aan de eisen en wensen van de organisatie voldoen en dus langer gebruikt worden. Alhoewel het lijkt dat het uiteindelijk vervangen van het ERP-pakket onoverkomelijk lijkt, is de levensduur van het ERP-pakket te verlengen door de in deze paragraaf aangedragen oplossingen te gebruiken. Indien een organisatie de ontstane hoeveelheid legacy kan terugdringen, is het vervangen van een ERPpakket eenvoudiger te bewerkstelligen.

68

7. Het gebruik van ERP-pakketten in de praktijk De voorgaande hoofdstukken beschrijven wat een ERP-pakket is, welke soorten er zijn, wat legacy is en hoe dit de flexibiliteit beïnvloedt. In dit hoofdstuk wordt een viertal cases weergegeven. Iedere case gaat in op het gebruik van het ERP-pakket, de verantwoordelijkheid van het ERP-pakket en de documentatie, de flexibiliteit van het ERP-pakket en de eventuele wens om het ERP-pakket te vervangen. De cases zullen de gevonden resultaten uit de literatuur bevestigen. De cases moeten de gevonden resultaten uit het literatuuronderzoek bevestigen. Daarnaast bieden deze cases extra inzichten die niet in de literatuur gevonden zijn. De cases zijn gegenereerd op basis van interviews. Van deze interviews zijn aantekeningen gemaakt. Tijdens het afnemen van deze interviews is een vragenlijst gebruikt, die te vinden is in bijlage A. De eerste paragraaf gaat in op het interviewprotocol. Hier is te vinden hoe de interviews zijn afgenomen en welke keuzes hierbij gemaakt zijn. De tweede paragraaf bespreekt de case Paradigit. De antwoorden op de vragen van Paradigit zijn te vinden in bijlage B. De derde paragraaf bespreekt de case Blackbox. De antwoorden op de vragen van Blackbox zijn te vinden in bijlage C. De vierde paragraaf bespreekt de case Schuitema. De antwoorden op de vragen van Schuitema zijn te vinden in bijlage D. De vijfde paragraaf bespreekt de case Kamer van Koophandel Nederland. De antwoorden op de vragen van de Kamer van Koophandel Nederland zijn te vinden in bijlage E. Tot slot worden er in de zesde paragraaf conclusies weergegeven over de gevonden resultaten in de praktijk.

69

7.1 Interviewprotocol Voor de interviews zijn een viertal personen van verschillende organisaties geïnterviewd. Per interview is er ongeveer een uur uitgetrokken, waarna het interviewverslag geschreven is. Voor het afnemen van het interview is gebruik gemaakt van een vragenlijst met open vragen. Deze vragen zijn opgesteld als leidraad voor het interview. Voorafgaand aan het interview is de organisatie bestudeerd aan de hand van websites, folders, nieuwsberichten, enzovoorts, om een beeld te krijgen van haar activiteiten. Deze activiteiten zijn bepalend voor het mogelijke gebruik van het ERP-pakket. Er is geverifieerd of de gevonden activiteiten ook daadwerkelijk kloppen door het interviewverslag te laten controleren. Daarnaast is er uitvoerig doorgevraagd op de rol van het ERP-pakket binnen de organisatie. De te interviewen persoon is vooraf ingelicht over het beoogde doel van het interview en hoe dit interview in de thesis gebruikt zou worden. Er is eveneens gevraagd in hoeverre de resultaten met naam van de organisatie gepubliceerd mogen worden. Indien er geen toestemming verkregen werd voor het publiceren, werd er overlegt of er een pseudoniem gebruikt mocht worden. Tijdens het interview werd er waar mogelijk doorgevraagd, om meer verheldering te krijgen op de gegeven antwoorden. Er werd ingegrepen indien het gegeven antwoord sterk van de vraag afwijkt omwille van de beschikbare tijd. Dit was ter beoordeling aan de interviewer, die hier over waakte. Er werd getracht het interview af te nemen in een omgeving waar geen storende achtergrondgeluiden waren. Dit kon het interview (negatief) beïnvloeden. De beoogde tijd voor het afnemen van het interview bedroeg ongeveer een uur. Tijdens het interview werden er door de interviewer aantekeningen gemaakt van het interview. Nadat het interview afgerond was, werd er door de interviewer een interviewverslag gemaakt. Dit moest zo snel mogelijk gebeuren om alle genoemde punten mee te nemen zodat ze niet vergeten zouden worden als ze niet in de aantekeningen bleken te staan. Het interviewverslag bestaat uit een lijst met de gegeven antwoorden (in samenvatting) op de gestelde vragen. Het interviewverslag is gemaild aan de geïnterviewde, om de juistheid te verifiëren. Bij eventuele onjuistheden kon de geïnterviewde de aanpassing laten weten, waarna deze verwerkt zijn in het interviewverslag. Het interviewverslag is verwerkt tot een case, waarbij met name de opvallende punten worden genoemd. Hierbij valt te denken aan de redenen voor het veranderen van een ERP-pakket en de tegengekomen problemen hierbij. 70

7.2 Case Paradigit

Omschrijving van de organisatie De Paradigit Groep is sinds 1992 actief in de computerbranche met de verkoop van computers en accessoires aan consumenten, bedrijven, overheid en onderwijs. Paradigit stelt zich als doel om optimale klanttevredenheid te realiseren door haar eindgebruikers uitstekend te adviseren over en te bedienen met kwaliteitsproducten, voorzien van levenslange ondersteuning. De Paradigit Groep kent een omzet van 129 miljoen euro (boekjaar 2007), verkoopt meer dan 120.000 computers per jaar en heeft daarmee een marktaandeel van ruim 4% van de totale Nederlandse markt. Bij de Paradigit Groep zijn 600 medewerkers in dienst. De functie van hoofdkantoor, logistiek dienstverlener en inkoopcombinatie wordt vervult door een aparte B.V, te weten PDC B.V. . De Paradigit Groep is onderverdeeld in de volgende onderdelen: -

Paradigit Retail o

Hieronder vallen de filialen van Paradigit en Computerland. Deze winkelketen verkoopt computers en accessoires daarvoor

-

Skool o

Skool verzorgt automatiseringsoplossingen voor scholen

o

ISL is de zakelijke dienstverleningstak. Naast het leveren van hardware en

ISL softwarecomponenten verzorgt ISL de installatie, het beheer en het onderhoud op IT gebied

-

Automotive o

Automotive levert backoffice toepassingen voor autodealers.

Het huidige ERP-pakket Het huidige ERP-pakket dat bij Paradigit wordt gebruikt, Concorde, is inmiddels zo’n 8 jaar in gebruik. Het ERP-pakket dat vóór dit ERP-pakket gebruikt werd, bestond uit door Paradigit ontwikkelde software. Dit pakket schoot echter te kort omdat het de gebruikershoeveelheden niet aan kon, maar eveneens omdat de functionaliteit ontoereikend was geworden. Er is toen besloten om het ERPpakket Concorde aan te schaffen, dat speciaal gericht is op logistieke en producerende omgevingen. Er is hier sprake van een branchespecifiek ERP-pakket. Het ERP-pakket is in ongeveer drie maanden

71

geïmplementeerd, wat vrij snel is. Het pakket is vanaf de implementatie steeds uitgebreid met meer functionaliteiten. De huidige configuratie lijkt niet meer op de configuratie van destijds. Concorde heeft de volgende modulen: -

Administratie;

-

Inkoop;

-

Productieplanning;

-

Productie;

-

Voorraadbeheer;

-

Logistiek;

-

Verkoop;

-

Service.

Concorde wordt niet gebruikt voor HRM noch voor CRM. Het ERP-pakket wordt gebruikt voor alle vier de onderdelen van de Paradigit Groep. Hiermee zijn verschillende businessmodellen gemoeid. Concorde biedt daar waar mogelijk ondersteuning, maar schiet soms te kort. Dit is te wijten aan het tekort schieten van de uitbreidbaarheid van het pakket. Onderhoud wordt er op dit moment slechts incidenteel gepleegd op momenten dat het ERP-pakket niet meer werkt door fouten. Het budget voor het ERP-pakket wordt niet regelmatig overschreden, omdat er gebruik wordt gemaakt van een onderhoudslicentie. Bij het uitbreiden van het ERP-pakket nemen de kosten van deze licentie toe. Verantwoordelijkheden De verantwoordelijkheid voor het ERP-pakket ligt volledig bij de directie van Paradigit. Het onderhoud wordt door de directie gedelegeerd aan de IT-afdeling, die op hun beurt weer samenwerken met de leverancier indien er zich problemen voordoen doen die uitzonderlijk zijn. Voor het bijhouden van de documentatie is er geen verantwoordelijke. Bij het invoeren van het ERPpakket is alles gedocumenteerd, maar naarmate er uitbreidingen worden gedaan wordt de documentatie lang niet altijd bijgewerkt. Paradigit is dan afhankelijk van de documentatie die de consultant op dat moment aanbiedt.

72

Flexibiliteit van het ERP-pakket Het ERP-pakket heeft in de periode na het invoeren vele toevoegingen en modificaties gekend. Na 8 jaar is het pakket “op”. Het schiet op dit moment te kort op het gebied van snelheid en uitbreidbaarheid. Dit komt, zegt de geïnterviewde, onder andere door de leeftijd, waardoor nieuwe doelstellingen moeilijk te bewerkstelligen zijn. Er zijn alternatieve gezocht om toch functionaliteiten toe te kunnen voegen. Een voorbeeld hiervan is het intranet, wat het mogelijk maakt om reserveringen via internet te accepteren. Een ander voorbeeld is TAP, een losstaand systeem om klantenreparaties te kunnen managen. Vervangen van het ERP-pakket Paradigit is bezig met de implementatie van Microsoft Dynamics, een nieuw ERP-pakket. Dit pakket omvat eigenlijk twee implementaties van Microsoft Dynamics, waarbij twee businessmodellen ondersteund gaan worden. Microsoft Dynamics wordt tweemaal geïnstalleerd, maar met verschillende parameters. Er is bewust voor deze configuratie gekozen omdat de bedrijfsvoering beter ondersteund wordt. Er zal wel een koppeling tussen beide ERP-pakketten zijn. Microsoft Dynamics is onder andere gekozen omdat het volgens de laatste standaarden werkt. Het ERP-pakket is bovendien schaalbaar, zodat er qua capaciteit zich weinig problemen voor zullen doen. De verwachting is dat het implementeren eenvoudig zal gaan, omdat er een lang voorbereidingstraject is gevolgd. De enige angst is dat functionaliteit die nu geleverd wordt, niet in het nieuwe ERP-pakket geleverd wordt omdat dit over het hoofd gezien wordt. Conclusie Het huidige ERP-pakket schiet te kort, en wordt daarom vervangen. Dit tekort schieten heeft te maken met de verlangde nieuwe functionaliteiten. Het systeem is “op”, waardoor de verwerkingssnelheid van het ERP-pakket en de uitbreidingsmogelijkheden door alle al toegevoegde functionaliteiten eveneens afneemt. Aanvankelijk was het ERP-pakket wel uit te breiden. De angst op het over het hoofd zien van functionaliteiten die in het huidige ERP-pakket geboden worden, maar in het nieuwe ERP-pakket niet, kan er op duidelijk dat er sprake is van legacy: het totaalbeeld van het ERP-pakket is niet aanwezig omdat er niet duidelijk is welke functionaliteiten het ERP-pakket vervult. Omdat de documentatie niet actueel is, moet er uitvoerig onderzoek plaats vinden naar de feitelijke werking van het huidige ERP-pakket. Wellicht dat dit de oorzaak is van het geplande lange ERP vervangingstraject van ongeveer een jaar.

73

7.3 Case Blackbox

Omschrijving van de organisatie Black Box Network Services is 's werelds grootste technische services bedrijf, toegewijd aan ontwerp, installatie en onderhoud van de huidige gecompliceerde netwerkinfrastructuur systemen. Black Box Network Services is sinds 1986 gevestigd te Utrecht en is een dochteronderneming van Black Box Corporation. Het hoofdkantoor is gevestigd te Pittsburgh - USA. Blackbox levert een diversiteit aan netwerkproducten. Blackbox in Utrecht is een samensmelting van een tweetal bedrijven: -

Blackbox Network Services o

Dit bedrijf levert netwerkproducten. Dit doen zij uitsluitend in het Business to Business segment.

-

Blackbox Data Services o

Dit bedrijf levert de service voor het aanleggen van netwerken bij organisaties. Dit is een dienstverlenende organisatie. De producten die benodigd zijn worden bij Blackbox Network Services gekocht.

Het huidige ERP-pakket Het huidige ERP-pakket dat bij Blackbox wordt gebruikt, Exact Globe DOS 3.3, is inmiddels zo’n 10 jaar in gebruik. Het voorgaande ERP-pakket was een oudere versie van Exact. Omdat de leverancier deze verouderde versie niet meer ondersteunde, is er de keuze gemaakt om over te stappen naar een nieuwe versie van Exact Globe DOS, versie 3.3. Het overstappen naar dit ERP-pakket is vrij soepel verlopen en duurde slechts 2 maanden. Een bijkomend voordeel was dat de kosten laag waren, omdat een upgrade van het ERP-pakket aanzienlijk goedkoper was. Blackbox gebruikt een branchegeneriek ERP-pakket. Het ERP-pakket is uitgebreider geworden, omdat Blackbox Data Services aan de bedrijfsvoering is “toegevoegd”. Op dit moment worden beide ERP-pakketten zonder koppeling tussen elkaar gebruikt. De reden hiervoor is dat het ERP-pakket van Blackbox Network Services (Exact Globe DOS 3.3) niet samen kan werken met het ERP-pakket van Blackbox Data Services (Exact DOS 7.1). Daarnaast zijn Blackbox Network Services en Blackbox Data Services twee verschillende typen bedrijven: Er worden producten verkocht, of er worden diensten geleverd. Dit is niet eenvoudig gelijktijdig in één ERPpakket te zetten, aangezien er twee typen bedrijfsvoeringen worden gebruikt. 74

Het ERP-pakket omvat naast Exact Globe DOS 3.3 en Exact DOS 7.1 nog enkele hulpapplicaties om functionaliteiten te vervullen die niet met het ERP-pakket mogelijk zijn. Voorbeelden zijn E-access om rapportages te maken, measuremail om mailings te verzenden en Sparco om het spaarprogramma up to date te houden. Het ERP-pakket wordt gebruikt voor vrijwel alle bedrijfsprocessen, maar HRM wordt hier niet in uitgevoerd. Het ERP-pakket bevat een CRM-module, maar het daadwerkelijke verzenden wordt door measuremail gedaan. De rapportages die met Exact Globe DOS 3.3 gegenereerd kunnen worden, bevatten niet de gewenste gegevens. Om deze reden wordt de database benaderd met E-access om de database naar Access om te zetten. Vervolgens worden vanuit Access de juiste rapporten gegenereerd. Dit leidt ertoe dat er een vertraging in de rapportages zit van ongeveer twee uur. De onderstaande afbeelding geeft de ERP-pakketten en de toevoegingen weer. De linkerzijde is Blackbox Network Services, de rechterzijde is Blackbox Data Services. De rode onderdelen zijn allen ontwikkeld om de DOS-basis te kunnen blijven gebruiken. Tussen beide ERP-pakketten is geen koppeling aanwezig. Er wordt intern gefactureerd mocht dat nodig zijn.

Afbeelding 6: Weergave ERP-omgeving Blackbox 75

Verantwoordelijkheden Er zijn servicecontracten opgesteld (SLA’s) voor het gegarandeerd werken van het ERP-pakket. De leverancier is dus op papier verantwoordelijk. De leverancier komt iedere maand onderhoud doen op de systemen. Het dagelijks onderhoud, zoals de back-up, wordt door een Blackbox collega gedaan. Er wordt een vast bedrag per maand betaald voor het onderhoud. Voor de documentatie is er geen verantwoordelijke opgesteld. Blackbox is afhankelijk van de leverancier hiervoor. Van de door Blackbox gemaakte rapportages is overigens wel uitvoerige documentatie beschikbaar. Flexibiliteit van het ERP-pakket Nadat het ERP-pakket ingevoerd is, heeft het vele veranderingen ondergaan. Er is onder andere een CRM module toegevoegd. Daarnaast zijn er extra afhankelijkheden bijgekomen door Measuremail en het Sparco spaarprogramma. Deze losse applicaties zijn toegevoegd omdat het huidige ERP-pakket deze functionaliteit niet meer kon bieden. Het ERP-pakket is nu niet meer flexibel. Dit komt onder andere omdat het in DOS werkt, wat een maximale programmagrootte van 640KB kent. Programma’s kunnen in DOS alleen starten en draaien in het UMB (Upper Memory Block), dat netto 640KB is. Het programma kan om technische redenen niet meer uitgebreid worden. Het platform, DOS, verhindert dit. Door de vele afhankelijkheden is een aanpassing niet eenvoudig te bewerkstelligen. De gesloten databasestructuur verlaagt de flexibiliteit aanzienlijk van het ERP-pakket. Het is mogelijk om data uit het ERP-pakket te krijgen, maar dit leidt tot veel vertraging omdat er een converter gebruikt moet worden. Een nieuwe functionaliteit real-time laten werken is niet mogelijk. Vervangen van het ERP-pakket Blackbox heeft regelmatig nagedacht over het vervangen van het ERP-pakket. Een nieuw ERP-pakket zou extra integratie mogelijk kunnen maken. De losse applicaties die nu gebruikt worden, zoals Measuremail en Sparco, kunnen in dat geval met één ERP-pakket werken. Rapportages kunnen eventueel zelfs real-time gemaakt worden, zodat er een actueler overzicht ontstaan. Daarnaast kunnen de twee ERP-pakketten wellicht vervangen worden door 1 pakket dat de twee businessmodellen ondersteund. Het grote probleem dat wordt genoemd zijn de kosten die een nieuw ERP-pakket met zich mee brengt. Het is niet alleen de aanschaf van het ERP-pakket, maar eveneens de kosten voor het implementeren van het ERP-pakket, zoals de onderzoekskosten. Het hoofdkantoor van Blackbox wil geen grote investeringen doen in het ERP-pakket dat in Nederland wordt gebruikt. 76

De gesloten databasestructuur van het ERP-pakket is een probleem gebleken. Er zijn diverse tests uitgevoerd om dit om te zetten door middel van E-access. Veel data konden overgezet worden, maar bevatten bijvoorbeeld spaties en tabs, waardoor de data alsnog handmatig gecontroleerd moet worden. Een nieuw ERP-pakket moet op zijn minst een open databasestructuur hebben. Een ERPpakket dat eenvoudig uit te breiden is met modules, is eveneens zeer wenselijk, zodat extra functionaliteit eenvoudig toe te voegen is. Het moge duidelijk zijn dat een nieuw ERP-pakket niet meer in een DOS omgeving draait. Dit leidt tot problemen in capaciteit en mogelijkheden. Conclusie Het gebruikte ERP-pakket bij Blackbox is sterk verouderd en voldoet niet meer aan de standaarden van deze tijd. Dit is onder andere te wijten aan het platform waarop het ERP-pakket draait. Deze veroudering is terug te zien in de geboden functionaliteit. Uitbreidingen worden niet goed meer ondersteund door de verouderde omgeving (DOS) en het gesloten databaseformaat. Het ERP-pakket is dus niet meer aanpasbaar. Alhoewel er op dit moment ongemakken zijn (zoals het niet up to date hebben van de rapportage), vormt het ERP-pakket geen zware last voor de dagelijkse bedrijfsvoering. Veranderingen zijn weliswaar niet mogelijk, maar deze zijn niet dringend noodzakelijk aangezien de bedrijfsvoering op dit moment niet in gevaar komt. De flexibiliteit is zeer laag. Het vervangen van het huidige ERP-pakket zou wel diverse voordelen bieden, zoals de integratie van twee ERP-pakketten (weliswaar met verschillende businessmodellen), het wegvallen van losse applicaties voor het verzenden van een mailing en het real-time kunnen genereren van rapporten. Blackbox is zich wel degelijk hiervan bewust en is zich aan het oriënteren op een nieuw ERP-pakket. De hoge kosten houden Blackbox op dit moment echter (nog) tegen. Deze hoge kosten houden verband met het afwikkelen van de ontstane losse applicaties, en zijn eigenlijk een vorm van legacy.

77

7.4 Case Schuitema

Omschrijving van de organisatie Schuitema n.v. is al meer dan 100 jaar actief in de levensmiddelenbranche. Schuitema biedt een uitgekiende combinatie van goederen en diensten met de beste prijs/kwaliteitverhouding die de hoogste geïntegreerde winst op termijn genereert. Schuitema is uitgegroeid van groothandel en retail support company naar een volwaardige supermarktorganisatie met één formule, C1000. Met meer dan 450 supermarkten is C1000 de tweede supermarktformule van Nederland. Schuitema biedt de C1000 ondernemers en bedrijfsleiders optimale ondersteuning in de vorm van producten en diensten. Van loonadministratie tot en met de financiering van een winkelverbouwing. Van personeelsbeleid tot en met winkelautomatisering. Het huidige ERP-pakket Het huidige ERP-pakket van Schuitema, Locus, is inmiddels zo’n 10 jaar in gebruik. Het voorgaande ERP-pakket was een pakket dat zelf ontwikkeld is en dat werd vervangen omdat er vele kosten en tijd gepaard gingen met het maatwerk. Omdat Schuitema voor één ERP-pakket gekozen heeft, zou er minder maatwerk zijn. Het huidige ERP-pakket is gekozen omdat de functionaliteit het beste paste bij de gewenste functionaliteit. De aanschafprijs heeft eveneens een belangrijke rol gehad in de keuze van het ERP-pakket. De implementatieduur heeft in totaal zo’n 5 jaar geduurd. Dit is te wijten aan de stapsgewijze invoering van het nieuwe pakket door middel van modulen. Tijdens de implementatie van het ERP-pakket was er door de diverse veranderingen sprake van organisatieproblemen. Door het lange implementatietraject speelde ook de veranderde markt een rol. Het implementatieproces zou versneld kunnen worden indien er meer personeel beschikbaar zou zijn voor de implementatie. De huidige ERP-omgeving omvat niet alleen het ERP-pakket, maar ook diverse andere applicaties om software te ondersteunen. Het ERP-pakket ondersteunt de modulen administratie, inkoop, logistiek, verkoop en voorraadbeheer. Er wordt een apart pakket gebruikt voor de productieplanning, service (klachtafhandeling) en HRM. Deze pakketten kunnen gegevens met het ERP-pakket uitwisselen. Het huidige ERP-pakket wordt binnenkort niet meer ondersteund door de leverancier. Hierdoor is Schuitema zich aan het oriënteren op een nieuw ERP-pakket. Er wordt geen actief onderhoud meer gedaan op het ERP-pakket, alleen indien dit vereist wordt door de bedrijfsvoering.

78

Verantwoordelijkheden De verantwoordelijke voor de werking van het ERP-pakket is het hoofd IT. Naast het onderhoud wat er gedaan wordt om het systeem werkende te houden, is het systeem dubbel uitgevoerd, zodat de service beschikbaar blijft indien één systeem uit zou vallen. Voor de documentatie is er niet zozeer een persoon verantwoordelijk. Schuitema werkt met Applicatiebeheerders. De applicatiebeheerder is verantwoordelijk voor de werking van de applicaties. Onder deze verantwoordelijkheid valt ook de documentatie. Indien er extra functionaliteit ontwikkeld wordt, dan gebeurd dit in software die op basis van de programmacode automatisch documentatie genereert. Op deze manier is de documentatie altijd correct en kan niet vergeten worden. Flexibiliteit van het ERP-pakket Het systeem zou nog uitgebreid kunnen worden met nieuwe functionaliteiten. Dit wordt overigens zeer zelden gedaan, omdat het ERP-pakket vervangen gaat worden. Alle veranderingen die nu gedaan worden vormen een extra belasting op de implementatie in de toekomst. Daarnaast moet er een afweging gemaakt worden: is het wijs om duizenden euro’s te investeren in iets waar slechts honderden euro’s mee worden verdiend? Wat betreft de uitbreidbaarheid is er qua software voldoende mogelijk. Wel wordt er aangegeven dat software met een hogere systeemcapaciteit het wellicht noodzakelijk maakt om andere, krachtigere hardware aan te schaffen. Het systeem is op dit moment afhankelijk van het AIX (een Unix variant) besturingssysteem. Een andere Unix variant is mogelijk, maar er zal goed getest moeten worden of dit niet tot onvoorziene problemen leidt. Het ERP-pakket maakt gebruik van een Oracle database, die om kan gaan met zeer veel records en tabellen. Het uitbreiden van deze database is daardoor relatief eenvoudig. Informatie is ook eenvoudig uit deze database te halen.

79

Vervangen van het ERP-pakket Schuitema is op dit moment bezig met het zoeken naar oplossingen om het ERP-pakket te vervangen. Zoals al genoemd is de belangrijkste reden hiervoor dat de leverancier het ERP-pakket niet meer ondersteund, waardoor een groot gedeelte van de expertise van het ERP-pakket aan de leverancierszijde wegvalt. Het vervangen van het ERP-pakket zal naar verwachting ongeveer drie jaar in beslag nemen. Het vervangen van het huidige ERP-pakket zal niet eenvoudig gaan, omdat het complex is. Alhoewel veel documentatie beschikbaar is, blijft het altijd afwachten of alle benodigde functionaliteit werkt en überhaupt beschikbaar is in het nieuwe ERP-pakket. Om dit te testen wordt er een uitvoerige risicoanalyse uitgevoerd door de IT-afdeling. Om het nieuwe ERP-pakket flexibel te houden, wordt er aangegeven dat de documentatie op orde moet zijn. De geïnterviewde zegt dat kennis “in huis” moet zijn zodat er actuele kennis is over het systeem. Dit kan bewerkstelligd worden door gekwalificeerd personeel in vaste dienst te nemen. Door het hebben van deze kennis over het systeem kunnen veranderingen eenvoudiger doorgevoerd worden en hierdoor blijft het ERP-pakket flexibel. Conclusie Het huidige ERP-pakket is op dit moment nog geschikt voor het gebruik, maar omdat de leverancier de ondersteuning stopt wordt het vervangen. Schuitema kan het ERP-pakket nog aanpassen, maar doet dit niet in verband met de kosten en de aankomende migratie naar een nieuw ERP-pakket. Het financiële aspect speelt dus een grote rol. Het gebruik van aparte applicaties suggereert dat de functionaliteiten die deze applicaties bieden, niet geboden wordt door het ERP-pakket. Indien dit het geval is, dan is het ERP-pakket minder flexibel dan dat het lijkt. Alhoewel de documentatie bij Schuitema op orde lijkt, is er onzekerheid over de werking van een eventueel nieuw ERP-pakket dat het oude moet vervangen met op zijn minst de oude functionaliteit. Wellicht is de documentatie per applicatie op orde, maar is de samenhang tussen deze applicaties niet uitvoerig gedocumenteerd. Een versplinterde verantwoordelijkheid kan hiertoe leiden. Schuitema kan gekenmerkt worden als een grote organisatie. De geschatte implementatietijd van drie jaar kan er echter op duiden dat er nog veel onvoorziene relaties tussen de aparte applicaties en het ERP-pakket zijn. Dit kan te wijten zijn aan legacy. Met de uitgebreide risicoanalyse wordt de ERPomgeving uitvoerig onderzocht en wordt er getest als er nieuwe modulen worden geïmplementeerd. 80

7.5 Case Kamer van Koophandel Nederland

Omschrijving van de organisatie De Kamer van Koophandel Nederland is het overkoepelende orgaan van alle Nederlandse Kamers van Koophandel. Iedere wijziging van bijvoorbeeld het handelsregister die bij een lokale Kamer van Koophandel gedaan wordt, komt terecht bij de Kamer van Koophandel Nederland. De Kamer van Koophandel Nederland beheert deze gegevens. Deze gegevens omvatten naast naam en adres van de organisatie bijvoorbeeld ook de jaarlijkse omzet, organisatievorm en de bestuurlijk verantwoordelijken. De Kamer van Koophandel Nederland is een organisatie die door de Nederlandse overheid is opgericht. Naast het beheer biedt de Kamer van Koophandel Nederland deze gegevens aan belangstellenden. Dit kunnen particulieren zijn om gegevens over een organisatie op te vragen. Andere grote afnemers zijn banken, om controles uit te kunnen oefenen op bijvoorbeeld kredietwaardigheid van een organisatie bij het afsluiten van een lening. Een zeer belangrijke afnemer is de Belastingdienst, die de gegevens om controledoeleinden gebruikt. Het huidige ERP-pakket Er is bij Kamer van Koophandel Nederland niet sprake van een enkel pakket. Er wordt gewerkt met losse modulen, die samenwerken door middel van een service bus. De modulen worden door een softwareleverancier geleverd. De Kamer van Koophandel Nederland hanteert het Service Oriented Architecture principe (zie paragraaf 5.3), waarbij er geen directe koppeling is tussen modulen, er is alleen koppeling met de service bus. Er is voor dit principe gekozen omdat het legacy zou voorkomen. Daarnaast streeft de Kamer van Koophandel Nederland een multichanneling strategie na: iedere klant moet een op maat gemaakte service kunnen ontvangen (zie paragraaf 1.4). Dit vereist de mogelijkheid om modulen dynamisch te kunnen koppelen met elkaar, om op deze manier de gewenste gegevens te verkrijgen. Het voorgaande ERP-pakket, eveneens losse modulen maar dan met diverse connectoren aan elkaar verbonden, kon geen dynamische koppelingen maken en dus niet de gewenste service leveren. De vorige ERP-oplossing was in eigen beheer ontwikkeld en was niet alleen vervangen omdat het niet de gewenste functionaliteit kon leveren. De modulen waren dusdanig met elkaar verweven geraakt dat er sprake was van legacy. Er is gekozen om de legacy per module te onderzoeken, zodat er per module gewijzigd kon worden. Daarbij werd het gehele ERP-pakket niet uit het oog verlopen. Op dit

81

moment wordt er nog steeds aan het vervangingstraject gewerkt om alle legacy volledig te verwijderen. Er wordt op dit moment vrijwel geen maatwerk gebruikt bij de Kamer van Koophandel Nederland. Dit is bewust gedaan, om zo veel mogelijk standaarden te gebruiken en zodoende minder specifieke componenten te hebben. Uitzondering hierop is het handelsregister. Aangezien de Kamer van Koophandel Nederland de enige is die het Handelsregister beheert, is hier geen standaard pakket voor. De ERP-omgeving wordt gebruikt voor vrijwel alle taken binnen de organisatie. Medewerkers van lokale Kamers van Koophandel worden door de software ondersteund in processen, en dwingen deze processen af. Kenmerkend is de controle bij de Gemeentelijke Basis Administratie (GBA) bij iedere inschrijving: De gegevens uit het GBA zijn leidend. Dit is bij wet bepaald. Iedere nacht worden gegevens uit het GBA gehaald en vergeleken met de gegevens uit de database en indien nodig bijgewerkt. Naast koppelingen met het GBA, kunnen organisaties ook rechtstreeks gekoppeld worden met de service bus. De Belastingdienst is hier een voorbeeld van. De onderstaande afbeelding geeft weer hoe de werking van de ERP-omgeving er globaal uit ziet. De modulen zijn met de service bus gekoppeld. De Belastingdienst heeft een rechtstreekse koppeling op de service bus.

Afbeelding 7: ERP-omgeving Kamer van Koophandel Nederland

82

Verantwoordelijkheden De verantwoordelijkheid voor het werken van de ERP-omgeving ligt bij de leverancier. Er zijn service contracten opgesteld over de beschikbaarheid. De leverancier is eveneens verantwoordelijk voor de documentatie. Indien er een module aangeschaft wordt, dan wordt er bij deze module documentatie geleverd, samen met de instellingen en parameters. De kosten voor het onderhoud zijn gestegen ten opzichte van de onderhoudskosten van de oude configuratie. Dit komt omdat de huidige configuratie een andere manier van werken heeft door middel van de Service Oriented Architecture. Deze kosten zijn overigens niet iedere maand zeer uiteenlopend, aangezien er ook hier weer gebruik wordt gemaakt van servicecontracten. Flexibiliteit van het ERP-pakket De huidige architectuur van de IT-omgeving is bewust gekozen om geen legacy te laten ontstaan. Dit zou voorkomen moeten worden door SOA te gebruiken. Modulen zouden eenvoudig “in het systeem geklikt” moeten kunnen worden zodat de ERP-omgeving flexibel blijft.. Omwille van de verwerkingssnelheid wordt er gebruik gemaakt van virtuele machines. Daarnaast vindt er load-balancing plaats om niet-gebruikte verwerkingssnelheid door een ander systeem te kunnen benutten. De verlangde kwaliteit bepaalt mede de prioriteit. Indien het systeem meer verwerkingssnelheid nodig heeft, dan kan er een extra licentie gekocht worden. Daardoor worden extra processoren of extra harde schijven beschikbaar gemaakt voor het systeem. Dit is overigens een kwestie van het invoeren van een activatiecode. De verwerkingssnelheid is feitelijk al aanwezig, maar er kan ingeschakeld worden indien dat noodzakelijk is. Vervangen van het ERP-pakket De huidige architectuur is er op gericht om functionaliteiten eenvoudig te kunnen vervangen of uit te kunnen breiden. Functionaliteiten kunnen eenvoudig toegevoegd worden, waardoor de uitbreidbaarheid eenvoudig blijft. Tegelijkertijd kunnen functionaliteiten verwijderd worden, aangezien er geen koppelingen zijn met andere modulen. Dit zou legacy moeten voorkomen. Qua capaciteit zit de organisatie voorlopig nog niet aan het plafond: zodra er hardwarematige capaciteitsproblemen dreigen, kan er extra capaciteit geactiveerd worden. Er wordt dus voorlopig nog niet nagedacht over het vervangen van het systeem. Er wordt echter met klem genoemd dat er geen maatwerk wordt gebruikt, maar standaardapplicaties en -modulen. De reden hiervoor is dat standaarden eenvoudiger geaccepteerd worden en gemakkelijker uit te breiden zijn. 83

Conclusie De omgeving van de Kamer van Koophandel Nederland ziet er veelbelovend uit. De organisatie is nog druk bezig met het migreren, maar als er eenmaal volledig overgestapt is naar de nieuwe omgeving, dan lijkt de organisatie nooit meer te maken te krijgen met legacy omdat er SOA gebruikt wordt. De vraag is echter hoe het pakket zich ontwikkelt in de loop der jaren. Er zijn dan geen koppelingen tussen modulen onderling, maar de modulen zijn wel allen gekoppeld aan de service bus. Dit legt een grote belasting op deze service bus. De capaciteit van de service bus is groot, maar niet oneindig. De literatuur is tegenstrijdig wat betreft het gebruik van SOA. Het is de vraag of de beloften die over SOA gedaan zijn ook daadwerkelijk uitkomen. De Kamer van Koophandel Nederland koopt bij een leverancier software die voldoet aan standaarden. De vraag is in hoeverre er standaarden zijn en of de leverancier zich hier wel aan houdt. De onderhoudskosten liggen hoger ten opzichte van de oude configuratie. De vraag is welke prijs organisaties willen betalen voor het flexibel en online houden van de systemen, en tegen welke functionaliteit. Voor de Kamer van Koophandel Nederland is er gekozen om een hoge prijs hiervoor te betalen. Als SOA bij iedere implementatie duurder is dan bij een niet-SOA implementatie, dan is het de vraag of SOA een groot succes wordt.

84

7.6 Conclusies gebruik ERP-pakketten in de praktijk Het eerste punt dat direct opvalt uit alle cases is dat alle vier de organisaties ERP-pakketten een belangrijke rol toebedelen. Het ERP-pakket is van belang voor de bedrijfsvoering. Dit is niet zo vreemd, aangezien vrijwel alle afdelingen bij alle vier de organisaties geautomatiseerd worden door middel van het ERP-pakket. De vervanging van het oude ERP-pakket naar het huidig ERP-pakket heeft de volgende oorzaken: -

Het ERP-pakket bood niet meer de gewenste capaciteit;

-

Het ERP-pakket kan niet meer uitgebreid worden;

-

De leverancier ondersteunt het ERP-pakket niet meer;

-

De kosten voor het onderhoud van het ERP-pakket werden te hoog.

De implementatietrajecten naar de huidige ERP-pakketten varieerden aanzienlijk: van enkele maanden tot enkele jaren. Wellicht heeft dit te maken met de grootte van de organisatie en de mate van geworteldheid van het ERP-pakket. Opvallend is dat een organisatie met een grote hoeveelheid legacy een langer implementatietraject moest doorlopen, zoals dat bij Schuitema het geval was. Als er bij de onderzochte bedrijven gekeken wordt naar de flexibiliteit van het huidige ERP-pakket, dan geldt ook hier dat er problemen ontstaan op het gebied van leveranciersondersteuning, kosten, capaciteit en flexibiliteit. Uitzondering hierop is de Kamer van Koophandel Nederland maar zij zijn ook pas overgeschakeld naar een nieuwe omgeving. Het wordt in iedere case duidelijk dat er naast het ERP-pakket zelf ook nog aparte software wordt gebruikt voor het vervullen van andere automatiseringstaken. De redenen hiervoor zijn onder andere dat het huidige ERP-pakket de functionaliteit van de andere software niet ondersteunt. Dit is een indicator voor inflexibiliteit: Het ERP-pakket kan niet of niet eenvoudig meer de gewenste functionaliteit leveren. Omdat er andere applicaties naast het ERP-pakket gebruikt worden, wordt de druk op het ERPpakket groter. Omdat er gegevens tussen de applicatie en het ERP-pakket uitgewisseld worden om toch een vorm van integratie te krijgen, ontstaan er meer afhankelijkheden. Het aanschaffen, implementeren en uitbreiden van een ERP-pakket lijkt een continu proces. Nadat het ERP-pakket is aangeschaft en geïmplementeerd, wordt het veranderd. Indien blijkt dat de gewenste functionaliteit naar verloop van tijd niet meer ondersteund wordt, komen er aparte applicaties bij. Vervolgens kunnen deze applicaties niet meer verbonden worden met het ERP-pakket 85

omdat de verwerkingssnelheid te laag is of omdat de mogelijkheden niet meer toereikend zijn. Als reactie hierop wordt er weer een nieuw ERP-pakket aangeschaft. Deze gang van zake lijkt bevestigd te worden door de cases: iedere organisatie is bezig met een nieuw ERP-pakket, of is bezig met een implementatie daarvan. De documentatie is bij veel bedrijven niet op orde. De oorzaak hiervan is dat er geen verantwoordelijke is, waardoor er niet gewaakt wordt over actuele en bijgewerkte documentatie. Dit leidt ertoe dat er later uitvoerig onderzoek nodig was over de werking van het ERP-pakket. De legacy is lastig te doorzien. Als mogelijke oplossingen om flexibel te blijven noemen de geïnterviewden de volgende mogelijkheden: -

Standaarden gebruiken;

-

Open databasestructuur gebruiken;

-

Schaalbaarheid creëren;

-

Kennis van het systeem behouden door documentatie of vakmensen;

-

Gebruik de Service Oriented Architecture.

Dit komt deels overeen met de literatuur. Door het gebruik van standaarden kunnen applicaties beter op elkaar aansluiten. De open databasestructuur kan gegevensuitwisseling eenvoudiger mogelijk maken. Door het creëren van schaalbaarheid kan de verwerkingssnelheid van het ERPpakket naar wens worden vergroot, bijvoorbeeld door extra hardware. Door het hebben van kennis over het systeem, weet men precies hoe het systeem werkt, en wat de gevolgen zijn voor een verandering. Alle in de interviews gegeven suggesties en tips zullen vrijwel zeker tot een flexibeler systeem leiden dan wanneer de organisatie deze tips en suggesties niet zou toepassen. De organisaties maken allen gebruik van verschillende soorten ERP-pakketten (zelfontwikkeld, branchespecifiek, branchegeneriek). De organisaties hebben echter allen te maken met legacy. Dit kan een indicatie zijn dat legacy ontstaat door andere factoren dan door de keuze voor het soort ERP-pakket. Het gebruik van de Service Oriented Architecture leidt op dit moment bij de Kamer van Koophandel Nederland tot een flexibel systeem. Volgens de literatuur is SOA nog niet uitvoerig bewezen. Het is de vraag of SOA over bijvoorbeeld 30 jaar nog steeds zo flexibel is als op dit moment. Desalniettemin is SOA een interessante ontwikkeling die zeker gevolgd moet worden als het gaat om legacybestrijding en het behoud van flexibiliteit in ERP-pakketten.

86

8. Conclusie In dit hoofdstuk komen de conclusies aan bod van het onderzoek. De eerste paragraaf, “algehele conclusie”, vat de gevonden conclusies en resultaten uit de literatuurhoofdstukken en het praktijkhoofdstuk samen. Vervolgens worden beiden met elkaar geconfronteerd, om tot de algehele conclusie te komen. In de tweede paragraaf, “Antwoord op de onderzoeksvraag”, wordt de onderzoeksvraag beantwoord. Alvorens dit te kunnen doen, worden eerst de subonderzoeksvragen beantwoord.

8.1 Algehele conclusie ERP-pakketten worden gebruikt voor het automatiseren van bedrijfsprocessen. Er zijn diverse niveaus mogelijk van ondersteuning. Deze niveaus hebben betrekking op de mate van integratie. Integratie van software leidt tot een meerwaarde: hoe, des te meer gegevens de software onderling kan uitwisselen. Deze gegevens kunnen vervolgens weer gebruikt worden in andere processen. Er kleeft echter een nadeel aan integratie: hoe verder de integratie reikt, des te meer afhankelijkheden tussen softwareonderdelen er ontstaan. Een verandering in een module kan gevolgen hebben voor andere modules. Er zijn diverse mogelijkheden om een ERP-pakket te verwerven. Het kan speciaal ontwikkeld worden, er kan een generiek pakket aangeschaft worden, of er kan een specifiek pakket aangeschaft worden. De verschillen zitten met name in de businessmodellen die het pakket ondersteunt. Een generiek pakket moet door middel van parameters het generieke businessmodel “passend” gemaakt worden op het bedrijf. Bij een specifiek pakket zou dit al minder het geval moeten zijn, omdat het pakket specifiekere businessmodellen ondersteunt. Bij een zelf ontwikkeld pakket kan het businessmodel naar wens gemaakt worden. Door vele afhankelijkheden wordt de werking van het ERP-pakket onoverzichtelijk. Indien dit alles goed gedocumenteerd zou zijn, dan zou de werking eenvoudig te achterhalen zijn. Echter, de bevindingen uit zowel de literatuur als de praktijk zijn dat documentatie vaak een “ondergeschoven kind” is. Een ERP-pakket wordt vaak uitgebreid door middel van extra modulen. Dit biedt extra functionaliteiten. Indien deze modulen niet (meer) beschikbaar zijn, dan is het mogelijk om andere software te gebruiken voor deze functionaliteiten. Om integratie te bereiken, worden er omzettingstools of converters gebruikt om het oorspronkelijke ERP-pakket te kunnen benaderen. 87

Hierdoor behoort de toegevoegde software niet direct tot het oorspronkelijke ERP-pakket, maar kan het hiermee wel gegevens uitwisselen. Het nadeel van deze methode is dat de omzettingstool of converter voor prestatieverlies zorgt: het vormt een extra belasting op het ERP-pakket bovenop de belasting die door de extra functionaliteit gecreëerd wordt. Dit is zeker indien er meerdere van dit soort oplossingen gebruikt worden. Het is overigens niet vreemd dat er voor dit soort oplossingen gekozen wordt. Aangezien de gewenste functionaliteit niet meer in het huidige ERP-pakket toe te voegen is als module, is de organisatie genoodzaakt om aparte applicaties te gebruiken. Door de opeenstapeling van extra software, modules en afhankelijkheden ontstaat er ICT-legacy. ICTlegacy maakt het lastig om componenten te vervangen of te verwijderen, aangezien het niet duidelijk is welke gevolgen dit heeft voor de werking van het ERP-pakket. Het vervangen van het ERP-pakket wordt ernstig bemoeilijkt, omdat er andere software van dit ERP-pakket afhankelijk is. Dit is volledig in overeenstemming met de resultaten uit de praktijk. Naast ICT-legacy kan een organisatie te maken krijgen business-legacy. Business-legacy heeft betrekking op de business-requirements. Taken, procedures en processen worden volgens de oude business-requirements uitgevoerd. Indien de organisatie haar business-requirements wil veranderen, zullen deze taken, procedures en processen eveneens moeten veranderen. Als deze taken, procedures en processen door het ERP-pakket ondersteund kunnen worden, vereist een aanpassing hiervan een aantal aanpassingen in het ERP-pakket. Dit is echter lastig te bewerkstelligen indien de organisatie een ERP-pakket heeft dat ICT-legacy vertoont. Het veranderen van een ERP-pakket brengt risico’s met zich mee, omdat de werking onvoldoende bekend is. Het businessmodel dat ondersteund wordt door het ERP-pakket zit verweven in het ERP-pakket door middel van de gekozen parameters en is niet eenvoudig te veranderen. De organisatie bevindt zich in dat geval in een spagaat: de organisatie wil graag haar nieuwe business-requirements behalen, maar kan dit alleen bewerkstelligen door het ERP-pakket aan te passen. Dit kan helaas niet, omdat het ERP-pakket onderhevig is aan ICT-legacy. Als de organisatie kan niet snel van business-requirements kan veranderen, is de organisatie inflexibel. De impact hiervan is onder andere dat er concurrentienadeel ontstaat. Concurrenten kunnen misschien wel nieuwe business-requirements realiseren. Uit de literatuur blijkt dat de businessperformance laag is van organisaties met een lage flexibiliteit. Business-legacy en ICT-legacy hebben beiden invloed op alle drie de soorten flexibiliteit (operationeel, structureel, strategisch). De flexibiliteit van de organisatie wordt dan lager. Dit wordt door zowel de literatuur als de praktijk versterkt. Dit gaat zeker op indien het ERP-pakket ouder wordt, en er meer ICT-legacy en businesslegacy ontstaat. 88

Om de organisatie flexibel te houden, moet er allereerst gezorgd worden dat het ontstaan van ICTlegacy en business-legacy vermeden wordt. ICT-legacy kan voorkomen worden door de volgende punten in acht te nemen: - Zorg dat de documentatie op orde blijft, zodat de exacte werking van het ERP-pakket en de omliggende systemen altijd na te gaan is; - Vermijd "spaghetticode" zodat er een heldere structuur blijft (dit geldt overigens alleen voor zelfgebouwde software, omdat er bij de aanschaf van een ERP-pakket louter parameters ingesteld dienen te worden); - Zorg dat er voldoende gekwalificeerd personeel beschikbaar is; - Zorg dat de performance van het systeem en het adaptatievermogen op orde blijven. Business-legacy kan niet makkelijk noch altijd voorkomen worden, aangezien er tijdens de implementatie van het ERP-pakket nu eenmaal gekozen moet worden voor een businessmodel en de daarbij behorende processen. Er kan echter wel achterhaald worden welke processen er op dit moment gebruikt worden door onder andere het gebruik van de huidige documentatie, “program slicing” en het afnemen van interviews bij werknemers. De flexibiliteit kan verbeterd worden door de variëteitbenadering te gebruiken: De werking van het proces is de verzameling van de variëteiten van het proces. Indien er zich een onvoorziene situatie voordoet, kan er een nieuwe variëteit gecreëerd worden. De variëteit is dus een variant op het proces dat deze onvoorziene situatie kan afhandelen. Een proces wordt op deze manier op een uitzonderlijke wijze gestandaardiseerd: Iedere mogelijk detail is immers vastgelegd in de variëteit van het proces. Dit leidt tot een zeer hoge mate van flexibiliteit: indien een variëteit niet bestaat, dan kan deze eenvoudig gecreëerd worden. Het implementeren van de variëteitbenadering is een lastig en omslachtig proces. Als het echter geïmplementeerd is leidt het tot een hogere mate van flexibiliteit. In de praktijk is gebleken dat ERP-pakketten de in de literatuur gevonden resultaten zich ook in dit onderzoek hebben voorgedaan. Het ERP-pakket wordt aangeschaft met alle mogelijke flexibiliteitopties open. Naarmate het pakket geïmplementeerd is (na een traject van enkele maanden tot enkele jaren) worden er instellingen veranderd of worden er modulen toegevoegd. Als dat niet mogelijk is wordt er aparte software gebruikt om alsnog de functionaliteit te kunnen bieden. Dit wordt gedaan met extra koppelingen en converters. De verwerkingssnelheid en uitbreidbaarheid van het ERP-pakket is eindig. In de praktijk krijgen organisaties daar snel mee te maken indien er vele zaken uitgebreid worden. De druk wordt groot op het pakket. Door de vele uitbreidingen creëren de 89

organisaties soms een wirwar van modules, databases en applicaties, waardoor er ICT-legacy ontstaat. Als de wens om te veranderen toeneemt, zijn de mogelijkheden die het ERP-pakket biedt hier soms te beperkt voor. Het gevolg is dat de organisatie een nieuw ERP-pakket verkiest. Een lang onderzoekstraject volgt, waarna er weer een periode van implementatie zal ontstaan. Het lijkt op een cyclisch proces. Opvallend is dat de vier organisaties allen gebruik maken van verschillende ERP-pakketten (laten ontwikkelen, specifiek en generiek). Er lijkt echter geen groot verschil tussen de soorten te zitten als het gaat om flexibiliteit in de toekomst. Tijdens de interviews zijn de volgende adviezen om het ERP-pakket zo lang mogelijk flexibel te houden naar voren gekomen: -

Standaarden gebruiken;

-

Open databasestructuur gebruiken;

-

Schaalbaarheid creëren;

-

Kennis van het systeem behouden door documentatie of vakmensen;

-

Gebruik de Service Oriented Architecture.

Door het gebruik van standaarden kunnen applicaties beter op elkaar aansluiten. De open databasestructuur kan gegevensuitwisseling eenvoudiger mogelijk maken. Door het creëren van schaalbaarheid kan de verwerkingssnelheid van het ERP-pakket naar wens worden vergroot. Door het hebben van kennis over het systeem, weet men precies hoe het systeem werkt, en wat de gevolgen zijn voor een verandering. Het gebruik van de Service Oriented Architecture is wellicht een methode die in de toekomst flexibiliteit kan waarborgen. Slechts een van de vier ondervraagde organisaties gebruikt SOA. De resultaten zijn voor deze organisatie zeer goed. Kanttekening hierbij is dat zij gebruik maken van standaardsoftware en dit niet zelf (laten) ontwikkelen. In de literatuur is helaas tegenstrijdige informatie te vinden. Desalniettemin is het uit het oogpunt van flexibiliteit verstandig om SOA als mogelijke optie mee te nemen.

90

8.2 Antwoord op de onderzoeksvraag In deze paragraaf wordt antwoord gegeven op de onderzoeksvraag en de deelvragen. De eerste deelvraag is: 1. "Wat is een ERP-pakket?" Een ERP-pakket is software die zorg draagt voor de automatisering van verschillende functies van een organisatie. Naast het louter automatiseren, kan een ERP-pakket een meerwaarde bieden door integratie te bereiken waardoor gegevensuitwisseling tussen processen mogelijk wordt. Dit kan leiden tot verregaande automatisering omdat er minder tussenkomst van personeel noodzakelijk is. Daarnaast biedt een ERP-pakket mogelijkheden voor extra managementinformatie. 1a. "Welke verschillende ERP-pakketten zijn er?" ERP-pakketten zijn er in drie verschillende soorten: -

Een voor de organisatie speciaal ontwikkeld ERP-pakket. Dit kan door de organisatie gemaakt zijn of kan door een softwareleverancier geleverd zijn.

-

Een generiek ERP-pakket. Dit ERP-pakket is in vrijwel iedere branche inzetbaar. Er wordt gekozen voor een generiek businessmodel in dit generieke ERP-pakket, waarna het ERPpakket passend wordt gemaakt door middel van parameters voor het gebruik in de organisatie.

-

Een specifiek ERP-pakket. Dit ERP-pakket is ontwikkeld voor een bepaalde branche. Het omvat enkele specifieke businessmodellen die speciaal geschikt zijn voor de branche waarin organisatie actief is. Het specifieke ERP-pakket moet eveneens aangepast worden door middel van parameters om specifieke wensen van de organisatie te kunnen bewerkstelligen.

De verschillen zitten dus met name in de beschikbaarheid en het toegewezen zijn van het businessmodel. Indien het ERP-pakket speciaal ontwikkeld is, zal het businessmodel exact aansluiten bij de organisatie. Bij specifieke en generieke ERP-pakketten worden er gewerkt met standaard businessmodellen die aangepast en ingesteld worden door middel van parameters. 1b. "Wat zijn de voordelen en nadelen voor het gebruik van een ERP-pakket? Naast het automatiseren van verschillende functies van een organisatie, biedt het ERP-pakket eveneens integratie tussen deze functies. Dit biedt een meerwaarde, omdat er extra efficiëntie kan worden bereikt. Daarnaast is er meer managementinformatie beschikbaar. Het nadeel van een ERPpakket is dat integratie gepaard gaat met extra afhankelijkheden. Deze afhankelijkheden kunnen het 91

vervangen van het ERP-pakket bemoeilijken. Het implementeren van een ERP-pakket kost zeer veel tijd. Naast de tijd spelen ook de kosten een rol. ERP-pakketten zijn duur in aanschaf. Een speciaal ontwikkeld ERP-pakket is hierbij het duurst. 2. "Wat is legacy?" Een onderdeel kan als ‘legacy’ worden beschouwd als het getracht wordt te veranderen maar door technische oorzaken en organisatorische afhankelijkheden moeilijk te veranderen is. Omdat legacy niet eenvoudig verwijderd kan worden, staat het verandering in de weg. 2a “Welke soorten legacy zijn er?” Legacy kent een tweetal vormen: -

ICT-legacy. ICT legacy wordt gekenmerkt door lastig te verwijderen ICT-componenten, waardoor de verandering hiervan niet eenvoudig is. ICT-legacy wordt gedefinieerd als: " ICTlegacy is een onderdeel van de informatievoorziening dat getracht wordt te veranderen maar dat wordt door technische oorzaken en organisatorische afhankelijkheden bemoeilijkt ".

-

Business-legacy. Business-legacy is geworteld in de organisatie in de vorm van verouderde processen, die het veranderen naar nieuwe processen bemoeilijkt (bijvoorbeeld door de verandering van business-requirements) omdat ze bijvoorbeeld door het ERP-pakket nog niet ondersteund worden. Het vereist verandering van het ERP-pakket om deze nieuwe processen te kunnen ondersteunen. Dit wordt weer bemoeilijkt door ICT-legacy. 2b "Waardoor ontstaat legacy?"

ICT-legacy ontstaat omdat er vele afhankelijkheden ontstaan tussen modulen van het ERP-pakket en van eventueel andere applicaties. Dit is zeker het geval indien het ERP-pakket wordt uitgebreid: er ontstaan in dat geval nog meer afhankelijkheden. De organisatie weet wellicht niet meer wat de invloed is van het veranderen van een module: er zijn wellicht meerdere modulen van afhankelijk. Het gevaar schuilt in grote mate in afhankelijkheden van modulen van het ERP-pakket. Indien het ERP-pakket niet meer naar wens werkt, wordt de bedrijfsvoering in gevaar gebracht. Business-legacy sluipt in het systeem zodra het ERP-pakket wordt geïmplementeerd. Op dat moment worden namelijk de dan geldende processen vastgelegd in het ERP-pakket. Het veranderen van het ERP-pakket leidt tot risico’s, waardoor oudere processen slechts moeilijk te vervangen zijn. 92

2c”Hoe kan legacy voorkomen worden?” ICT-legacy kan voorkomen worden door de volgende punten in acht te nemen: - Zorg dat de documentatie op orde blijft, zodat de exacte werking van het systeem altijd na te gaan is; - Vermijd "spaghetticode" zodat er een heldere structuur blijft (dit geldt overigens alleen voor zelfgebouwde software, omdat er bij de aanschaf van een ERP-pakket louter parameters ingesteld dienen te worden); - Zorg dat er voldoende gekwalificeerd personeel beschikbaar is; - Zorg dat de performance van het systeem en het adaptatievermogen op orde blijven door regelmatig onderhoud te verrichten. Het gebruik van standaarden zorgt dat uitbreidingen eenvoudiger te bewerkstelligen zijn. Business-legacy kan niet eenvoudig voorkomen worden, aangezien er tijdens de implementatie van het ERP-pakket nu eenmaal gekozen moet worden voor een businessmodel en de daarbij behorende processen. Er kan echter wel achterhaald worden welke processen er gebruikt worden door onder andere het gebruik van de huidige documentatie, “program slicing” en het afnemen van interviews bij werknemers. 3. "Wat is organisationele flexibiliteit?" Organisationele flexibiliteit is de snelheid waarmee een verandering plaats kan vinden van een oude situatie naar een nieuwe situatie. Hoe sneller de organisatie kan veranderen, des te flexibeler is de organisatie. Het is gewenst om flexibel te zijn: hierdoor kan een organisatie beter inspelen op klantenwensen waardoor haar concurrentiepositie kan worden versterkt. Daarnaast wordt flexibiliteit in verband gebracht met de performance van de organisatie. 3a "Wat beïnvloedt de organisatorische flexibiliteit?” Er worden drie soorten flexibiliteit onderscheiden: - Operationele flexibiliteit, waarmee het volume en /of de mix van de output van een organisatie gemoeid is; - Structurele flexibiliteit, waarmee aanpassingen van de vorm (structuren en processen) van een organisatie gemoeid zijn; 93

- Strategische flexibiliteit, waarmee de visie en doelstellingen van een organisatie gemoeid zijn. Alle drie de soorten flexibiliteit hebben direct invloed op de organisationele flexibiliteit. De hoeveelheid aanwezige ICT-legacy en Business-legacy beïnvloedt alle drie de soorten flexibiliteit, waardoor de organisationele flexibiliteit eveneens beïnvloed wordt. 3b "Hoe kan organisationele flexibiliteit behouden worden?" Een belangrijke oorzaak voor organisationele inflexibiliteit blijkt ICT-legacy en business-legacy te zijn. Door beide vormen van legacy te voorkomen kan de organisatie snel schakelen tussen nieuwe technologie, nieuwe vormen van (software) ondersteuning en business-requirements. Tijdens de interviews zijn de volgende adviezen om het ERP-pakket zo lang mogelijk flexibel te houden naar voren gekomen: -

Standaarden gebruiken;

-

Open databasestructuur gebruiken;

-

Schaalbaarheid creëren;

-

Kennis van het systeem behouden door documentatie of vakmensen;

-

Gebruik de Service Oriented Architecture.

De flexibiliteit kan verbeterd worden door de variëteitbenadering te gebruiken: De werking van het proces is de verzameling van de variëteiten van het proces. Indien er zich een onvoorziene situatie voordoet, kan er een nieuwe variëteit gecreëerd worden. Een proces wordt op deze manier op een uitzonderlijke wijze gestandaardiseerd: Iedere mogelijke vorm van detail is immers vastgelegd in de variëteit van het proces. Dit leidt tot een zeer hoge mate van flexibiliteit: indien een variëteit niet bestaat, dan kan deze eenvoudig gecreëerd worden. Het implementeren van de variëteitbenadering is een lastig en omslachtig proces. Als het echter geïmplementeerd is leidt het tot een hogere mate van flexibiliteit. De combinatie van de variëteitbenadering en het voorkomen van legacy leidt tot een systeem dat zeer flexibel is. De onderzoeksvraag van deze thesis is: " Welke maatregelen zijn noodzakelijk om een door legacy verouderd ERP-pakket te kunnen vervangen zodat de organisatorische flexibiliteit behouden blijft?"

94

Door middel van de antwoorden op de deelvragen kan het volgende antwoord gegeven worden op deze onderzoeksvraag. Zoals al naar voren is gekomen, is ICT-legacy een belangrijke oorzaak van inflexibiliteit. ICT-legacy kan voorkomen worden door de volgende punten in acht te nemen: - Zorg dat de documentatie op orde blijft, zodat de exacte werking van het systeem altijd na te gaan is; - Vermijd "spaghetticode" zodat er een heldere structuur blijft (dit geldt overigens alleen voor zelfgebouwde software, omdat er bij de aanschaf van een ERP-pakket louter parameters ingesteld dienen te worden); - Zorg dat er voldoende gekwalificeerd personeel beschikbaar is; - Zorg dat de performance van het systeem en het adaptatievermogen op orde blijven door regelmatig onderhoud te verrichten. Business-legacy kan niet zozeer voorkomen worden, aangezien er tijdens de implementatie van het ERP-pakket nu eenmaal gekozen moet worden voor een businessmodel en de daarbij behorende processen. Er kan echter wel achterhaald worden welke processen er op dit moment gebruikt worden door onder andere het gebruik van de huidige documentatie, program slicing en het afnemen van interviews bij werknemers. Tijdens de interviews zijn de volgende adviezen om het ERP-pakket zo lang mogelijk flexibel te houden naar voren gekomen: -

Standaarden gebruiken;

-

Open databasestructuur gebruiken;

-

Schaalbaarheid creëren;

-

Kennis van het systeem behouden door documentatie of vakmensen;

-

Gebruik de Service Oriented Architecture.

Door de variëteitbenadering te gebruiken ontstaan er standaard processen die per variëteit uit te breiden zijn. Dit verhoogt eveneens de flexibiliteit. Door alle adviezen op te volgen blijft een ERP-pakket langer flexibel. Hierdoor kan het ERP-pakket eenvoudiger aangepast worden om te voldoen aan bijvoorbeeld nieuwe business-requirements.

95

Er moet in gedachten worden gehouden dat een ERP-pakket niet oneindig uitbreidbaar is. Op een bepaald moment is het ERP-pakket “op” en zal het vervangen moeten worden. Indien men eindeloos door blijft gaan met het koppelen van extra applicaties, wordt de hoeveelheid ICT-legacy alleen maar groter. Het vervangen van een ERP-pakket wordt daardoor steeds lastiger, waardoor de flexibiliteit eveneens afneemt. Durf dus op tijd te kijken naar een vervangend ERP-pakket indien het oude niet meer geschikt blijkt.

96

9. Vervolgonderzoek Er is in dit onderzoek gekozen om naast de ERP-pakketten zelf ook de losstaande modulen en applicaties mee te nemen, als verlengstuk van het ERP-pakket. Dit zou een indicatie kunnen zijn dat het ERP-pakket niet meer de gewenste functionaliteiten kan leveren. Er is bewust gekozen om de losstaande modulen en applicaties wel mee te nemen in dit onderzoek naar de vervanging: het zou immers mogelijk kunnen zijn dat de gewenste functionaliteit wel in het ERP-pakket te implementeren is, maar dat de kosten van een losse module of applicatie lager zijn dan die van het uitbreiden van deze functionaliteit in het ERP-pakket. De redenen voor het kiezen van losse modulen en applicaties zijn deels aan bod gekomen in het praktijkonderzoek. Sommige organisaties gebruiken deze vorm van uitbreiden omdat het ERP-pakket daadwerkelijk tekort schiet. Dit is echter geen hard bewijs voor het feit dat uitbreiding een gevolg is van een ERP-pakket dat tekort schiet. Duidelijk is wel dat extra software dat verbonden wordt met het ERP-pakket leidt tot extra afhankelijkheden en wellicht tot een vorm van moeilijk te verwijderen legacy. Vervolgonderzoek naar de redenen voor het gebruik van losse modulen en applicaties zou duidelijkheid hierover kunnen scheppen. De gevonden resultaten uit de praktijk zijn in overeenstemming met wat de literatuur aangeeft. Het praktijkonderzoek had betrekking op een viertal organisaties. Omwille van de tijd was het niet mogelijk om een groot aantal organisaties te interviewen. Wellicht dat er bij een grotere hoeveelheid organisaties andere conclusies kunnen worden gevonden. Overigens is het verrassend dat alle vier de organisaties (100%) een zelfde soort verloop kenden. Dit is dus een goede indicatie. De gekozen organisaties waren allen verschillend in grootte en verschillend in de branche. Het is mogelijk dat er verschil zit in het gebruik van het ERP-pakket tussen kleine en grote organisaties. Daarnaast is het mogelijk dat er grote verschillen te vinden zijn tussen branches. Alhoewel de vier organisaties een mix waren van overheid, dienstensector en commerciële organisatie, is het natuurlijk een laag aantal. De soorten ERP-pakketten die de organisaties gebruikten waren eveneens verschillend. De ene organisatie gebruikte een zelfontwikkeld ERP-pakket, de ander een specifiek ERP-pakket en weer een ander een generiek ERP-pakket. Een vervolgonderzoek uitgesplitst per branche, per soort ERP-pakket en per grootte zou uit kunnen sluiten dat er verschil zit in deze parameters. Dit is noodzakelijk, omdat een ERP-pakket ingewikkelde software is dat per organisatie verschillend geïmplementeerd dient te worden. Alle organisaties zijn Nederlandse organisaties. Het is mogelijk dat er verschillen zijn in het gebruik van ERP-pakketten in verschillende landen. Er kunnen andere factoren een rol spelen, zoals een lager budget of een markt die langzamer of sneller veranderd ten opzichte van die van Nederland. Een 97

zelfde onderzoek in een ander land zou tot een andere conclusie kunnen leiden. Wang et al. (2006) noemen niet alleen dat er verschil zit in het land waar het ERP-pakket geïmplementeerd is, maar dat er zelfs een verschil is indien de afkomst van de ERP-pakketleverancier verschillend is. Verder onderzoek moet dit gat dichten. Tot slot zou het gebruik en de werking van de Service Oriënted Architecture beter onderzocht moeten worden. Alhoewel het door één organisatie in het praktijkonderzoek gebruikt wordt, is de literatuur nog niet uitvoerig genoeg en biedt tegenstrijdige inzichten. Door het gebruik van de Service Oriented Architecture zou ICT-legacy eenvoudiger te voorkomen zijn. Door hier vervolgonderzoek naar te doen, kan het wellicht als advies meegenomen worden om legacy te bestrijden en om ERPpakketten flexibel te houden.

98

10.

Literatuuroverzicht

Alt R., Fleisch E. (2000) Business Networking Systems: Characteristics and Lessons Learned, International Journal of Electronic Commerce, Volume 5 , Issue 2 (Number 2/Winter 2000/01) pp. 727, M. E. Sharpe, Inc. Backlund A. (2002) The concept of complexity in organizations and informational systems, Volume 31, Issue 1, pp. 30-43. Bakry A. H., Bakry S. H. (2005) Enterprise resource planning: a review and a stope view, International Journal of Network Management, Volume 15, issue 5 (September 2005) pp. 363-370, John Wiley & Sons, Inc. Barrett D.J., Clarke L.A., Tarr P.L., Wise A.E. (1996) A framework for event-based software integration, Transactions on Software Engineering and Methodology (TOSEM) , Volume 5 Issue 4, pp.378-421 ACM. Basoglu N., Daim T., Kerimoglu O. (2007) Organizational adoption of enterprise resource planning systems: A conceptual framework, Journal of High Technology Management Research 18 (2007) pp. 73–97, Elsevier. Beatty R. C., Williams C. D. (2006) ERP II: best practices for successfully implementing an ERP upgrade, Communications of the ACM, Vol. 49, number 3, pp. 105-109, ACM. Benders J., Batenburg R., Blok, van der, H. (2006) Sticking to standards: Technical and other isomorphic pressures in deploying ERP-systems, Information & Management, Volume 43, Issue 2, pp. 194 – 203. Blume M., Appel A.W. (1999) Hierarchical modulairity, ACM Transactions on Programming Languages and Systems, Vol. 21, No. 4, pp. 813-847, ACM Brun M.H., Lanng C. (2006) Reducing barriers for e-business in SME’s through an open service oriented architecture, ICEC '06: Proceedings of the 8th international conference on Electronic commerce, pp. 403-410, ACM. Burmeister B., Arnold M., Copaciu F., Rimassa G. (2008) BDI-agents for agile goal-oriented business processes, Proceedings of the 7th international joint conference on Autonomous agents and multiagent systems: industrial track, pp. 37-44. Burns T. (1993) Auditing MRP systems, SIGSAC Review, Volume 11, Issue 3, pp. 2-13, ACM. Chessbrough, H., Spohrer, J. (2006), A research manifesto for services science, Communications of the ACM vol. 49 issue 7 pp. 35-40

99

Chung S.H., Byrd T. A., Ford F.N. (2005) An Empirical Study of the Relationships Between IT Infrastructure Flexibility, Mass Customization, and Business Performance, The DATABASE for Advances in Information Systems, Summer 2005, Vol. 36, No. 3, pp. 26-44, SIGMIS. Damen J. (2005) Hoe ketenintegratie gebruiken om marges te verbeteren en productiviteit te verhogen?, Managementkennisbank, 2005, http://www.managementkennisbank.nl/NL/facilitairproductie-inkoop-advies/ketenintegratie-samenwerking/marges-productiviteit-ketenmanagement/ Davenport T.H. (1993) Process innovation: reengineering work through information technology, Boston, MA: Harvard Business School Press Dittrich Y., Vaucouleur S. (2008) Practices Around Customization of Standard Systems, CHASE’08, May 13, 2008, Leipzig, Germany, pp. 37-40, ACM Press Dor N., Lev-Ami T., Litvak S., Sagiv M., Weiss D. (2008)Customization change impact analysis for ERP professionals via program slicing, ISSTA '08: Proceedings of the 2008 international symposium on Software testing and analysis, pp. 97-108, ACM Earls A.B., Embury S.M., Turner N.H. (2002) A method for the manual extraction of business rules from legacy source code, BT Technology Journal, Volume 20 Issue 4, pp. 127-145, Kluwer Academic Publishers Emmerich, W., Aoyama, M., Sventek, J. (2007), The impact of research on middleware technology, ACM SIGSOFT Software Engineering Notes vol. 32 issue 1 pp. 21-46, ACM Ethiraj, S., Guler, I., Singh, H. (2000) The impact of internet and electronic technologies on firms and its Implications for Competitive Advantage, Knowledge Wharton, http://johnmolson.concordia.ca/gkersten/ec_papers/models/00Ethiraj_models.pdf Everdingen van, Y., Hillegersberg van, J., Waarts E. (2000) Enterprise resource planning: ERP adoption by European midsize companies, Communications of the ACM, volume 43, issue 4 (april 2000) pp. 2731, ACM. Gabriel R.P., Goldman R. (2006) Conscientious software, OOPSLA’06: Proceedings of the 21th annual ACM SIGPLAN conference on Object-oriented programming systems, languages and applications, pp. 433-450, ACM. Gefen D. (2004) What Makes an ERP Implementation Relationship Worthwhile: Linking Trust Mechanisms and ERP Usefulness, Journal of Management Information Systems , Vol. 21 No. 1, Summer 2004 pp. 263 – 288, M. E. Sharpe, Inc. Giaglis G.M. (1999) Focus issue on legacy systems and business process change: on the integrated design and evaluation of business processes and information systems, Communications of the AIS, volume 2, article 5, pp. 1-33, Association for Information Systems

100

Govers M.J.G. (2003) Met ERP-systemen op weg naar moderne bureaucratieën?, proefschrift, Katholieke Universiteit. Nijmegen, 2003 Govers, M. (2006) ERP-software ondermijnt organisatorische flexibiliteit, Automatiseringsgids nr. 10, 2006. Gupta, A. (2000) Enterprise resource planning: the emerging organizational value systems, Industrial Management and Data Systems, 100 (3),pp. 114-118 Hall R.W. (1983) Zero Investments, Homewood, IL: Dow Jones-Irwin. Hasselbring W. (2000) Information system integration, Communications of the ACM, Volume 43, Issue 6, pp. 32-38, ACM Hau E., Aparicio M. (2008) Software internationalization and localization in Web based ERP, SIGDOC '08: Proceedings of the 26th annual ACM international conference on Design of communication, pp. 175-180, ACM Heinhuis, D. Vries, E.J. de (2007), Customer behavior in multichannel service distribution, PrimaVera Working Paper 2007-12, oktober 2007 Henkel M., Zdrakovic J., Johannesson P. (2004) Service-based processes: designed for business and technology, ICSOC '04: Proceedings of the 2nd international conference on Service oriented computing, pp. 21-29, ACM Ho S.Y., Kwok S.H. (2002) The attraction for personalized services for users in the mobile commerce, SIGecom Exchanges, Volume 3, Issue 4, pp. 10-18, ACM. Holland C., Light B. (2001), A stage Maturity Model for Enterprise Resource Planning Systems Use, ACM SIGMIS Database vol. 21 issue 2, pp. 34-45, ACM Press. Huang H., Tsai W.T., Bhattacharya S., Chen X.P., Wang Y., Sun J. (1996) Business Rule Extraction from Legacy Code, Proceedings of IEEE 20th Computer Software and Applications Conference (COMPSAC’96), pp.162-167 Huizing A. (2007) The Value of a Rose: Rising above Objectivism and Subjectivism, University of Amsterdam, Netherlands . Sprouts: Working Papers on Information Systems, 7(11). http://sprouts.aisnet.org/7-11 Jacobs D. (2005) Enterprise software as Service, Queue July/August 2005, pp. 36-42, ACM. Jansen W., Jägers H.P.M., Steenbakkers G.C.A, Melger H. (2003) Business models Ontwerpen voor de toekomst, Ten Hagen & Stam, ICT Bibliotheek, Den Haag 2003, ISBN 90-440-0569-3

101

Jeppesen L. (2005) User toolkits for innovation: Consumers support each other. The journal of product innovation management 2005, Volume 22, pp. 347-362 Product Development & Management Association 2005. Jin Y., Tang A., Han J., Liu Y. (2007) Performance evaluation and prediction for legacy information systems, ICSE '07: Proceedings of the 29th international conference on Software Engineering, pp. 540-547, IEEE Computer Society Johne, A. Storey, C. (1998) New service development: a review of the literature and annotated bibliography. European Journal of Marketing, volume 32, no. 4, pp. 184-251 MCB university press 1998. Kelly S., Gibson N., Holland C. P., Light B. (1999) Focus issue on legacy information systems and business process change: a business perspective of legacy information systems, Communications of the AIS, Volume 2 (July 1999), article no. 7, pp. 2-27, Association for Information Systems. Kim Y. G. (1997) Improving Legacy Systems Maintainability, Information Systems Management, Volume 14:1, pp. 7 – 11, Taylor & Francis Koop R., Rooimans R., Theye, de, M. (2003) Regatta, ICT-implementaties als uitdaging voor een viermet-stuurman, Ten Hagen Stam Uitgevers, ISBN 9044005758 Kotler P., Armstrong G., Saunders J., Wong V. (1996) “Principles of marketing”. Pearson Education Limited, Prentice Hall Europe, ISBN 90-430-0821-4 Kumar R.L, Crook C.W. (1999) A multi-disciplinary framework of the interorganizational system, ACM SIGMIS Database winter 1999 volume 30, issue 1, pp. 22-37, ACM Press Kumar K., Hillenberg, van, J. (2000), Enterprise resource planning: an introduction, Communications of the ACM, Volume 43, Issue 4, pp. 22-26, ACM Langefors B. (1995) Essays on infology, Student literature 1995, pp. 70, Lund Lievers B., Lubberding J.B. (2001) Change management, tweede druk,pp. 111-113, Wolters Noordhoff 2001 Lindley J.T., Topping S., Lindley L.T. (2008) The hidden financial costs of ERP software, Managerial Finance, Volume 34 no. 2, 2008, pp. 78-90 Lloyd A., Dewar R., Pooley R. (1999) Legacy information systems and business process change: a patterns perspective, Communications of the AIS, Volume 2 , Issue 4 (December 1999) article no. 2, pp. 2-41, Association for Information Systems.

102

Loeffen J.M.J.,Wortmann J.C. (2000) IT challenges organizational design: how to connect manufacturing concepts to IT. International Journal of Technology Management, Volume 19, no. 6, pp. 630-637 Malone T., Crowston K. (1994) The interdisciplinary study of Coordination, ACM Computer survey 26, volume 1, pp. 87-119. Markus M.L., Tanis C., Fenema, van, P.C. (2000) Enterprise resource planning: Multisite ERP implementations, Communications of the ACM, Volume 43, Issue 4, pp. 42-46, ACM Martinsons M.G. (2004) ERP in China: One package, two profiles, Communications of the ACM, July 2004, Volume 47, no. 7, pp. 65-68 McAdam, R. and Galloway, A. (2005) Enterprise resource planning and organisational innovation: a management perspective, Industrial Management & Data Systems, Vol. 105, No. 3, pp.280–290. Medjahed, B., B. Benatallah, et al. (2003) Business-to-business interactions: issues and enabling technologies, The VLDB Journal, Volume 12, Issue 1, pp. 59-85. Michelis, de, G., Dubois E., Jarke M., Matthes F., Mylopoulos J., Schmidt J.W., Woo C., Yu E. (1998) A three-faceted view of information systems, Communications of the ACM, Volume 41, Issue 12, pp. 64-70, ACM Muntslag, D.R. (2001). De kunst van het implementeren, pp. 1-63, ISBN 9075498454 Nah F.F., Lau J.L. (2001) Critical factors for successful implementation of enterprise systems, Business Process Management Journal, Vol. 7 No. 3, pp. 285-296, MCB University Press Nonaka I., Krogh, von, G. (2006) Organizational Knowledge Creation Theory: Evolutionary Paths and Future Advances, Organization Studies, Vol. 27, No. 8, pp. 1179-1208 Nonaka I., Takeuchi T. (1995) The Knowledge creating company, ISBN 0195092694 O'Brien L., Brebner P., Gray J. (2008) Business transformation to SOA: Aspects of the Migration and Performance and QoS Issues, SDSOA '08, pp. 35-40, ACM. Omelayenko B. (2000) Integration of product ontologies for B2B marketplaces: a preview, SIGecom Exchanges, Volume 2, Issue 1, pp. 19-25, ACM Press. Papazoglou M.P., Heuvel van den W. (2007) Service oriented architectures: approaches,technologies and research issues, The VLDB Journal (2007), Volume 17, pp. 389-415, Springer-Verlag 2007. Phippen A.D., Taylor J., Allen R. (2005) Issues in moving from web services to service orientation, Internet research, Volume 15, no. 5, pp. 518-526

103

Pollock N., Williams R., Procter R. (2003) Fitting standard software packages to non-standard organizations: the “biography of” an enterprise wide System, Technology Analysis & Strategic Management, Volume 15, Issue 3 September 2003 , pp. 317–332. Porter M.E. (1985) "Competitive Advantage",The Free Press. New York Poston R., Grabski S. (2000) The impact of enterprise resource planning systems on firm performance, Proceedings of the twenty first international conference on Information systems, pp. 479-493, ACM. Ragowski A., Somers T. (2002) Enterprise Resource Planning, Journal of Management Information Systems vol. 19 issue 1, pp. 11-15, M. E. Sharpe, Inc. Ragowsky A., Gefen D. (2008) What makes the competitive contribution of ERP strategic, SIGMIS Database, Volume 39, Issue 2, pp. 33-49, ACM Rashid, M.A., L. Hossain, and J.D. Patrick 2002 "The evolution of ERP systems: A historical perspective." In L. Hossain, J.D. Patrick, and M.A. Rashid, Enterprise resource planning: Global opportunities and challenges, pp. 1-16. Hershey: Idea Group Publishing. Rostambeik S., Simoni N., Boutignon A. (2007) Userware: A framework for next-generation personalized services, Computer Communications, Volume 30, Issue 3, pp. 619-629, ButterworthHeinemann. Schepers T.G.J., Lacob M.E., Eck van P.A.T. (2008) A lifecycle approach to SOA Governance, SAC '08, march 16-20 2008, pp. 1055-1061, ACM Sia S., Tang M., Soh C., Boh W. F. (2002) Enterprise resource planning (ERP) systems as a technology of power: empowerment or panoptic control?, ACM SIGMIS Database, Volume 33 , Issue 1 (Winter 2002), pp. 23-37, ACM. Sneed H.M. (2001) Recycling software components extracted from legacy programs, IWPSE '01: Proceedings of the 4th International Workshop on Principles of Software Evolution, pp. 43-51, ACM Sneed H., Erdos K. (1996) Extracting Business Rules from Source Code, Proceedings of the IEEE 4 th international Workshop on Program Comprehension (IWPC’96), pp. 240-247 Soh C., Kien S.S., Tay-yap J. (2000) Enterprise resource planning: cultural fits and misfits: Is ERP an universal solution?, Communications of the ACM, Volume 43, Issue 4, pp. 47-51, ACM Sommerville I. (2000) Software Engineering, 6th edition, chapter 26, pp. 1-22, Addison Wesley 2000. Souza, de, S.C.B., Anquetil N., Oliveira, de, K.M. (2005) A study of the documentation essential to software maintenance, SIGDOC’05: Proceedings of the 23rd annual international conference on Design of communication: documenting & designing for pervasive information, pp. 68-75, ACM. 104

Stedman C. (1998) ERP can magnify errors, Computerworld, www.computerworld.com/home/print.nsf/all/9810197066. Sumner M. (2000) Risk factors in enterprise wide information management system projects, SIGCPR '00: Proceedings of the 2000 ACM SIGCPR conference on Computer personnel research, pp. 180-187, ACM Suresh N., Rao A.N.V., Babu A.J.G. (1996) A software reliability growth model, International Journal of Quality & Reliability Management,Vol. 13 No. 3, 1996, pp. 84-94, MCB University Press

Themistocleous M., Irani Z., O'Keefe R.M. (2001) ERP and application integration Exploratory survey, Business Process Management Journal, volume 7, no. 3, 2001, pp. 195-204, MCB University Press Thiran P., Hainaut J., Houben G., Benslimane D. (2006) Wrapper-based evolution of legacy systems, Transactions on Software Engineering and Methodology (TOSEM), Volume 15, Issue 4, pp. 329-359, ACM Timmers, P. (1998) Business models for electronic markets, International Journal of Electronic Markets, Volume 98, nr. 2, pp. 1-12 Umble E.J., Haft R.R., Umble M.M. (2003) Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research 146, pp. 241-257, Elsevier. Venkateswaran J., Son Y., Kulvatunyou B. (2002) Manufacturing supply chain applications: investigation of influence of modeling fidelities on supply chain dynamics, Proceedings of the 34th conference on winter simulation: exploring new frontiers, december 2002, Winter Simulation Conference, pp. 1183-1191 Verschuren, P.J.M. and Doorewaard, H. (2000) Het ontwerpen van een onderzoek, Utrecht, Lemma. Vogt C. (2002) Intractable ERP: a comprehensive analysis of failed enterprise resource planning projects, ACM SIGSOFT Software Engineering Notes, Volume 27, issue 2, pp. 62-68, ACM. Vries, de, E.J. (2005), Multi-channeling and Front, Mid and Back Office Architectures in the Financial Service Industry, IEEE Second International Workshop on Enterprise Applications and Services in the Finance Industry at the 13th European Conference of Information Systems, Regenburg, May 25-28, 2005, pp. 1-19. Wang E.T.G., Klein G., Jiang J.J. (2006) ERP Misfit: Country of origin and organisational factors, Journal of Management Information Systems, Volume 23, No. 1, pp. 263-292, M.E. Sharpe Inc.

105

Wang X., Sun J., Yang X., He Z., Maddineni S. (2004) Business rules extraction from large legacy systems, CSMR '04: Proceedings of the Eighth Euromicro Working Conference on Software Maintenance and Reengineering, pp. 249-243, IEEE Computing Society Wenger E. (1998) Communities of Practice: Learning, Meaning, and Identity, Cambridge University Press Yen, H.R., and Sheu, C. Aligning ERP implementation with competitive priorities of manufacturing firms: An exploratory study. International Journal of Production Economics, Volume 92, Issue 3, pp. 207–220.

106

11.

Bijlagen

Bijlage A: Vragenlijst Keuze en implementatie De eerste zes vragen hebben betrekking op de keuze en implementatie van de huidige ERP-omgeving. Hierbij wordt achterhaald waarom de huidige ERP-omgeving is gekozen en waar het eventueel mis is gegaan tijdens de implementatie van deze ERP-omgeving. 1. Om welke redenen is het huidige ERP-pakket/ERP-omgeving gekozen? Waarom is het voorgaande ERP-pakket vervangen, of zouden jullie deze willen vervangen? 2. Wat waren de alternatieven, en wat waren de minpunten van deze alternatieve ERP-pakketten? 3. Wat is de (geschatte) implementatieduur geweest van het ERP-pakket? Zou dit sneller gekund hebben? Wat zou hiervoor nodig zijn? 4. Vormt het te vervangen ERP-pakket een obstakel voor een (eventueel) nieuw in te voeren ERPpakket? Zo ja, welke obstakels bent u tegengekomen? 5. Zijn er door de leverancier functionaliteiten beloofd die achteraf niet waar te maken zijn? 6. Welke obstakels bent u tegengekomen tijdens het implementeren van het ERP-pakket? - Organisatieproblemen - veranderende markt - (te) duur onderhoud - te weinig functionaliteit - Onduidelijkheden over de werking - Er ontstonden problemen doordat de werking van het oude ERP-pakket niet duidelijk was - Anders, namelijk... Verantwoordelijkheden en budget De volgende drie vragen hebben betrekking op de verantwoordelijkheden en het budget van de ERPomgeving. Een sterk gespreide verantwoordelijkheid kan duiden op onduidelijkheden en versplintering. Een zeer hoog budget of een structurele overschrijding hiervan kan duiden op een complexe omgeving. 7. Wie is verantwoordelijk voor de werking van het ERP-pakket? Wat wordt er gedaan om de werking te waarborgen? Welke rol speelt de leverancier hierin? 8. Is er een verantwoordelijke voor het opstellen en beheren van documentatie van het ERP-pakket? 9. Welk budget is er beschikbaar voor het onderhoud van het ERP-pakket? Wordt dit vaak overschreden? 107

Huidig ERP-pakket De volgende vragen hebben betrekking op de huidige ERP-omgeving. Deze vragen gaan in op de rol van de ERP-omgeving, de minpunten van de ERP-omgeving, de flexibiliteit en eventueel de mogelijke wens om te vervangen. 10. Hoe oud is de huidige ERP-omgeving? Zijn alle onderdelen ineens vervangen, of is er steeds een deel vervangen? 11. Wat is de rol van het ERP-pakket in de organisatie? Hoe afhankelijk is de organisatie van het ERPpakket? Het ERP-pakket wordt gebruikt voor de volgende functies: - Administratie - Inkoop - Productieplanning - Productie - Voorraadbeheer - logistiek - verkoop - service - HRM - CRM 12. Wat zijn de minpunten van het huidige ERP-pakket? Zijn deze op te lossen? 13. Is er al eens aan vervanging van het ERP-pakket gedacht? Wordt het soepel en eenvoudig vervangen van het ERP-pakket gewaarborgd mocht dit nodig zijn? 14. Denkt u dat vervangen eenvoudig mogelijk is? Waar baseert u dit op? 15. Hoe "flexibel" is het ERP-pakket ten aanzien van uitbreidingen, veranderingen, enzovoorts? Wat doet u om deze flexibiliteit te waarborgen? Voorbeelden flexibiliteit: - Uitbreidingen bewerkstelligen - kunnen inspelen op veranderingen - Platform(on)afhankelijkheid - onvoorziene situaties in processen kunnen opvangen - capaciteit vergroten 108

16. Zijn er op dit moment dingen niet mogelijk met het ERP-pakket, door onvoorziene situaties of bekende problemen in het ERP-pakket? 17. Zijn er zaken die belemmerd worden door het gebruik van het ERP-pakket, zoals bijvoorbeeld het niet kunnen uitvoeren van een uitzonderlijke situatie, of een situatie die anders is dan dat hij in de procedures is vastgelegd? Kunt u hier een voorbeeld van noemen? 18. In hoeverre gebruikt u andere software-ondersteuningspakketten anders dan het ERP-pakket? Voor welke afdelingen gebeurt dit? Werkt deze software samen met het ERP-pakket? Waarom (niet)? Toekomst Tot slot wordt er in de laatste vragen ingegaan op "de toekomst" van de ERP-omgeving. Wanneer zou er overgestapt worden naar een nieuwe ERP-omgeving? Wat zou er dan anders moeten? Deze vragen bieden inzicht in de vervangingswens van de ERP-omgeving. 19. Wat zou voor u in de toekomst de overweging zijn om een ander ERP-pakket aan te schaffen? (Bijvoorbeeld: de leverancier die geen ondersteuning meer biedt, de functionaliteit te beperkt is, enz.) 20. Kunt u op dit moment problemen noemen die bij een toekomstige ERP-pakketimplementatie een rol kunnen gaan spelen, zoals hoge kosten of lange implementatietrajecten? Zijn deze problemen voortijdig te verhelpen? Waardoor doen deze problemen zich voor? 21. Wat zou u doen om het ERP-pakket flexibel te houden zodat het langer mee kan gaan? Hoe zit het met de kosten om dit te bewerkstelligen? Denk aan: - Extra functionaliteiten - Extra gebruikers - extra capaciteit

Hartelijk dank voor uw medewerking!

109

Bijlage B: Antwoorden Paradigit Keuze en implementatie De eerste zes vragen hebben betrekking op de keuze en implementatie van de huidige ERP-omgeving. Hierbij wordt achterhaald waarom de huidige ERP-omgeving is gekozen en waar het eventueel mis is gegaan tijdens de implementatie van deze ERP-omgeving. 1. Om welke redenen is het huidige ERP-pakket/ERP-omgeving gekozen? Waarom is het voorgaande ERP-pakket vervangen, of zouden jullie deze willen vervangen? Het ERP-pakket wat op dit moment gebruikt wordt is gekozen omdat het goed aansloot bij de logistieke en producerende processen. Op dit moment wordt Concorde gebruikt. Het vorige pakket was een door Paradigit ontwikkeld pakket, maar is vervangen omdat het niet meer voldeed aan de wensen. Er wordt een branchespecifieke variant gebruikt. 2. Wat waren de alternatieven, en wat waren de minpunten van deze alternatieve ERPpakketten? Het huidige pakket draait op dit moment meer dan acht jaar. De alternatieven waren minder gericht op de logistieke en producerende processen, en om deze manier minder geschikt. 3. Wat is de (geschatte) implementatieduur geweest van het ERP-pakket? Zou dit sneller gekund hebben? Wat zou hiervoor nodig zijn? Het implementeren van het huidige ERP-pakket heeft ongeveer drie maanden geduurd. Dit is aanzienlijk snel, en kon eigenlijk niet sneller gebeuren. 4. Vormt het te vervangen ERP-pakket een obstakel voor een (eventueel) nieuw in te voeren ERP-pakket? Zo ja, welke obstakels bent u tegengekomen? Er worden geen (grote) obstakels gezien. Op dit moment wordt er een nieuw ERP-pakket geïmplementeerd. Het huidige ERP-pakket is versplinterd geraakt: Naast Concorde vervult het intranet nu functies van een ERP-pakket, dat hier eigenlijk niet voor bedoelt is. Het gevaar zit hem in het feit dat niet alle functionaliteit wordt meegenomen in het nieuwe ERP-pakket. Om dit te voorkomen wordt er uitvoerig onderzoek uitgevoerd. 5. Zijn er door de leverancier functionaliteiten beloofd die achteraf niet waar te maken zijn? Er zijn altijd functionaliteiten die in het ERP-pakket achteraf niet mogelijk zijn. Dit is bijvoorbeeld te wijten aan een specifieke configuratie van het ERP-pakket, waardoor andere functionaliteiten niet of moeilijk te implementeren zijn.

110

6. Welke obstakels bent u tegengekomen tijdens het implementeren van het ERP-pakket? - Organisatieproblemen nee - veranderende markt nee - (te) duur onderhoud nee - te weinig functionaliteit nee - Onduidelijkheden over de werking Onduidelijkheden over de werking van een nieuw ERP-pakket horen bij het nieuwe gebruik van software. Dit speelde ook bij de implementatie van het ERP-pakket bij Paradigit. - Er ontstonden problemen doordat de werking van het oude ERP-pakket niet duidelijk was Nee, het oude pakket zorgde niet voor problemen Verantwoordelijkheden en budget De volgende drie vragen hebben betrekking op de verantwoordelijkheden en het budget van de ERPomgeving. Een sterk gespreide verantwoordelijkheid kan duiden op onduidelijkheden en versplintering. Een zeer hoog budget of een structurele overschrijding hiervan kan duiden op een complexe omgeving. 6. Wie is verantwoordelijk voor de werking van het ERP-pakket? Wat wordt er gedaan om de werking te waarborgen? Welke rol speelt de leverancier hierin? De directie is verantwoordelijk voor de werking van het ERP-pakket. Om de werking te waarborgen wordt er gedelegeerd naar de afdeling systeembeheer/IT ondersteuning. De leverancier speelt een cruciale rol als het gaat om ondersteuning van het ERP-pakket, door informatie en updates te kunnen leveren. 7. Is er een verantwoordelijke voor het opstellen en beheren van documentatie van het ERPpakket? De aanvankelijke documentatie is door de leverancier opgesteld, in samenwerking met de consultant en systeembeheer. Bij het uitbreiden van het ERP-pakket is de organisatie afhankelijk van de documentatie die de consultant opstelt. Er wordt niet actief beleid gevoerd om de documentatie up to date te houden, en er is geen direct verantwoordelijke voor. 8. Welk budget is er beschikbaar voor het onderhoud van het ERP-pakket? Wordt dit vaak overschreden? 111

Er wordt gewerkt met service contracten, er is dus een vast bedrag per maand wat Paradigit kwijt is aan het onderhoud. In het geval van een uitbreiding, dan zullen deze kosten toenemen, omdat de prijs van het servicecontract hoger wordt. Er vindt geen overschrijding van het budget plaats, aangezien dit budget vast staat. Huidig ERP-pakket De volgende vragen hebben betrekking op de huidige ERP-omgeving. Deze vragen gaan in op de rol van de ERP-omgeving, de minpunten van de ERP-omgeving, de flexibiliteit en eventueel de mogelijke wens om te vervangen. 9. Hoe oud is de huidige ERP-omgeving? Zijn alle onderdelen ineens vervangen, of is er steeds een deel vervangen? De huidige ERP-omgeving is acht jaar oud. Het vervangen is in een keer gebeurd. Overigens zijn de functionaliteiten in deze acht jaar enorm uitgebreid. 10. Wat is de rol van het ERP-pakket in de organisatie? Hoe afhankelijk is de organisatie van het ERP-pakket? Het ERP-pakket wordt gebruikt voor de volgende functies: HRM en CRM functies worden niet gebruikt in het ERP-pakket, De andere (belangrijke) processen worden wel in het ERP-pakket gedaan. 11. Wat zijn de minpunten van het huidige ERP-pakket? Zijn deze op te lossen? Het huidige ERP-pakket ondersteunt geen grote uitbreidingen meer. Het wordt daarom langzaam “uitgefaseerd”. Er wordt op dit moment een implementatie uitgevoerd van een nieuw ERP-pakket, waardoor er slechts ingegrepen wordt bij in het ERP-pakket als er zich fouten voordoen. Het oude pakket is niet flexibel. Hierdoor is er bijvoorbeeld in het intranet functionaliteit toegevoegd die eigenlijk in het ERP-pakket zouden moeten zitten. Het gevolg is dat het traag werkt. 13. Is er al eens aan vervanging van het ERP-pakket gedacht? Wordt het soepel en eenvoudig vervangen van het ERP-pakket gewaarborgd mocht dit nodig zijn? Door nauw samen te werken met de betrokkenen van Paradigit worden wensen en eisen beter gehoord, en kan er tijdig ingegrepen worden indien er afgeweken wordt. Daarnaast wordt een soepele overgang gewaarborgd door een uitvoerig onderzoek naar de werking van het huidige pakket, zodat alle gewenste functionaliteit in kaart gebracht wordt. 14. Denkt u dat vervangen eenvoudig mogelijk is? Waar baseert u dit op? Door het uitgebreide onderzoek en de ondersteuning van de leverancier en consultants moet dit eenvoudig mogelijk zijn. 15. Hoe "flexibel" is het ERP-pakket ten aanzien van uitbreidingen, veranderingen, enzovoorts? Wat doet u om deze flexibiliteit te waarborgen? Voorbeelden flexibiliteit: - Uitbreidingen bewerkstelligen 112

- kunnen inspelen op veranderingen - Platform(on)afhankelijkheid - onvoorziene situaties in processen kunnen opvangen - capaciteit vergroten Het huidige ERP-pakket is “verzadigd” qua uitbreidingen, en kan zodoende niet meer uitgebreid worden. Dit is de reden dat het ERP-pakket vervangen wordt, omdat het huidige ERP-pakket niet meer voldoet. Ook qua capaciteit is het huidige ERP-pakket niet meer toereikend, en dat is eveneens een reden voor vervanging. Er wordt een visie van 5 jaar vertaald in een ERP-pakket, wat inhoudt dat een ERP-pakket nu eenmaal vervangen moet worden na enkele jaren. Bij de nieuwe implementatie wordt er gekozen voor een tweetal ERP-pakketconfiguraties voor twee verschillende bedrijfsonderdelen. Dit wordt gedaan om niet alles afhankelijk te laten zijn in 1 implementatie. Daarnaast passen een tweetal implementaties beter bij de organisatie. Deze twee implementaties worden overigens wel met elkaar gekoppeld, zodat er gegevens uitgewisseld kunnen worden. 16. Zijn er op dit moment dingen niet mogelijk met het ERP-pakket, door onvoorziene situaties of bekende problemen in het ERP-pakket? Ook hier geldt weer dat er niet uitgebreid kan worden. Zodra er problemen zijn die de huidige werking beïnvloeden, worden deze problemen opgelost. Er wordt echter niets meer geïnvesteerd in het vernieuwen van het pakket, aangezien het vervangende ERP-pakket er aan komt. Door wetgeving is het soms noodzakelijk om een andere situatie in te voeren, en dat kan op dit moment niet meer. 17. Zijn er zaken die belemmerd worden door het gebruik van het ERP-pakket, zoals bijvoorbeeld het niet kunnen uitvoeren van een uitzonderlijke situatie, of een situatie die anders is dan dat hij in de procedures is vastgelegd? Kunt u hier een voorbeeld van noemen? Dat is op dit moment niet aan de orde. 18. In hoeverre gebruikt u andere software-ondersteuningspakketten anders dan het ERP-pakket? Voor welke afdelingen gebeurt dit? Werkt deze software samen met het ERP-pakket? Waarom (niet)? Op dit moment bestaan er vele losse applicaties naast het ERP-pakket, omdat het ERP-pakket deze functies niet kon vervullen. Een voorbeeld hiervan is het intranet of TAP, het reparatiesysteem. Deze zijn gekoppeld met het ERP-pakket, maar dit is veelal niet real-time. Toekomst Tot slot wordt er in de laatste vragen ingegaan op "de toekomst" van de ERP-omgeving. Wanneer zou er overgestapt worden naar een nieuwe ERP-omgeving? Wat zou er dan anders moeten? Deze vragen bieden inzicht in de vervangingswens van de ERP-omgeving. 19. Wat zou voor u in de toekomst de overweging zijn om een ander ERP-pakket aan te schaffen? (Bijvoorbeeld: de leverancier die geen ondersteuning meer biedt, de functionaliteit te beperkt is, enz.) 113

Zodra het ERP-pakket werkbelemmering oplevert doordat het geen functionaliteit meer kan bieden om de bedrijfsvoering op de juiste wijze te kunnen nastreven, is het tijd voor een nieuw ERP-pakket. 20. Kunt u op dit moment problemen noemen die bij een toekomstige ERP-pakketimplementatie een rol kunnen gaan spelen, zoals hoge kosten of lange implementatietrajecten? Zijn deze problemen voortijdig te verhelpen? Waardoor doen deze problemen zich voor? Mogelijke problemen zijn de twee verschillende businessmodellen die gebruikt worden. Om dit op te lossen worden een tweetal implementaties uitgevoerd, beiden met hetzelfde ERP-pakket maar met verschillende parameters. Het risico is dat niet alle functionaliteit die nu door het oude ERP-pakket geboden wordt niet meegenomen wordt in het nieuwe ERP-pakket. 21. Wat zou u doen om het ERP-pakket flexibel te houden zodat het langer mee kan gaan? Hoe zit het met de kosten om dit te bewerkstelligen? Denk aan: - Extra functionaliteiten - Extra gebruikers - extra capaciteit Er wordt allereerst voor standaarden gekozen. Daarnaast is Microsoft als leverancier gekozen. Het databaseformaat is van een standaardstructuur (SQL). Er wordt gekozen om modulair te werken, zodat functionaliteiten toe te voegen zijn. Het pakket is schaalbaar, zodat er rekening wordt gehouden met extra gebruikers en extra capaciteit.

Hartelijk dank voor uw medewerking!

114

Bijlage C: Antwoorden Blackbox Keuze en implementatie De eerste zes vragen hebben betrekking op de keuze en implementatie van de huidige ERP-omgeving. Hierbij wordt achterhaald waarom de huidige ERP-omgeving is gekozen en waar het eventueel mis is gegaan tijdens de implementatie van deze ERP-omgeving. 1. Om welke redenen is het huidige ERP-pakket/ERP-omgeving gekozen? Waarom is het voorgaande ERP-pakket vervangen, of zouden jullie deze willen vervangen? Het ERP-pakket wat op dit moment gebruikt wordt is gekozen omdat het goed aansloot bij de gebruikte processen binnen Blackbox. De prijs was gunstig, en Exact bood alle functionaliteit die wij op dat moment wensten. Het voorgaande ERP-pakket was een verouderde versie van Exact. Het werd niet meer ondersteund door de leverancier, en daarom is er een upgrade uitgevoerd. 2. Wat waren de alternatieven, en wat waren de minpunten van deze alternatieve ERPpakketten? De alternatieven waren allen duurder. De prijs voor een upgrade was goedkoper, omdat de leverancier korting aanbood. Daarnaast was de migratie eenvoudig, omdat er al een versie van Exact gebruikt werd. 3. Wat is de (geschatte) implementatieduur geweest van het ERP-pakket? Zou dit sneller gekund hebben? Wat zou hiervoor nodig zijn? Dit duurde ongeveer twee maanden. Sneller had alleen mogelijk geweest indien er meer mankracht beschikbaar was geweest om de implementatie sneller te laten verlopen. 4. Vormt het te vervangen ERP-pakket een obstakel voor een (eventueel) nieuw in te voeren ERP-pakket? Zo ja, welke obstakels bent u tegengekomen? De gebruikte Exact versie, Exact Globe 3.3, wordt niet meer ondersteund door de leverancier. Dit maakt het lastiger om ondersteuning te krijgen indien er zich problemen voor doen. Daarnaast gebruikt Exact 3.3 een eigen, gesloten databasestructuur. Om de data hier uit te krijgen moeten er speciale programma’s gebruikt worden. 5. Zijn er door de leverancier functionaliteiten beloofd die achteraf niet waar te maken zijn? Dat niet zozeer, alles wat door de leverancier toegezegd is, is ook toegevoegd en werkt. Nieuwe functionaliteiten, zoals het verzenden van mailings, worden niet door het pakket ondersteund. De leverancier heeft dit ook nooit toegezegd.

115

6. Welke obstakels bent u tegengekomen tijdens het implementeren van het ERP-pakket? - Organisatieproblemen nee - veranderende markt nee - (te) duur onderhoud Ja - te weinig functionaliteit nee - Onduidelijkheden over de werking - Er ontstonden problemen doordat de werking van het oude ERP-pakket niet duidelijk was De reden voor het vervangen was omdat de leverancier geen updates meer kon bieden. Het onderhoud van het oude ERP-pakket zou daardoor erg duur worden, aangezien updates en ondersteuning moeilijk verkrijgbaar is. Verantwoordelijkheden en budget De volgende drie vragen hebben betrekking op de verantwoordelijkheden en het budget van de ERPomgeving. Een sterk gespreide verantwoordelijkheid kan duiden op onduidelijkheden en versplintering. Een zeer hoog budget of een structurele overschrijding hiervan kan duiden op een complexe omgeving. 6. Wie is verantwoordelijk voor de werking van het ERP-pakket? Wat wordt er gedaan om de werking te waarborgen? Welke rol speelt de leverancier hierin? Er zijn servicecontracten opgesteld over de (gegarandeerde) werking van het pakket. Eens per maand komt de leverancier langs voor updates en onderhoud. 7. Is er een verantwoordelijke voor het opstellen en beheren van documentatie van het ERPpakket? Dit is voor het ERP-pakket de leverancier. De uitbreidingen die gedaan zijn, zijn zo goed mogelijk gedocumenteerd. 8. Welk budget is er beschikbaar voor het onderhoud van het ERP-pakket? Wordt dit vaak overschreden? Er wordt gewerkt met service contracten, dus er is geen overscheiding. Huidig ERP-pakket

116

De volgende vragen hebben betrekking op de huidige ERP-omgeving. Deze vragen gaan in op de rol van de ERP-omgeving, de minpunten van de ERP-omgeving, de flexibiliteit en eventueel de mogelijke wens om te vervangen. 9. Hoe oud is de huidige ERP-omgeving? Zijn alle onderdelen ineens vervangen, of is er steeds een deel vervangen? Exact 3.3 is inmiddels zo’n 10 jaar oud. Het oude ERP-pakket is ineens vervangen door Exact 3.3. 10. Wat is de rol van het ERP-pakket in de organisatie? Hoe afhankelijk is de organisatie van het ERP-pakket? Het ERP-pakket wordt gebruikt voor de volgende functies: HRM wordt niet uitgevoerd in Exact. CRM zit in het pakket, maar het verzenden van mailings wordt in combinatie met het programma MailMerge gedaan. 11. Wat zijn de minpunten van het huidige ERP-pakket? Zijn deze op te lossen? Het pakket is oud. De databasestructuur is niet toegankelijk en functionaliteiten zijn niet meer bij te kopen, omdat de leverancier dit niet ondersteund. Een nieuw pakket zou uitkomst bieden, maar dit gaat gepaard met hoge kosten. 13. Is er al eens aan vervanging van het ERP-pakket gedacht? Wordt het soepel en eenvoudig vervangen van het ERP-pakket gewaarborgd mocht dit nodig zijn? Jazeker, maar door de hoge kosten is dit niet gedaan. Er is gekeken hoe bijvoorbeeld dat data overgezet kan worden. Dit is mogelijk, maar eveneens weer tegen hoge kosten. 14. Denkt u dat vervangen eenvoudig mogelijk is? Waar baseert u dit op? Nee, er zal zeer veel geld, werk en tijd nodig zijn om het pakket te vervangen, omdat het niet meer ondersteund wordt door de leverancier. 15. Hoe "flexibel" is het ERP-pakket ten aanzien van uitbreidingen, veranderingen, enzovoorts? Wat doet u om deze flexibiliteit te waarborgen? Voorbeelden flexibiliteit: - Uitbreidingen bewerkstelligen - kunnen inspelen op veranderingen - Platform(on)afhankelijkheid - onvoorziene situaties in processen kunnen opvangen - capaciteit vergroten Het huidige ERP-pakket werkt in een DOS omgeving. Met diverse converters en koppelingen zijn er wat extra mogelijkheden gecreëerd, zoals Mailmerge en het spaarprogramma via de website. DOS kent een geheugenlimiet, waardoor de capaciteit niet eindig is van Exact. Er zijn op dit moment geen noemenswaardige problemen, maar uitbreidingen zijn niet mogelijk. 117

16. Zijn er op dit moment dingen niet mogelijk met het ERP-pakket, door onvoorziene situaties of bekende problemen in het ERP-pakket? Een voorbeeld hiervan is het willen afhalen van producten zonder dat de klant via de website besteld heeft. Alhoewel de producten vaak op voorraad zijn, moet er bij de receptie eerst een weborder gemaakt worden. Contant afrekenen is een ander voorbeeld: dit is niet mogelijk, het ERP-pakket werkt alleen met debiteuren. 17. Zijn er zaken die belemmerd worden door het gebruik van het ERP-pakket, zoals bijvoorbeeld het niet kunnen uitvoeren van een uitzonderlijke situatie, of een situatie die anders is dan dat hij in de procedures is vastgelegd? Kunt u hier een voorbeeld van noemen? Zie de vorige vraag, er kunnen altijd “workarounds” worden uitgevoerd om dit op te lossen. 18. In hoeverre gebruikt u andere software-ondersteuningspakketten anders dan het ERP-pakket? Voor welke afdelingen gebeurt dit? Werkt deze software samen met het ERP-pakket? Waarom (niet)? De website maakt onderdeel uit van het bestelproces, al is deze via een omweg gekoppeld. Daarnaast is het zogenoemde Mailmerge een voorbeeld. Het genereren van rapporten gebeurt door middel van Excel sheets. Deze sheets maken een koppeling met de database. Helaas kan dit niet realtime. Blackbox Data services gebruikt een eigen ERP-pakket (eveneens Exact), omdat dit een organisatie is die diensten levert, terwijl Blackbox Networks Services producten levert. Toekomst Tot slot wordt er in de laatste vragen ingegaan op "de toekomst" van de ERP-omgeving. Wanneer zou er overgestapt worden naar een nieuwe ERP-omgeving? Wat zou er dan anders moeten? Deze vragen bieden inzicht in de vervangingswens van de ERP-omgeving. 19. Wat zou voor u in de toekomst de overweging zijn om een ander ERP-pakket aan te schaffen? (Bijvoorbeeld: de leverancier die geen ondersteuning meer biedt, de functionaliteit te beperkt is, enz.) Indien het pakket de organisatie echt niet meer kan ondersteunen, is het tijd voor een vernieuwing. Het ERP-pakket moet immers ondersteunen, en geen last worden voor de organisatie. 20. Kunt u op dit moment problemen noemen die bij een toekomstige ERP-pakketimplementatie een rol kunnen gaan spelen, zoals hoge kosten of lange implementatietrajecten? Zijn deze problemen voortijdig te verhelpen? Waardoor doen deze problemen zich voor? Dit is eigenlijk al in voorgaande vragen aan het licht gekomen. De hoge kosten voor vervanging en de gesloten databasestructuur vormen problemen. 21. Wat zou u doen om het ERP-pakket flexibel te houden zodat het langer mee kan gaan? Hoe zit het met de kosten om dit te bewerkstelligen? Denk aan: 118

- Extra functionaliteiten - Extra gebruikers - extra capaciteit Een open databasestructuur is zeer van belang. Daarnaast moet het pakket met eenvoudig uit te breiden modules werken, zodat uitbreiden van extra functionaliteit makkelijk mogelijk is.

Hartelijk dank voor uw medewerking!

119

Bijlage D: Antwoorden Schuitema Keuze en implementatie De eerste zes vragen hebben betrekking op de keuze en implementatie van de huidige ERP-omgeving. Hierbij wordt achterhaald waarom de huidige ERP-omgeving is gekozen en waar het eventueel mis is gegaan tijdens de implementatie van deze ERP-omgeving. 1. Om welke redenen is het huidige ERP-pakket/ERP-omgeving gekozen? Waarom is het voorgaande ERP-pakket vervangen, of zouden jullie deze willen vervangen? Het vorige ERP-pakket was een zelfontwikkeld pakket. Er was dus sprake van echt maatwerk. Dit maatwerk is door de grote diversiteit vervangen door één ERP-pakket. Dit nieuwe ERP-pakket is een standaardpakket geworden, zodat er niet ellenlange maatwerkconfiguraties noodzakelijk zijn. 2. Wat waren de alternatieven, en wat waren de minpunten van deze alternatieve ERPpakketten? De reden voor het kiezen van dit specifieke pakket was omdat dit pakket het best aansluit bij de wensen en eisen van Schuitema. Een belangrijke factor hierbij was de prijs. 3. Wat is de (geschatte) implementatieduur geweest van het ERP-pakket? Zou dit sneller gekund hebben? Wat zou hiervoor nodig zijn? De implementatieduur van het ERP-pakket bedroeg ongeveer 5 jaar. Dit komt omdat het pakket per module is ingevoerd, en niet ineens. Sneller zou niet mogelijk zijn geweest, aangezien er dan eerder fouten in de werking zouden ontstaan. 4. Vormt het te vervangen ERP-pakket een obstakel voor een (eventueel) nieuw in te voeren ERP-pakket? Zo ja, welke obstakels bent u tegengekomen? Het huidige ERP-pakket bestaat uit diverse programma’s en kent daardoor vele afhankelijkheden. Indien het ERP-pakket vervangen moet worden, is het obstakel de “onduidelijkheid”: Er zal uitvoerig onderzoek plaats moeten vinden op de werking van het pakket. Dit kost veel tijd en is in die zin een obstakel. 5. Zijn er door de leverancier functionaliteiten beloofd die achteraf niet waar te maken zijn? De leverancier spiegelt dingen vaak mooier voor dan dat ze in werkelijkheid zijn. Het artikelbeheer zou standaard moeten zijn, maar is niet als een standaard toegankelijk. Daarnaast zaten er enkele bugs in het ERP-pakket, waar de leverancier niet over gesproken heeft.

120

6. Welke obstakels bent u tegengekomen tijdens het implementeren van het ERP-pakket? - Organisatieproblemen Ja, dit is te wijten aan de veranderde manier van werken. - veranderende markt Ja, nieuwe technologie is snel beschikbaar. Het implementatietraject van 5 jaar heeft er zeker toe geleid dat het ERP-pakket niet de laatste techniek bevatte. - (te) duur onderhoud Ja - te weinig functionaliteit nee - Onduidelijkheden over de werking Ja - Er ontstonden problemen doordat de werking van het oude ERP-pakket niet duidelijk was Ja Daarnaast is een obstakel ook zeker de hoeveelheid personeel dat beschikbaar was voor de implementatie. Verantwoordelijkheden en budget De volgende drie vragen hebben betrekking op de verantwoordelijkheden en het budget van de ERPomgeving. Een sterk gespreide verantwoordelijkheid kan duiden op onduidelijkheden en versplintering. Een zeer hoog budget of een structurele overschrijding hiervan kan duiden op een complexe omgeving. 7. Wie is verantwoordelijk voor de werking van het ERP-pakket? Wat wordt er gedaan om de werking te waarborgen? Welke rol speelt de leverancier hierin? Het hoofd IT is verantwoordelijk voor de werking. Om de werking te waarborgen is het systeem dubbel uitgevoerd. De leverancier biedt kennis over het geleverde ERP-pakket, maar is niet verantwoordelijk. 8. Is er een verantwoordelijke voor het opstellen en beheren van documentatie van het ERPpakket? Er is niet zozeer één verantwoordelijke. De beheerder van een applicatie is verantwoordelijk voor die applicatie, en dus ook voor de documentatie. Het ontwikkelen van software wordt gedaan met een tool wat automatisch de juiste documentatie genereerd.

121

9. Welk budget is er beschikbaar voor het onderhoud van het ERP-pakket? Wordt dit vaak overschreden? Op dit moment wordt er alleen “problem solving” gedaan, omdat er gekeken wordt naar een ander ERP-pakket. Dit komt omdat de leverancier stopt met de ondersteuning. Huidig ERP-pakket De volgende vragen hebben betrekking op de huidige ERP-omgeving. Deze vragen gaan in op de rol van de ERP-omgeving, de minpunten van de ERP-omgeving, de flexibiliteit en eventueel de mogelijke wens om te vervangen. 10. Hoe oud is de huidige ERP-omgeving? Zijn alle onderdelen ineens vervangen, of is er steeds een deel vervangen? Het ERP-pakket is inmiddels zo’n 10 jaar oud. De onderdelen zijn stapsgewijs (per module) vervangen. 11. Wat is de rol van het ERP-pakket in de organisatie? Hoe afhankelijk is de organisatie van het ERP-pakket? Het ERP-pakket wordt gebruikt voor de volgende functies: Er vindt geen CRM activiteit plaats, omdat de klanten niet snel fluctueren. Productieplanning, productie, service en HRM worden via een andere automatiseringsoplossing gedaan. 11. Wat zijn de minpunten van het huidige ERP-pakket? Zijn deze op te lossen? Er is geen continuïteit omdat de leverancier stopt met het ondersteunen. 13. Is er al eens aan vervanging van het ERP-pakket gedacht? Wordt het soepel en eenvoudig vervangen van het ERP-pakket gewaarborgd mocht dit nodig zijn? Ja, een nieuw implementatietraject zou naar schatting 3 jaar duren. 14. Denkt u dat vervangen eenvoudig mogelijk is? Waar baseert u dit op? Nee, er is nu eenmaal tijd nodig om te testen en om risicoanalyses te maken. 15. Hoe "flexibel" is het ERP-pakket ten aanzien van uitbreidingen, veranderingen, enzovoorts? Wat doet u om deze flexibiliteit te waarborgen? Voorbeelden flexibiliteit: - Uitbreidingen bewerkstelligen Dit is mogelijk, maar niet wenselijk omdat er een ander ERP-pakket ingevoerd gaat worden. - kunnen inspelen op veranderingen Dit is mogelijk, maar niet wenselijk omdat er een ander ERP-pakket ingevoerd gaat worden. Indien het gaat om een noodzakelijke verandering waar de bedrijfvoering mee gemoeid is, dan zal er wel veranderd moeten worden. 122

- Platform(on)afhankelijkheid Het systeem is te migreren naar andere platformen, maar hier zullen onvolkomenheden bij voorkomen. Daarom is er bewust gekozen voor AIX, omdat de kennis hiervan in huis is en de licenties eveneens aanwezig zijn. - onvoorziene situaties in processen kunnen opvangen Ja, maar er wordt een afweging gemaakt van de baten en lasten hiervan. - capaciteit vergroten Softwarematig is dit mogelijk, hardwarematig moet hiernaar gekeken worden. 16. Zijn er op dit moment dingen niet mogelijk met het ERP-pakket, door onvoorziene situaties of bekende problemen in het ERP-pakket? Deze onvoorziene situaties zijn in het systeem vast te leggen en op te lossen door nieuwe functionaliteit te ontwikkelen. De vraag is in hoeverre dit wenselijk is, en wat dit oplevert. Er wordt een kosten /baten analyse gemaakt om de kosten en lasten tegen elkaar weg te strepen,zodat er eenvoudig achterhaalt kan worden of het ontwikkelen de moeite waard is. 17. Zijn er zaken die belemmerd worden door het gebruik van het ERP-pakket, zoals bijvoorbeeld het niet kunnen uitvoeren van een uitzonderlijke situatie, of een situatie die anders is dan dat hij in de procedures is vastgelegd? Kunt u hier een voorbeeld van noemen? Zie de vorige vraag 18. In hoeverre gebruikt u andere software-ondersteuningspakketten anders dan het ERP-pakket? Voor welke afdelingen gebeurt dit? Werkt deze software samen met het ERP-pakket? Waarom (niet)? Naast Het ERP-pakket (Lawson) worden er diverse andere applicaties gebruikt. Voorbeelden zijn Locus (ondersteuning voor het warehouse), Perman (voor het bijhouden van uren) en een klachtensysteem. Deze zijn met het ERP-pakket verbonden en kunnen dus data uitwisselen. Toekomst Tot slot wordt er in de laatste vragen ingegaan op "de toekomst" van de ERP-omgeving. Wanneer zou er overgestapt worden naar een nieuwe ERP-omgeving? Wat zou er dan anders moeten? Deze vragen bieden inzicht in de vervangingswens van de ERP-omgeving. 19. Wat zou voor u in de toekomst de overweging zijn om een ander ERP-pakket aan te schaffen? (Bijvoorbeeld: de leverancier die geen ondersteuning meer biedt, de functionaliteit te beperkt is, enz.) Indien de leverancier geen ondersteuning meer biedt, is het noodzakelijk om over te stappen naar een ander ERP-pakket. 123

20. Kunt u op dit moment problemen noemen die bij een toekomstige ERP-pakketimplementatie een rol kunnen gaan spelen, zoals hoge kosten of lange implementatietrajecten? Zijn deze problemen voortijdig te verhelpen? Waardoor doen deze problemen zich voor? Zowel de hoge kosten als een lang implementatietraject zijn bekende problemen bij een implementatie. Er dient altijd een uitvoerige risicoanalyse gemaakt te worden, waarbij de kwaliteit bewaakt wordt. De problemen zijn niet te verhelpen, ze gaan nu eenmaal gepaard met het vervangen van het ERP-pakket. 21. Wat zou u doen om het ERP-pakket flexibel te houden zodat het langer mee kan gaan? Hoe zit het met de kosten om dit te bewerkstelligen? Denk aan: - Extra functionaliteiten - Extra gebruikers - extra capaciteit Er dient voldoende kennis in huis te zijn om het ERP-pakket aan te passen waar nodig. Daarnaast is goede documentatie van belang. Beiden kunnen ook gecombineerd worden: Een applicatiebeheerder die het systeem door en door kent, is misschien nog wel waardevoller dan slechts een dik pak met documentatie.

Hartelijk dank voor uw medewerking!

124

Bijlage E: Antwoorden Kamer van Koophandel Nederland Keuze en implementatie De eerste zes vragen hebben betrekking op de keuze en implementatie van de huidige ERP-omgeving. Hierbij wordt achterhaald waarom de huidige ERP-omgeving is gekozen en waar het eventueel mis is gegaan tijdens de implementatie van deze ERP-omgeving. 1. Om welke redenen is het huidige ERP-pakket/ERP-omgeving gekozen? Waarom is het voorgaande ERP-pakket vervangen, of zouden jullie deze willen vervangen? Met het oog op uitbreidbaarheid en ter voorkoming van legacy is er gekozen voor de nieuwe configuratie. 2. Wat waren de alternatieven, en wat waren de minpunten van deze alternatieve ERPpakketten? Andere oplossingen leiden weer tot een vorm van legacy, terwijl dit juist voorkomen moet worden. 3. Wat is de (geschatte) implementatieduur geweest van het ERP-pakket? Zou dit sneller gekund hebben? Wat zou hiervoor nodig zijn? Het invoeren is een continu verbeterproces, waardoor er geen sprake is van een begin of eindtijd 4. Vormt het te vervangen ERP-pakket een obstakel voor een (eventueel) nieuw in te voeren ERP-pakket? Zo ja, welke obstakels bent u tegengekomen? De bedoeling van de huidige ERP oplossing is juist dat deze niet verouderd raakt omdat er SOA gebruikt wordt. De losse modulen moeten eenvoudig te vervangen zijn. 5. Zijn er door de leverancier functionaliteiten beloofd die achteraf niet waar te maken zijn? Dit is niet aan de orde.

125

6. Welke obstakels bent u tegengekomen tijdens het implementeren van het ERP-pakket? - Organisatieproblemen nee - veranderende markt Ja en nee, er wordt continu verbeterd om in te kunnen spelen op veranderingen - (te) duur onderhoud nee - te weinig functionaliteit Deze functionaliteit kan stapsgewijs worden uitgebreid door functionaliteit erbij te kopen. - Onduidelijkheden over de werking nee - Er ontstonden problemen doordat de werking van het oude ERP-pakket niet duidelijk was nee Verantwoordelijkheden en budget De volgende drie vragen hebben betrekking op de verantwoordelijkheden en het budget van de ERPomgeving. Een sterk gespreide verantwoordelijkheid kan duiden op onduidelijkheden en versplintering. Een zeer hoog budget of een structurele overschrijding hiervan kan duiden op een complexe omgeving. 6. Wie is verantwoordelijk voor de werking van het ERP-pakket? Wat wordt er gedaan om de werking te waarborgen? Welke rol speelt de leverancier hierin? De leverancier is de verantwoordelijke voor de software 7. Is er een verantwoordelijke voor het opstellen en beheren van documentatie van het ERPpakket? Dit is de leverancier van de software. Indien er een nieuwe functionaliteit geleverd wordt, wordt de documentatie erbij geleverd. Vaak is dit een online-documentatie. 8. Welk budget is er beschikbaar voor het onderhoud van het ERP-pakket? Wordt dit vaak overschreden? Het budget is hoger ten opzichte van de vorige softwareoplossing. Het budget wordt niet vaak overschreden. Huidig ERP-pakket

126

De volgende vragen hebben betrekking op de huidige ERP-omgeving. Deze vragen gaan in op de rol van de ERP-omgeving, de minpunten van de ERP-omgeving, de flexibiliteit en eventueel de mogelijke wens om te vervangen. 9. Hoe oud is de huidige ERP-omgeving? Zijn alle onderdelen ineens vervangen, of is er steeds een deel vervangen? Er is niet zozeer een begin en eindpunt, alle onderdelen zijn geleidelijk vervangen. 10. Wat is de rol van het ERP-pakket in de organisatie? Hoe afhankelijk is de organisatie van het ERP-pakket? Het ERP-pakket wordt gebruikt voor de volgende functies: - Administratie ja - Inkoop Ja (mutaties etc.) - Productieplanning nvt - Productie nvt - Voorraadbeheer Ja (kvk gegevens) - logistiek Gebeurt online - verkoop ja - service ja - HRM Ja, via peoplepodium, aparte software - CRM Ja. 11. Wat zijn de minpunten van het huidige ERP-pakket? Zijn deze op te lossen? 127

Het onderhoud van de service bus is duurder dan de vorige situatie, dit is het enige minpunt. 13. Is er al eens aan vervanging van het ERP-pakket gedacht? Wordt het soepel en eenvoudig vervangen van het ERP-pakket gewaarborgd mocht dit nodig zijn? De software wordt continu verbeterd en vervangen, net als de losse modulen. Aangezien er (bijna) geen afhankelijkheden zijn, kunnen modulen eenvoudig vervangen worden. 14. Denkt u dat vervangen eenvoudig mogelijk is? Waar baseert u dit op? Ja, omdat legacy vrijwel niet aanwezig is in het systeem. 15. Hoe "flexibel" is het ERP-pakket ten aanzien van uitbreidingen, veranderingen, enzovoorts? Wat doet u om deze flexibiliteit te waarborgen? Voorbeelden flexibiliteit: - Uitbreidingen bewerkstelligen Dit kan zeer eenvoudig gebeuren door extra functionaliteit aan te schaffen bij een softwareleverancier - kunnen inspelen op veranderingen Ja (al is de KVK gebonden aan de wet) - Platform(on)afhankelijkheid Ja, door het gebruik van Java - onvoorziene situaties in processen kunnen opvangen Ja (al moet alles volgens de wet gebeuren) - capaciteit vergroten Ja, door systemen uit te voeren met een licentiesysteem. Indien er extra capaciteit nodig is wordt dit dmv een licentie geactiveerd. Daarnaast werkt alles op virtuele machines, zodat server load verdeelt kan worden. 16. Zijn er op dit moment dingen niet mogelijk met het ERP-pakket, door onvoorziene situaties of bekende problemen in het ERP-pakket? Nee. 17. Zijn er zaken die belemmerd worden door het gebruik van het ERP-pakket, zoals bijvoorbeeld het niet kunnen uitvoeren van een uitzonderlijke situatie, of een situatie die anders is dan dat hij in de procedures is vastgelegd? Kunt u hier een voorbeeld van noemen? Nee.

128

18. In hoeverre gebruikt u andere software-ondersteuningspakketten anders dan het ERP-pakket? Voor welke afdelingen gebeurt dit? Werkt deze software samen met het ERP-pakket? Waarom (niet)? Alle losse modulen werken samen als geheel via de service bus. De meeste modules zijn van IBM afkomstig, maar ook van andere leveranciers. Toekomst Tot slot wordt er in de laatste vragen ingegaan op "de toekomst" van de ERP-omgeving. Wanneer zou er overgestapt worden naar een nieuwe ERP-omgeving? Wat zou er dan anders moeten? Deze vragen bieden inzicht in de vervangingswens van de ERP-omgeving. 19. Wat zou voor u in de toekomst de overweging zijn om een ander ERP-pakket aan te schaffen? (Bijvoorbeeld: de leverancier die geen ondersteuning meer biedt, de functionaliteit te beperkt is, enz.) Indien de software de werkzaamheden niet meer ondersteund en niet meer uitgebreid kan worden, is het gebruik van software als ondersteuning zinloos. 20. Kunt u op dit moment problemen noemen die bij een toekomstige ERP-pakketimplementatie een rol kunnen gaan spelen, zoals hoge kosten of lange implementatietrajecten? Zijn deze problemen voortijdig te verhelpen? Waardoor doen deze problemen zich voor? Nee, aangezien de modulen los te vervangen zijn. 21. Wat zou u doen om het ERP-pakket flexibel te houden zodat het langer mee kan gaan? Hoe zit het met de kosten om dit te bewerkstelligen? Denk aan: - Extra functionaliteiten - Extra gebruikers - extra capaciteit Er worden systemen aangeschaft die schaalbaar zijn dmv licenties, daarnaast vind er load-balancing plaats tussen de virtuele machines. Een bepaalde module kan een prioriteit toegewezen krijgen door middel van QoS. Modules kunnen eenvoudig uitgebreid worden door ze op de service bus “aan te sluiten”. Hartelijk dank voor uw medewerking!

129