Ben je nog alleen een hardwarebedrijf als software ineens veel makkelijker te bouwen is?

Veel hardwarebedrijven werken nog steeds met een oude, logische scheiding:

Wij bouwen het fysieke product.
De software daaromheen kopen we in.

Dat was lang een verstandige keuze.

Niet omdat software onbelangrijk was, maar omdat software bouwen duur, traag en specialistisch was. Als het niet je kerncompetentie was, was inkopen vaak gewoon rationeler. Zeker als je onderscheid vooral in je machine, apparaat of installatie zat.

Alleen is er iets fundamenteels veranderd.

Een hardwarebedrijf bouw je nog steeds niet zomaar na.
De softwarelaag eromheen wel steeds minder moeilijk.

En precies daar schuift de strategische logica.

Wat veranderd is, is niet de hardware. Het is de maakbaarheid van software.

Een hardwarebedrijf opbouwen blijft lastig.

Je hebt te maken met productie, supply chains, kwaliteitscontrole, certificering, margedruk, fysieke distributie, service, kapitaalbeslag en vaak ook langere ontwikkelcycli. Dat kopieer je niet even.

Maar software is een ander verhaal geworden.

Door moderne tooling, betere cloudinfrastructuur en steeds meer AI-assisted development, inclusief AI agents die een groot deel van het ontwikkelwerk kunnen versnellen, is de drempel om software te bouwen, testen en aanpassen hard gedaald. Niet naar nul. Wel ver genoeg om oude organisatiekeuzes opnieuw te bekijken.

Dat maakt dit voor mij de kernvraag:

Als software rond je product veel makkelijker te bouwen is geworden dan vroeger, waarom zou je die laag dan nog structureel ver van je eigen bedrijf organiseren?

Niet alle software natuurlijk. Wel de software die direct raakt aan hoe je product wordt gebruikt, onderhouden, ondersteund en verbeterd.

Het verschil zit steeds vaker in de laag rond het product

Dat betekent niet dat hardwarebedrijven ineens softwarebedrijven moeten worden in culturele zin.

Wel denk ik dat veel hardwarebedrijven software nog te vaak behandelen als iets wat er een beetje bij hangt.

Een portaal erbij.
Een dashboard erbij.
Een service-interface erbij.
Een app erbij.

Terwijl daar in de praktijk steeds vaker precies het verschil wordt gemaakt.

Niet alleen in consumentenmarkten, maar juist ook in B2B en industrie.

Denk aan vragen als:

• Hoe configureer je een machine?
• Hoe snel zie je storingen?
• Hoe plan je onderhoud?
• Hoe goed werkt remote support?
• Hoe leert je organisatie van wat er in het veld gebeurt?
• Hoeveel frictie ervaart een operator, monteur of klant?

Dat zijn geen bijzaken meer.

Daar komen gebruiksgemak, uptime, snelheid en leervermogen samen. En dus ook een groeiend deel van de klantwaarde.

Je ziet dat patroon op veel plekken terug. John Deere is al lang niet alleen interessant vanwege de machine zelf, maar ook vanwege de digitale laag rond support, monitoring en prestaties. Hilti laat iets vergelijkbaars zien op een toegankelijke manier: de tool blijft belangrijk, maar het systeem rond beheer, service, gebruik en zichtbaarheid is een groot deel van de klantwaarde. Caterpillar en Komatsu laten ook zien dat telematics, onderhoudssignalen en operationele software steeds minder bijzaken zijn.

Dat zijn niet ineens softwarebedrijven geworden.

Het zijn hardwarebedrijven die hebben geleerd dat de softwarelaag rond hun product te belangrijk is geworden om als bijzaak te behandelen.

Vroeger was afstand logisch. Nu moet je die afstand opnieuw verdedigen.

Vroeger was het logisch om software verder van het kernbedrijf te organiseren. Via leveranciers, externe partijen of generieke platforms. Gewoon omdat zelf bouwen vaak te duur, te traag of te ingewikkeld was.

Dat argument is veel zwakker geworden.

Als software sneller te bouwen en aan te passen is, wordt het ook realistischer om die dichter op je productteam, serviceorganisatie en operationele realiteit te zetten.

En dan is het de moeite waard om opnieuw te kijken naar wat je uitbesteedt uit gewoonte, terwijl het eigenlijk allang dicht op je onderscheid zit.

