Watervalmethode of wendbare ERP-implementatie?

De invoering van ERP-software vergt meestal veel middelen en de benodigde tijd is vaak enorm – dit is niets nieuws. Maar dit is ook niet verwonderlijk als je bedenkt hoe sterk het systeem verweven is met je eigen processen. Door het project ruim van tevoren te organiseren wordt ieders werk gemakkelijker en worden kostbare aanpassingen achteraf voorkomen. Dit houdt ook in dat er een procedure moet worden vastgesteld voor de integratie van de nieuwe software. Dus nog voor het eigenlijke project begint, moeten de klant en de ERP-provider zich afvragen welke aanpak het snelst en efficiëntst de introductie kan implementeren. Er zijn twee zeer contrasterende modellen die een grote populariteit blijven genieten – de watervalmethode en de wendbaarheid.

Volgens het motto “oude bezems goed vegen” vertrouwen de meeste bedrijven op de klassieke en beproefde watervalmethode. Hoewel steeds meer klanten ook geïnteresseerd zijn in agile ontwikkelmethodes, durven slechts enkelen ook het nieuwe ERP-systeem volgens dit concept te introduceren. Veel verantwoordelijken zijn nog steeds sceptisch en zijn niet bereid om een deel van hun controle op te geven. Nu kunnen er vragen rijzen: Wat is precies het verschil tussen de twee benaderingen? Welke is beter geschikt voor mijn bedrijf? Deze post is bedoeld om u een overzicht te geven van de twee methoden en hun voor- en nadelen, waardoor de beslissing hopelijk wat gemakkelijker wordt.

De klassieke aanpak – De watervalmethode

Meestal verloopt een ERP-implementatie volgens de klassieke watervalmethode. Vooral in de softwaresector was dit lange tijd standaard. De eerste formele beschrijving van dit model wordt toegeschreven aan Winston W. Royce. In zijn artikel “Managing the Development of large Software Systems”, gepubliceerd in 1970, gebruikt hij niet de term “waterval”, maar zelfs toen maakte hij duidelijk dat deze methode uitbreidbaar was en niet geschikt voor elk project. De watervalmethode wordt gekenmerkt door een strikt lineair projectverloop. In het begin wordt de koers bepaald door het project in verschillende fasen op te delen. Deze worden dan consequent achter elkaar en in een vooraf bepaalde volgorde doorgewerkt. Na afloop van een fase controleren de klant en de aanbieder de resultaten en geven deze vervolgens vrij. Elke voltooide fase start een nieuwe en wordt als onveranderlijk beschouwd; latere wijzigingen zijn meestal niet voorzien. Beslissingen kunnen en mogen niet worden teruggedraaid.

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

  • Analyse van de behoeften – Bepaling van de geplande functies.
  • Conceptie – ontwikkeling van de software-architectuur
  • Implementatie – Ontwikkeling en integratie van de software
  • Integratietesten – zoeken naar en elimineren van fouten
  • Uitrol – ingebruikname van het systeem
  • Ondersteuning – Ervoor zorgen dat de klant geen problemen heeft met het product

De bedrijfsdoelstellingen en eisen van de klant voor het ERP-systeem worden vastgelegd in een requirementspecificatie, en hoe deze moeten worden geïmplementeerd wordt gedefinieerd in de functionele specificatie. De concrete uitvoering varieert van aanbieder tot aanbieder.

Sterke punten van de Watervalmethode

De watervalmethode is nog steeds erg populair. Niet zonder reden, want het biedt vooral duidelijke en overzichtelijke structuren, wat voor sommige ondernemers een hoge prioriteit heeft. De invoering van ERP-software is in de eerste plaats een grote verandering, planning en structuur geven een beetje meer zekerheid in deze tijd en zijn daarom welkom. Uiterlijk na de voorbereidingsfase is het voor alle projectdeelnemers duidelijk welke stappen tot aan de daadwerkelijke start in detail zullen worden genomen, op welk moment van de uitvoering men zich bevindt en wat er nog moet gebeuren. De planning en berekening van het budget en de tijd, vooral voor zeer omvangrijke projecten, is natuurlijk zeer nauwkeurig.

Zwakke punten van de Watervalmethode

De watervalmethode draagt echter ook enkele niet te onderschatten risico’s, vooral in het geval van lastige en verwarrende ERP-implementaties. Ironisch genoeg leidt de strikt lineaire aanpak vaak tot verlies van controle. De conceptuele inspanning die met deze methode gepaard gaat, is meestal zeer hoog, omdat de afzonderlijke stappen tot in detail moeten worden gepland. Omdat de afzonderlijke fasen strikt van elkaar gescheiden zijn, is men sterk gebonden aan de vooraf gedefinieerde processen. Dit maakt het vrij rigide en inflexibel, parallel werk is nauwelijks of niet mogelijk.

