· 6 min lezen
De kmo die per ongeluk een softwarebedrijf werd.
De meeste owner-led kmo's waar ik bij word geroepen, hebben nooit beslist om een softwarebedrijf te worden. Ze werden er een op de dag dat een enkel intern systeem, gebouwd door twee mensen en een agency, het ding werd waar de zaak geen dag zonder kan. Dat is het ongeluk: softwarerisico zonder softwareleiderschap. De oplossing is niet een techbedrijf worden. Het is de software een eigenaar geven en een volwassene in de kamer zetten met de leverancier.
Hoe wordt een kmo een softwarebedrijf zonder het te beslissen?
In kleine, redelijke stappen. Een spreadsheet wordt een tool. De tool krijgt een database. Een agency wordt ingehuurd voor de stukken die niemand intern kan bouwen. Een of twee zelfgeleerde mensen, meestal degenen die met de spreadsheet begonnen, houden het geheel in hun hoofd. Vijf jaar later draait de orderflow, de prijszetting, het klantenportaal of de productieplanning op eigen code, en een bedrijf dat meubels, verzekeringen of logistiek verkoopt, is stilletjes een softwarebedrijf dat nooit iemand aanwierf om software te leiden. Niemand koos hiervoor. Elke afzonderlijke beslissing was juist. De som is een bedrijfskritisch systeem zonder eigenaar, zonder roadmap, en met een leverancier die niemand in huis kan beoordelen.
De vorm is opvallend consistent. In België en Nederland zie ik ze meestal bij winstgevende bedrijven met 40 tot 400 medewerkers, vaak familiaal of owner-led, in een sector die niets met software te maken heeft: productie, distributie, dienstverlening, een groothandel met een portaal. De omzet is echt en de marges zijn in orde. Wat ontbreekt, is iemand wiens job het is om naar de software te kijken als een systeem in plaats van een reeks tickets.
Wat het echt betekent
Het betekent dat je softwarerisico draagt zonder softwareleiderschap, en dat risico duikt op twee plaatsen op. Het eerste is concentratie: het systeem dat de zaak draait, leeft in het hoofd van een of twee mensen, dus hun opzegtermijn is nu je grootste operationele blootstelling en niemand heeft opgeschreven waarom iets is zoals het is. Het tweede is toezicht: je kan niet zeggen of de factuur van de agency correct is, omdat niemand intern het werk goed genoeg leest om het te aanvaarden of af te keuren. Je betaalt voor capaciteit die je niet kan beoordelen en je hangt af van kennis die je niet bezit.
Het patroon herhaalt zich over opdrachten heen. In een geval dat ik uitschreef was een klantenportaal al 18 maanden "drie maanden weg", factureerde de agency tegen een contract dat niemand technisch kon inschatten, en besteedde de interne lead zijn weken aan het nakijken van werk dat hij geen mandaat had om af te keuren. De blokkade was geen code. Het was dat niemand de beslissingen bezat, en niemand het mandaat had om nee te zeggen.
Wat je eraan doet
Begin met het hardop te benoemen. In het deel van de zaak dat telt, ben je nu een softwarebedrijf, en het organigram mag dat toegeven. Dan drie zetten, in volgorde.
- Geef het systeem een eigenaar met het mandaat om nee te zeggen. Vaak zit die persoon er al: de zelfgeleerde lead die het ding bouwde en zowel de code als de klanten begrijpt. Promoot hem in de rol, met de titel, de loonstap en de bevoegdheid om het werk van een leverancier af te keuren. Een bekwame insider met een mandaat verslaat een externe aanwerving die de zaak eerst nog moet leren.
- Zet de leverancier onder volwassen toezicht. Iemand moet het contract en de codebase in dezelfde week lezen, beslissen of de blokkade code is of beslissingen die het bedrijf nooit maakte, en de scope van de agency herschrijven zodat ze voor resultaten betaalt in plaats van voor benoemde profielen. Dat is het werk, en het is het snelste geld dat je zal vinden.
- Zorg voor een roadmap die de eigenaar kan lezen. Geen backlog. Een korte lijst van wat de software de komende twee kwartalen moet doen, wat ze moet stoppen te doen, en wat ze kost. Zodra die bestaat, verdwijnt de meeste paniek, want het risico wordt een plan.
Niets hiervan vraagt dat je een techbedrijf wordt. Het vraagt een paar dagen per maand toezicht van iemand die eerder software heeft geleid, en dat is net de vorm van werk waar de kmo-praktijk voor gemaakt is. De meeste owner-led bedrijven in deze positie zijn een promotie en een heronderhandeling verwijderd van zichzelf deblokkeren.
Wanneer dit prima is, en wanneer je niet moet overcorrigeren
Niet elke kmo met software heeft dit probleem. Als een bekwame persoon het systeem bezit, de kennis opgeschreven staat, en de leverancier op resultaten wordt beoordeeld, dan zit je goed en heb je mij niet nodig. Als je software een publieke website is en een standaard ERP die je niet aanpast, ben je geen softwarebedrijf en moet je niet doen alsof.
De faalmodus in de andere richting is even duur. Een eigenaar die net doorheeft dat software kritisch is, gaat soms overcorrigeren: een VP of Engineering aanwerven, een platformteam optuigen en een herbouw starten voor een probleem dat een eigenaar en een beter contract nodig had. Op maat brengen werkt in twee richtingen: dezelfde discipline die zegt wanneer je een te groot team afslankt, zegt ook bouw geen software-organisatie die je niet nodig hebt. Stem het leiderschap af op het risico, niet op de mode.
Veelgestelde vragen
Hoe wordt een bedrijf per ongeluk een softwarebedrijf?
In kleine, redelijke stappen die niemand als strategie berekende. Een spreadsheet wordt een tool, de tool krijgt een database, een agency wordt ingehuurd voor de stukken die niemand intern kan bouwen, en een of twee zelfgeleerde mensen houden het geheel in hun hoofd. Vijf jaar later draait de orderflow, de prijszetting, het klantenportaal of de productieplanning op eigen code, en een bedrijf dat meubels, verzekeringen of logistiek verkoopt, is stilletjes een softwarebedrijf dat nooit iemand aanwierf om software te leiden. Elke afzonderlijke beslissing was juist. De som is een bedrijfskritisch systeem zonder eigenaar, zonder roadmap, en met een leverancier die niemand in huis kan beoordelen.
Heeft een kmo die op maatwerk draait een CTO nodig?
Meestal heb je een eigenaar en volwassen toezicht op de leverancier nodig, geen voltijdse CTO. Als een systeem bedrijfskritisch is, hoort een benoemde persoon de roadmap te bezitten en het mandaat te hebben om het werk van een agency af te keuren, en die persoon zit vaak al binnen: de lead die het bouwde. Een paar dagen per maand fractional toezicht volstaat om het contract te beoordelen, de open beslissingen te forceren en de insider te steunen. Een voltijdse aanwerving is pas juist als de software het product is en de roadmap groot genoeg is om een leider bezig te houden.
Waaraan zie je dat je bedrijf een softwarebedrijf is geworden?
Twee tekenen beslissen het. Ten eerste: een systeem waar de zaak geen dag zonder kan, leeft in het hoofd van een of twee mensen, dus hun opzegtermijn is je grootste operationele risico. Ten tweede: je kan niet zeggen of de factuur van de agency correct is, omdat niemand in huis het werk goed genoeg leest om het te aanvaarden of af te keuren. Zijn beide waar, dan ben je al een softwarebedrijf in het deel dat telt, en blijft alleen de vraag over wie het bezit.
Vraagt dit om een fractional CTO of een interim CTO?
Meestal niet. Een paar dagen per maand fractional toezicht, hierboven beschreven, volstaat. Een interim CTO, volle bevoegdheid voor een afgebakende periode met een vertrek dat vanaf dag één vastligt, past bij een smaller geval: de interne lead die het systeem bouwde staat op het punt te vertrekken, levering ligt al stil, of er komt een herstructurering aan en de board wil ze laten uitvoeren door iemand zonder geschiedenis in het gebouw. Dat is dezelfde stoel in België en in Nederland, ingenomen zolang de situatie het vraagt en geen week langer.
Geschreven vanuit patronen uit eerdere opdrachten. Als iets te specifiek klinkt om algemeen te zijn, is dat de reden.