Tag Archief van: ERP-implementatie

In veel bedrijven is het ERP-systeem het middelpunt waar alles om draait. “Never change a running system” is daarom op veel plaatsen het motto als het gaat om de gebruikte software – zelfs als die inmiddels verouderd of te klein is geworden. De processen en structuren in het bedrijf veranderen echter voortdurend. De dagelijkse gang van zaken is moeilijk te beheren zonder ondersteunende software. ERP-systemen worden daarom vaak al vele jaren gebruikt. Vooral oudgedienden zien er vaak tegenop om het te vervangen door een moderne oplossing. Een verouderd ERP-systeem brengt uw bedrijf echter vaak in een nadelige concurrentiepositie. Waarom? In de meeste gevallen kan de software niet meer goed aan de eisen voldoen. In dit artikel leert u welke waarschuwingssignalen duiden op verouderde ERP-software. En wanneer het voor u tijd is om na te denken over een ERP-verandering.

Redenen voor een ERP-verandering

Het begint allemaal met ontevredenheid. In het verleden was het bedienen en onderhouden van ERP-software tijdrovend. Veel bedrijven accepteren daarom liever de nadelen in plaats van de software te optimaliseren – of een nieuwe oplossing te introduceren. In de meeste gevallen denken bedrijven pas aan een ERP-verandering als ze niet meer tevreden zijn met de vorige oplossing. Maar hoe uit zich dit? Een bestaande, verouderde software is in de eerste plaats te herkennen aan een gebrek aan transparantie, functionaliteiten en flexibiliteit. De software kan slechts in beperkte mate worden aangepast en eenvoudige uitbreidingen zijn vaak niet mogelijk. Als gevolg hiervan worden er steeds meer aparte oplossingen gebruikt: Dit verhoogt de onderhoudsinspanning en ook de kosten voor service en onderhoud enorm.

Regelmatig gebruik van Excel: ERP-verandering heeft zin?

Het duidelijkste teken dat u een verouderd ERP-systeem gebruikt, is waarschijnlijk het regelmatige gebruik van Excel. Exporteert u bijvoorbeeld gegevens uit het ene systeem en importeert u deze in een ander systeem op basis van tabellen? Worden belangrijke analyses uit verschillende systemen herhaaldelijk samengevoegd in tabellen omdat er geen gestandaardiseerde database is? Excel is een van de meest gebruikte IT-tools omdat het makkelijk te leren en eenvoudig te gebruiken is. Excel heeft de neiging contraproductief te zijn als het gaat om het best mogelijke beheer van dagelijkse bedrijfstaken en de nadelen wegen zwaarder dan de voordelen – dus overstappen op ERP zou zeker een idee zijn.

anzeichen-fuer-erp-wechsel

De uitdagingen: Excel is geen database, wat veel beperkingen met zich meebrengt. De bestanden worden meestal op lokale computers opgeslagen. Als de werknemer met de laatste gegevensstatus niet op kantoor is, is het niet mogelijk om te garanderen dat de gegevens up-to-date zijn. Dit betekent dat gegevens vaak twee keer worden ingevoerd. Latere wijzigingen moeten dan in alle tabellen worden doorgevoerd. Het programma is ook gevoelig voor fouten en toegangsrechten zijn moeilijk te beheren. Het gebruik van Excel brengt geen extra kosten met zich mee, maar het kost wel tijd en personeel die effectiever gebruikt zouden kunnen worden. Overweeg daarom of een ERP-verandering zinvol is!

Old ERP-systeem? Snelheidsproblemen zijn aan de orde van de dag

ERP-update voor meer efficiëntie – ja of nee? Een verouderd ERP-systeem is ook te herkennen aan snelheidsproblemen. Deze worden vaak pas duidelijk met uitgebreide rapporten en analyses. Maar het dagelijkse werk wordt ook snel gekenmerkt door wachttijden. Zelfs als dit maar korte onderbrekingen zijn: De tijd waarin een werknemer niet kan worden ingezet om waarde toe te voegen, loopt op. Dit is een kostenfactor die snel relevant wordt, vooral als er meerdere gebruikers zijn. Een traag ERP-systeem is ook een negatieve factor voor de motivatie van werknemers. Op de lange termijn heeft een ERP-verandering ook een positief effect op de productiviteit van werknemers.

Beperkte mobiele toegang – wilt u een ERP-update?

De cultuur binnen veel bedrijven is de afgelopen jaren aanzienlijk veranderd. Thuiswerken en slimmer werken zijn slechts twee voorbeelden. Hebben uw werknemers geen of slechts beperkte mobiele toegang? En moeten ze eerst via een virtual private network (VPN) verbinding maken met de bedrijfsserver? Dan gebruikt u waarschijnlijk nog een oud ERP-systeem. Verbinding maken via VPN is niet meer van deze tijd, vooral als de interface niet geoptimaliseerd is voor mobiele apparaten. Uw werknemers moeten thuis of onderweg kunnen werken, zodat ze flexibel zijn. De standaardvereiste voor moderne ERP-oplossingen: mobiele toegang tot relevante gegevens – op elk moment en vanaf elke locatie. Dit is vooral belangrijk voor uw klantenservice-, verkoop- en managementteams. Een ERP-verandering is hier dus een groot voordeel.

De oude ERP-oplossing optimaliseren of een nieuw systeem invoeren

Uiteindelijk ligt de beslissing voor of tegen een nieuw ERP-systeem bij de ondernemer. Weet u niet zeker of u een nieuw systeem nodig hebt? Of zal het optimaliseren en aanpassen van de oude software voorlopig volstaan? Controleer eerst of uw ERP-software up-to-date is. Updates bevatten vaak functionele verbeteringen en beveiligingsupdates. Bovendien kunnen sommige problemen worden opgelost door de hardware te upgraden of de database op te schonen en te moderniseren – zodat de software weer sneller draait. Deze aanpak werkt echter niet meer als individuele functionaliteiten niet meer door het ERP-systeem in kaart kunnen worden gebracht. Als gevolg daarvan bereiken bedrijven uiteindelijk het punt waarop het alleen nog maar zin heeft om een moderne oplossing te introduceren. Wanneer is een ERP-verandering de moeite waard? Vooral wanneer de bedrijfsprocessen niet meer door het ERP-systeem in kaart kunnen worden gebracht – en Office-tools zoals Excel steeds vaker worden gebruikt.

Door een complete oplossing te implementeren die aan uw behoeften is aangepast, kunt u geïsoleerde oplossingen tot het verleden laten behoren. Overweegt u ook een ERP-verandering? Wilt u meer weten over de volledige reeks functies van TimeLine ERP? Stuur ons een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Is uw ERP-implementatie mislukt? Hoe het de volgende keer te voorkomen

Als een ERP-implementatie is mislukt, blijft er aan beide kanten frustratie bestaan – niet alleen bij u, maar ook bij de leverancier. Met de juiste expertise kunt u risico’s tijdens een ERP-implementatie herkennen en tot een minimum beperken. Dit bespaart u tijd, zenuwen en kosten. Hier presenteren we 5 veelvoorkomende redenen waarom een ERP-implementatie problemen kan veroorzaken – en geven we u 5 tips die u kunt gebruiken om de risico’s tijdens een ERP-implementatie tot een minimum te beperken.

Wat zijn de oorzaken van een mislukte ERP-implementatie?

De invoering van ERP-software is zowel een kans als een risico voor een bedrijf. In het ideale geval wordt het project zonder grote problemen afgerond en merkt u al snel verbeterde processen. Om een project van deze omvang te realiseren, moeten ERP-aanbieders en bedrijven hand in hand werken. Toch zijn er enkele valkuilen die het project kunnen vertragen of terugdraaien.

Het komt zelden voor dat een ERP-implementatie in de MKB-sector mislukt – maar het gebeurt wel. Beide partijen kunnen verantwoordelijk zijn voor het mislukken van een project, vaak om dezelfde redenen. Om goed voorbereid te zijn op alle situaties, moet u zich bewust zijn van mogelijke risico’s tijdens de ERP-implementatie en deze tijdig uitsluiten. Hieronder zetten we de belangrijkste risicofactoren voor problemen tijdens de ERP-implementatie op een rijtje – en leggen we uit wat u eraan kunt doen.

ERP implementatie: risico’s en probleemgebieden

Als een ERP-implementatie is mislukt, is daar niet slechts één reden voor. Er zijn vaak verschillende oorzaken die met elkaar samenhangen en elkaar beïnvloeden. Hieronder volgt een samenvatting van 5 punten die als ERP-projectrisico’s worden beschouwd.

1e risico: Ongeschikt projectteam

Eén van de belangrijkste risicofactoren voor een mislukte ERP-implementatie is een ongeschikt projectteam. Vergeet niet: veel werknemers zijn van nature sceptisch over een verandering die in eerste instantie hun dagelijkse werkroutine op zijn kop zet. Het is niet eenvoudig om deze situatie in goede banen te leiden. Een professioneel projectteam en duidelijke verantwoordelijkheden zijn daarom het allerbelangrijkste bij de invoering van ERP. U moet terughoudendheid onder het personeel serieus nemen – uw werknemers zijn tenslotte degenen die in de toekomst met de nieuwe software zullen werken en zijn daarom ook in belangrijke mate betrokken bij het succes of falen van het project.

Om de risico’s van een ERP-implementatie te beperken, moet de nieuwe software door het personeel worden geaccepteerd. Als een ERP-implementatie mislukt, komt dat vaak doordat het doel achter de verandering niet werd herkend. Het projectteam moet daarom regelmatig vergaderingen houden om verslag uit te brengen over de voortgang van het project en om de voordelen van de nieuwe software te benadrukken.

erp-selection

Het projectteam moet uitleggen welke doelen worden nagestreefd met de verandering en wat er precies zal veranderen. Maak duidelijk dat de software niet wordt gebruikt om banen te vervangen, maar om de dagelijkse routine voor iedereen gemakkelijker en efficiënter te maken. Alleen als iedereen samenwerkt, kan de implementatie succesvol zijn – en voorkomen dat de ERP-implementatie mislukt.

Het projectteam draagt veel verantwoordelijkheid en moet veel uitdagingen overwinnen. Bedenk dus van tevoren wie welke rol moet vervullen. Niet iedereen is geschikt voor elke functie. Een gebrek aan expertise of te weinig inlevingsvermogen in het team leidt altijd tot problemen tijdens de ERP-implementatie, waardoor de realisatie en dus een succesvolle afronding van het project wordt bemoeilijkt. Hoe u een goed ERP-projectteam samenstelt, welke kwaliteiten de deelnemers moeten hebben en waar u nog meer rekening mee moet houden, leest u hier: Hoe stel ik een goed ERP-projectteam samen?

2e risico: Te platte hiërarchieën

Vandaag de dag hebben veel bedrijven platte hiërarchieën en structuren. Dit is eigenlijk vooruitstrevend, omdat het alle werknemers in staat stelt om betrokken te raken en samen beslissingen te nemen. Iedereen kan en mag zijn zegje doen en harmonieuze samenwerking staat meestal hoog op de prioriteitenlijst. Dus hoewel platte hiërarchieën veel voordelen hebben, kunnen ze ook een oorzaak zijn van het mislukken van ERP-implementaties.

Het risico: Projectmanagement en leveranciers willen het project snel en gemakkelijk implementeren. Het streven naar consensus betekent echter vaak dat iedereen het iedereen naar de zin wil maken. Het is echter bijna onmogelijk om met alle wensen, ideeën en suggesties voor verbetering rekening te houden en dit leidt zelden tot een snelle projectafronding.

Het is belangrijk om het personeel in een vroeg stadium bij het planningsproces te betrekken en inspraak te geven. Maar het draait allemaal om evenwicht, want belangrijke beslissingen moeten snel worden genomen. Als er te veel mensen bij een project betrokken zijn, kan het snel ingewikkeld worden. Bovendien hebben veel werknemers de neiging om alleen naar hun eigen positie in het bedrijf te kijken. De ervaring leert dat wensen en ideeën vaak alleen betrekking hebben op hun eigen toepassingsgebied – een procesgerichte kijk en manier van werken ontbreekt.

U wilt verandering toestaan, maar bent niet bereid om oude gewoonten los te laten. Kortom, dit kan de rem zetten op veel relevante beslissingen. Om dit tegen te gaan, moet u duidelijke verantwoordelijkheden creëren en specifieke doelen formuleren. Het is ook nuttig om het inzicht van uw personeel in de behoeften en taken van andere afdelingen van het bedrijf te vergroten.

3e risico: geïsoleerde oplossingen binnen het bedrijf

Elk bedrijf heeft zijn eigen afdelingen met hun eigen taken en verantwoordelijkheden. Elke werknemer heeft ook zijn eigen begrip van zijn rol. Na verloop van tijd ontstaat er een bekend netwerk van hiërarchieën en verantwoordelijkheden. Afdelingen worden daarom vaak intern beheerd als “vorstendommen”. Als er van buitenaf nieuwe processen of taken op uw eigen afdeling worden geïntroduceerd, zijn conflicten onvermijdelijk.

Mensen vinden het moeilijk om oplossingen los te laten. Veel werknemers vinden het moeilijk om oude gewoonten los te laten, om verder te denken en te handelen dan hun eigen werk en afdelingsgrenzen – en dat is heel menselijk. Achter deze defensieve houding schuilt vaak de angst om vervangbaar te zijn.

Als een ERP-project is mislukt, komt dat vaak doordat er binnen het bedrijf niet is nagedacht. Werknemers die weerstand opbouwen of de vorige aanpak verdedigen uit bezorgdheid over een verlies aan expertise, kunnen problemen veroorzaken tijdens de ERP-implementatie. De sleutel is communicatie. Probeer de angst voor vervangbaarheid weg te nemen en communiceer de voordelen van het ERP-systeem transparant.

4e risico: ERP-systeem past niet bij het bedrijf

Als een ERP-implementatie mislukt, kan dit ook te wijten zijn aan ongeschikte software. Veel bedrijven onderschatten hoe belangrijk het is om het juiste ERP-systeem te kiezen. U moet daarom veel aandacht aan deze taak besteden. Er zijn nu zoveel ERP-systemen op de markt dat het niet eenvoudig is om de juiste voor een bedrijf te kiezen.

Wie de risico’s tijdens de ERP-implementatie wil beperken, schakelt daarom vaak een extern adviesbureau in. Het probleem hierbij is dat managementconsultants over het algemeen uitgaan van standaardprocessen. Zij zijn niet bekend met de individuele specialiteiten van uw bedrijf. Die leren ze pas kennen als de nieuwe software al gekozen is.

