Maatwerk of een standaardpakket: hoe kies je?

Je zoekt software voor een proces dat nu in spreadsheets en e-mail leeft. Er is een pakket dat het grotendeels doet, en er is de mogelijkheid om het te laten bouwen. Die keuze gaat zelden over techniek. Hij gaat over de vraag hoeveel van je eigen werkwijze je wilt inleveren, en wat dat waard is.

Waar kies je eigenlijk tussen?

Een standaardpakket is de werkwijze van iemand anders, netjes uitgewerkt en door duizenden bedrijven versleten. Je krijgt updates, documentatie en mensen op de markt die ermee kunnen werken. Daar staat tegenover dat jij je aanpast aan het pakket.

Software op maat is jouw werkwijze, vastgelegd in code. Je bepaalt wat het doet en wat het niet doet. Daar staat tegenover dat jij eigenaar bent van het geheel: beheer, updates, beveiliging en de kennis om het aan te passen. Wat daarbij komt kijken staat bij software op maat.

De vraag is dus niet welke van de twee beter is. De vraag is welk deel van je proces bijzonder genoeg is om zelf vast te leggen.

Waarom loopt de keuze meestal vast?

Drie patronen zie je steeds terug.

• De demo: je ziet het pakket op zijn mooist, met schone data en zonder jouw uitzonderingen. Wat je beoordeelt is de demo, wat je krijgt is je eigen administratie.
• De eisenlijst: honderd regels waarvan er negentig voor elk pakket gelden. De tien die er echt toe doen verdwijnen in de massa.
• Het uitzonderingsgeval: een enkele klant met een eigen prijsafspraak wordt de reden om alles te laten bouwen, terwijl het om een paar procent van de orders gaat.

Alle drie komen ze uit hetzelfde tekort. Er ligt geen beschrijving van het proces zoals het vandaag werkelijk loopt, dus wordt er gekozen op gevoel.

Stap 1: schrijf op wat het proces nu echt doet

Loop het proces een keer na met de mensen die het uitvoeren, niet met de mensen die het ooit hebben beschreven. Noteer per stap wie hem doet, waar het gegeven vandaan komt, hoe lang het duurt en hoe vaak het misgaat.

Je zoekt vooral de stappen die niet in het handboek staan. Het belletje naar de planner, het tabblad naast het systeem, de mail die iemand doorstuurt omdat het systeem het niet kan. Precies daar zit het verschil tussen een pakket en eigen software.

Stap 2: scheid wat gewoon is van wat bijzonder is

Zet elke stap in een van twee kolommen. Gewoon betekent: elk bedrijf in jouw sector doet dit ongeveer zo. Bijzonder betekent: dit is de reden dat klanten voor jou kiezen, of het volgt uit een afspraak die je niet kunt veranderen.

Boekhouding, salaris en urenregistratie zijn bijna altijd gewoon. Daar bestaan goede pakketten voor en die ga je niet verslaan. Je prijsopbouw, je planlogica of de manier waarop je een dossier opbouwt kunnen wel bijzonder zijn.

Is bijna alles gewoon, koop dan. Zit het bijzondere midden in je omzet, dan is zelf bouwen te verdedigen.

Stap 3: toets pakketten op je uitzonderingen

Ga niet af op de functielijst. Geef de leverancier drie echte gevallen uit je eigen administratie, inclusief de lastige, en vraag of hij die in de demo-omgeving wil uitvoeren. Niet beschrijven, uitvoeren.

Let op het antwoord dat iets kan met een kleine aanpassing. Vraag door wie die aanpassing bouwt, wat hij kost en wat ermee gebeurt bij de volgende update van het pakket. Een pakket met twintig aanpassingen is in beheer duurder dan eigen software.

Stap 4: reken vijf jaar door, niet een

Zet beide kanten naast elkaar over vijf jaar. Bij een pakket: licenties per gebruiker, implementatie, koppelingen, aanpassingen, migratie van je data en de uren die je eigen mensen erin stoppen. Bij eigen software: bouw, hosting, beheer, doorontwikkeling en het risico dat de kennis bij een partij blijft hangen.

Licenties per gebruiker worden het vaakst onderschat. Ze groeien mee met je personeel, ook als het gebruik niet meegroeit. Richtbedragen voor eigen software staan bij wat een webapplicatie kost. Wat het huidige handwerk je kost, reken je uit bij de kosten van handmatig werk.

Reken in dezelfde som ook de opbrengst mee. Hoe dat model eruitziet staat in de businesscase berekenen. Voor automatisering zonder AI werkt precies dezelfde opzet.

Waar let je op bij een standaardpakket?

Op drie dingen die pas na de handtekening zichtbaar worden.

• Je data: kun je er zonder de leverancier bij, via een export of een API, en zitten alle velden erin of alleen de basis?
• De koppelingen: bestaat er een verbinding met je boekhouding en je webshop, en welke gegevens gaan er mee? Wat per pakket mogelijk is staat bij de koppelingen.
• Het releasebeleid: hoe vaak komt er een update, en wat gebeurt er dan met jouw aanpassingen?

Wanneer is zelf bouwen een slecht idee?

Als er binnen je bedrijf niemand is die de beslissingen over de software neemt. Eigen software zonder eigenaar wordt binnen twee jaar een systeem dat niemand meer durft aan te raken.

Ook als het proces nog elke maand verandert. Dan leg je iets vast dat nog niet vaststaat. En als het volume klein is: vijftien handelingen per week rechtvaardigen zelden een eigen systeem.

Bestaat er een tussenweg?

Ja, en die wordt het vaakst gekozen. Je neemt pakketten voor het gewone werk en je bouwt alleen het bijzondere stuk zelf. Dat eigen deel praat via koppelingen met de rest. Wat zo'n verbinding kost staat in wat een koppeling kost.

Weet je nog niet welk stuk dat zou moeten zijn, dan is dat precies wat de AI Opportunity Audit uitzoekt: waar in je proces het werk blijft liggen, en of een pakket, een koppeling of eigen software het antwoord is.