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.

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!

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.

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 herken ik als gebruiker een goed ERP-systeem?
• Proces van een succesvolle ERP-implementatie
• 3 tekenen dat het tijd is voor een ERP-verandering

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.

    

    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!

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.

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.

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.

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.

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!