Als er wordt gekozen voor software die niet geschikt is voor het bedrijf, wordt dit meestal duidelijk wanneer de implementatiefase is begonnen. Het wordt dan duidelijk dat de gekozen software niet alle vereisten dekt of te groot is. Er worden verbeteringen en aanpassingen aangebracht – de voltooiing van het project wordt vertraagd. Als u externe consultants wilt inschakelen, moet u dit zeker vóór het selectieproces doen en niet wanneer de keuze al gemaakt is.

Een uitgebreide projectanalyse is daarentegen nuttig. Een ERP-systeem dat bedrijfsprocessen verkeerd in kaart brengt, inflexibel is en de dagelijkse gang van zaken niet goed afdekt, leidt vaak tot nieuwe geïsoleerde oplossingen. Het zijn juist deze waar u eigenlijk vanaf wilt door ERP-software te introduceren. In het ergste geval mislukt de ERP-implementatie en moet u een nieuwe leverancier kiezen – een situatie die u koste wat kost moet vermijden.

Een verkeerde softwareselectie is vaak te wijten aan een slechte ERP-selectie en onvoldoende voorbereiding van de ERP workshop. Een complete eisenspecificatie en een uitgebreide procesanalyse zijn zeer aan te bevelen! Als u een duidelijk beeld hebt van de doelprocessen, zal de keuze gemakkelijker voor u zijn.

Verricht het selectieproces zorgvuldig en betrek het personeel erbij. Overweeg van tevoren zo realistisch mogelijk de ERP systeemkosten. Ondoordachte beslissingen worden snel duur. Zorg er ook voor dat de nieuwe oplossing flexibel en aanpasbaar is. Zo kunt u de risico’s van een ERP-implementatie aanzienlijk beperken.

5e risico: Te krap berekend tijd- en kostenkader

Uw ERP-leverancier gaat ervan uit dat u duidelijke doelen nastreeft met de introductie van software. De nieuwe software betekent immers een verandering die enige middelen zal vergen. Veel ondernemers willen echter vooral tijd en geld besparen met een ERP-project. Gelukkig komt het, zoals hierboven beschreven, zelden voor dat de hele ERP-implementatie op een mislukking uitloopt.

Het overschrijden van het geplande tijd- en kostenkader voor het ERP-systeem is daarentegen een veelvoorkomend probleem. Het doet zich meestal voor als u de voorbereiding niet zorgvuldig hebt uitgevoerd of ongeduldig bent en te vroeg met de ERP-implementatie begint. Als er op het moment van de implementatie nog steeds essentiële vragen onbeantwoord zijn, loopt het project onnodig uit en blijven de kosten door ongeplande aanpassingen stijgen. Vaak wordt er ook veel te weinig tijd ingecalculeerd. Het is misschien niet zo dat de hele ERP-implementatie mislukt – maar de voltooiing van het project wordt herhaaldelijk uitgesteld.

5 tips voor uw ERP-implementatie: risico’s minimaliseren – kansen benutten

U kunt typische valkuilen vermijden om de risico’s voor uw ERP-implementatie te minimaliseren. Als u rekening houdt met de volgende tips, hebt u al goede voorwaarden gecreëerd voor een succesvol ERP-project:

    1. Goede voorbereiding: Als een ERP-implementatie mislukt, ligt de fout vaak bij een gebrek aan voorbereiding. Een project kan niet slagen als het bedrijf zijn rol niet speelt. Bepaal welke processen geoptimaliseerd moeten worden met de nieuwe ERP-software en welke specifieke doelen u met de invoering nastreeft.
    2. Verminder angsten: Maak uw ERP-project vanaf het begin transparant om de zorgen van werknemers weg te nemen. Niet alleen krijgen ze te maken met een nieuwe gebruikersinterface, ze moeten ook leren om over afdelingen heen te denken.
    3. Training aanbieden: Om de risico’s van ERP-implementatie te verminderen, moet u uw werknemers training aanbieden. Het personeel leert nieuwe werkstappen en functies van het ERP-systeem vanaf het begin op de juiste manier en het is voor iedereen duidelijk waarom ze op deze manier moeten worden uitgevoerd.
    4. Het ERP-systeem optimaliseren: Als alle projectvereisten zijn geïmplementeerd, wordt de ERP-implementatie als voltooid beschouwd. Veel bedrijven hebben dan de neiging om de software niet verder te optimaliseren. Functionaliteiten die eigenlijk beschikbaar zijn, worden niet gebruikt. Verzamel suggesties voor verbetering en implementeer deze in samenwerking met de ERP-leverancier.
    5. Blijf oplossingsgericht: Het is belangrijk om te begrijpen dat de software het minst verantwoordelijk is voor het mislukken van een ERP-project. Zoek niet naar iemand om de schuld te geven, maar zoek naar een oplossing – bij voorkeur samen met uw ERP-leverancier.

Als u meer wilt weten over risicofactoren voor ERP-projecten of over het volledige aanbod van TimeLine ERP-functies, stuur ons dan een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. Wij geven u graag advies!

De invoering van ERP-software vergt meestal veel middelen en de benodigde tijd is vaak enorm, wat niets nieuws is. Dit is echter niet verwonderlijk als u bedenkt hoe nauw het systeem verweven is met uw eigen processen. Als u het project van tevoren goed organiseert, wordt het werk voor alle betrokkenen gemakkelijker en voorkomt u dure aanpassingen achteraf. Dit houdt ook in dat u een procedure moet bepalen voor de integratie van de nieuwe software. Nog voordat het eigenlijke project begint, moeten de klant en de ERP-leverancier zich afvragen welke aanpak de implementatie het snelst en efficiëntst kan realiseren. Er zijn twee zeer contrasterende modellen die nog steeds erg populair zijn – de watervalmethode en de agile aanpak.

Volgens het motto “Oude bezems vegen schoon”, vertrouwen de meeste bedrijven op de klassieke en beproefde watervalmethode. Hoewel steeds meer klanten geïnteresseerd zijn in agile ontwikkelmethoden, hebben slechts enkelen het vertrouwen om het nieuwe ERP-systeem volgens dit concept te introduceren. Veel managers zijn nog steeds sceptisch en niet bereid om een deel van hun controle uit handen te geven. Dit kan een aantal vragen oproepen: Wat is precies het verschil tussen de twee benaderingen? Welke is beter geschikt voor de vereisten van mijn bedrijf? Dit artikel is bedoeld om u een overzicht te geven van de twee methoden en hun voor- en nadelen, zodat uw beslissing hopelijk iets gemakkelijker wordt.

De klassieke aanpak – de watervalmethode

Een ERP-implementatie verloopt meestal volgens de klassieke watervalmethode. Dit was lange tijd standaard, vooral in de softwaresector. De eerste formele beschrijving van dit model wordt toegeschreven aan Winston W. Royce. In zijn artikel uit 1970 “Managing the Development of large Software Systems” gebruikte hij de term “waterval” niet, maar maakte hij toen al duidelijk dat deze methode uitgebreid kon worden en niet voor elk project geschikt was. De watervalmethode wordt gekenmerkt door een strict lineair projectproces. Aan het begin wordt het verloop bepaald door het project in verschillende fasen op te delen. Deze worden dan consequent na elkaar doorlopen in een vooraf bepaalde volgorde. Zodra een fase is voltooid, bekijken de klant en de leverancier de resultaten en keuren deze vervolgens goed. Elke voltooide fase initieert een nieuwe fase en wordt als onveranderlijk beschouwd; latere wijzigingen worden over het algemeen niet overwogen. Beslissingen kunnen en mogen niet worden teruggedraaid.

Er zijn nu verschillende varianten, maar het basismodel bestaat uit de volgende zes stappen:

    • Behoeftenanalyse – Definitie van de beoogde functies
    • Concept – Ontwikkeling van de softwarearchitectuur
    • Implementatie – Ontwikkelen en integreren van de software
  • Integratietests – Fouten vinden en elimineren
  • Rollout – Inbedrijfstelling van het systeem
  • Support – Ervoor zorgen dat de klant geen problemen heeft met het product

In een specificatie worden de bedrijfsdoelstellingen en vereisten van de klant voor het ERP-systeem uiteengezet en hoe deze worden geïmplementeerd, wordt in de specificatie vastgelegd. De specifieke implementatie varieert van aanbieder tot aanbieder.

Sterke punten van de watervalmethode

De watervalmethode is nog steeds erg populair. Niet zonder reden, want het biedt duidelijke en georganiseerde structuren, wat voor sommige ondernemers erg belangrijk is. De invoering van ERP-software is vooral een grote verandering, planning en structuur bieden in deze tijd wat meer zekerheid en zijn daarom welkom. Uiterlijk aan het einde van de voorbereidingsfase zullen alle projectdeelnemers duidelijkheid hebben over de gedetailleerde stappen die tot de daadwerkelijke lancering leiden, het huidige stadium van de implementatie en wat er nog in het verschiet ligt. Het plannen en berekenen van het benodigde budget en de benodigde tijd, vooral voor zeer uitgebreide projecten, is natuurlijk zeer nauwkeurig.

Zwakke punten van de watervalmethode

De watervalmethode herbergt echter ook enkele niet te onderschatten risico’s, vooral voor lastige en verwarrende ERP-implementaties. Ironisch genoeg leidt de strikt lineaire aanpak vaak tot verlies van controle. De ontwerpinspanning die voor deze methode nodig is, is meestal erg hoog, omdat de afzonderlijke stappen tot in het kleinste detail gepland moeten worden. Aangezien de afzonderlijke fasen strikt van elkaar gescheiden zijn, bent u erg gebonden aan de vooraf gedefinieerde processen. Dit maakt deze methode erg star en inflexibel, waardoor parallel werken bijna onmogelijk is.

De grootste zwakte hier is dat defecten of misvattingen die aan het begin van de ontwerpfase ontstaan, pas aan het einde van de implementatie aan het licht komen, of nog ongunstiger – tijdens de functionele tests. Het is ook mogelijk dat een use case helemaal vergeten wordt tijdens de ontwerpfase. Het ERP-systeem houdt hier dan natuurlijk geen rekening mee. In beide situaties leidt dit tot ongepland en vooral kostenintensief extra werk. Aan de andere kant kan het ook gebeuren dat de leverancier door een gebrek aan communicatie onnodige functies implementeert, die uiteindelijk in de praktijk nooit gebruikt worden. Over het algemeen is de beperkte communicatie bij deze methode vaak een reden voor misverstanden, omdat de klant en de ERP-aanbieder verschillende interpretaties van het concept hebben. Het resultaat: de klant is ontevreden omdat het systeem niet aan zijn verwachtingen voldoet. Dit is natuurlijk een situatie die koste wat het kost voorkomen moet worden.

Agile ontwikkelingsmethoden

Agile benaderingen werden ontwikkeld als reactie op de zwakke punten van de watervalmethode. Een van de eerste varianten van deze methode was Scrum. Scrum is een procesmodel voor project- en productbeheer, met name voor agile softwaretechnologie. De oorsprong van deze aanpak gaat terug tot het artikel “The New New Product Development Game” in de Harvard Business Review in 1986. Takeuchi en Nonaka benadrukken onder andere het belang van zelfgeorganiseerde teams in het hele ontwikkelingsproces. Vandaag de dag wordt deze relatief nieuwe aanpak voornamelijk gebruikt bij softwareontwikkeling, maar ook op veel andere gebieden.

 width=

Volgens de methode worden taken niet volgens een lineair plan uitgevoerd, maar in korte implementatiecycli, de zogenaamde sprints. Aan het begin van elke sprint worden doelen gesteld. In de loop van elke cyclus implementeert het projectteam een werkpakket volledig, meestal een functionele vereiste. Dit wordt vervolgens getest, zodat er aan het einde van elke cyclus een uitvoerbaar, presenteerbaar subsysteem ontstaat. Dit geeft de klant de mogelijkheid om op elk moment feedback te geven. Idealiter duurt een cyclus tussen de twee en vier weken. Met elke volgende cyclus proberen het projectteam en de gebruiker de vereisten te verbeteren en geleidelijk dichter bij een optimale oplossing te komen. Deze aanpak laat veel ruimte voor interactie, aanpassingen en updates. Dit is vooral handig als de klant zijn eisen voor de software in de loop van de implementatie verandert of als er andere uitdagingen ontstaan.

De agile aanpak ziet er als volgt uit:

  • Stap1 (ontwerp, implementatie, testen, documentatie, evaluatie)

Afzonderlijke stappen lopen naadloos in elkaar over en vinden soms parallel plaats.

Sterke punten van de agile aanpak

Een belangrijk voordeel van de agile aanpak is dat deze bijzonder flexibel en praktijkgericht is in de uitvoering – communicatie en klanttevredenheid staan hier duidelijk centraal. Het projectteam en de klant of de toekomstige gebruikers van het systeem werken vanaf het begin nauw samen. De gebruikers worden bij elke cyclus betrokken en zien individuele onderdelen van het systeem al in een vroeg stadium in actie, aangezien er, zoals reeds vermeld, na elke cyclus een uitvoerbaar subsysteem wordt gemaakt. Dit betekent dat de software al tijdens de implementatiefase getest kan worden.

Fouten in het ontwerp komen snel aan het licht en de klant kan ook snel zien of de software aan zijn verwachtingen en eisen voldoet. Misverstanden kunnen ook veel gemakkelijker worden voorkomen. Het projectteam kan feedback van de klant direct implementeren en de nieuwe bevindingen gebruiken om de procedure zo nodig aan te passen. Bovenal voorkomt de agile aanpak dat het project eindigt in een dure aanpassingsmarathon. De acceptatie door gebruikers neemt ook toe, omdat werknemers het project door voortdurende betrokkenheid kunnen beïnvloeden en zich daardoor sterker met het systeem kunnen identificeren.

Zwakke punten van de agile aanpak

Hoewel deze methode meer voordelen dan nadelen heeft, is ze toch niet geschikt voor elk bedrijf. Om een ERP-implementatie op een agile manier uit te voeren, moet het management enige controle opgeven, aangezien de agile aanpak niet gebaseerd is op vaste projectplannen en planningen. Bovendien gaat er altijd enige planningszekerheid verloren, aangezien het nooit mogelijk is om van tevoren precies te zeggen wanneer welke functie klaar en klaar voor gebruik zal zijn en welk resultaat verwacht kan worden.

Agile of watervalmethode – wat zijn de belangrijkste verschillen?

