Maatwerk is zo slecht nog niet

Jaren geleden kreeg maatwerk software-ontwikkeling een wat negatief imago. Zo zou het traject vaak duur zijn. Kosten die bij een standaard softwarepakket immers aan vele klanten kunnen worden toegerekend, worden bij maatwerk software doorberekend aan één klant. Daarnaast bestond het imago dat maatwerk moeilijk te onderhouden was. Hierbij kwamen nog de verhalen over softwareleveranciers die klanten in hun greep hielden, door broncode niet af te staan. Tegenwoordig moeten we maatwerk software echter in een nieuw licht zien.

Vooropgesteld valt of staat het succes van een maatwerksoftware project met de partner die men hiervoor kiest. Wordt er gekozen voor een risicovolle partner, met weinig kennis van zaken, dan zal de kans op succes afnemen. Dit is overigens niet anders in andere branches. Laat je een huis bouwen door een ervaren man, of iemand die in zijn vrije tijd weleens een muurtje gemetseld heeft?

Maatwerksoftware 2.0

Er is veel veranderd ten opzichte van jaren geleden. Deze veranderingen zijn onder meer tot stand gekomen door enkele trends van de afgelopen jaren, zoals de opkomst van Scrum als methodiek voor software ontwikkeling, de aandacht voor werken onder architectuur en de evolutie van de moderne ontwikkelomgevingen.

Tegenwoordig kan maatwerk software zo ontwikkeld worden dat veel nadelen van vroeger verleden tijd zijn. Hier een opsomming van maatwerksoftware 2.0:
‘Lean’ software ontwikkeling: Scrum heeft software ontwikkeling ‘lean’ gemaakt. Hiermee behoren lange trajecten tot het verleden en kunnen resultaten snel en direct volgen na de start, zodat een klant tijdig kan bijsturen en alleen zaken uitgewerkt worden die ook echt ‘ontwikkeld’ gaan worden.
Standaardisatie maatwerk ontwikkeling: Scrum en andere goede principes zorgen voor standaardisatie van software ontwikkeling. Zo is het relatief eenvoudig zaken door een andere ontwikkelaar te laten oppakken.
Standaard componenten: Daarnaast hebben ontwikkelomgevingen een vlucht genomen. Als je software maakt heb je toegang tot enorme bibliotheken met componenten en voorbeelden. Grote kans dat hetgeen dat wordt gemaakt al eens een keer eerder in een andere situatie is toegepast. Software kan hiermee veel efficienter ontwikkeld worden.
Architectuur: Werken onder architectuur zorgt ervoor dat oplossingen op lange termijn houdbaar zijn en dat er nagedacht wordt over de toekomst van de oplossing.
Betrouwbaar: Het testen van software kan op een goede manier geautomatiseerd worden. Zo neemt de betrouwbaarheid van opleveringen enorm toe en krijgt een klant vertrouwen in een leverancier.
Koppelen: Het koppelen van systemen kan tegenwoordig overzichtelijk en laagdrempelig geschieden. Oplossingen kunnen dus gemakkelijker ingepast worden in een bestaande situatie.

Zo komt het krachtig over als je als softwareleverancier kan zeggen: binnen enkele weken staat deel één van de gewenste oplossing klaar, beste klant, en kan je dit gebruiken. Bovendien kun je erop vertrouwen dat de oplossing goed werkt. Je oplossing past overigens heel goed binnen je bestaande architectuur en er zijn koppelingen gelegd met andere delen van je infrastructuur, zodat de oplossing niet als een eiland op zichzelf staat.

Samenwerken ++

Een nadeel van een implementatie van een standaardpakket is vaak dat een organisatie veel aandacht besteedt aan de initiële implementatie, maar vervolgens veel minder aandacht aan de periode hierna, met als resultaat dat de initiële oplossing na enkele jaren toch minder aansluit bij de organisatie. Organisaties veranderen immers. Uiteraard is het bovenstaande geen feit. Standaard softwareleveranciers en hun klanten kunnen er immers voor zorgen dat een oplossing deze aandacht krijgt na de initiële implementatie. In de praktijk komt het helaas veel vaker voor dat deze aandacht er niet is.

Het voordeel van een maatwerksoftware 2.0 traject is dat de softwareleverancier en een klant direct worden opgevoed. Vanaf dag één zullen zij moeten samenwerken en middels Scrum kan dit worden geborgd in beide organisaties. Dit zorgt er in de praktijk voor dat leverancier en klant elkaar ook veel gemakkelijker weten te vinden na het initiële project. Ook doorontwikkeling van een pakket vindt veel gemakkelijker plaats. Men is immers gewend om extra functies op een juiste manier af te wegen, in te schatten en te realiseren op basis van een goede business case. Dit heeft men namelijk het gehele traject al gedaan.

Alternatieve business modellen

Dan rest natuurlijk nog het argument dat maatwerk duur is. Hier kunnen veel argumenten tegenin gebracht worden, bijvoorbeeld dat het ontwikkelen van software met behulp van de huidige mogelijkheden veel efficiënter kan dan voorheen. Uiteraard blijft dan nog het argument overeind dat de kosten nog steeds op één klant worden verhaald.

Hier ligt een kans voor de moderne maatwerksoftware 2.0 leverancier om slim ondernemerschap te tonen. Denk eens in alternatieve business modellen, zoals een verdienmodel, gebaseerd op het verdienmodel van de klant, of alternatieve ‘fund’-mogelijkheden. In samenwerking met de klant zou het toch mogelijk moeten zijn om financiële risico’s samen te delen, evenals potentiële financiële baten.

Mario Brenters, directeur Dataleaf smart software solutions