Wat als je klanten allemaal dezelfde software wilden? Hoe snel zou je dan groeien?
Hoe maatwerk je software ontwikkeling kan tegenhouden en wat je eraan kunt doen.
Deel 1: Waarom maatwerk in software tot het verleden zou moeten behoren
Als je enterprise oplossingen maakt, weet je dat elke echt grote organisatie op zijn minst een paar wensen voor maatwerk. Dat is meestal op één of meer van de volgende gebieden:
- De implementatie van hun eigen styling/branding. Dit kan geregeld worden met een goed content management component en een configureerbare stylesheet.
- Gepersonaliseerd jargon / unieke invoervelden. Elk bedrijf heeft zijn eigen terminologie en wil vaak eigen velden invoeren. Het is niet zozeer het veld zelf dat de uitdaging vormt, maar de noodzaak om dat aangepaste veld te laten interacteren met de rest van je applicatie.
- Integraties. Het ecosysteem waarin je applicatie werkt heeft altijd wel een paar usual suspects waar je een business case omheen kunt bouwen. Maar vooral in de modernere, granulaire architecturen komen sommige integraties maar één of twee keer voor. Als er een API beschikbaar is, maakt dat de integratie gemakkelijker. Maar integraties kunnen leiden tot een impasse tussen twee leveranciers, die allebei vinden dat de ander op hun API moet integreren.
- Besluitvorming op maat. Enterprise organisaties hebben hun eigen processen, beslissingsregels, berekeningen en manieren om aan compliance te voldoen. Afhankelijk van de complexiteit van de beslisregels kan dit een tijdrovende taak zijn die veel aansprakelijkheid met zich meebrengt.
Voor- en nadelen van maatwerk
Maatwerk leveren aan klanten heeft zowel voor- als nadelen: het voordeel is dat de aanvankelijke omzet kan toenemen. Wanneer je maatwerk levert tegen een uurtarief, leidt dat tot een zeer winstgevend project. Als het onderhoud van het maatwerk deel uitmaakt van het contract, kunnen het zelfs terugkerende inkomsten zijn. Er zijn drie manieren om met dit soort projecten om te gaan:
OPTIE 1: Huur een flexibel extern team of zakenpartner in om het maatwerk uit te voeren. In dat geval riskeer je het ‘Frankenstein-fenomeen’: niet-uniforme manieren om specifieke code-uitdagingen te benaderen. Het onderhouden van de maatwerkontwikkeling wordt al gauw een specialistische klus die slechts enkele developers kunnen doen.
OPTIE 2: Een eigen intern team toewijzen aan het maatwerk. Dit houdt een financieel risico in, omdat het team voortdurend aan een project moet werken om te voorkomen dat het bedrijf financieel leegloopt. Die continuïteit is er soms niet.
OPTIE 3: Voer deze projecten uit met behulp van je reguliere developers. Deze keuze heeft minder risico, maar vertraagt je generieke ontwikkeling drastisch. Toch is dit wat we het meest zien gebeuren in organisaties.
En natuurlijk is er altijd nog de vierde optie: ‘nee’ zeggen tegen maatwerk en verwijzen naar de generieke roadmap.
Het grootste nadeel van maatwerkprojecten is dat de inkomsten gebaseerd zijn op werkuren, wat niet schaalbaar is. Een toename van klanten leidt direct tot meer diensten die je moet uitvoeren, dus tot meer werknemers die je moet aannemen. En zoals we weten zijn goede werknemers heel moeilijk te krijgen.
Maar nog belangrijker: als je besluit om personeel uit je vaste team te halen, betekent dat een forse vertraging van je generieke ontwikkeling. Als het maatwerk onderhoud vereist, stagneert je generieke ontwikkeling helemaal.
En ten slotte vormt maatwerk een uitdaging op het gebied van aansprakelijkheid. Het is moeilijk om verwachtingen te managen als het gaat om maatwerk-development. En zelfs als je dit goed voor elkaar krijgt, is het voor de klant een uitdaging om de functionaliteit van het systeem te testen, vooral als er dingen hard-coded zijn in de applicatie. Zodra fouten, misinterpretaties of miscommunicatie aan het licht komen, rijst de vraag wie aansprakelijk is voor de gevolgen.
Optie 1 lijkt vanuit dit perspectief nog de meest aantrekkelijke. Wanneer je het maatwerk buiten je organisatie plaatst, beperk je de bijbehorende kwetsbaarheden. Je loopt wel het risico dat de klantervaring in het gedrang komt.
Volg ons en lees binnenkort deel II van dit artikel, waarin we de 5 niveaus van business rule maturity besprken. Zorg dat je het niet mist, en volg Rulecube op LinkedIn.