Beide benaderingen hebben hetzelfde doel, maar volgen verschillende procedures. Dit zijn de belangrijkste verschillen:

Watervalmethode

  • Klassieke aanpak, was lange tijd standaard in de ERP-sector
  • Lineaire aanpak
  • Het project wordt opgedeeld in afzonderlijke fasen, die na elkaar worden verwerkt
  • De projectresultaten worden aan het eind gepresenteerd
  • Het proces en het concept van het project zijn aan het begin gedefinieerd en worden over het algemeen niet gewijzigd
  • Eenmaal voltooid, worden de fasen niet meer veranderd
  • Het dienstenaanbod is bekend, de scope duidelijk gedefinieerd
  • De klant heeft duidelijke eisen die niet of nauwelijks veranderen
  • Het project heeft een vrij korte looptijd
  • De klant wil slechts in geringe mate in het proces geïntegreerd worden

 

  • Voordelen
  • Hoge planningszekerheid
  • Budget, huidige status en volgende stappen tot aan de echte start zijn te allen tijde bekend
  • Het geplande tijdschema kan gemakkelijker worden aangehouden dankzij duidelijke en georganiseerde structuren

 

  • Nadelen
  • Relatief star en niet flexibel bij veranderingen
  • Vaak dure aanpassingen nodig, omdat fouten uit de ontwerpfase pas aan het eind aan het licht komen
  • Hoge ontwerpinspanning
  • Individuele stappen moeten zeer gedetailleerd gepland worden
  • Agile aanpak

      • Alternatief voor de watervalmethode
      • Lineaire processen worden vervangen door cycli (zogenaamde sprints)
        • In elke cyclus wordt een werkpakket, meestal een functionele eis, volledig geïmplementeerd en getest zodat er een uitvoerbaar subsysteem ontstaat
      • Het projectproces is flexibel
        • Planning en concept zijn niet star, maar worden in de loop van het project verder ontwikkeld
        • Deelresultaten worden aangepast op basis van feedback van gebruikers
      • Het dienstenaanbod is tamelijk onbekend, de reikwijdte is variabel
      • Het project heeft een vrij lange looptijd
      • Eisen zijn onduidelijk en er zijn veel aanpassingen te verwachten
      • Klant wil sterke betrokkenheid bij het proces
      • Voordelen
        • Flexibel en zeer praktijkgericht
        • Communicatie en klanttevredenheid staan centraal in deze methode
        • Gezamenlijk leerproces
          • Nauwe samenwerking tussen klant en ERP-leverancier
        • Minder vertragingen en rework
          • Conceptuele fouten worden sneller ontdekt omdat er na elke cyclus tests worden uitgevoerd
        • De gebruikersacceptatie neemt toe omdat werknemers voortdurend bij het project betrokken zijn en de processen kunnen beïnvloeden
      • Nadelen
        • Managers moeten een deel van de controle opgeven
        • Er gaat wat planningszekerheid verloren, omdat het nooit helemaal duidelijk is wanneer welke functie klaar zal zijn
      • Welke methode is de beste keuze voor mijn vereisten?

        Welke methode voor u en uw bedrijf het beste is, hangt van veel factoren af en kan niet per se worden beantwoord. Helaas is er geen universele oplossing die voor alle bedrijven even goed werkt. De watervalmethode wordt vaker gebruikt in bedrijven met hiërarchische structuren, waar planningszekerheid, controle en georganiseerde structuren een prioriteit zijn. Klanten die graag een overzicht hebben van de workflows en processen in het bedrijf zullen eerder voor deze methode kiezen. Dit zijn vaak projecten met constante eisen. Projecten met veel onvoorspelbare factoren die flexibele aanpassingen vereisen, zijn meestal ongeschikt voor deze methode.

        De volgende vragen kunnen u helpen beslissen welke aanpak voor u de juiste is:

        • Zijn de doelen vooraf duidelijk definieerbaar?
        • Heeft de klant precieze ideeën?
        • Heeft het projectteam een duidelijke managementstructuur nodig?
        • Is er een deadline of zijn er duidelijk gedefinieerde mijlpalen?
        • Is het budget duidelijk gedefinieerd?
        • Worden er geen grote veranderingen verwacht in de loop van het project?

        Als u “ja” antwoordt op de meeste vragen, dan is de watervalmethode waarschijnlijk geschikter voor u. Agile ontwikkelingsmethoden kunnen daarentegen een aanpak zijn als de klant nog geen duidelijk idee heeft van wat hij precies wil. Deze methode is met name interessant voor bedrijven waar men ervan uit kan gaan dat het project een langere looptijd zal hebben en dat randvoorwaarden, wensen of prioriteiten in de loop van de tijd eerder zullen veranderen. Bedrijven kiezen vaak voor een combinatie van beide modellen. Deze hybride benaderingen combineren elementen van beide benaderingen. Het is bijvoorbeeld denkbaar om een langetermijnplan op te stellen op basis van de watervalmethode, maar zonder de afzonderlijke fasen strikt te scheiden – een mix van planningszekerheid en flexibiliteit.

        In elk geval is het de moeite waard om beide methoden nader te bekijken, want ze hebben allebei hun voor- en nadelen. U kunt het beste wat tijd nemen om onderzoek te doen en samen met uw ERP-leverancier uit te zoeken welk model het beste bij uw eisen past.

        Als u meer wilt weten over de watervalmethode, agile benaderingen voor uw ERP-implementatie of het volledige aanbod van TimeLine ERP-functies, stuur ons dan een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Alle belangrijke vragen over workshops voor ERP-systemen

U hebt waarschijnlijk wel eens van ERP-workshops gehoord – en u misschien afgevraagd: Wat is een ERP-workshop precies? Nou, de zoektocht naar softwareoplossingen voor bedrijven verloopt vaak volgens een eenvoudige, uit drie fasen bestaande methode. Ten eerste wordt er een basiszoekopdracht op internet uitgevoerd om duidelijk te maken welke aanbieders over het algemeen geschikt zijn. Vervolgens worden alle oplossingen die het beste aan uw eisen voldoen met elkaar vergeleken en wordt er een definitieve beslissing genomen.

Hoewel deze aanpak voor veel systemen werkt, is hij minder geschikt voor het selecteren van ERP (Enterprise Resource Planning)-softwareoplossingen. Een ERP-systeem is complex en moet nauw aansluiten op uw bedrijfsprocessen. Een ruwe zoektocht op het web kan een eerste hulp zijn om een overzicht van verschillende ERP-systemen te krijgen, maar het internet kan u niet helpen met individuele vragen. Als u wilt weten of de software uw specifieke processen ondersteunt, is een rechtstreeks gesprek met de ERP-aanbieder essentieel. Om deze en andere vragen te beantwoorden, wordt er een ERP workshop georganiseerd. Wat zo’n workshop voor ERP-systemen precies is en hoe het werkt, wordt hieronder uitgelegd.

Wat is een ERP workshop

Een ERP workshop is een evenement waarbij de klant en de ERP-leverancier elkaar voor het eerst persoonlijk leren kennen. Dit maakt een ERP workshop de laatste stap en de basis voor de uiteindelijke ERP selectie. Het is als het ware het centrale beslissingscriterium: welke aanbieder het meest overtuigend is tijdens de ERP-systemen workshop krijgt het contract. Voor u als klant is dit natuurlijk een goede gelegenheid om de ERP-aanbieder te leren kennen en een idee te krijgen van de software. Uw belangrijkste doel op de ERP workshop moet zijn om erachter te komen of de software uw individuele eisen en wensen kan implementeren. Zo’n workshop is niet zomaar een informatie-evenement waar u achterover kunt leunen en ontspannen. Uw deelname heeft een grote invloed op de kwaliteit van de ERP workshop! Als u het maximale uit de workshop wilt halen, zijn een goede voorbereiding en uw actieve deelname essentieel.

Waar vindt de ERP workshop plaats?

Een workshop voor ERP-systemen vindt altijd bij de klant plaats. De reden hiervoor is dat de ERP workshop meestal gepaard gaat met een rondleiding door het bedrijf. Hierdoor kunnen de ERP-experts de processen en workflows van uw bedrijf beter begrijpen en het hele projectteam leren kennen.

Hoe lang duurt een ERP workshop?

De duur van de ERP workshop hangt af van de omvang, reikwijdte en complexiteit van uw project. Om u een ruwe indicatie te geven: Voor kleine bedrijven wordt meestal één dag uitgetrokken voor de workshop, voor middelgrote bedrijven is dat één tot twee dagen. Voor grote projecten wordt voor een ERP-workshop één dag per gespecialiseerde afdeling verwacht – dus ongeveer drie tot vijf dagen in totaal.

Wie moet er deelnemen aan de workshop voor ERP-systemen?

Vanuit het oogpunt van de klant moeten het hele projectteam en een verantwoordelijke persoon van de betreffende gespecialiseerde afdeling aanwezig zijn bij de workshop voor ERP-systemen. Natuurlijk is het niet altijd gemakkelijk om alle betrokkenen weg te halen van de dagelijkse werkzaamheden. Het is echter belangrijk voor een succesvolle ERP-workshop dat alle betrokkenen aanwezig zijn. Iedereen vervult een belangrijke functie in dit project en moet daarom ook aandacht besteden aan andere details. Plan dit dus zo mogelijk in. Er zijn meestal twee mensen van de leverancier aanwezig bij de ERP-workshop: een senior consultant en de vertegenwoordiger met wie u het eerste contact had. Bij grotere, uitgebreidere projecten kunnen er ook meerdere mensen aanwezig zijn.

U bent misschien ook geïnteresseerd in:

Hoe wordt een ERP workshop voorbereid door de leverancier?

Bij veel providers wordt de softwareoplossing in de ERP-workshop gepresenteerd. TimeLine is anders: wij houden een eerste bespreking met u vóór de ERP-workshop. In dit gesprek presenteren wij u ons ERP-systeem met alle functionaliteiten in een online presentatie. We leggen ook belangrijke vragen over u en uw bedrijf van tevoren uit, bijvoorbeeld:

      • In welke bedrijfstak bent u werkzaam
      • Bent u een eenmalige of seriematige fabrikant?
      • Welke software gebruikt u momenteel?
      • Wat zijn de problemen met de huidige software?
      • Wat hoopt u te bereiken met het nieuwe ERP-systeem?

      Dit is handig om uw bedrijf en de bijbehorende processen beter te kunnen beoordelen vóór de ERP-workshop. In tegenstelling tot een zoektocht op het web of een schriftelijke aanvraag, ontvangt u direct alle belangrijke informatie die u nodig hebt voor een goede voorbereiding. Er is ook de mogelijkheid voor beide partijen om vragen te stellen. Dit betekent dat u tijdens de ERP workshop al bekend bent met de functionaliteiten van het systeem en dat de focus kan liggen op hoe uw specifieke eisen en wensen geïmplementeerd kunnen worden.

      erp-workshop

      Hoe bereiden klanten zich voor op de ERP workshop?

      Als klant moet u zich voorbereiden op de ERP workshop door van tevoren belangrijke informatie te verzamelen. Dit kunnen voorbeeldprocessen en bijbehorende gegevens zijn, die u vervolgens in de vorm van PDF’s, Word-bestanden of diagrammen naar de ERP-aanbieder stuurt. Het is belangrijk dat u zich beperkt tot de belangrijkste workflows en processen en niet te veel gegevens verzamelt. De regel hier is: kwaliteit voor kwantiteit!

      Hoe werkt een ERP workshop?

      De ERP workshop is verdeeld in verschillende fasen. Het proces ziet er meestal als volgt uit:

      • Introductie & voorbespreking: De ERP workshop begint met een kennismakingsronde van beide kanten. Alle deelnemers stellen zichzelf voor en het bedrijf wordt ook kort voorgesteld.
      • Bedrijfsrondleiding: De tweede stap is een gezamenlijke rondleiding door het bedrijf. De ERP-aanbieder wil zien hoe een order door het bedrijf loopt – van het plaatsen van de order tot de productie en levering. Aangezien de ERP-workshops worden uitgevoerd door ervaren projectmanagers, kunnen zij uw processen direct analyseren – en beoordelen welke aanpassingen aan het ERP-systeem moeten worden gemaakt.
      • Individuele gesprekken met de gespecialiseerde afdelingen: De derde stap van de ERP workshop bestaat uit individuele gesprekken met alle gespecialiseerde afdelingen. Hierbij ligt de nadruk op een zogenaamde GAP-analyse. Een GAP-analyse is een klassiek planning- en controle-instrument. Het dient om de problemen in uw bedrijf te herkennen en erop te reageren. Er wordt bepaald welke speciale vereisten u als klant hebt die nog niet in de standaardoplossing zijn opgenomen, hoe uw individuele problemen kunnen worden opgelost en vereisten kunnen worden geïmplementeerd en of er aanpassingen aan het systeem nodig zijn. U moet ook rekening houden met toekomstige projecten en langetermijndoelen.
      • Ruw ontwerp van het projectplan: Het laatste punt op de agenda van een ERP workshop is het opstellen van een ontwerp-projectplan. Hierin wordt vastgelegd wanneer u de software in gebruik wilt nemen, wanneer de trainingsdata moeten plaatsvinden, wanneer de gegevensoverdracht is gepland en welke aanpassingen over het algemeen nodig zijn voor een succesvolle implementatie.

      Hoe blijven de klant en de ERP-leverancier over aan het einde van de ERP-workshop?

      Tijdens de ERP-workshop of een paar dagen later geven we u een gedetailleerde offerte over hoeveel de ERP-implementatie gaat kosten. Dit is inclusief kostenramingen en het trainingsconcept. U ontvangt ook een transcript, het zogenaamde organisatiehandboek. Op basis hiervan kunt u een beslissing nemen.

      Wat kost een workshop voor ERP-systemen?

      De kosten voor ERP workshops verschillen per aanbieder. Bij TimeLine kost een ERP-workshop 1.500 euro per dag. Daarnaast zijn er kosten voor het reizen van en naar de workshop, evenals accommodatie en onkosten. De kosten voor de workshop worden in rekening gebracht wanneer de opdracht wordt geplaatst.

      Waar moet u op letten bij een ERP workshop?

      Bij het gebruik van ERP-software streven de klant en de ERP-leverancier altijd naar een samenwerking op lange termijn. Zie de ERP-workshop als een kans om de leverancier en hun software te leren kennen, maar ook om uw eigen bedrijfsprocessen zo goed mogelijk te beschrijven. Dit helpt de leverancier om uw processen beter te begrijpen en de beste oplossing voor u te vinden. Een goede voorbereiding kan de kwaliteit van de ERP-workshop aanzienlijk verbeteren.

      Hoe herken ik een goede ERP-aanbieder?

      Gebruik de ERP-workshop om vragen te stellen en eventuele onduidelijkheden weg te nemen. Richt u op de vraag of uw specifieke vereisten geïmplementeerd kunnen worden en let op het communicatieniveau. Reageert de aanbieder op uw vragen of vermijdt hij bepaalde onderwerpen? Ligt de nadruk op de implementatie van uw vereisten of meer op de functies en kenmerken van het systeem? Deze tips zullen u helpen om de juiste ERP-oplossing voor uw bedrijf te vinden.

      Lees meer over ERP workshops van TimeLine

      Als u meer wilt weten over ERP-workshops of het volledige aanbod van TimeLine ERP-functies, kunt u ons een bericht sturen via het contactformulier, schrijven naar [email protected] of contact opnemen met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Hoe de kosten voor ERP-software zijn opgesplitst – en hoe u kunt besparen