Niet omdat je alles intern moet bouwen. Wel omdat de prijs van afstand veranderd is.

Als een strategische softwarelaag buiten je eigen invloed ligt, verlies je namelijk niet alleen marge. Je verliest ook tempo.

Elke wijziging loopt trager. Leren uit het veld duurt langer. Serviceverbeteringen landen later. Prioriteiten schuiven mee met de roadmap van iemand anders.

Dat voel je niet altijd op dag één. Maar zodra klantverwachtingen veranderen of je sneller wilt verbeteren, merk je het meteen.

Niet alle software is strategisch

Daar zit natuurlijk nuance in.

ERP hoef je meestal nog steeds niet zelf te bouwen. Payroll ook niet. Finance tooling, standaard HR-processen, compliance tooling, generieke CRM-basis en commodity infrastructuur blijven voor de meeste bedrijven gewoon iets om verstandig in te kopen.

Daar win je meestal niet.

Maar de softwarelaag die dicht op je product en operatie zit, is iets anders.

Denk aan:

• configuratie van machines of systemen
• operatorinterfaces
• service- en onderhoudsflows
• remote diagnostics
• dispatch en escalaties
• klantportalen
• usage dashboards
• datalogica die sensordata omzet in acties
• AI-lagen voor support, onderhoud of interpretatie

Dat is software die werk stuurt, beslissingen ondersteunt, frictie verlaagt en leervermogen vergroot.

Juist omdat die laag nu veel toegankelijker is geworden om te bouwen en aan te passen, wordt het strategischer om hem dichter bij jezelf te houden.

Het echte risico

Het risico is volgens mij niet dat je als hardwarebedrijf te weinig software doet.

Het risico is dat je software nog steeds behandelt als iets ondersteunends, terwijl daar in de praktijk al een groot deel van je onderscheid zit.

Dan verkoop je nog steeds hardware, maar iemand anders bepaalt intussen:

• hoe de workflow loopt
• hoe data wordt geïnterpreteerd
• hoe service verbetert
• hoe snel veranderingen landen
• hoe feedback uit het veld terugkomt in de operatie

Dat is niet alleen een afhankelijkheidsprobleem. Het is ook een snelheidsprobleem.

En snelheid wordt belangrijker zodra software sneller maakbaar wordt.

Een praktische beslisregel

Als ik het heel simpel maak, dan is dit mijn vuistregel:

Koop de software die vooral gestandaardiseerd moet zijn.
Breng de software die je product slimmer, bruikbaarder en waardevoller maakt dichter naar je eigen bedrijf.

Niet omdat AI alles oplost.
Niet omdat je dan modern klinkt.
Maar omdat de maakbaarheid van software fundamenteel is veranderd.

En als de maakbaarheid verandert, moet je ook je organisatiekeuzes herzien.

De relevante strategische vraag

Veel hardwarebedrijven hoeven geen softwarebedrijf te worden in identiteit.

Maar ik denk wel dat veel van hen opnieuw moeten nadenken over waar software hoort te zitten.

Want je hardwarebedrijf is niet zomaar gekopieerd.
De softwarelaag rond je hardware wordt wel steeds makkelijker om te bouwen, verbeteren en aanpassen.

Dus de relevante vraag is volgens mij niet:

Moeten we ook software gaan doen?

De relevantere vraag is:

Welke software rond ons product is inmiddels zó belangrijk geworden dat we die niet meer met te veel afstand moeten organiseren?

Werk je in een hardwarebedrijf en merk je dat software steeds belangrijker wordt voor service, uptime of klantwaarde? Dan is dat waarschijnlijk een zinvoller strategisch gesprek dan de abstracte vraag of je "ook een softwarebedrijf" moet worden.

Als je die grens scherper wilt krijgen, praat ik daar graag over mee.

Verder lezen

• Porter & Heppelmann, How Smart, Connected Products Are Transforming Competition
• Porter & Heppelmann, How Smart, Connected Products Are Transforming Companies
• Vandermerwe & Rada, Servitization of Business: Adding Value by Adding Services
• Wise & Baumgartner, Go Downstream: The New Profit Imperative in Manufacturing
• McKinsey, Software-defined hardware in the age of AI