7 fouten die mkb-bedrijven maken bij het kopen van maatwerksoftware

De meeste kleine bedrijven die hun vingers branden aan een maatwerksoftwareproject, branden ze niet aan slechte programmeurs. Ze branden ze weken voordat er ook maar iets geprogrammeerd is — in een kick-offmeeting, een mailwisseling, een handdruk — door een beslissing die op dat moment klein leek. Tegen de tijd dat de code er is, zit de fout er al ingebakken. Het goede nieuws is dat deze fouten saai voorspelbaar zijn, wat betekent dat ze te vermijden zijn als u weet hoe ze eruitzien.

Ik heb veel van deze projecten van binnenuit gezien, aan beide kanten van de tafel. Sommige werden tools waarvan een bedrijf zich niet kon voorstellen dat het ooit zonder had gewerkt. Andere werden een half afgebouwd inlogscherm, een gespannen factuurconflict en een ondernemer die zwoer nooit meer voor maatwerk te kiezen. Het frustrerende is hoe weinig die twee uitkomsten scheidde. De techniek was zelden het probleem. De beslissingen rond de techniek bijna altijd wel.

Dus hier zijn de zeven fouten die ik keer op keer zie wanneer een klein bedrijf maatwerksoftware laat bouwen. Geen ervan vereist een technische achtergrond om te vermijden. Ze vereisen alleen dat u weet dat ze bestaan voordat u iets tekent.

Fout 1: Een oplossing kopen voordat u het probleem begrijpt

De duurste fout gebeurt als eerste, en hij klinkt onschuldig: “We hebben een app nodig die X doet.” Tegen de tijd dat iemand dat hardop zegt, heeft hij meestal al de vorm van de oplossing bepaald — een dashboard, een portaal, een mobiele app — zonder dat iemand het werkelijke probleem in gewone taal heeft opgeschreven. De bouw levert vervolgens trouw het verkeerde af, prachtig.

Goede software begint bij een probleemstelling, niet bij een lijst met functies. “Ons kantoorteam typt elke bestelling uit de e-mail over in het boekhoudsysteem, en dat kost twee mensen een halve dag” is een probleem. “We hebben een maatwerk-CRM nodig” is een gok naar een oplossing voor een probleem dat niemand de moeite nam te benoemen. Het eerste is goedkoop op te lossen en meetbaar. Het tweede is een open uitnodiging om geld uit te geven.

Fout 2: Alles tegelijk willen bouwen

Maatwerksoftware voelt als een aankoop van eens in de tien jaar, dus mensen proberen tien jaar aan wensen in versie één te proppen. Elke afdeling voegt een verzoek toe. Elk "nu we toch bezig zijn" krijgt een ja. De scope zwelt op, de planning verdrievoudigt, en het project bezwijkt onder zijn eigen ambitie nog lang voordat iemand het gebruikt.

De bedrijven die slagen doen het tegenovergestelde. Ze kiezen het meest pijnlijke deel van het probleem en bouwen dat eerst — een echt, werkend ding in productie binnen een paar maanden. Daarna laten ze het werkelijke gebruik vertellen wat het volgende is. Dit is niet alleen goedkoper; het is veiliger. U leert of het idee werkt terwijl de inzet nog klein is, in plaats van na zes maanden en een dikke factuur te ontdekken dat u het verkeerde hebt ontworpen.

Daaronder schuilt een harde waarheid: u weet nog niet echt wat u nodig hebt. Niemand weet dat aan het begin. Uw begrip van het probleem verandert op het moment dat echte mensen een echte tool aanraken. Alles vooraf bouwen legt uw vroegste, minst geïnformeerde gokken vast. In stukjes bouwen houdt u flexibel — en houdt het budget onder controle terwijl u nog aan het leren bent.

Fout 3: Alleen op prijs kiezen

U krijgt drie offertes. Eén is dramatisch goedkoper dan de andere. Opluchting — die neemt u. Dit is een van de meest betrouwbare manieren om een klein project in een duur project te veranderen, want de goedkope offerte betekent bijna nooit dat het werk goedkoper is. Meestal betekent het dat beide partijen de opdracht anders begrepen.

Een laag bedrag wijst vaak op een van een paar dingen: de leverancier heeft de scope te laag ingeschat omdat hij te weinig vragen stelde, hij is van plan zijn marge later op meerwerk te halen, of hij is onervaren en weet nog niet wat hij niet weet. Geen daarvan loopt goed voor u af. De koptekstprijs is het minst bruikbare getal in de offerte. Wat telt is of de leverancier uw probleem duidelijk begrijpt, ongemakkelijke vragen stelt en eerlijk is over wat er niet bij zit.

Fout 4: Vergeten dat software geen eenmalige aankoop is

Maatwerksoftware wordt vaak gepitcht, en gekocht, als een meubelstuk: één keer betalen, voor altijd bezitten. Zo is het niet. Software leeft in een bewegende wereld — besturingssystemen updaten, browsers veranderen, beveiligingspatches landen, uw bedrijf verschuift, de tools waarmee u koppelt veranderen hun regels. Een tool die niemand onderhoudt, stopt langzaam met werken en breekt dan op het slechtst denkbare moment.

Dit treft kleine bedrijven hard omdat de onderhoudskosten onzichtbaar zijn bij het tekenen. U vergelijkt twee offertes op de bouwprijs en stelt nooit de vraag die meer telt: wat kost het om dit elk jaar levend en gezond te houden? Hosting, updates, kleine reparaties, af en toe een wijziging als uw bedrijf evolueert — reken erop als een normale, terugkerende kostenpost, zoals u dat doet voor verzekeringen of boekhouding. Het is meestal bescheiden, maar alleen als u het verwacht.

