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
Helemaal mee eens. Tegenwoordig lijkt “maatwerk” een vies woord te zijn. Het moeten “standaard oplossingen” worden, anders wordt het “te duur” voor de klant.
Op zich is er niets mis met standaard oplossingen, zo lang ze maar voldoen aan de klantwensen en geen afgedwongen werkwijze hebben. In mijn ogen is de ICT nog altijd ondersteunend aan de bedrijfsprocessen en niet leidend, zoals bij veel standaard oplossingen het geval is.
Men kan standaard oplossingen uiteraard aanpassen naar de klantsituatie, maar dit is in veel gevallen weer zo duur en complex, dat men achteraf beter af was geweest met maatwerk.
Dit artikel is een “spekkie naar mijn bekkie”.
Ik heb hierover een hoofdstuk in een boek geschreven, maar het boek is wat uit de hand gelopen en het editen was zoveel werk dat het nog even op de “plank” staat.
De titel van dit hoofdstuk is “De twee smaken van software automatisering”.
A) Je koopt standaard software
B) Je maakt eigen software
Voordeel van A is dat het relatief goedkoop is en dat het een organisatorische verandering is. Je moet de organisatie aanpassen naar de software. Ander voordeel van A is dat je meegroeit, er komt automatisch nieuwe functionaliteit beschikbaar. Nadeel is dat er altijd gaps zijn en bijvoorbeeld dat je geen invloed uit kan oefenen waar het met de software naar toe gaat en dat je vaak betaald voor onderhoud.
Voordeel van B is dat de software zich schikt naar de organisatie (die al functioneert) en dat software maken tegenwoordig een stuk simpeler is dan tien jaar geleden. Nadeel van B is dat je zelf verantwoordelijk bent voor alle fouten en tekortkomingen, dat je alle ontwikkelkosten betaalt en je moet blijven investeringen in doorontwikkelingen.
Wat is nu het geval? Veel grote bedrijven kiezen vaak voor A en laten daar dan maatwerk op bouwen en dat is de allerslechtste keuze die je kunt maken!!
Je hebt namelijk GEEN voordelen van A of B en je hebt ALLE nadelen van A en B.
Kort door de bocht opsomming van nadelen:
– Je betaalt alle ontwikkeling alleen (nadeel van B)
– Alle ontwikkeling is MOEILIJKER omdat je niet vrij bent in ontwikkeling, maar je ook nog moet vormen naar de onmogelijkheden van die standaard software die helemaal niet ingericht is op maatwerk
– Je kunt niet zomaar meer mee naar nieuwe versies dus loopt altijd achter en de kosten zijn enorm bij elke release omdat je alles moet testen en aanpassen omdat het maatwerk in de nieuwe versie niet aansluit.
– De standaard software groeit een kant op die helemaal niet aansluit bij je maatwerk, dus een VENDOR LOCK-IN van heb ik jou daar
En ga zo maar verder.
Nu is er wel zoiets als “platform” software. Software die in de basis niet heel specifiek is en die je standaard al heel erg kunt vormen. “Standaard maatwerk” zou je dit kunnen noemen. Per platform zul je *zeer* goed moeten kijken of dit het vehikel is waarop je inzet. Hoe ze tegen het licht van bovenstaand lijstje.
Reactie is wat lang geworden, maar dit is echt een essentieel onderdeel van software keuze.
On Topic: Leuk artikel, wel wat tekort, maar een goed vertrekpunt.
Een ander nadeel van standaard software is dat je niet de enige klant van je leverancier bent.
Op een moment x in de tijd kan een pakket versie V1.0 prima geschikt zijn voor zowel bedrijf A als bedrijf B.
Nu willen bedrijven zich graag onderscheiden in de markt en bedrijf A en B zullen verschillende eisen aan het pakket gaan stellen.
Als op moment y versie V2.0 uitkomt zal er functionaliteit in gerealiseerd zin die niet voor beide bedrijven meer relevant is.
Naarmate A en B zich verder onderscheiden hoe groter dit effect zal worden.
Het pakket is dan dus groter geworden dan dat je nodig hebt. Een groter pakket betekent een instabieler en moeilijker te onderhouden pakket.
Maatwerk kan je software lean houden en toegespitst op je bedrijf. Daarnaast kan je alle aanpassingen er in krijgen waar je voor bereid bent te betalen.
Waar wel voor opgepast moet worden is dat je maatwerk pakket wel onderhoudbaar blijft en dat het niet in de jaren een bende wordt. Dit gevaar bestaat overigens ook voor een standaard pakket.
Om de argumenten van Henri te verduidelijken op zijn woorden over “Nu is er wel zoiets als “platform” software.” .
In zo een platform bestaat de benodigde functionaliteit uit componenten. Afhankelijk van de behoefte van de klant wordt de benodigde componenten (=werkende functionaliteit) en met elkaar verbonden, waardoor een werkend geheel als applicatie ontstaat met alle benodigde condities en afhankelijkheden. Bij wijzigen en of toevoegingen kun je je dan concentreren om alleen de betrokken componenten na te lopen of uit te breiden..om de wijziging door te voeren. Uiterst effectief en deze wijze van werken is “een mix” van standaard software en maatwerk..
Wat niet naar voren komt in het artikel en ook niet in de reacties (tot nu toe): er is een spectrum van functionaliteitseisen dat loopt van generiek naar heel specifiek. Ik denk dat de meeste bedrijven geen financieel system meer laten ontwikkelen en ook CRM gaat die kant op. Maar een heel specifiek stuk software wat inderdaad het onderscheid maakt, daar hoop je geen standaard voor te vinden.
Daarnaast heb je in het bedrijfsleven de concurrentiepositie die dit onderscheid voortdurend laat verschuiven (kopieergedrag van concurrenten) maar in overheidsorganisaties zie je veel meer dat processen domweg voorgeschreven zijn en daarom best gestandaardiseerd kunnen worden en ook met standard software ondersteunt.
Platform-software probeert beide werelden te bedienen. Dat maakt ze wel complex en daardoor ook duur. Inrichten kost consultancy-arbeid, bij standaard pakketten is het veel meer implementatie-arbeid.
Voor MKB geldt vaak dat zelf ontwikkelen te lang duurt en te kostbaar is. Voor die organisaties hangt het een beetje van de concurrentiepositie af welke kant van het spectrum voor hen voordelig is.
Al met al voor mij lastig om voor het één of het ander te pleiten.
En waar valt Open Source Software in?
@Ewout: In principe gaat de discussie niet om open source of geen open source. Hoewel de aspecten ervan wel degelijk een rol spelen (risico analyse, zelf kunnen aanpassen, support) is dit niet de kern van de discussie en maakt het alleen maar subtiel ingewikkelder maar niet fundamenteel anders.
@Leen: Uiteraard is de werkelijkheid weerbarstig en heeft een bedrijf altijd meer dan 1 software pakket die varieert van kantoor automatisering (generiek) tot verticaal (voor die branche). Hoewel veel organisaties inderdaad behoefte hebben aan iets specifieks voor hun branche heeft elke branche wel een marktleider waarmee je het spectrum afdekt. De gaps waar ik het over had gaat hier in feite over. Ook daar ben ik sterk van mening dat je OF je organisatie aan moet passen zodat je de gaps veranderd in fits waardoor het *lijkt* alsof je aan onderscheidend vermogen inlevert maar mijn beleving is dat het onderscheid meer in de mens zit dan in de software.
OF je kiest voor jouw specifieke branche om het lekker helemaal zelf te bouwen en te koppelen aan de generieke pakketten zoals financiele administratie.
Ik ben het niet met je eens dat het voor MKB te lang duurt en te kostbaar is. Ik ben zelf een maatwerk bouwer geweest en mijn klanten zijn bijna allemaal MKB waarbij sommige bedrijven “slechts” tien mensen in dienst hebben. Zij kunnen dus wel onderscheidend zijn met hun software.
Het maken van goede degelijke software is helemaal niet zo moeilijk en door goed gebruik van cloud computing (of in ieder geval virtualisatie) en open standaarden + API’s is integratie geen groot ding meer. En zoals Marcel al zegt, kun je met platformen al heel snel meters maken.
Als je ziet wat SaleForce kost als je los gaat op Force.com dan is zelf bouwen echt wel een mogelijk alternatief en juist op dit gebied kan cloud computing heel goedkoop zijn.
@Henri
Als er appels en peren met elkaar vergeleken worden dan voeg ik graag nog wat fruit aan de schaal toe. Want Open Source ligt misschien wel tussen standaard en maatwerk in en wordt dan ook vaak gebruikt door leveranciers van ‘proprietary’ oplossingen.
En het wordt ook populair als een framewerk waarop specifieke oplossingen en diensten gebouwd kunnen worden. Want waarom telkens het wiel opnieuw uitvinden als er ‘gevorkt’ kan worden op idee van een ander?
Misschien moeten we daarom de naam van deze software wel wijzigen in Community Software zodat voorkomen wordt dat er steeds meer deeloplossingen komen die uiteindelijk slecht integreren.
@Henri
Ik kan me helemaal vinden in je reactie.
@All
De beste keuze (maatwerk, standaard software of een combi ervan) hangt uiteraard af van de uitdaging die de klant heeft. En ook van de branche/markt waar de klant zich in begeeft. De IT manager en het management (het beste zou een gezamenlijke beslissing zijn) van een bedrijf zullen deze keuze moeten maken, al dan niet geholpen door externe leveranciers. Maar hoe weet je of een externe leverancier het totale speelveld wel overziet (het ene systeem is van invloed op andere systemen en bedrijfsprocessen) en niet bezig is om alleen zijn eigen product/dienst te verkopen, ook al is dit niet altijd de beste oplossing. Natuurlijk varen bedrijven bij de leveranciers selectie veel op gevoel en vertrouwen. En vaak is dat gevoel goed. Toch is het handig dit gevoel te onderbouwen en bij deze dus enkele tips:
• Zorg dat je met in ieder geval 1 leverancier samenwerkt die in staat is het strategische speelveld te overzien en kritisch is. Deze IT partner heeft bij voorkeur ook business wise kennis van zaken. Gaat het om grote investeringen, dan kan het nog de moeite lonen een second opinion in te zetten.
• Hoe tijdrovend ook, maar voer een gedegen reference check uit. Naast referenties kun je denken aan het checken op kwaliteit van de medewerkers (vraag naar de CV’s van de mensen die aan het project gaan werken, wat is het niveau van de werknemers generiek, hoe goed is hun lead architect).
• Vraag de leverancier naar alternatieven voor zijn product/dienst. Kennen ze alternatieven, kennen ze dan ook de voor- en nadelen ervan, et cetera.
Rest mij iedereen hele fijne feestdagen en fantastisch 2013 te wensen!
Er is steeds meer verzuiling in het applicatielandschap. Combinaties van standaard, maatwerk en hybride oplossingen.De vraag rijst;
Wat te doen als mijn processen over meerdere applicaties en systemen lopen?
Hoe zorg ik dat mij bedrijfsprocessen zo goed/snel mogelijk verlopen?
Waarom deze vragen?
Onafhankelijk van de keuze moet je als bedrijf nadenken hoe je je gaat onderscheiden ten opzichte van je concurrentie; zeer terecht Leen Blom. Processen raken meerdere applicaties, afdelingen en disciplines.
Welke keuze je ook maakt, voor welk proces je ook software nodig hebt, integratie van processen (Business Process Automation) is essentieel om mee te nemen in de architectuur. Dit levert uiteindelijk concurrentievoordeel op.