De grootste zwakte is dat tekortkomingen of misvattingen die aan het begin van de ontwerpfase zijn ontstaan, pas in grote getale aan het eind van de uitvoering, of nog ongunstiger – tijdens de functionele tests – aan het licht komen. Het is ook mogelijk dat een use case tijdens de ontwerpfase volledig wordt vergeten. Natuurlijk wordt hier dan geen rekening mee gehouden door het ERP-systeem. In beide situaties leidt dit tot ongeplande en vooral kostenintensieve extra werkzaamheden. Aan de andere kant kan het ook gebeuren dat de aanbieder door een gebrek aan communicatie onnodige functies implementeert, die uiteindelijk nooit in de praktijk worden gebruikt. In het algemeen is de beperkte communicatie in deze methode vaak een reden voor misverstanden, omdat de klant en de ERP-provider 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 ten koste van alles moet worden vermeden.

Wendbare ontwikkelingsmethoden

Als antwoord op de zwakke punten van de watervalmethode zijn wendbare methoden ontwikkeld. Een van de eerste varianten van deze methode was Scrum. Scrum is een procesmodel van project- en productmanagement, vooral voor agile software engineering. De oorsprong van deze aanpak gaat terug op het Harvard Business Review artikel “The New Product Development Game” uit 1986. Takeuchi en Nonaka benadrukken daarin onder andere het belang van zelfgeorganiseerde teams gedurende het hele ontwikkelingsproces. Deze aanpak, die nog vrij nieuw is, wordt vandaag de dag vooral gebruikt in de softwareontwikkeling, maar wordt ook op vele andere gebieden toegepast.

Volgens de methode worden taken niet volgens een lineair plan uitgevoerd, maar in korte uitvoeringscycli, de zogenaamde sprints. Aan het begin van elke sprint worden doelen gesteld. In het verdere verloop van elke cyclus implementeert het projectteam een werkpakket, meestal een functionele eis. Dit wordt vervolgens getest, zodat aan het einde van elke cyclus een uitvoerbaar, representatief subsysteem ontstaat. Dit geeft de klant de mogelijkheid om op elk gewenst moment feedback te geven. Idealiter duurt een cyclus tussen twee en vier weken. Bij elke volgende cyclus proberen het projectteam en de gebruiker de eisen te verbeteren en geleidelijk aan een optimale oplossing te benaderen. Deze aanpak biedt veel ruimte voor interacties, aanpassingen en updates. Dit is vooral nuttig als de klant zijn eisen voor de software verandert of als er andere uitdagingen ontstaan in de loop van de implementatie.

De wendbaarheid ziet er zo uit:

  • Sprint 1 (ontwerp, implementatie, testen, documentatie, evaluatie).
    • Sprint 2 (ontwerp, uitvoering, testen, documentatie, evaluatie)
      • Sprint 3 (ontwerp, uitvoering, testen, documentatie, evaluatie)

Afzonderlijke stappen vloeien in elkaar over en vinden soms parallel plaats.

Sterke punten van de wendbare aanpak

Een groot voordeel van de wendbare 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 de afzonderlijke onderdelen van het systeem al in een vroeg stadium in actie, aangezien, zoals reeds vermeld, na elke cyclus een uitvoerbaar subsysteem wordt gecreëerd. Hierdoor kan de software tijdens de implementatiefase op gang worden gebracht.

Fouten in het ontwerp komen snel aan het licht en de klant ziet ook snel of de software al dan niet voldoet aan zijn werkelijke ideeën en eisen. Misverstanden kunnen ook veel gemakkelijker worden voorkomen. Het projectteam kan de feedback van de klant direct implementeren en de nieuwe inzichten gebruiken om de procedure bij te sturen als dat nodig is. Bovenal voorkomt de agile aanpak dat het project eindigt in een dure aanpassingsmarathon. Daarnaast neemt de acceptatie door de gebruikers toe, omdat de medewerkers het project kunnen beïnvloeden door voortdurende deelname en zich zo sterker identificeren met het systeem.

Zwakke punten van de wendbare aanpak

Hoewel deze methode meer voordelen dan nadelen heeft, is ze toch niet voor elk bedrijf geschikt. Om een ERP-implementatie op een agile manier te implementeren, moet het management enige controle opgeven, omdat de agile aanpak niet gericht is op vaste projectplannen en planningen. Bovendien gaat er altijd wat planningszekerheid verloren, want je kunt nooit van tevoren precies zeggen wanneer welke functie klaar en gebruiksklaar is, en welk resultaat je kunt verwachten.

