Software: standaard of maatwerk?

Dagelijks zijn er organisaties bezig met de keuze voor een nieuw softwarepakket ter ondersteuning van de financiële administratie, het inkoopproces, de personeels- en/of salarisadministratie, enzovoort. En steeds is er weer de keuze: ‘Nemen we een standaard pakket of staan we maatwerk toe?’

Bijna iedereen wil dan een standaard oplossing. De kosten en doorlooptijd van een implementatie zullen dan immers lager uitvallen, omdat je makkelijker kunt reageren op updates van de leverancier. Aan de andere kant vindt iedere organisatie dat hun processen toch dermate afwijken, dat maatwerk moet worden toegestaan.

Een belangrijke graadmeter is natuurlijk de complexiteit van de eigen organisatie en administratie: een kleine of lokale organisatie met maar één vestiging en bijvoorbeeld 50 medewerkers, heeft heel andere eisen dan een internationaal opererende organisatie met honderden of duizenden medewerkers.

Maar wij zijn anders…

In alle jaren dat ik al bezig ben in de ICT zie ik aanvragen voorbijkomen, waarin de aanvrager (groot en klein) in eerste instantie vraagt naar een standaard oplossing, die zo van de plank gehaald kan worden. Vaak volgt in een later stadium alsnog een vragenlijst met eisen en wensen. Hierbij wordt vaak teruggegrepen op de eigen specifieke werkwijze, die de aanvrager achteraf toch graag in de oplossing terug wil vinden.

Om niet bij voorbaat te worden afgewezen, leidde dit soort verzoeken vaak tot een lastige afweging bij de beantwoording. Zeggen we: ‘ja dat kan’? Of: ‘ja dat kan, maar….’? Daarnaast was het ook reden tot argumentaties tijdens de implementatie van ‘on premis’ geïntegreerde oplossingen (ERP-systemen).

Bedrijven die zich gespecialiseerd hebben in implementatie van ERP-systemen (system integrators), weten al bij de beantwoording in te spelen op eventuele aanpassing. Het antwoord is dan dat men dit al eerder heeft uitgevoerd bij voorgaande projecten en dat de aanpassing dus hanteerbaar is en ‘bewezen’ functioneert.

Smijten met de deuren

Gedurende de afgelopen jaren heb ik het maar één keer meegemaakt dat een internationaal opererend bedrijf bewust ervoor koos om processen bij te sturen ten behoeve van de gekozen softwareoplossing. Ondanks dat er tijdens het implementatieproject wel eens met deuren werd gesmeten, is deze lijn volgehouden. Dit heeft geresulteerd in een succesvolle standaardimplementatie, binnen tijd en binnen budget met zeer tevreden gebruikers.

Hiervoor noemde ik al even ‘on premis’ geïntegreerde oplossingen. Hierbij staat de software geïnstalleerd op de computers van de organisatie. Door licenties te kopen is de software eigendom geworden van de organisatie en is het toevoegen van maatwerk verleidelijk en makkelijker te realiseren.

De afgelopen jaren wordt steeds vaker gesproken over ‘cloudoplossingen’. Heel kort: de software staat ergens op een computer van de aanbieder en door een (maandelijks) abonnement te betalen kan men dit gebruiken.

De aanbieder blijft eigenaar en heeft volledige controle over de software. Hij zal zorgen voor (periodieke) updates waar elke klant direct profijt van heeft. Dit betekent dat iedereen met dezelfde standaard software werkt. We kunnen de software wel configureren, zodat onze organisatiestructuur herkenbaar is, maar dit is geen maatwerk.

Is dit – afgezien van de voortdurende ‘securityvraagstukken’ - dan ook de reden waarom cloudoplossingen makkelijker toe te passen zijn voor kleinere organisaties? Daar zijn processen ‘standaard’ en is de organisatie flexibel genoeg om processen bij te stellen, zodat zij optimaal van de oplossing gebruik kunnen maken.

Minder sleutelen?

De grotere organisaties die voldoende flexibel zijn om processen aan te passen, zullen minder moeite hebben om over te stappen op (goedkopere?) cloudoplossingen. Ook system integrators zullen anders te werk moeten gaan en zich misschien meer moeten richten op configuratie en beheerondersteuning dan op het sleutelen aan maatwerk. Bovendien ontstaan er nieuwe mogelijkheden, zelf een service ontwikkelen en aanbieden die ‘hiaten’ in de standaard producten invullen.

Wouter: “Vaak volgt in een later stadium alsnog een vragenlijst met eisen en wensen”