Wanneer kies je nu voor maatwerk?

Je ziet ze wel eens op plaatjes in geschiedenisboekjes: een gevangene met een ronde kogel, bevestigd via een ketting aan het been om het snel wegkomen te bemoeilijken. Letterlijk een blok aan het been. Dat heb je toch niet voor je lol? Tja, maar als ik dat zie moet ik toch nog wel eens denken aan ons vak. Er zijn klanten die zichzelf, bewust of onbewust, een blok aan het been aanmeten. Wij noemen dat in IT-termen ook wel ‘teveel maatwerk’.

Vaak zien we dat klanten aan het begin van het traject het nobele streven hebben zichzelf geen blok aan het been te laten aanmeten. Maar als de implementatie vordert, groeit dat blok toch langzaam aan. Voor ons als softwareleveranciers is maatwerk op korte termijn een bron van inkomsten, maar anderzijds realiseren we ons terdege dat maatwerk lastig is. Het brengt extra kosten met zich mee voor de klant, de doorlooptijd van het project verlengt en de onderhoudbaarheid en beheersbaarheid van de oplossing wordt complexer. Misschien is het woord ‘projectrisico’ wel het beste woord als we dat moeten samenvatten. Het grote voordeel is dat de applicatie op maat gesneden is voor de klant in kwestie. Maar per saldo is het ook in ons belang als een klant zo ver mogelijk kan worden weggehouden van maatwerk.

De doorlooptijd wordt verlengd, want goed maatwerk bouwen kost nu eenmaal tijd. Dat geldt tijdens(!) een project, maar ook na livegang zal dit een blok aan het been blijven. Denk maar aan het onderhoud van de applicatie: Microsoft besluit om een nieuwe release uit te brengen waar juist dat stuk software in zit wat voor de organisatie perfect is. Na een implementatie zonder maatwerk sluit die nieuwe release netjes aan op de bestaande applicatie. In de situatie dat er een hoop maatwerk is gebouwd is een standaard upgrade niet voldoende, want het maatwerk moet ook weer aansluiten op de nieuwe release … extra kosten, doorlooptijd, je voelt het al. Het blok aan het been wordt aangemeten en via een lange ketting bevestigd, het wegkomen van de gevangene wordt vertraagd. Overdrachtelijk: een bedrijf belemmert zijn eigen ontwikkeling als het softwaresysteem niet mee kan groeien met de ontwikkelingen binnen de onderneming.

Dynamics AX staat erom bekend hoe eenvoudig het is om maatwerk te maken, ongeacht of het nu een eenvoudig of complex proces is, het meeste is wel aan te passen. De keuze om een probleem in het proces op te lossen door maatwerk te bouwen kan snel worden gemaakt, soms te snel.

Maar wanneer kies je nu wel en wanneer kies je niet voor maatwerk? De vuistregel is: als je eraan kunt ontkomen, blijf er dan ver vandaan. En zorg voor de juiste mechanismes om dat maatwerk wat wel nodig is, zo zorgvuldig mogelijk te definiëren.

STAP 1 is: bij elke maatwerkaanvraag eerst een stap terug doen om te kijken of het proces eenvoudig kan worden aangepast, waardoor er geen maatwerk nodig is. Is de conclusie dat er niet aan te ontkomen valt, zie dan stap 2.

STAP 2: als er dan toch wordt gekozen om bepaalde problemen op te lossen via maatwerk, hoe voorkom je dan dat dit maatwerk een blok aan het been wordt, zowel tijdens het project als na livegang? Zorg voor goedkeuring door de stuurgroep. Elk op te lossen probleem wordt beschreven als een ‘gap’. Per ‘gap’ wordt een globale inschatting gemaakt wat de kosten zijn, waarna het aan de stuurgroep is om te bepalen of iets wel of niet wordt opgelost via maatwerk. Bij goedkeuring wordt er een Functional Design geschreven wat de basis is voor het bouwen van het maatwerk.

STAP 3: als de stuurgroep besluit dat er maatwerk moet worden gebouwd, zorg dan voor de juiste documentatie. Zorg dat deze documentatie goed en compleet beschrijft wat er wordt gemaakt en welk probleem wordt opgelost. Zorg ook dat die documentatie wordt beheerd door de eigen organisatie en dat er niet wordt geleund op de leverancier. Neem uitdrukkelijk de onderhoudbaarheid mee in het ontwerp. Tijdens het bedenken en uitwerken van de oplossing wordt er rekening gehouden met een aantal punten. Wat is bijv. het risico bij een aanpassing van dat proces? Kunnen we hierna nog steeds relatief eenvoudig een upgrade of hotfix installatie uitvoeren? Gaan we in een bestaand complex proces ingrijpen of gaan we iets bedenken waardoor het bestaande proces in tact blijft en daar dan zo dicht mogelijk tegenaan een oplossing maken? De antwoorden op deze vragen zullen bij elke wijziging verschillend zijn, maar helpen uiteindelijk wel bij het maken van de juiste keuze. Dit verkleint het risico en vergroot de onderhoudbaarheid en beheersbaarheid van de applicatie.

In gedachten zie ik ze gaan: de gevangenen met het blok aan hun been. Ze tillen hun blok op om beter te kunnen lopen. En dan zie ik degenen die een klein blokje hebben, heel makkelijk en snel bewegen, net alsof het blokje niet bestaat. En een enkeling blijft achter, omdat het blok niet te tillen is. Want uiteindelijk moet de applicatie je niet alleen helpen over de hele linie binnen de bedrijfsprocessen van vandaag, maar ook binnen de bedrijfsprocessen van morgen, volgende maand, volgend jaar en ver in de toekomst.


Terug naar overzicht