Wendbare 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 op het gebied van ERP
  • Lineaire aanpak
  • Het project is opgedeeld in afzonderlijke fasen, die na elkaar worden verwerkt.
  • De projectresultaten worden aan het eind gepresenteerd
  • Het proces en het concept van het project worden aan het begin gedefinieerd en worden meestal niet gewijzigd.
  • Eenmaal voltooid, worden de fasen niet meer gewijzigd
  • Het aanbod van diensten is bekend, het toepassingsgebied is duidelijk afgebakend
  • De klant heeft duidelijke eisen die niet of nauwelijks veranderen.
  • Het project heeft een vrij korte looptijd
  • De klant wil slechts in geringe mate geïntegreerd zijn in het proces

Voordelen

  • Hoge planningsbetrouwbaarheid
  • Het budget, de huidige status en de volgende stappen tot aan de livestart zijn te allen tijde bekend.
  • Het geplande tijdsbestek kan gemakkelijker worden aangehouden dankzij duidelijke en geordende structuren.

Nadelen

  • Relatief rigide en inflexibel ten opzichte van veranderingen
  • Vaak kostbare aanpassingen nodig, omdat fouten uit de ontwerpfase pas op het einde aan het licht komen.
  • Hoge conceptie-inspanning
  • Afzonderlijke stappen moeten tot in detail worden gepland

Wendbare 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 rigide, maar worden in de loop van het project verder ontwikkeld.
  • Gedeeltelijke resultaten worden aangepast op basis van de feedback van de gebruiker
  • Het scala aan diensten is vrij onbekend, de reikwijdtevariabele
  • Het project heeft een vrij lange looptijd
  • De 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 bij deze methode centraal
  • Gezamenlijk leerproces
  • Nauwe samenwerking tussen klant en ERP-provider
  • Minder vertragingen en herbewerking
  • Ontwerpfouten worden sneller opgemerkt, omdat de tests na elke cyclus worden uitgevoerd.
  • De acceptatie door de gebruiker neemt toe omdat de medewerkers voortdurend betrokken zijn bij het project en invloed kunnen uitoefenen op de processen.

Nadelen

  • Verantwoordelijke partijen moeten een deel van de controle afstaan
  • De planningsbetrouwbaarheid gaat enigszins verloren, omdat het nooit helemaal duidelijk is wanneer welke functie klaar is.

Welke methode is de beste keuze voor mijn eisen?

Welke methode voor u en uw bedrijf het beste is, hangt af van vele factoren 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 de veiligheid van de planning, de controle en de geordende structuren prioriteit hebben. Klanten die graag een overzicht hebben van de workflows en processen in het bedrijf, kiezen eerder voor deze methode. Vaak zijn dit projecten met constante eisen. Projecten met veel onvoorspelbare factoren die flexibele aanpassingen vereisen, zijn eerder ongeschikt voor deze methode.

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

  • Zijn de doelen op voorhand duidelijk definieerbaar?
  • Heeft de klant precieze ideeën?
  • Heeft het projectteam behoefte aan een duidelijke managementstructuur?
  • Is er een deadline of zijn er duidelijk omschreven mijlpalen?
  • Is het budget stevig vastgelegd?
  • Worden er in de loop van het project geen grote veranderingen verwacht?

Als u het merendeel van de vragen met “ja” beantwoordt, is de watervalmethode waarschijnlijk geschikter voor u. Agile ontwikkelmethodes daarentegen kunnen een aanpak zijn als de klant nog geen precies beeld heeft van wat hij precies wil. Deze methode is met name interessant voor bedrijven waar kan worden aangenomen dat het project een langere looptijd heeft en dat de randvoorwaarden, wensen of prioriteiten in de loop van de tijd eerder zullen veranderen. Ook 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 dat gericht is op de watervalmethode, maar niet om de afzonderlijke fasen strikt van elkaar te scheiden – een mix van planningszekerheid en flexibiliteit.

Het is in ieder geval de moeite waard om beide methoden nader te bekijken, want beide hebben hun voor- en nadelen. Het is het beste om wat tijd te nemen om te onderzoeken en samen te werken met uw ERP-leverancier om uit te vinden welk model het beste bij uw behoeften past.

Wilt u meer weten over de watervalmethode, de agile aanpak van uw ERP-implementatie of het volledige functionele aanbod van TimeLine ERP, stuur ons dan een bericht via het contactformulier, schrijf naar info@timelineconsulting.nl. Wij horen graag van u en geven u graag advies!