Digitalisering vereist dat bedrijven hun processen herstructureren en afdelingen meer dan ooit in een netwerk onderbrengen. Een goede manier om dit te doen is met een ERP-systeem. Natuurlijk vragen bedrijven zich af hoeveel ERP-systemen kosten. Het goede nieuws: Niet alle kosten van een ERP-implementatie staan vast. Er is een variabel deel van de kosten van ERP-software dat u zelf kunt beïnvloeden. In dit artikel komt u te weten hoe ERP-kosten in elkaar zitten, hoe u kostendrijvers kunt herkennen en welke tips u kunt gebruiken om kosten te besparen tijdens de ERP-implementatie.

Waaruit bestaan de kosten van een ERP-systeem precies?

Ten eerste moeten we verduidelijken hoe de kosten van een ERP implementatie zijn opgebouwd. Als u dit weet en zich bewust bent van de factoren die een negatieve invloed kunnen hebben op de kosten van een ERP-systeem, hebt u meer mogelijkheden om de ontwikkeling te beïnvloeden. Afhankelijk van de omvang van de processen die gedekt moeten worden, bestaat de prijs van het ERP-systeem uit verschillende factoren. Er wordt bijvoorbeeld rekening gehouden met welke modules of hoeveel werkstations u nodig hebt. Omdat de prijsmodellen echter van bedrijf tot bedrijf verschillen, is het bijna onmogelijk om algemene uitspraken te doen over de werkelijke kosten van een ERP-systeem. In het algemeen kan echter gezegd worden dat de kosten uit twee gebieden bestaan:

  • Licentiekosten voor ERP-software: De licentiekosten voor de software vormen ongeveer 50 procent van de totale kosten van het ERP-systeem. Helaas kunnen deze kosten niet worden gereduceerd en moeten ze altijd volledig worden begroot.
  • Kosten voor ERP-services: De andere 50 procent van de ERP-kosten zijn voor services. Deze zijn variabel en dus beïnvloedbaar. Diensten omvatten maatwerk, consulting en services, evenals training voor hoofdgebruikers en eindgebruikers.

Welke ERP-systeemkosten worden er gemaakt voor de dienstensector?

Hoeveel van uw budget wordt besteed aan maatwerk, consulting en training hangt af van hoe nauw u aan de standaard werkt. Of het nu gaat om ERP-workshop, conceptualisatie, coördinatievergaderingen, programmeren, gegevensoverdracht, rapportage of training – als klant hebt u invloed op alle diensten. Natuurlijk moet u niet helemaal afzien van dit aanbod. Consultancy, training en technische aanpassingen zijn ongetwijfeld belangrijk om het ERP-systeem aan te passen aan de vereisten en processen van uw bedrijf en om uw werknemers vertrouwd te maken met het systeem.

Hoe kunt u de kosten van het ERP-systeem verlagen?

Met een goede voorbereiding kunt u de kosten van ERP-systemen in de dienstensector aanzienlijk verlagen. Uw medewerking is vereist! Helaas kunnen ongewenste kosten niet altijd volledig worden vermeden. Soms zijn bepaalde punten moeilijk in te schatten, ondanks de ERP workshop en specificaties. Deze worden dan pas duidelijk in de loop van het project. Er zijn echter ook kostenveroorzakers die met een goede voorbereiding vermeden kunnen worden.

5 tips voor gunstigere ERP software kosten

Tip 1: Duidelijke doelen en specifieke vereisten

Als u besluit om een ERP-systeem te gaan gebruiken, hebt u waarschijnlijk al een globaal idee van hoe het uw processen zou moeten verbeteren. Veel bedrijven formuleren hun wensen en doelen echter erg vaag. Ze willen vaak implementeren wat mogelijk is – volgens het motto “Elke functie komt ooit van pas”. Het probleem hiermee is dat u met zo’n aanpak nauwelijks de kosten van ERP-software kunt berekenen.

Als de vereisten vaag gedefinieerd zijn en problemen alleen aan de oppervlakte worden geschraapt zonder de mogelijke oorzaken te onderzoeken, staat het project vanaf het begin op wankele grond. Het resultaat wordt op zijn laatst duidelijk wanneer de specificaties worden opgesteld. Dan hebt u geen andere keuze dan te werken met wat het personeel wil – en dat kan leiden tot vertragingen en complicaties.

U moet daarom vanaf het begin duidelijke doelstellingen en specifieke eisen formuleren, zodat er een ERP-systeem wordt gecreëerd dat aan uw behoeften voldoet – en dat gemakkelijk voor uw budget is. Zo kan de leverancier het juiste ERP-systeem selecteren, een succesvolle ERP-implementatie garanderen en onnodige extra kosten besparen.

erp-systeem-kosten

Tip 2: Balans tussen projectmanagement en afdelingen

Een andere factor voor hoge ERP-softwarekosten kan het gedrag van individuele afdelingen zijn in combinatie met zwak projectmanagement. Het komt vaak voor dat individuele werknemers of afdelingen meer vrijheid hebben dan anderen. Ze zijn gewend om hun plannen door te drukken en weinig compromissen te sluiten. Dan moet elk idee, hoe klein ook, worden uitgevoerd – of het nu een evaluatie, lijst of query is.

Als deze situatie nog verergerd wordt door een projectmanager die gemakkelijk toegeeft en alle verzoeken goedkeurt, zult u als besluitvormer al snel geconfronteerd worden met een lange lijst met verzoeken, vereisten en ideeën van uw werknemers – en zult u uiteindelijk voor navenant hoge ERP-systeemkosten komen te staan. Om de kosten in de gaten te houden, hebt u een sterk projectmanagement nodig dat soms suggesties van het personeel kan afwijzen.

Natuurlijk moeten de suggesties van werknemers serieus genomen worden, omdat zij het beste kunnen beoordelen welke functies nuttig zouden zijn. Een goede optie is om eerst alle aanpassingsverzoeken van het personeel te noteren en voorlopig nog met de standaard query’s te werken. Na een bepaalde tijd in de dagelijkse praktijk zal duidelijk worden of verdere aanpassingen zinvol zijn of dat de gewenste punten overbodig zijn geworden.

U kunt hier lezen hoe u een sterk projectteam kunt samenstellen:

Tip 3: Bereid gegevens nauwkeurig voor

De database vormt de basis van een ERP-systeem. Aan het begin van elke ERP-implementatie wordt bepaald welke gegevens naar het nieuwe systeem worden overgezet. Dit zijn meestal alleen de stamgegevens. Iedereen heeft echter een andere definitie van stamgegevens, en daarom moet u eerst bepalen welke gegevens overgezet moeten worden – en controleren of ze up-to-date zijn. Zo kunt u met verse gegevens beginnen en het meeste uit de software halen zonder na te hoeven denken over aanpassingen achteraf. Dit kan de kosten van het ERP-systeem aanzienlijk verlagen.

U kunt hier lezen hoe u gegevens goed kunt voorbereiden:

Tip 4:Professionele gebruikers trainen

U moet een deel van de kosten van het ERP-systeem begroten voor de training van de relevante gebruikers. Hoe hoog deze kosten zullen zijn, hangt af van twee factoren: ten eerste, welke en hoeveel modules er gebruikt gaan worden en ten tweede, hoeveel mensen er getraind moeten worden en hoe vaak. Hoe groter het aantal modules, hoe meer tijd de training natuurlijk zal kosten. De ervaring leert dat de benodigde hoeveelheid training lager is bij een jonge leeftijdsopbouw dan bij een oudere leeftijdsopbouw. Jonge, PC-vaardige mensen hoeven vaak maar één keer getraind te worden, terwijl oudere mensen vaker getraind moeten worden.

Verder nuttige informatie over training vindt u hier:

Tip 5: Geef uw ERP-project de juiste prioriteit

Veel bedrijven denken dat de invoering van een ERP-systeem een project is dat naast de eigenlijke dagelijkse activiteiten loopt en niet veel middelen vereist. Dit idee moet u loslaten. Het project is geen dienst die u bij uw ERP-leverancier bestelt en waar u vervolgens niets meer mee te maken hebt. Het gaat tenslotte om uw processen en uw werknemers.

Als u het project niet de nodige aandacht geeft, zal het uitgesteld worden – en dit zal hoogstwaarschijnlijk weerspiegeld worden in hoge ERP-systeemkosten. Elke extra vergadering, elke uitgestelde afspraak en elke reis van de ERP-consultant verhoogt de kosten van de ERP-software. Uw medewerking is nodig om ervoor te zorgen dat de implementatie zo soepel mogelijk verloopt en uw kosten niet onnodig stijgen.

Klantprojecten krijgen vaak voorrang op ERP-projecten. Het projectteam bestaat uit onervaren medewerkers, omdat de ervaren collega’s elders nodig zijn. Vanuit uw oogpunt kan dit logisch zijn – de klant brengt uw bedrijf immers omzet en het ERP-project daarentegen kost u in eerste instantie middelen. Deze aanpak leidt echter meestal tot extra kosten, omdat onervaren werknemers vaak fouten maken die vermeden kunnen worden. Het principe is eigenlijk eenvoudig: hoe meer prioriteit u aan het project geeft, hoe sneller u de ERP-software kunt implementeren – en hoe lager de ERP-implementatiekosten uiteindelijk zullen zijn.

Conclusie: Hoe u de kosten van een ERP-systeem kunt verlagen

De invoering van een ERP-systeem gaat in eerste instantie gepaard met hoge kosten. De software wordt geleverd met veel standaardfuncties, maar geen enkel systeem kan vanaf het begin perfect op uw behoeften worden afgestemd. Aanpassingen op maat zijn daarom belangrijk om uw processen optimaal te ondersteunen en volledig af te dekken. Slechts de helft van de kosten van ERP-systemen zijn echter vaste kosten – hier moet u van profiteren.

Als u met deze punten rekening houdt, staat niets een succesvol – en betaalbaar – ERP-project in de weg:

    1. Goede voorbereiding ensamenwerking – met een gedetailleerde analyse van de vereisten kunt u latere aanpassingen voorkomen. Bepaal zo precies mogelijk wat het systeem uiteindelijk moet kunnen.
    2. Een sterk projectmanagement helpt om de kosten van de implementatie binnen de perken te houden. Stel hiervoor iemand aan die de kostenkwestie niet uit het oog verliest en standvastig blijft met het personeel.
    3. Zorgvuldig voorbereide gegevens voorkomen aanpassingen achteraf en verbeteren de prestaties.
    4. De trainingsinspanning kan worden verminderd met een slimmeselectie van gebruikers en modules.
    1. Hoe meer aandacht u aan het project besteedt, hoe lager de kosten uiteindelijk zullen zijn

.

Als u meer wilt weten over de kosten van een ERP-systeem, kunt u ons een bericht sturen via het contactformulier, schrijven naar [email protected] of contact opnemen met ons verkoopteam op +31 46 234 00 99. Wij geven u graag advies!

Er zijn een paar dingen waar u rekening mee moet houden om een ERP-project succesvol te laten verlopen. Het maken van een eisenspecificatie helpt u om het overzicht te bewaren. Het uitvoeren van een eisenanalyse moet bijvoorbeeld bovenaan uw takenlijst staan. Hierbij bepaalt u wat het systeem moet kunnen om uw processen optimaal te ondersteunen. De resultaten van de analyse worden meestal vastgelegd in een specificatieblad. Klinkt eenvoudig, nietwaar? Maar dat is het allerminst. De uitdaging is om de juiste balans te vinden. Als uw specificaties te oppervlakkig zijn, zullen er veel vragen of verschillende interpretaties van uw formuleringen zijn. Als u zich daarentegen verliest in de details, zullen ERP-aanbieders uw specificaties nauwelijks kunnen implementeren – en de moeite die dat kost zal niet in verhouding staan tot de voordelen. Maar wat is de optimale structuur van een specificatieblad? In dit artikel leest u wat een specificatieblad eigenlijk is en waar u rekening mee moet houden als u er een maakt.

Definitie – Wat is een specificatieblad?
Een eisenspecificatie is een onderdeel van requirements management en vormt als het ware de basis voor een succesvolle ERP-implementatie. Het wordt gemaakt door de klant, die in het geval van een ERP-project de klant is. Zoals reeds vermeld, worden de resultaten van de eisen-analyse in dit document vastgelegd. Het beschrijft alle eisen waaraan moet worden voldaan om het projectdoel te bereiken. Concreet betekent dit welke mogelijkheden en functies een ERP-systeem moet hebben. Het maken van een goede eisenspecificatie betekent ondersteuning voor alle betrokkenen – het is zowel een hulpmiddel bij de besluitvorming voor het bedrijf als een richtlijn voor de ERP-leverancier. Uiteindelijk laat het zien hoe het gebruik van de software helpt om de processen in uw bedrijf optimaal te ondersteunen. Zodra het document is opgesteld, wordt het naar alle potentiële ERP-aanbieders gestuurd. Dit ondersteunt ook het selectieproces.

U bent misschien ook geïnteresseerd in:

Specificatie van vereisten vs. functionele specificatie – wat is het verschil?
De specificaties beschrijven dus wat een ERP-systeem moet kunnen. In verband met de eisenspecificatie komt u echter vaak de term “functionele specificatie” tegen – waar gaat het om? De eisen-specificatie wordt in een later stadium gemaakt door de opdrachtnemer, in dit geval de ERP-leverancier. Het beschrijft hoe de vereisten uit het specificatieblad concreet moeten worden ingevuld. De eisenspecificatie bevat daarom duidelijke oplossingsvoorstellen voor de implementatie. Het wordt gebruikt voor een gedetailleerde planning voor de implementatie van de software en bevat exacte specificaties voor de softwareconfiguratie.