Fout 5: De eisen vaag en zonder eigenaar laten

"Jullie zijn de experts, bouw gewoon iets goeds" klinkt genereus. Het is eigenlijk hoe projecten gaan zwerven. De mensen die uw bedrijf het best begrijpen, bent u en uw team — niet de ontwikkelaars. Als u een vage briefing overhandigt en verdwijnt, vult de leverancier de gaten met zijn beste gok, en die gokken ontdekt u op het slechtste moment: bij oplevering, wanneer ze veranderen het duurst is.

Twee rollen moeten aan uw kant worden ingevuld, en kleine bedrijven vullen er routinematig geen van beide in. De eerste is een enkele beslisser — één persoon die ja kan zeggen, meningsverschillen tussen afdelingen kan beslechten en niet weken te druk is om vragen te beantwoorden. De tweede is de bereidheid om specifiek te zijn over de dingen die ertoe doen: de uitzonderingsgevallen, de vreemde uitzondering die uw bedrijf altijd met de hand heeft afgehandeld, de regel die iedereen kent maar niemand opschreef. Dat is precies waar de software het goed moet doen.

Fout 6: Niet vragen wie de code en de data bezit

Dit is de stille, en het is degene die jaren later het meest pijn doet. U betaalt voor maatwerksoftware, u gaat ervan uit dat het van u is. Dan verzuurt de relatie met de leverancier, of hij verhoogt de prijzen, of hij verdwijnt gewoon — en u ontdekt dat u niet weg kunt. U hebt de broncode niet. De data zit in een systeem dat alleen zij kunnen benaderen. Uw hele bedrijfsvoering hangt nu af van een bedrijf dat u niet meer vertrouwt, en u hebt geen onderhandelingspositie.

Niets hiervan vereist een advocaat om te voorkomen. Het vereist drie eenvoudige vragen die voordat u begint worden gesteld, terwijl u nog alle onderhandelingskracht hebt: Wie bezit de broncode als dit klaar is? Kan ik al mijn data exporteren, in een bruikbaar formaat, wanneer ik maar wil? En als we uit elkaar gaan, wat neem ik dan precies mee? Een betrouwbare partner beantwoordt deze zonder met de ogen te knipperen. Aarzeling hier is de allergrootste rode vlag in het hele proces.

• Leg schriftelijk vast dat u de broncode bezit, of er een heldere, eerlijke licentie op hebt.
• Bevestig dat u uw eigen data in een standaardformaat kunt exporteren, op verzoek, zonder toestemming.
• Zorg dat het werk goed genoeg is gedocumenteerd zodat een andere ontwikkelaar het kan oppakken.
• Vermijd propriëtaire lock-in waar een gewone, bekende technologie hetzelfde werk zou doen.
• Spreek vooraf af wat er met hosting en accounts gebeurt als u ooit van leverancier wisselt.

Fout 7: De lancering als eindstreep behandelen

De software is opgeleverd, hij werkt, iedereen is opgelucht. Het project wordt klaar verklaard. Zes maanden later is de helft van het team stilletjes teruggegleden naar de oude spreadsheet, en de dure nieuwe tool wordt door twee mensen voor één ding gebruikt. De bouw slaagde. De adoptie mislukte — en dat zijn twee totaal verschillende problemen.

Mensen verzetten zich niet tegen nieuwe tools omdat ze dom of koppig zijn. Ze verzetten zich omdat de nieuwe manier onbekend is en de oude manier nog werkt, een beetje. Dat overwinnen vergt bewuste inspanning die niemand begrootte: een beetje training, een duidelijke reden waarom de verandering hen specifiek helpt, iemand die in de eerste weken de domme vragen zonder oordeel beantwoordt, en een stevig besluit om de oude manier af te schaffen zodat er geen terugval mogelijk is.

1. 1
   Lanceer eerst bij een kleine groep

   Rol de tool uit bij een paar bereidwillige mensen voordat het hele team meedoet. Zij vinden de scherpe randjes en worden uw interne ambassadeurs.
2. 2
   Toon de persoonlijke winst, niet de bedrijfswinst

   "Dit bespaart het bedrijf geld" motiveert niemand. "Dit betekent dat u geen adressen meer dubbel hoeft te typen" krijgt mensen mee.
3. 3
   Wijs een aanspreekpunt voor vragen aan

   De eerste maand neemt iemand de domme vragen op zich. Wrijving in week één is wat de adoptie voorgoed de kop kost.
4. 4
   Zet de oude manier echt uit

   Zolang de oude spreadsheet bestaat, blijven mensen hem gebruiken. Zodra het werkt, schaft u de terugvaloptie af — zachtjes maar duidelijk.

Alles samen: de mindset van een koper

Lees die zeven terug en er loopt één rode draad doorheen. Bijna geen ervan is technisch. Ze gaan over duidelijkheid, eigenaarschap en terughoudendheid — uw probleem kennen voordat u winkelt, in kleine stappen bouwen, leveranciers beoordelen op begrip in plaats van prijs, plannen voor het leven van de tool en niet alleen de geboorte, betrokken blijven, uw uitgang beschermen, en de lancering behandelen als het begin van het echte werk.

Maatwerksoftware is werkelijk een van de beste investeringen die een klein bedrijf kan doen zodra het de kant-en-klare tools die iedereen deelt ontgroeid is. Een systeem dat precies gevormd is rond hoe u werkt, in plaats van uw bedrijf te dwingen zich naar het product van iemand anders te wringen, is een echt en blijvend voordeel. De bedrijven die daar komen, zijn niet die met de grootste budgetten. Het zijn die welke de zeven fouten hierboven vermeden — en dat is een kwestie van oordeel, niet van geld.

Veelgestelde vragen