applatenmaken.com/kennisbank/softwareleverancier kiezen
Softwareleverancier kiezen
U gaat software of een app laten bouwen en moet bepalen wie dat doet. Deze pagina gaat over die keuze: welke vormen van samenwerking er bestaan, welke signalen werkelijk iets zeggen, en wat u vastlegt voordat u tekent.
De keuze begint eerder dan u denkt
De meeste selecties beginnen met een lijstje bureaus en een kennismaking, terwijl de uitkomst dan al half bepaald is door een vraag die vaak wordt overgeslagen: wat besteedt u eigenlijk uit? Een afgebakende opdracht met een duidelijk einde vraagt een ander soort partij dan een systeem dat in gebruik blijft en meebeweegt.
Wie uitblinkt in korte trajecten is ingericht op afronden: scherpe scope, strak tempo, team weer weg na oplevering. Efficiënt, maar de kennis vertrekt mee. Een partij die op continuïteit is ingericht houdt dezelfde mensen bij uw systeem en investeert in documentatie, ook als er weinig gebeurt.
Geen van beide is beter. Het gaat mis wanneer u het ene inkoopt en het andere verwacht. Wie zijn eisen eerst op papier zet, merkt in het eerste gesprek al welke partij daar iets zinnigs mee doet; daarover gaat een programma van eisen schrijven.
Waarom een portfolio zo weinig bewijst
Elke leverancier laat zijn geslaagde projecten zien. Dat is geen misleiding, het is hoe een portfolio ontstaat: er belanden alleen opdrachten in die zijn afgerond en waarbij de klant toestemming gaf om te publiceren. Het project dat halverwege vastliep treft u er nooit in aan, terwijl juist dat iets zegt over hoe een partij zich gedraagt als het tegenzit. Dat is de situatie waarin u hem straks nodig hebt.
Drie vragen halen dat naar boven. De eerste: vertel eens over een project dat is uitgelopen. Wie zegt dat alles altijd volgens plan liep, heeft weinig gebouwd of vertelt niet alles. U wilt weten wat de oorzaak was, wanneer de klant het hoorde en wie de rekening droeg. Dat laatste is het scherpst: daar blijkt hoe de partij omgaat met het verschil tussen wat er is geoffreerd en wat er nodig blijkt.
De tweede: mag ik spreken met een klant die al in beheer zit? Referenties zijn bijna altijd net opgeleverde projecten, wanneer de tevredenheid het hoogst is en het onderhoud nog niets heeft gekost. Wie het systeem al langer draait, weet hoe er op een storing buiten kantooruren wordt gereageerd en of de bouwers er nog zijn. Bestaat zo'n referentie niet, dan is dat op zichzelf informatie.
De derde: wie werkt er straks feitelijk aan? In het verkoopgesprek zit vaak de meest ervaren persoon. Vraag wie de code schrijft, hoeveel projecten die tegelijk draait en wat er gebeurt als hij vertrekt. Dat uw gesprekspartner niet de bouwer is, is normaal; dat u de bouwers pas na ondertekening spreekt, niet.
Bureau, detacheerder of freelancer
Deze drie worden meestal op prijs vergeleken, terwijl u bij elk iets anders koopt: bij een bureau een team en een werkwijze, bij een detacheerder capaciteit waarvan u de aansturing zelf houdt, en bij een freelancer één vakman zonder tussenlaag. Detachering werkt alleen als er bij u iemand kan sturen.
Een freelancer lijkt goedkoper omdat u geen overhead betaalt, en dat klopt zolang het goed gaat. Zodra hij ziek wordt, een grotere opdracht aanneemt of ermee stopt, ligt uw systeem stil en moet iemand anders zich inlezen in code die hij niet schreef. Bij een bureau is de overhead echt: u betaalt ook voor mensen die op dat moment niet aan uw project werken. Daar staat tegenover dat vervanging niet uw probleem is en dat meer dan één persoon uw systeem kent.
| Vorm | Wat u koopt | Waar het knelt |
|---|---|---|
| Bureau | ✓Een team, een proces en vervanging als iemand wegvalt | !Overhead die doorloopt, en soms afstand tot de bouwers |
| Detacheerder | ✓Extra handen binnen uw eigen werkwijze | !Richting en samenhang blijven uw verantwoordelijkheid |
| Freelancer | ✓Korte lijnen en een lager tarief | !Alles hangt aan één persoon, en die is ooit een keer weg |
Signalen die er echt toe doen
Kan de partij nee zeggen. Een leverancier die in het eerste gesprek al uw wensen omarmt, is aan het verkopen. Een leverancier die zegt dat een van uw wensen onnodig duur is of pas logisch wordt zodra het systeem draait, denkt mee. Let op wat er gebeurt als u iets vraagt dat technisch onhandig is: krijgt u een alternatief, of alleen een bedrag?
Vraagt hij naar uw proces of alleen naar uw functiewensen. Softwareprojecten lopen zelden stuk op techniek. Ze lopen stuk omdat het systeem een werkwijze moet ondersteunen die in de praktijk anders verloopt dan op papier, met uitzonderingen die niemand noemde omdat ze vanzelfsprekend leken. Wie daarnaar doorvraagt, is met uw probleem bezig. Wie alleen een functielijst afvinkt, bouwt precies wat u vroeg, inclusief de aannames waar u naast zat.
Krijgt u een inschatting of een belofte. Een inschatting heeft een bandbreedte, een onderbouwing en de aannames waaronder hij geldt. Een belofte is een rond getal zonder marge. Vraag waar de onzekerheid zit en wat die zou vergroten; wie daar geen antwoord op heeft, heeft geraden. Hoe u de rest van zo'n document leest, staat in een software-offerte beoordelen.
Vragen om mee te nemen naar het gesprek
Niet elk antwoord hoeft sluitend te zijn; het gaat erom of de vraag wordt herkend.
Wat u vastlegt voordat u tekent
Drie onderwerpen bepalen hoeveel vrijheid u later overhoudt.
Het eigendom van de code. In Nederland ligt het auteursrecht op software in beginsel bij de partij die de code schrijft; betalen voor de bouw levert dus niet vanzelf eigendom op. Let op het verschil tussen overdracht van rechten en een gebruiksrecht, en op onderdelen die uit eigen bibliotheken of open source komen. Regel tegelijk de praktische kant: staan repository, hosting, domeinnamen en accounts op uw naam? Broncode-eigendom en overdracht gaat daar dieper op in. Laat een jurist naar uw eigen overeenkomst kijken; dit is uitleg van het mechanisme, geen juridisch advies.
Wie het beheer doet. Spreek af wie reageert als het systeem stilvalt, en wat onder onderhoud valt en wat als nieuwe opdracht telt. Dat onderscheid is de bron van de meeste latere discussies: wat u herstel noemt, telt bij de leverancier al snel als wijziging.
Wat er gebeurt bij een overstap. Leg vast dat u bij beëindiging de code, de documentatie, uw gegevens in een bruikbaar formaat en een overdracht aan een opvolger krijgt. Een partij die daar ontspannen over is, gaat ervan uit dat u blijft omdat het bevalt.
Goedkoop, duur, en wat werkelijk telt
De laagste offerte is bijna nooit de goedkoopste oplossing, en dat komt zelden door slechte bedoelingen. Een lager bedrag ontstaat doordat er minder is ingecalculeerd: minder analyse, minder testen, minder ruimte voor wat pas tijdens het bouwen zichtbaar wordt. Dat werk verdwijnt niet, het verschuift naar later, waar het meerwerk heet.
De hoogste offerte is evenmin een garantie. U kunt betalen voor een naam, voor een organisatielaag die u niet gebruikt, of voor een team dat het uwe ertussendoor doet. Een bedrag zegt iets over hoe een partij is ingericht, niet over hoe goed hij u begrijpt.
Wat wel voorspelt hoe het gaat lopen, is of de partij uw probleem kan navertellen zonder uw eigen woorden te herhalen. Wie uitlegt waar het bij u knelt en wat hij eerst zou bouwen om dat te toetsen, heeft nagedacht. Welke vormen maatwerk aanneemt per sector leest u op software op maat.
Veelgestelde vragen
Waar let ik op bij het kiezen van een softwareleverancier?
Of de partij past bij wat u uitbesteedt: een afgebakend project vraagt een ander type leverancier dan een systeem dat blijft veranderen. Of hij doorvraagt over uw werkproces en niet alleen over uw functielijst. En of u een onderbouwde inschatting krijgt in plaats van een rond getal.
Is een freelancer of een bureau beter voor softwareontwikkeling?
Dat hangt af van het risico dat u wilt dragen. Een freelancer werkt met korte lijnen en meestal een lager tarief, maar uw systeem hangt aan één persoon. Bij een bureau betaalt u overhead voor projectleiding en vervanging, en dat is wat u terugkrijgt als iemand wegvalt.
Hoe controleer ik een referentie van een softwarebureau?
Vraag niet om de klant die net is opgeleverd, maar om een klant die het systeem al langer in beheer heeft. Die weet hoe er op een storing wordt gereageerd en of de oorspronkelijke bouwers er nog zijn.
Van wie is de broncode als een externe partij mijn software bouwt?
In Nederland ligt het auteursrecht op software in beginsel bij de partij die de code schrijft. Betalen voor de bouw levert dus niet vanzelf eigendom op; dat spreekt u schriftelijk af, samen met toegang tot de repository, de omgevingen en de accounts. Laat een jurist naar uw overeenkomst kijken.