Koffiekopje

Waarom moet u een specificatieblad maken?
Elk ERP-project begint met de vraag waarom en in welke afdelingen van het bedrijf de software gebruikt gaat worden. Op dit punt zou u moeten beginnen met het opstellen van een specificatieblad. Maar hebt u er echt een nodig? Absoluut, want de eisenspecificatie vervult twee belangrijke functies:

Een specificatieblad opstellen is belangrijk voor zowel de klant als de ERP-leverancier

Aan de ene kant helpt het u bij alle beslissingen die u tijdens het ERP-project moet nemen. De vereisten die in het specificatieblad zijn vastgelegd, zijn bijvoorbeeld nuttig bij het vinden van een geschikte ERP-aanbieder. U kunt er ook steeds weer naar verwijzen tijdens de realisatie. Aan de andere kant is de eisenspecificatie een belangrijk document voor de leveranciers op uw lange en korte lijst. Dit komt omdat het alle relevante informatie over uw bedrijf en uw vereisten samenvat.

De vereisten in de specificaties weerspiegelen als het ware uw verwachtingen van het systeem – het dient dus als een soort leidraad. ERP-aanbieders kunnen zo beter bepalen of uw specifieke wensen ook gerealiseerd kunnen worden. En ze reageren in detail met mogelijke suggesties om aan de vereisten te voldoen. Bovendien wordt, zoals reeds vermeld, de eisenspecificatie in een later stadium ontwikkeld tot uw functionele specificatie. Enerzijds maakt deze deel uit van het contract tussen u en de geselecteerde ERP-leverancier, anderzijds vormt deze de basis voor het testen en de acceptatie.

U bent misschien ook geïnteresseerd in:

Gidsregel – Hoe maak ik een specificatieblad

Het vinden van de juiste informatie voor een specificatieblad is niet zo eenvoudig. Een goed specificatieblad is meer dan alleen een lijst met vereisten. Aan de ene kant definieert het de basisvereisten en bevat het ook uitleg zodat buitenstaanders de formulering van de documentatie correct kunnen interpreteren. De uitdaging hier is echter om niet te veel in detail te treden. Er zijn momenteel geen bindende regels of wettelijke criteria voor de term specificaties of de inhoud van het document. In de loop der tijd is er echter een duidelijke inhoud ontstaan die in alle bedrijfstakken wordt nageleefd.

lastenheft-meeting

De volgende punten moeten worden opgenomen bij het maken van een specificatieblad:</h3
De eisen die in de eisenspecificatie worden gedocumenteerd, moeten zo worden opgesteld dat ze idealiter op een later tijdstip verder kunnen worden ontwikkeld tot een functionele specificatie. Het is ook raadzaam om de inhoud op een gestructureerde manier te organiseren in plaats van deze willekeurig te rangschikken.

Beschrijving van het bedrijf

Begin met een korte introductie van het bedrijf. Dit zal de toekomstige ERP-leverancier een eerste indruk geven van u, uw situatie en uw diensten. Het zal hen ook een beter idee geven of ze naar tevredenheid aan uw verwachtingen en voorwaarden kunnen voldoen. Dit omvat natuurlijk de naam van uw bedrijf, de bedrijfstak, locaties en een contactpersoon met wie ze contact kunnen opnemen als ze vragen hebben. U kunt ook de marktomgeving en uw producten en diensten beschrijven. Hoewel deze informatie optioneel is, zal het de kwaliteit van uw specificaties aanzienlijk verbeteren. U kunt deze vragen bijvoorbeeld beantwoorden

  • Wat verkoopt u?
  • Heeft u concurrenten? Zo ja, wie?
  • Wat zijn uw sterke en zwakke punten?
  • Wat onderscheidt u van andere bedrijven? Is er een unique selling point of zijn er bepaalde mijlpalen?

Vervolgens moet u de huidige status-quo en de gewenste doelstatus beschrijven:

Initiële situatie

Beschrijf uw huidige uitgangssituatie en de huidige IT-infrastructuur:

    • Hoe is de wens voor een nieuw ERP-systeem ontstaan?
    • Heeft u al een ERP-systeem? Zo ja, welke problemen bent u tegengekomen? Hoe heeft u deze tot nu toe opgelost?
    • Gebruikt u andere softwareoplossingen die via een interface verbonden moeten worden?

Specificaties projectteam

Maak specificaties met doelstellingen & planning

Zelfs als een ERP-implementatie een omvangrijk en tijdrovend project is, moet u het doel niet uit het oog verliezen. U moet daarom specifiek de procedure en resultaten definiëren die u verwacht en hoe u succes wilt meten. Dit is niet alleen belangrijk voor de ERP-leverancier, maar kan ook nuttig zijn voor uzelf. Zo kunt u zichzelf van tijd tot tijd herinneren aan de prioriteiten van het project. Een planning moet ook deel uitmaken van uw specificaties:

  • Wanneer verwacht u een antwoord?
  • Wanneer moeten er workshops plaatsvinden?
  • Wanneer moet de implementatie beginnen?
  • Met betrekking tot digitalisering & Industrie 4.0:
    • Hoe zou de toekomstige richting van het bedrijf eruit moeten zien?

Gebruik het ERP-systeem niet alleen om de huidige status te verbeteren en fouten te elimineren – want slechts een heel klein deel van het potentieel wordt op deze manier benut. Daarom moet u zeker de doelstellingen van het bedrijf voor de komende jaren erin opnemen.

Functionele en niet-functionele vereisten

U moet dit punt verrijken met een bijzonder grote hoeveelheid informatie. Dit maakt het voor de leverancier veel gemakkelijker om een geschikte oplossing voor u te ontwikkelen. Functionele en niet-functionele vereisten zijn vaak geen duidelijke verklaringen die slechts één interpretatie toelaten. Ze beschrijven vaak slechts één doel, waarvoor verschillende oplossingsrichtingen denkbaar zijn. Ons artikel “Waarom is een requirements analyse zo belangrijk?” beschrijft functionele en niet-functionele requirements in meer detail.

U bent misschien ook geïnteresseerd in:

De specificaties op de laptop plannen

Toepassingsgebieden van de specificaties

Beschrijf het beoogde doel en de gebruiksgebieden.

    • In welke gebieden moet de software worden gebruikt?
    • Wie moet het gebruiken?

Houd er rekening mee dat planningsprocessen voortdurend veranderen en nooit in steen gebeiteld zijn. Bedenk daarom hoe beslissingen worden genomen en wiens goedkeuring vereist is. En ook hoe eventuele wijzigingen vervolgens in de specificaties moeten worden opgenomen.

Samenvatting

  • Beschrijving van het bedrijf
    • Naam, bedrijfstak, rechtsvorm, locaties, contactpersonen, enz.
    • Marktomgeving, producten, diensten
  • Beschrijving van de huidige en beoogde status
    • Initiële situatie
    • Huidige IT-infrastructuur
    • Doelinstelling & schema
      • Tijdschema, deadlines, data
  • Functionele & niet-functionele eisen
  • Toepassingsgebieden

Tips waarmee u rekening moet houden bij het maken van een specificatieblad

Het maken van een specificatieblad vereist een gestructureerde aanpak. Het is in ieder geval aan te raden om niet blindelings te beginnen met schrijven. Neem de tijd en stel uzelf de volgende vragen over uw project: Waarom heeft het bedrijf een ERP-systeem nodig? Welke doelen moeten met de invoering worden bereikt en welke processen moeten worden geoptimaliseerd? Het maken van een specificatieblad kan enkele weken of zelfs maanden duren. Het is het beste om aan het begin een deadline vast te stellen. Dit kan nuttig zijn om met de nodige discipline aan de creatie te werken. Vooral als er uitgebreide herstructureringen gepland zijn als onderdeel van het project.

Controleer de procesketens

Begin bij voorkeur met het controleren van de procesketens en het vinden van de zwakste schakel. Begin hiervoor bij het begin van de waardeketen en stel van daaruit vragen aan de volgende afdelingen. Wat zijn precies de problemen? Enerzijds heeft dit het voordeel dat het projectteam het hele proces en de respectieve afhankelijkheden leert kennen – en zo een goed overzicht van de processen krijgt. Anderzijds kunnen bekende zwakke punten al in de planningsfase worden opgelost door optimale doelprocessen te creëren. In de volgende stap kunt u nu de vereiste kenmerken uit de beschreven processen afleiden.

ERP projectteam

Eisen moeten gebaseerd zijn op de doelstellingen

Houd er rekening mee dat de vereisten gebaseerd moeten zijn op uw doelstellingen – en dat u de bedrijfsstrategie niet uit het oog mag verliezen. Zorg er ook voor dat u alleen de vereisten beschrijft en niet hun implementatie. In tegenstelling tot de functionele specificatie, moet de eisenspecificatie altijd oplossingsneutraal geformuleerd worden en op zo’n manier dat het ook door buitenstaanders begrepen kan worden. Het is ook belangrijk dat u uw werknemers bij het proces betrekt. In grote bedrijven is het echter zeer waarschijnlijk dat u veel en uitgebreide “verlanglijstjes” ontvangt. Zorg ervoor dat u deze niet ongefilterd in de specificaties opneemt – anders is chaos onvermijdelijk.

U bent misschien ook geïnteresseerd in:

Conclusie

Een specificatieblad ondersteunt u bij het selecteren van een geschikte leverancier en vormt de basis voor een succesvolle ERP-implementatie. Het is niet alleen een nuttig hulpmiddel voor de projectplanning: u wordt zich ook bewust van uw eigen doelen en processen. Bij het opstellen van de eisenspecificatie is het belangrijk om een balans te vinden tussen de twee “uitersten” en een geschikte diepte van informatie. Beschrijf uw vereisten op zo’n manier dat iemand die geen deel uitmaakt van uw bedrijf ze kan begrijpen. Vermijd irrelevante details en onrealistische “nice to have” functies. Idealiter zijn uw specificaties gestructureerd, procesgericht en oplossingsneutraal. In geval van twijfel geldt echter altijd: het ERP-systeem moet zich kunnen aanpassen aan uw processen – niet andersom.

Wilt u meer weten over behoeftenanalyses, specificaties of het hele scala aan functies van TimeLine ERP? Stuur ons een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Een nieuw ERP-systeem wordt in de volgende gevallen ingevoerd: Als er al geen in gebruik is of als het vorige systeem niet meer aan de eisen voldoet. Veel bedrijven gaan meestal meteen op zoek naar een geschikte ERP-leverancier. De specifieke vereisten voor het systeem worden in dit stadium echter vaak niet in detail overwogen of onderzocht – evenmin als de zakelijke criteria en doelen die in de toekomst worden nagestreefd. Maar hoe komt u erachter welk ERP-systeem het beste bij u past? Vooral als u niet naar uw eigen processen kijkt? De gevolgen worden vaak duidelijk tijdens de implementatie – problemen die hier ontstaan, zijn vaak te wijten aan een slechte voorbereiding. De eerste stap moet daarom altijd het maken van een kwalitatief hoogwaardige eisenanalyse zijn. In dit artikel hebben we alle belangrijke informatie over het onderwerp eisenanalyse voor u verzameld.

Wat is een requirements analyse eigenlijk?
Voordat we het hebben over de beste manier om een eisenanalyse op te stellen, moeten we eerst een paar vragen ophelderen: Wat houdt het precies in en waarom gebruik je het eigenlijk? Een eisen- en wensenanalyse wordt vaak uitgevoerd in de IT, maar kan ook op veel andere gebieden gebruikt worden. Het is echter bijzonder geschikt voor de invoering van een ERP-systeem. Met een gedetailleerde analyse van de vereisten kunt u de behoefte aan aanpassingen later in het project aanzienlijk verminderen. Dit bespaart niet alleen tijd en geld, maar spaart ook alle andere gebruikte middelen. Een eisen- en wensenanalyse is een document dat wordt gemaakt vóór de daadwerkelijke ERP-selectie. Het doel erachter: Voordat u aan het ERP-project begint, moet u de vereisten voor het nieuwe systeem in detail bekijken. Vervolgens moet u deze op een begrijpelijke manier documenteren. Er moet ook rekening worden gehouden met toekomstige doelen en de strategie van het bedrijf.

requirements-analysis-create-project-team

Een eisenanalyse voor software is echter niet alleen nodig om de pure eisen vast te leggen. Het kan gebruikt worden om te bepalen of de gewenste eisen überhaupt technisch en economisch gerealiseerd kunnen worden. In de praktijk is het vaak zo dat problemen die zich voordoen tijdens het project achteraf terug te voeren zijn op fouten in de analyse. Alle verzamelde informatie moet daarom vooraf gecontroleerd worden op haalbaarheid en risico. Er zijn verschillende opties en methoden om een dergelijke analyse uit te voeren. Deze omvatten verschillende hulpmiddelen die de vereisten analyseren, documenteren en beheren. De resultaten worden meestal in detail overgebracht naar een specificatieblad. In een later stadium worden ze in samenwerking met de ERP-leverancier uitgebreid tot een functionele specificatie. Bij het analyseren van vereisten wordt onderscheid gemaakt tussen functionele en niet-functionele vereisten:

Functionele vereisten

Functionele vereisten zijn specifieke criteria die direct aan het project kunnen worden toegewezen:

    • Wat moet het systeem doen?
      • Let op precieze formuleringen
          • Voorbeeld: “Het ERP-systeem moet minstens 1500 orders per dag kunnen verwerken.”
    • Welke diensten moet het aanbieden?
  • Invoer, verwerking, uitvoer, toegang
  • Gedrag in bepaalde situaties
    • Indien van toepassing: Wat moet het expliciet niet doen?

Niet-functionele eisen

Niet-functionele eisen zijn criteria die niet direct aan het project kunnen worden toegewezen. Dit komt omdat ze niet alleen in het ERP-project zelf worden gebruikt. Ze kunnen ook worden overgedragen naar andere projecten en plannen:

  • Hoe moeten het systeem of individuele functies werken (eigenschappen)?
  • Welke kwaliteitseisen hebt u met betrekking tot
    • Prestaties, betrouwbaarheid of onderhoudbaarheid
  • Eisen aan de bruikbaarheid van het systeem
  • Technische eisen

Waarom moet u een behoeftenanalyse uitvoeren?

