Als je mag kiezen, kies je dan voor maatwerk of standaard software? Het mantra in veel organisaties en zeker binnen de overheidsorganisaties waar ik zelf veel kom, is dat standaard software altijd de voorkeur heeft. Deze reflex is naar mijn idee weinig onderbouwd. Laten we daarom hier even bij stil staan.
Veel managers hebben het beeld dat standaard software een aantal voordelen geeft: (meestal) goedkoper in de aanschaf, beter doorontwikkeld en goedkoper in onderhoud. De leverancier heeft immers veel tijd gestoken in het ontwikkelen van de software en blijft die tijd steken in het onderhoud ervan.
Maatwerk heeft als stigma dat het ontwikkelen lang duurt en dus kostbaar is. Daarnaast moet je het onderhoud zelf doen en dat is arbeidsintensief en dus duur. In de praktijk is dit sterk afhankelijk van de kwaliteit van je applicatiebeheerders en jouw vertrouwen in hen, maar daarover later meer.
Nieuwe software kopen
Software moet aansluiten op de behoefte van je organisatie. Je organisatie heeft een probleem en wil software ondersteuning om hierbij te helpen. Dit betekent dat je een pakket moet kopen of maken dat voldoet aan deze vraag. Je brengt de vraag in kaart, bijvoorbeeld in een programma van eisen en gaat opzoek naar de juiste software.
In standaard software staat het aanbod van de functionaliteit vast. De keuze voor het juiste pakket is daarmee heel belangrijk. Hierin treden een paar knelpunten op. De standaard software biedt zelden precies de functionaliteit waar je om vraagt. Een potentieel pakket biedt vaak een gedeelte van jouw eisen, maar even vaak ook functies waar je niet direct om vraagt.
Als de software niet biedt wat je zoekt kan je de eisen bijstellen, maar dit is zelden wat je wil, want die eisen heb je met zorg opgesteld en staan met een reden in het programma van eisen. In veel gevallen valt de keuze dan op het aanpassen van de standaard software en heb je toch een vorm van maatwerk te pakken.
Het omgekeerde kan natuurlijk ook. De software doet vaak ook meer dan je programma van eisen. En dat kan danig in de weg zitten. Dit vraagt soms om het alsnog aanpassen van de software, hetgene wat je nou net wilde voorkomen. In extreme gevallen kan de software toevallig ook wat je nodig hebt, maar ook zoveel andere dingen zodat je meer uit moet schakelen dan je aan functionaliteit overhoudt.
De kans dat je aanpassingen aan de software geheel kan ontlopen is dan ook klein. Daarnaast is de software steeds meer verbonden met elkaar. Dus de keuze voor het ene product heeft invloed op het andere product. Die koppelingen tussen de diverse applicaties zijn vaak maatwerk aanpassingen.
Nieuwe software maken
Het alternatief op software kopen is software (laten) maken. Ik laat even in het midden of je het de eigen organisatie laat doen of daar een andere voor inhuurt. De basis van de aanpak gaat er vanuit dat de software precies gaat doen wat je er van vraagt. Niet meer en niet minder.
De valkuil van deze aanpak is dat tijdens de bouw de vraag van de organisatie vaak verandert of uitbreid. Dit hoeft geen probleem op te leveren, mits de werkvorm dit toestaat. De klassieke ‘waterval’ aanpak laat over het algemeen minder ruimte voor aanpassingen gedurende het project dan de ‘agile’ aanpak. Voor beide methoden geldt dat er limieten zijn in de besteedbare capaciteit van de programmeurs, het budget en/of de doorlooptijd.
In deze projecten gaat extra aandacht uit naar het testen van het resultaat. In standaard software wordt deze gegarandeerd door de leverancier, maar in deze situatie dien je dit zelf vast te stellen. Ook dit vraagt tijd, capaciteit en budget.
Een randgeval van de term maatwerk zijn de grote software pakketten die je als ‘platform software’ zou kunnen aanmerken. Denk hierbij aan zoiets als een workflowmanagement-pakket of crm-applicatie. Deze software moet na installatie nog uitgebreid ingericht en geconfigureerd worden. Door een vrijwel eindeloze combinatie van configuratie-instellingen zit je heel dicht tegen programmeren aan en kom je er zelden uit zonder hulp van een expert (die je programmeur zou kunnen noemen).
Vertrouwen
Een belangrijke factor in beide aanpakken is vertrouwen. Vertrouwen of de software gaat doen wat hij moet doen, binnen budget en binnen de gestelde tijd. Daarbij is een argument tegen maatwerk, dat dit minder goed gegarandeerd kan worden, omdat de software zich nog niet heeft kunnen bewijzen. Er zijn immers geen andere klanten die dezelfde software al gebruiken.
Standaard software heeft een leverancier die garant staat voor de functionaliteit van hun software. Maar in de praktijk is software van leveranciers ook niet altijd even foutloos. Niet helemaal vreemd aangezien een softwareleverancier voortdurend moet balanceren om goede software te leveren met zo laag mogelijke eigen kosten. In die afweging tussen kwaliteit en investering, worden soms keuzes gemaakt die jou al gebruiker niet uitkomen.
En daarmee komt het uit op vertrouwen. Wie vertrouw je meer? De leverancier die je een software pakket kan leveren of de mensen die je potentiële maatwerk gaan bouwen?
Onderhoud
Het onderhouden van standaard software is belegd bij de leverancier. Maar de introductie van de nieuwe versie van die standaard software in de eigen organisatie is zelden ‘plug-and-play’. Neem bijvoorbeeld je tekstverwerker, die in 99 procent van de gevallen standaard software betreft. Als je hier een nieuwe versie van introduceert, levert dit altijd aanpassingsproblemen op met andere applicaties, zowel standaard als maatwerk. De overige software moet altijd meebewegen als een nieuwe versie van een belangrijk programma wordt geïntroduceerd.
Het onderhouden van maatwerk zal je altijd zelf moeten regelen, aangezien er geen leverancier is die dit voor je doet. Natuurlijk vult je (technisch) applicatiebeheerder deze taak graag voor je in, maar het vraagt een extra inspanning van je eigen organisatie voor het verzamelen en prioriteren van de gewenste wijzigingen en het testen van de uitkomsten.
Conclusie
Er is zelden iets zoals een ‘pure’ standaard software-oplossing en het is niet per definitie een betere oplossing dan maatwerk. In heel veel gevallen kom je toch uit op een combinatie van standaardsoftware en aanvullend maatwerk. Een pure maatwerk-oplossing levert precies wat je vraagt, maar met een grotere eigen verantwoordelijkheid.
Mijn oproep zou dan ook zijn om open te staan voor beide oplossingsrichtingen.
Harmen Lindeboom, adviseur bij M&I Partners
@Leen Met de begrippen generiek/specifiek is het volgens mij precies waar het om draait. In mijn eigen woorden zou ik zeggen dat standaard software de voorkeur geniet als je je bedrijfsproces aan de software kunt en wilt aanpassen. Andersom verdient juist maatwerk de voorkeur. In de praktijk zie je vaak dat er standaard software wordt ingezet die aan allerlei specifieke eisen en wensen wordt aangepast. Men gebruikt een standaard softwarepakket als programmeerplatform. Dan wordt het duur.
Wat betreft de stelling over het vervangen van de tekstverwerker onder het kopje Onderhoud ben ik van mening dat dit pas een probleem is als er allerlei macro’s en proprietary koppelingen gemaakt zijn. Integratie is de lijm van de vendor/version lock-in. En dat lijkt mij voer voor architecten.
Standaard lijkt niet te bestaan. Er moet vaak nog het nodige aangepast worden, vooral als het om interfaces gaat.
Het echt open landschap hebben we nog lang niet bereikt.
Soms heb ik het gevoel dat we met Access en Excel een hoop aan elkaar knopen.
Bedankt voor dit goede stuk over een thema waar veel organisaties mee worstelen. Mijn twee centen hebben te maken met wat ik keer op keer fout zie gaan in de praktijk: maatwerk op standaardsoftware door simpelweg kopiëren van een aantal codemodules en vervolgens daarin de aanpassingen doen. Dat kopiëren is in een paar minuten gebeurt, maar daarmee wordt wel een enorme last geïntroduceerd want alle gekopieerde code moet apart worden onderhouden. Dat is duur en in veel gevallen gebeurt het daarom niet, dus als klant blijf je vervolgens zitten met een oude versie totdat het niet meer gaat en dan is de minst onvoordelige keuze om weer de nieuwe code te kopiëren en het maatwerk opnieuw te doen.
Het succes van aangepaste maatwerksoftware wordt daarom sterk bepaald door de manier waarop de software kan worden aangepast. De kunst is daarbij dat gedrag configureerbaar is, of zich op een zinnig detailniveau laat aanpassen via duidelijke plug-in interfaces en niet door het aanpassen van code. Wat daarbij hoort is een strikt beleid van scepsis ten opzichte van elke aanpassing, de zorg dat interfaces niet veranderen en dat copy/paste programmeren wordt geminimaliseerd
Al eerder is gesteld dat de keuze voor standaard of maatwerk betekent dat er eerst op procedureel gebied keuzes moeten worden gemaakt. En dat houdt in dat er eenduidigheid en transparantie moet komen en vooral dat er gecommuniceerd wordt hoe er (voortaan) wordt gewerkt. Hier geldt het aloude adagium: eerst organiseren, dan automatiseren.
Wie goed georganiseerd is kan beter aangeven wat hij nodig heeft. ICT kan vervolgens beter helpen de juiste keuzes te maken (make or buy). Alleen als dat het geval is ben je in staat om in het ene geval te kiezen voor standaard, in het andere geval voor maatwerk en, ook al beweren sommigen dat dat niet verstandig is, in een enkel geval zelfs voor de combi.
Eens dat maatwerk op standaardsoftware taboe is. Niet eens dat maatwerk vaak beter is. Mn. niet als standaardsoftware makkelijk te configureren is (liefst door de klant: zero-coding) terwijl je voor maatwerk (kraswerk) vaak terug moet naar de leverancier (wat een lock-in oplevert). En maatwerk (of meerwerk op standaard) leidt vaak tot verwarmde buitenspiegels en uitloop. Zie ook mijn 10-geboden (www.argitek.nl/downloads/De-tien-geboden-voor-systeemontwikkeling_ag-pag20-21-22nov2012.pdf).