Watervalmethode of agile ERP-implementatie?
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!
-