We hebben nu vastgesteld dat een eisen- en wensenanalyse de eerste stap moet zijn bij de invoering van een ERP-systeem. Maar waarom eigenlijk? Is het niet veel gemakkelijker om meteen op zoek te gaan naar een leverancier om geen kostbare tijd te verspillen? Een ERP-implementatie mislukt zelden omdat er geen geschikte leverancier gevonden kan worden. De systemen zijn nu afgestemd op een breed scala aan bedrijfstakken, bedrijfsgroottes en bedrijfsgebieden – dus er is voor iedereen een geschikte oplossing te vinden. Vooral omdat individuele en specifieke aanpassingen altijd mogelijk zijn.

Een voorbereiding zonder analyse van vereisten doet ERP-projecten mislukken

Een slechte voorbereiding door een gebrek aan communicatie en documentatie is eerder een reden voor het mislukken van een ERP-project. Hoe complexer een project is en hoe meer mensen erbij betrokken zijn, hoe moeilijker het is om met elkaar te communiceren. Daarom is het bijzonder belangrijk om alle relevante punten zo gedetailleerd mogelijk vast te leggen, vooral bij een ERP-project. Het budget en de inspanning die nodig zijn voor een gedetailleerde requirementsanalyse worden echter vaak tot een minimum beperkt. Fouten die pas in de loop van het project ontdekt en vervolgens gecorrigeerd hoeven te worden, zijn veel tijdrovender om te herstellen – en brengen ook meer kosten met zich mee.

Bespreking van behoefteanalyse

Voordelen van een eisenanalyse

Een kwalitatief hoogwaardige analyse kost natuurlijk tijd en geld, maar is belangrijk voor het verdere verloop van het project. Het legt als het ware de basis voor alle toekomstige beslissingen met betrekking tot het ERP-project. Het dient als basis voor verdere stappen, zoals de systeemarchitectuur, het contractontwerp of de onderlinge communicatie. De behoeftenanalyse helpt u dus om de omvang van het project beter in te schatten. Zie het als een goede gelegenheid om uw eigen bedrijf met al zijn structuren en processen opnieuw te analyseren – en misschien ook om uzelf af te vragen of er gebieden zijn die in de toekomst geoptimaliseerd kunnen worden.

Een ander voordeel is dat een behoeftenanalyse helpt om het overzicht te behouden en een gemeenschappelijke consensus te creëren. Elke afdeling heeft waarschijnlijk verschillende input en daarom verschillende vereisten voor het systeem. Deze moeten zeker geharmoniseerd en aangepast worden om chaos en onnodige functies te voorkomen. Last but not least helpt het natuurlijk ook om de verdere ERP-selectie te beperken.

Wat moet er in een eisen- en wensenanalyse staan?

Het is niet mogelijk om te veralgemenen wat er precies in de eisen- en wensenanalyse moet staan. De inhoud hangt sterk af van uw individuele project. De volgende punten zijn daarom geen must, maar eerder een richtlijn die u als leidraad kunt gebruiken.

Bepaling van vereisten

Ten eerste moet u alle functionele en niet-functionele vereisten verzamelen en vastleggen die aan het ERP-project verbonden zijn. Dit kunt u het beste doen door middel van gebruikersdiscussies. Zorg ervoor dat u uw werknemers bij het proces betrekt. Zij hebben meestal het beste zicht op de feitelijke workflows en processen in hun respectievelijke verantwoordelijkheidsgebieden. Als u al een eisenspecificatie van een vorig project hebt, kunt u hier ook naar verwijzen.

Behoeftenanalyse

In de volgende stap moet u de informatie die u hebt verzameld analyseren en classificeren en in detail controleren op volledigheid. Vergelijk het vervolgens met andere vereisten om thematisch vergelijkbare verzoeken samen te vatten.

Beschrijving van vereisten

Nadat u alle vereisten hebt verzameld en geanalyseerd, moet u ze zo gedetailleerd mogelijk samenvatten in een document. Het is raadzaam om individuele use cases te beschrijven, zodat de informatie ook door buitenstaanders begrepen kan worden. Uitspraken als “Dit proces is vanzelfsprekend, we hoeven het niet te documenteren” moeten koste wat het kost worden vermeden. Er is hier natuurlijk veel ruimte voor interpretatie.

Revisie van vereisten

U moet de gedocumenteerde vereisten op een later tijdstip opnieuw bekijken. En als de vereisten veranderd zijn ze indien nodig aanpassen. Deze stap is niet absoluut noodzakelijk, maar het is raadzaam om het hele proces altijd in de gaten te houden.

projektbesprechung

Naast de vereisten moeten ook andere punten gedocumenteerd worden. Beschrijf uw project in algemene termen en definieer uw doelen. Wat verwacht u van de software? De huidige status moet ook beschreven worden. Vooral als u al een ERP-systeem gebruikt waar u niet tevreden over bent. Last but not least: Definieer interne bedrijfstermen die niet voor iedereen vanzelfsprekend zijn om misverstanden te voorkomen. Deze informatie zal uiteindelijk resulteren in een gedetailleerde analyse van de vereisten en een goede basis voor de volgende stappen.

Samenvatting van de behoeftenanalyse

    • Eisen verzamelen en documenteren
      • functionele eisen
      • niet-functionele eisen
    • Doelstelling bepalen
    • Algemene beschrijving van het project
    • Beschrijf de huidige status
    • Beschrijf de doelstatus
        • Wat verwacht u van de software

      ?

    • Bepaal afkortingen en technische taal

.

Hoe benadert u een eisenanalyse – hoe verzamelt u alle belangrijke informatie

Helaas is er geen gestandaardiseerde of voorgeschreven aanpak die u als leidraad kunt gebruiken. Wij kunnen u echter wel handige tips en methoden geven, zodat u geen belangrijke informatie vergeet. Zoals hierboven vermeld, moet u beginnen met het verzamelen van alle belangrijke informatie. Er zijn verschillende manieren om dit te doen:

Brainstormen

Samen brainstormen is natuurlijk een geweldige manier om veel verschillende standpunten te horen en in korte tijd informatie te verzamelen. Ga hiervoor met werknemers uit verschillende werkgebieden en afdelingen om de tafel zitten. Iedereen krijgt dan de kans om aan te geven wat ze hopen te winnen bij het nieuwe systeem. U zult al snel merken dat sommige wensen elkaar overlappen en andere sterk uiteenlopen. In de volgende stap is het belangrijk om alle genoemde wensen te selecteren en samen te vatten. Zo kunt u snel zien welke eisen belangrijk zijn en welke u voorlopig beter in uw achterhoofd kunt houden.

 width=

Observatie

Met deze methode kunt u bijvoorbeeld een of meer werknemers uit verschillende werkgebieden begeleiden bij hun dagelijkse werkzaamheden. Hoewel dit erg tijdrovend is, is het ook informatief. Het geeft u een goed inzicht in de dagelijkse gang van zaken en stelt u in staat om beter te beoordelen welke vereisten echt belangrijk zijn. U kunt ook specifieke vragen stellen in een directe dialoog. Het belangrijkste hierbij is dat u zich niet verliest in de details, maar naar het grote geheel kijkt.

Rapportage

Deze methode is vergelijkbaar met de vorige, met dit verschil dat de werknemer in kwestie zijn activiteiten zelf documenteert. Dit betekent minder werk voor u. Het nadeel is echter dat de mening van de werknemer altijd subjectief is – en duidelijke richtlijnen en een hoge mate van motivatie van de werknemer vereist.

Vragenlijsten

Deze methode is vooral geschikt voor grote bedrijven met veel werknemers. Deel gewoon vragenlijsten uit aan de werknemers of managers van de afzonderlijke afdelingen. Zorg er wel voor dat de vragen duidelijk geformuleerd zijn. Anders kunnen er begripsproblemen en verschillende meningen ontstaan die niet direct besproken kunnen worden. Houd er ook rekening mee dat het analyseren van de vragen waarschijnlijk veel tijd in beslag zal nemen – afhankelijk van hoeveel werknemers aan het onderzoek deelnemen.

Interviews

Deze aanpak is vergelijkbaar met de vorige. Het verschil: u interviewt de werknemers van de verschillende afdelingen rechtstreeks om verschillende standpunten te verkrijgen. Deze methode is ook erg tijdrovend, maar vragen en problemen kunnen direct besproken worden.

Conclusie van de requirementsanalyse

Zorg ervoor dat u de requirements analyse altijd aanpast aan uw eigen bedrijf. Niet elke methode is geschikt voor elk bedrijf. Het is belangrijk om het project van alle kanten te bekijken. Zo ziet u geen eisen over het hoofd en houdt u rekening met alle wensen. Zorg er daarom voor dat u niet alleen rekening houdt met uw eigen wensen, maar ook met de mening van toekomstige gebruikers. Zij zijn tenslotte degenen die dagelijks met de software zullen werken. Als u nog steeds niet zeker weet hoe u het beste te werk kunt gaan, kunt u ook een externe consultant inschakelen. Zij kunnen u op nieuwe perspectieven wijzen en u behoeden voor operationele blindheid.

Wilt u meer weten over behoeftenanalyses of het hele scala aan functies van TimeLine ERP? Stuur ons een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Het opstellen van een vereisten- en functionele specificatie is meestal een van de verplichte taken voor een ERP-implementatie. Toegegeven, het opstellen van deze twee documenten is niet een van de meest populaire taken in een ERP-project. De voorbereiding ervan kost veel tijd en legt beslag op middelen die elders meestal dringender nodig zijn. Tijdsdruk of bezettingsgraad zijn vaak zelfs een reden om ze helemaal niet of slechts heel kort en oppervlakkig op te stellen. De gevolgen van deze aanpak worden vaak pas later in het project duidelijk. U moet het opstellen van een functionele specificatie niet overslaan, vooral niet bij veeleisende ERP-projecten. Het helpt u om de implementatie zo goed mogelijk te plannen en zo de risico’s in het project te minimaliseren – om maar een paar voordelen te noemen. In dit artikel leest u waarom het zinvol is om een functionele specificatie te maken, wat er in moet staan en waar u nog meer op moet letten.</strong

Definitie – Wat is een functionele specificatie?

De eisenspecificatie is een document dat door de aannemer wordt gemaakt. In het geval van een ERP-project is dit altijd de ERP-leverancier. Het is gebaseerd op de specificaties die door de klant, in dit geval de klant of belanghebbende, zijn geformuleerd in de eisenspecificatie. In een functionele specificatie beschrijft de leverancier, meestal in zeer gedetailleerde vorm, hoe hij van plan is om de eisen van de klant te realiseren. Het bevat daarom een concrete beschrijving van de oplossing, evenals een gedetailleerd werkconcept en duidelijk gedefinieerde doeltoestanden die van tevoren gezamenlijk zijn overeengekomen. Dit document definieert ook de technische mogelijkheden, functies en configuraties van het ERP-systeem waarmee deze doelstellingen gerealiseerd kunnen worden. Kortom, het “hoe” en “waarmee” zijn bijzonder belangrijk bij het maken van een functionele specificatie. Het is als het ware de “routekaart” voor een soepele implementatie en vormt een kader voor het hele verloop van het project.

 

Bovendien dient de inhoud van de eisenspecificatie als contractuele basis voor de samenwerking tussen de klant en de ERP-leverancier en heeft het ook een juridisch bindende status. Aan het einde van het project dient het ook als acceptatiecriterium voor de geïmplementeerde ERP-oplossing. Zoals u kunt zien, heeft de eisenspecificatie absoluut bestaansrecht. Steeds weer worden de termen eisen-specificatie en verplichtingen-specificatie door elkaar gebruikt, wat vaak tot misverstanden en verwarring leidt. Vanuit zuiver juridisch oogpunt is het in feite bijzonder belangrijk in welk van de twee documenten iets is vastgelegd. Als één van de twee partijen zich niet houdt aan de eerder overeengekomen inhoud, kunnen de klant en de ERP-leverancier zich te allen tijde beroepen op de schriftelijke afspraken uit de specificaties. In deze context is het belangrijk om te weten dat alle eerder besproken afspraken tussen de klant en ERP-leverancier hun geldigheid verliezen als gevolg van de eisenspecificatie, tenzij anders vermeld in de specificatie.

U bent misschien ook geïnteresseerd in:

Wat zijn de voordelen van een functionele specificatie?

Een functionele specificatie wordt eigenlijk altijd gebruikt als er een klant en een aannemer zijn. Het is vooral nuttig voor zeer uitgebreide projecten. Naast de rechtszekerheid die het beide partijen biedt, heeft het nog drie andere grote voordelen:

Planningszekerheid voor de klant en ERP-leverancier

Dankzij de zeer nauwkeurige documentatie van de doelstatussen en de noodzakelijke werkstappen, zijn zowel de klant als de ERP-leverancier te allen tijde op de hoogte van de planning van het project. Dit zorgt ervoor dat deadlines zoveel mogelijk gehaald worden. Bovendien weten beide partijen wanneer het project naar verwachting voltooid zal zijn en kunnen ze dienovereenkomstig plannen. Maar dat is niet alles – het helpt ook om het budget in de gaten te houden. Elke aanpassing heeft invloed op de kosten en dit voorkomt dat ze uit de hand lopen. De klant weet dus precies wat hij krijgt voor zijn geld en de aannemer kan zijn uitgaven met zekerheid berekenen.

Transparante processen

De gedetailleerde schriftelijke formulering van de oplossingsaanpak maakt het hele proces tot aan de go-live transparant. Alle betrokkenen weten te allen tijde in welk stadium van implementatie ze zich bevinden en welke stappen er nog nodig zijn totdat het project is afgerond.

Minder heronderhandelingen

Eerst en vooral bespaart een goed ontwikkelde specificatie zenuwslopende heronderhandelingen en discussies. Zoals al eerder vermeld, kunnen zowel de klant als de ERP-leverancier op elk moment vertrouwen op de punten die in het document zijn overeengekomen – alles wat niet in de specificatie van vereisten staat, valt niet onder de leveringsomvang. Voor alle latere wijzigingsverzoeken wordt een vervolgverzoek aangemaakt. Latere leveringen, wijzigingen en zogenaamde “scope creep” – een ongecontroleerde toename van projectvereisten tijdens de implementatie – kunnen zo gemakkelijk worden voorkomen.

U bent misschien ook geïnteresseerd in:

Procedure – van eisenspecificatie tot functionele specificatie

In de regel stelt de klant of potentiële klant de specificaties op en als onderdeel van een ERP-workshop bespreken de klant en de potentiële ERP-leverancier welke punten kunnen worden geïmplementeerd en hoe. De potentiële klant en de leverancier nemen samen de afzonderlijke punten door en de leverancier bepaalt of deze in het standaardsysteem zijn opgenomen of dat maatwerk nodig is. De ERP-aanbieder geeft vaak advies over de vereisten die in de specificaties staan. Als een vereiste niet zinvol lijkt of als een extra functie of service in deze context geschikter zou zijn, doet de leverancier meestal een tegenvoorstel. De eisenspecificatie wordt meestal opgesteld nadat de EPP-selectie is afgerond en aan het begin van de implementatiefase. Bij TimeLine worden de specificaties soms tijdens de workshop of kort daarna opgesteld. De punten die met de belanghebbende partij zijn besproken, worden gedocumenteerd en samengevat.

project-team-meeting

In de regel heeft de projectmanager één dag per workshopdag nodig voor vervolgwerk. De eisenspecificatie bepaalt uiteindelijk de kosten, d.w.z. hoe duur het ERP-project uiteindelijk zal zijn. Hoewel het de basis is voor de offerte, betekent het nog niet dat de order wordt geplaatst. Op dit punt kunnen andere aanbieders nog steeds “in het spel” zijn. De potentiële klant kan dan beslissen of de concurrentie misschien een aanbod heeft gedaan dat meer functies biedt of gewoon beter bij het bedrijf past. Voordat de potentiële klant een keuze maakt, kunnen er nog wijzigingen in de specificaties worden aangebracht. Op het moment dat de potentiële klant een ERP-leverancier selecteert, maakt de specificatie deel uit van het koopcontract en kan deze niet meer worden gewijzigd. De potentiële klant bestelt op basis van de specificaties en u gaat een zogenaamde intentieovereenkomst aan.

Wat als de klant toch nog aanpassingen wil doen?

Vooral bij grote projecten ontstaan er vaak ongeplande wijzigingen tijdens de implementatie. Maar als de klant achteraf iets wil wijzigen, verandert ook het koopcontract. Telkens als er een wijziging wordt aangevraagd, beslist de ERP-leverancier of het item in kwestie nog in het budget is opgenomen of niet. Als dit niet het geval is, wordt er een tweede offerte of een vervolgorder aangemaakt. Alles wat verder gaat dan de specificaties is een vervolgorder. Hoewel het uurtarief hetzelfde blijft, staat de klant in een betere onderhandelingspositie als hij vanaf het begin meer diensten bestelt en niet achteraf extra functies bestelt.

Hoe wordt een succesvolle implementatie gemeten?

De licenties worden na de installatie met de klant doorgenomen. Aanpassingen worden niet eenmalig aan het einde van het project gecontroleerd, zoals misschien wordt verondersteld. Het is veeleer een proces dat continu wordt uitgevoerd en gecontroleerd, bijvoorbeeld wekelijks of maandelijks. Dit geeft ook feedback voor beide partijen of u nog steeds op schema ligt.

U bent misschien ook geïnteresseerd in:

Structuur en inhoud – deze punten moeten worden opgenomen in een specificatie van vereisten

Een specificatieblad wordt op veel verschillende gebieden gebruikt, dus standaardisatie is eenvoudigweg niet mogelijk. Er is geen regelgeving of wettelijke norm die beschrijft welke inhoud een functionele specificatie moet hebben, welke structuren gevolgd moeten worden of hoe een functionele specificatie er in het algemeen uit moet zien. Er zijn echter verschillende benaderingen – de volgende structuur heeft zich bewezen bij softwareontwikkeling

Inleiding

Het is altijd raadzaam om de belangrijkste kerngegevens voor een ERP-project samen te vatten. Zorg ervoor dat alle betrokken personen expliciet worden genoemd en dat het project kort wordt beschreven. De communicatiekanalen moeten hier ook vermeld worden.

  • Wie is betrokken bij het project?
    • Aannemer en opdrachtgever,
    • Stakeholders,
    • Projectteam,
    • Contactpersoon voor vragen of problemen
  • Zijn de communicatiekanalen vermeld?
  • Waar gaat het project over?
  • Hoe moet het eindresultaat eruit zien?
    • Beschrijving van de mijlpalen,
    • Kadervoorwaarden
      • Bepaling van deadlines (voltooiing, acceptatie, implementatie)
  • Indien nodig, speciale kenmerken van het project

Doelstellingen en niet-doelstellingen van het project

Het zou duidelijk moeten zijn dat de doelstelling van het project vermeld moet worden. Er zijn echter vaak punten in een ERP-implementatie die op de een of andere manier aan de rand van het project “gedokt” zijn. Daarom kan het nuttig zijn om naast de projectdoelen ook de niet-doelen te definiëren. Als expliciet wordt vastgelegd welke gebieden deel uitmaken van het project en welke niet, kunnen discussies gemakkelijk worden vermeden. Door niet-doelen te formuleren, worden de grenzen van het project duidelijker en het “grijze gebied” kleiner. Op deze manier krijgt u snel duidelijkheid over wat “in scope” is en wat “out of scope” is in een project.

  • Wat gaat het project behandelen?
  • Wat gaat het project expliciet niet behandelen?
  • Welke problemen lost het project op?

 

Toepassingsgebied en productomgeving

Het toekomstige toepassingsgebied en de omgeving van het product moeten ook worden gespecificeerd in de specificatie van eisen. Dit omvat de doelgroep, toepassingsgebieden, bedrijfsprocessen die beïnvloed worden en de bedrijfsomstandigheden.

Functies

Zorg er ook voor dat alle functies en use cases in detail worden beschreven.

  • Hoe en onder welke omstandigheden wordt de functie uitgevoerd?
  • Welke invloed heeft dit op de andere bedrijfsprocessen?

Services

De services beschrijven de vereisten die u hebt voor een specifieke functie. Hieronder valt bijvoorbeeld de uitvoeringstijd of de nauwkeurigheid van een berekening. Zorg ervoor dat alle services worden vermeld.

Kwaliteitseisen

De kwaliteitseisen moeten ook worden samengevat:

  • Wat zijn uw kwaliteitseisen?
  • Hoe zien kwaliteitsborging, kwaliteitscontrole en kwaliteitsacceptatie eruit?

Om dit nog preciezer te specificeren, is het zinvol om een kwaliteitsniveau toe te kennen aan bepaalde kenmerken, zoals

  • Veranderlijkheid = niet relevant
  • Efficiëntie = goed

Gebruikersinterface

Basisvereisten voor het type lay-out, dialoogstructuur of toegangsrechten moeten hier worden vermeld.

Projectteamvergadering

Andere en speciale vereisten

Hieronder vallen bijvoorbeeld documentatie, boekhouding of beveiligingsvereisten zoals wachtwoordbeveiliging.

Technische vereisten

De technische apparatuur die nodig is voor de implementatie moet hier worden vermeld. Het is zinvol om een lijst te maken van de software- en hardwaresystemen die voor de toepassing geïnstalleerd moeten worden. Dit is onder andere belangrijk om de beschikbaarheid van de netwerkverbinding te garanderen.

  • Welke apparatuur hebt u nodig voor welke taak?

Interfaces

Alle bestaande systemen en producten en interfaces moeten hier worden vastgelegd. Dit is belangrijk om het product aan alle andere toepassingen te kunnen koppelen. Zijn er misschien al projectgerelateerde systemen en/of producten die niet meer door de aannemer geïmplementeerd hoeven te worden?

Probleemanalyse

De belangrijkste problemen en misschien ook de te verwachten problemen moeten hier samengevat worden. Voor de meest waarschijnlijke problemen moet een oplossingsrichting beschikbaar zijn.

Projectontwikkeling

Hier moet zo nauwkeurig mogelijk beschreven worden welke stappen op welk moment gepland zijn en hoe het hele project georganiseerd is.

Testen en acceptatievoorwaarden

Tests controleren het product voor voltooiing op functies, eigenschappen en kwaliteitskenmerken. Na een foutloze uitvoering kan het product compleet worden verklaard.

    • Aan welke voorwaarden moet worden voldaan?

Dit is slechts één voorbeeld van hoe een specificatieblad eruit kan zien. Sommige criteria zijn essentieel, andere zijn belangrijk maar niet doorslaggevend. Weer andere zijn wenselijk, maar u kunt ook zonder. Welke eigenschappen een “must have” of “nice to have” zijn, verschilt van bedrijf tot bedrijf. Zorg er gewoon voor dat ze duidelijk als zodanig herkenbaar zijn. De afzonderlijke punten kunnen in verschillende mate van detail worden beschreven, maar vooral de technische vereisten moeten zeer gedetailleerd worden beschreven. Uiteindelijk is het belangrijk dat de eisen uit de specificaties consistent zijn met de verklaringen in de eisenspecificatie en dat er geen ruimte is voor interpretatie. De eisenspecificatie moet goed beschreven en gedocumenteerd zijn, weinig ruimte overlaten voor interpretatie, specifiek zijn en een noodzakelijke kostenraming bevatten. Als vuistregel geldt dat er geen vragen onbeantwoord mogen blijven en dat een buitenstaander moet begrijpen wat er bedoeld wordt.

U bent misschien ook geïnteresseerd in:

Waar moet u nog meer op letten?

Vanuit het oogpunt van de klant moet u allereerst de tijd nemen om de specificaties zorgvuldig te bekijken en ze niet zomaar ongelezen door te wuiven. Concentreer u vooral op de interpretatie van uw eisen en controleer of ze volgens uw wensen zijn geïmplementeerd – eenvoudig, maar het kan u later een hoop problemen besparen. Bovendien bestaat altijd het risico dat u bij het opstellen van de vereisten en functionele specificaties de huidige situatie in het bedrijf vergeet. Dit betekent dat u de kans mist om het verbeteringspotentieel te realiseren door het nieuwe systeem te introduceren. Zie het ERP-project als een kans om uw workflows en bedrijfsprocessen kritisch onder de loep te nemen – zo kunt u het potentieel beter benutten.

Bijeenkomst van een projectteam

Vanuit het oogpunt van de ERP-leverancier is het zinvol om wat tijd te investeren in de uitwerking, om tot in detail af te stemmen met de klant en om niets onopgelost te laten. Als er vragen onbeantwoord blijven, als u op zoek bent naar een antwoord en als er knelpunten zijn, verduidelijk dit dan onmiddellijk met de klant. Het is cruciaal om zo nauwkeurig en gedetailleerd mogelijk te zijn bij het opstellen van het rapport. Het is ook raadzaam om begrijpelijke taal te gebruiken en, indien mogelijk, het gebruik van technische termen te vermijden. Veel verschillende mensen lezen de specificaties – en niet iedereen heeft een diepgaande technische kennis. Grafische voorstellingen zijn ook een goede manier om complexe inhoud op een begrijpelijke manier over te brengen. Werk met diagrammen, tabellen of mindmaps om de wensen van de klant te visualiseren en zo begrijpelijk mogelijk te maken.

Conclusie

Het maken van een eisenspecificatie is een noodzakelijke stap om de risico’s in een ERP-project te minimaliseren. Aan de ene kant dient het om te voldoen aan de eisen die in de specificaties staan en om de implementatie zo goed mogelijk te plannen, zodat er aan het eind geen onaangename verrassingen zijn. Aan de andere kant helpt het om de geïmplementeerde oplossing aan het einde van het project te valideren en beide partijen te beschermen. Het is vooral belangrijk om het verschil te weten tussen specificaties en functionele specificaties. Juridisch gezien maakt het een groot verschil in welk van de twee documenten iets gedefinieerd is.

Als u meer wilt weten over eisen-analyses, specificaties en functionele specificaties of het hele scala aan TimeLine ERP functies, stuur ons dan een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

De invoering van een ERP-systeem is vaak een lang en complex proces dat veel afzonderlijke stappen omvat. Het kan enkele maanden duren voordat het systeem in uw dagelijkse bedrijf is geïntegreerd – afhankelijk van de complexiteit van de vereisten en het aantal werknemers. Een project als dit kost tijd, middelen en waarschijnlijk een paar zenuwen. Maar voordat u de handdoek in de ring gooit, geldt voor de invoering van een ERP-systeem hetzelfde als voor elk ander project: planning is alles. Het succes van een ERP-project hangt zelden af van de technologie. Maar wat zorgt ervoor dat het mislukt? Het zijn eerder slecht gedefinieerde doelen, onduidelijke processtructuren of zelfs de afwijzing van werknemers. Wat u dus nodig hebt, is een goede voorbereiding en een projectteam dat vanaf het begin samenwerkt. Hieronder vindt u een overzicht van het ERP-implementatieproces – en waar u nog meer op moet letten om van uw project een succes te maken.</strong

De ERP-implementatie voorbereiden en analyseren

Voordat u begint met het onderzoeken van geschikte ERP-aanbieders, moet u zich afvragen of u klaar bent voor een ERP-systeem. Bijvoorbeeld, zelfs de beste software kan een gebrek aan basis niet compenseren. Als klein of middelgroot bedrijf hebt u vaak ook beperkte middelen. U moet daarom niet laks zijn in uw eerste overwegingen. Een belangrijke factor is bijvoorbeeld gecentraliseerd gegevensbeheer in uw bedrijf. Uw gegevens moeten up-to-date zijn en uw processen moeten regelmatig gedocumenteerd worden. Wat wilt u bereiken met de invoering van een ERP-systeem? Wat moet het systeem kunnen? Fundamentele vragen die veel bedrijven vaak licht opvatten. Zodra u de essentiële zaken hebt opgehelderd, hebt u de basis voor uw ERP-project gelegd.

Behoefteanalyse en specificaties

Het volgende op uw lijst is het uitvoeren van een eisenanalyse. Hier moet u proberen zo open mogelijk te zijn. Om nieuwe perspectieven te krijgen, kan het nuttig zijn om externe deskundigen in te schakelen – zo kunt u uw bedrijf vaak door andere ogen bekijken. Het kan ook nuttig zijn om uw werknemers bij het proces te betrekken. Zij zijn tenslotte degenen die later met de ERP-software zullen werken. De beste manier om dit te doen is met een rondleiding door het bedrijf en een persoonlijk gesprek. Een goede manier om uw bedrijfsdoelstellingen en de vereisten voor het ERP-systeem vast te leggen is een specificatieblad. Dit document is de basis voor de verdere ERP-selectie. Er wordt onderscheid gemaakt tussen technische en functionele vereisten. Probeer uw verwachtingen echter oplossingsneutraal te formuleren en laat de implementatie gewoon over aan uw toekomstige ERP-leverancier.

einführung-erp-system

Naast de vereisten voor het ERP-systeem moet het document ook een beschrijving van uw bedrijf en de marktomgeving bevatten. Informatie over uw producten, diensten, sterke punten en huidige IT-infrastructuur zijn ook nuttige toevoegingen. Een tijdschema en een contactpersoon zijn ook belangrijk. Neem de tijd om dit te formuleren, aangezien aanpassingen achteraf meestal duur zijn.

Projectmanager en hoofdgebruiker

Naast het uitvoeren van een behoefteanalyse en het maken van een specificatieblad, is het projectteam minstens zo belangrijk bij de introductie van een ERP-systeem. U hebt een projectmanager en een sleutelgebruiker nodig. Bij het selecteren van uw werknemers moet u hun karaktereigenschappen niet verwaarlozen. De projectmanager moet bijvoorbeeld assertief maar ook emphatisch zijn. Oog hebben voor het grote geheel en dicht bij de dagelijkse gang van zaken blijven. Key users vertegenwoordigen daarentegen de belangen van uw werknemers. Zij bemiddelen, fungeren als mentor en wijzen op de voordelen en veranderingen die voortvloeien uit de invoering van een ERP-systeem. Zij proberen op een gevoelige manier angsten en bedenkingen weg te nemen en zijn degenen die het personeel trainen in het systeem. Uw key user moet zoveel mogelijk ervaring en expertise hebben. Wees u ervan bewust dat beide functies veel tijd in beslag nemen. Tijd waarin de normale dagelijkse taken verdeeld moeten worden over andere werknemers.

Van de longlist naar de shortlist

De juiste ERP-aanbieder vinden is niet zo eenvoudig. Maar omdat u de komende jaren met hen zult werken, moet u de keuze niet licht opvatten. Er is echter een goede manier om uw zoektocht wat gemakkelijker te maken. Begin uw zoektocht door onderzoek te doen op het internet en een checklist bij te houden. Vat in een document ruwweg samen welke aanbieders over het algemeen in aanmerking komen. Deze zogenaamde longlijst geeft u een eerste overzicht. Houd altijd rekening met zowel de technische als de functionele eisen: Zijn er bijvoorbeeld vereiste interfaces met andere systemen? Zodra u alle providers hebt verzameld, stuurt u hen de specificaties die u eerder hebt opgesteld. Observeer nu hoe de providers op uw aanvraag reageren. Hoe lang moet u wachten op een antwoord? Is de e-mail een standaardtekst of krijgt u een persoonlijk antwoord? Op deze manier kunt u andere ERP-aanbieders eruit filteren.

erp-einführung-projektteam

De overgebleven kandidaten vormen uw shortlist en u moet met hen een afspraak maken voor een korte presentatie. Hier kunt u uw huidige situatie presenteren en eventuele vragen toelichten. Daarna volgt een ERP workshop. Een presentatie op maat. De leverancier kan de functies die u nodig hebt in hun eigen systeem demonstreren – met behulp van voorbeeldgegevens of een kleine selectie van uw originele gegevens. Dit geeft u een idee van hoe het ERP-systeem in uw bedrijf zou passen. Het hele projectteam moet bij de workshop aanwezig zijn. Let ook op het persoonlijke vlak, ze moeten tenslotte goed met elkaar overweg kunnen. Na de workshop kan de leverancier u precies vertellen wat u qua prijs kunt verwachten. Vooraf kunnen alleen de licentiekosten worden genoemd.

Invoering van een ERP-systeem – de implementatiefase

Zodra u een geschikte ERP-aanbieder hebt gekozen, kan de implementatie beginnen. In een specificatieblad zal uw leverancier u laten zien hoe zij uw vereisten willen implementeren. De termen specificatie en eisen-specificatie worden vaak door elkaar gebruikt, maar het zijn twee verschillende documenten. Neem de eisenspecificatie zorgvuldig door, want deze vormt de basis van uw ERP-implementatie. Zo kunt u aanpassingen zoveel mogelijk vermijden naarmate het project vordert. Vervolgens wordt het systeem geïnstalleerd met demodata, set-up en maatwerk. Tot slot hoeft u alleen nog maar uw gegevens over te dragen. De opleiding van het personeel wordt meestal verzorgd door uw hoofdgebruiker. En dan is het klaar! Het systeem gaat live.

Checklist – Bent u klaar voor de invoering van een ERP-systeem?

  • Is er een actuele, gecentraliseerde database beschikbaar?
  • Is het projectteam beschikbaar?
  • Worden de bedrijfsprocessen regelmatig en consistent in het systeem ingevoerd?
  • Is de uitwisseling van informatie geregeld op basis van processen?

Samenvatting van de ERP-implementatie

Een korte samenvatting van de afzonderlijke stappen voor een beter overzicht:

  • Het uitvoeren van een behoeftenanalyse
  • Opstellen van een eisenspecificatie
  • Samenstellen van een projectteam
  • Opstellen van een lange en korte lijst
  • Het houden van een ERP-workshop
  • Het maken van de ERP-selectie
  • Specificaties laten opstellen
  • Installatie van de ERP-software
  • Gegevensoverdracht
  • Aanpassing & rapportage
  • Echte werking (dagelijkse werkzaamheden)

In het volgende artikel leest u welke factoren uw ERP-project zullen helpen slagen en wat u moet vermijden. Wilt u meer weten over ERP-implementatie of het volledige aanbod van TimeLine ERP-functies? Stuur ons een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!

Een nieuw ERP-systeem kan veel positieve effecten hebben op uw bedrijf. Het beïnvloedt bedrijfsprocessen en interne workflows. Als het correct gebruikt wordt, vereenvoudigt het de dagelijkse taken, biedt het structuur en verbetert het de communicatie. Het bedrijf wordt transparanter en daardoor toekomstbestendiger. In het vorige artikel werd stap voor stap beschreven hoe u een ERP-systeem in uw bedrijf kunt introduceren – van planning tot selectie en implementatie. In dit artikel leert u hoe u ERP-beheer kunt organiseren om ervoor te zorgen dat uw investering vruchten afwerpt. Er zijn enkele succesfactoren – en ook fouten die u moet vermijden.

Succesfactoren worden gedefinieerd als “beïnvloedende variabelen en omstandigheden die het succes of falen van een ondernemersactiviteit bepalen”. Kritische succesfactoren zijn factoren “van bijzonder groot belang” (Dömer 1998). Als deze factoren goed zijn, zal uw ERP-project ook succesvol zijn. Er zijn ongetwijfeld talloze factoren die het succes of falen van een project beïnvloeden.

erp-management-succesfactoren

Zijn er bedrijfsbrede randvoorwaarden van kracht?

Hoe organiseert u ERP-beheer? Ten eerste is het belangrijk om van tevoren de randvoorwaarden voor uw project te definiëren – deze omvatten doelstellingen, middelen en kosten. U moet deze tijdens het project altijd in de gaten houden. Dit houdt ook in dat u de voortgang van het project regelmatig moet documenteren en communiceren. Naast het selecteren van uw projectteam, is ook de rolverdeling binnen het team zelf belangrijk – om het project soepel te laten verlopen. Functies en taken moeten duidelijk worden toegewezen. De uitdaging hierbij is dat het project niet alleen maar extra werk moet worden. Probeer de leden van het project zoveel mogelijk vrij te maken van hun lijnactiviteiten. Er zullen waarschijnlijk nog steeds momenten zijn dat de dagen op kantoor langer worden. Kleine gebaren van erkenning kunnen helpen om voor nieuwe motivatie te zorgen.

Veranderingsbeheer: een van de belangrijkste succesfactoren

Het belangrijkste aspect om van de nieuwe ERP-oplossing een succes te maken, zijn waarschijnlijk uw werknemers. Effectief verandermanagement is een van de belangrijkste succesfactoren van een ERP-project. Zelfs het beste ERP-systeem heeft geen toegevoegde waarde voor een bedrijf als uw werknemers zich ertegen verzetten. Om dit te voorkomen, moet u het volledig geïmplementeerde systeem niet aan de werknemers voorleggen. Haal uw werknemers zo vroeg mogelijk aan boord – op die manier kunt u ze snel enthousiast maken voor de nieuwe oplossing. Het is het beste om de aankomende veranderingen aan te kondigen zodra besloten is om het nieuwe systeem in te voeren. Maar wat is de beste manier om dit te doen?

Goed ERP-beheer: ERP-succes is teamwerk

Kondig de transformatie stap voor stap aan. En bij voorkeur persoonlijk, niet per rondschrijvende e-mail. Dit geeft uw werknemers de tijd om aan het idee te wennen en zich niet overweldigd te voelen. De beste methode is om uw plannen en zorgen openlijk te communiceren – zo voorkomt u ook geruchten en creëert u transparantie. Dit omvat bijvoorbeeld de betrokken mensen, een tijdlijn en ook wat er in de toekomst zal veranderen. Als u een ERP-manager of consultant wilt inschakelen, stel deze dan voor aan uw werknemers. Een personeelsvergadering biedt bijvoorbeeld een goed platform. Op deze manier zijn alle werknemers aanwezig en hebben ze dezelfde informatie. Vragen kunnen direct gesteld en beantwoord worden. Verder moet u de ERP implementatie niet presenteren als een puur IT-project. Anders zou het snel de indruk kunnen wekken dat het slechts een technische omschakeling is.

Wat te doen als werknemers het ERP-systeem afwijzen

Als uw werknemers het nieuwe ERP-systeem afwijzen, zit daar zelden kwade opzet achter. Het is eerder de angst voor nieuwe of veranderde operationele en organisatorische processen die op de voorgrond treedt: processen worden transparanter, fouten worden sneller opgespoord en de angst voor een vermeende bedieningsfout neemt toe. Deze angst is niet geheel ongegrond, want een modern ERP-systeem brengt processen automatisch in kaart op basis van correcte gegevens – en dat is precies wat het zo effectief maakt. Het is daarom belangrijk dat u de angst van uw werknemers serieus neemt en niet negeert. Wijs op de voordelen van de nieuwe ERP-oplossing en de positieve effecten die de omschakeling op het hele bedrijf zal hebben. Maak duidelijk dat dit een toekomstgericht project is: de ERP-software stelt banen veilig en biedt nieuwe mogelijkheden om bij te dragen aan het bedrijf.

Stel effectieve doelen – dankzij ERP-beheer

Zodra u het personeel aan uw kant hebt, is het tijd om doelen te formuleren. U kunt alleen succesvol zijn als u doelen hebt. Onduidelijke doelen en onnauwkeurige eisen zijn een van de meest voorkomende redenen waarom projecten mislukken – gevolgd door een gebrek aan middelen en een te klein projectbudget.

“Verbeter structuren en processen”

Dit kan een doel zijn, maar het is niet goed geformuleerd. Welke structuren? Welke processen? Hoe moeten ze precies verbeterd worden? Binnen welk tijdsbestek? En hoe weet u wanneer het doel bereikt is? Als u zo’n doel aan het begin van een project definieert, is de kans groot dat het resultaat teleurstellend is. Vooral als er meerdere partijen bij betrokken zijn, is er veel ruimte voor interpretatie.

Succesfactoren voor een vlekkeloze ERP-implementatie. Zakenman vliegt de lucht in bij een brandende gloeilamp.

Maak uw doelen SMART – met de hulp van ERP-beheer

Een duidelijke formulering van doelen is daarom bijzonder belangrijk. De SMART-methode bestaat uit vijf criteria. Slimme doelen moeten

  • Specifiek
  • Meetbaar
  • geAccepteerd
  • Realistisch
  • geTimed

worden. Wat dit in detail betekent, wordt hieronder beschreven.

Specifiek

Specifieke doelstellingen zijn belangrijk zodat alle betrokkenen hetzelfde idee hebben van wat het project moet bereiken – en er geen ruimte is voor interpretatie. Deze vijf vragen zullen u helpen om ze te formuleren:

  • Wat wilt u precies bereiken?
  • Waaromis dit belangrijk?
  • Wie is hierbij betrokken?
  • Wanneer wilt u resultaat hebben?
  • Hoe wilt u te werk gaan?

Meetbaar

Definieer criteria aan de hand waarvan u kunt meten of u de doelen hebt bereikt. Dit kunnen concrete cijfers of gegevens zijn. Zo kunt u de voortgang beoordelen – maar ook tegenmaatregelen nemen als u te ver afdwaalt van de gedefinieerde doelen.

  • Hoe kan de verwezenlijking van de doelstellingen worden gemeten?
  • Wanneer weet ik dat ik het doel heb bereikt?

Geccepteerd

Stel u voor dat u aan een doel moet werken dat niet haalbaar is. Zorg ervoor dat uw doelen uitdagend maar haalbaar zijn. Anders zal uw motivatie snel afnemen.

  • Is het doel motiverend en geaccepteerd door alle betrokkenen?
  • Is het haalbaar door het project?

Realistisch

Realistische doelen zijn nauw verbonden met acceptatie. Als doelen realistisch zijn, worden ze meestal geaccepteerd. Als doelen onrealistisch geformuleerd zijn, hebben mensen de neiging om ze te negeren. Hierbij is het ook belangrijk of het bereiken van het doel beïnvloed kan worden.

  • Heeft u de benodigde middelen?
  • Is het tijdsbestek voldoende?

Geplande

Duidelijke deadlines zijn belangrijk voor uw team. Taken zonder deadline worden vaak niet op tijd gerealiseerd. Maar niet alle doelen hoeven gepland te worden. Er zijn bijvoorbeeld financiële doelen die ongeacht een specifieke datum moeten worden bereikt.

    • Voor wanneer moet het doel bereikt zijn?
    • Is het doel haalbaar binnen de looptijd van het project?

Zodra u uw doelen hebt gevonden en vastgelegd, bent u al een grote stap verder. Nu is het tijd om ze in de gaten te houden en ervoor te zorgen dat u niet van het pad afwijkt. Het succes van een ERP-implementatie hangt niet af van de technologie – het zijn de mensen die met het ERP-systeem werken. Daarom draait geen van de genoemde succesfactoren om de software zelf.

Wilt u meer weten over ERP-implementatie, ERP-beheer of het hele scala aan TimeLine ERP-functies? Stuur ons een bericht via het contactformulier, schrijf naar [email protected] of neem contact op met ons verkoopteam op +31 46 234 00 99. We horen graag van u en adviseren u graag!