WBSO-ICT definitie niet meer van deze tijd
In een eerder artikel over de WBSO-ICT beschreef ik al de ontstane paradoxale Catch-22 situatie. De volgende situatie is gaande binnen de WBSO regeling voor ICT projecten: Er is een bepaalde problematiek of ‘aanleiding’ om te programmeren. Van tevoren moet men in kunnen schatten welke problemen er binnen het traject verwacht worden én hierbij aangeven hoe deze opgelost kunnen worden. Als men geen oplossingsrichting kan aangeven, voldoet het project zich volgens de criteria niet aan de WBSO. Als de oplossingsrichtingen wel duidelijk zijn, ontstaat echter het gevaar dat de omschreven knelpunten opgelost kunnen worden en dus helemaal niet meer als technische knelpunten bestempeld mogen worden. Stilletjes heeft de RVO de definitie van programmatuur verder aangescherpt, waardoor deze paradox nog relevanter wordt. Daarnaast zien wij een aantal trends in het ICT-landschap die niet verenigbaar zijn met de huidige omschrijving van de WBSO. Is het tijd om de WBSO-definitie aan te passen?
Goede oude tijd
De WBSO is ooit voor de maakindustrie bedacht, vandaar dat er in de regeling veel nadruk gelegd wordt op de ‘fysieke’ ontwikkeling van producten en processen. Gaandeweg zijn er diverse uitzonderingen en bijzonderheden aan de regeling toegevoegd. Veel gevallen van wat in de volksmond R&D wordt genoemd, komt helemaal niet in aanmerking vanwege de nauwe definitie. Hierdoor kwamen er onder andere uitzonderingen voor veredeling van planten (volgens de klassieke regels geen WBSO) of voor het laten uitvoeren van medisch onderzoek (geen eigen ontwikkeling).
Op een gegeven moment is ook programmatuur als subsidiabele activiteit toegevoegd. In de goede oude tijd was bijna al het programmeerwerk WBSO-waardig. Het aan elkaar koppelen van softwaresystemen, implementaties in nieuwe talen en problemen met dataverwerking en -performance kwamen allemaal in aanmerking. Zelfs de fase van het functioneel ontwerp viel binnen de WBSO. Het is dan ook niet gek dat de WBSO subsidie zeer populair is onder ICT bedrijven en het animo jaarlijks blijft groeien.
Pijnpunt in de WBSO-ICT
Door de jaren heen is RVO beduidend strenger geworden met het beoordelen van ICT-gerelateerde WBSO aanvragen. Budgettaire overwegingen lijken hieraan ten grondslag te liggen. Dit vind ik overigens een zeer valide redenatie. Veel IT-ontwikkeling heeft immers weinig met innovatie te maken en kan inderdaad als reguliere ontwikkeling beschouwd worden. Er is ook geen onbeperkt WBSO budget, dus moet er zorgvuldig gekeken worden of er wel echt sprake is van innovatie.
Er wordt echter een arbitraire scheidslijn getrokken. Het bedenken van algoritmes en het uittekenen van hoe software eruit moet gaan zien, wordt niet als WBSO gezien. Alleen het programmeren, en dan specifiek het programmeren van technisch nieuwe software en een nieuw informatietechnologisch werkingsprincipe, wordt beschouwd als subsidiabele activiteit. Deze termen zijn overigens geheel subjectief en staan ook nergens gedefinieerd. In de wettekst staat verder het volgende: “Het (technische) ontwerp, de beschrijving van de architectuur en instructies in natuurlijke taal vallen buiten de definitie van programmatuur”. Bovendien moet het systeem vastgelegd worden in een formele programmeertaal zoals C++ of Java. RVO lijkt zich dan ook in bochten te wringen om de WBSO voor ICT in te perken. Mijns inziens probeert men dit door een nauwe definitie te hanteren die uitsluitend goed op papier klinkt.
Het innovatieve van programmeren zit niet alleen in het inkloppen van codes, maar juist in het bedenken van hoe de algoritmes (samen) moeten werken, het uitdenken van het technisch ontwerp en de gehele inrichting van de programmatuur. Deze onderdelen zijn immers essentieel voor goed werkende software en zijn niet los te koppelen van innovatie. Daarnaast wordt door deze definitie de ontwikkeling in ‘niet-formele programmeertalen’ afgeschoten. Afgaande op onze ervaringen, heeft RVO een voorkeur voor meer low-level programmeertalen. Dit is in strijd met de geest der tijd, waarin nieuwe talen juist steeds meer high-level worden (bijv. Swift) om developers zo snel mogelijk werkende software te kunnen laten programmeren. Programmeren in een taal als C of C++ is voor de meeste toepassingen helemaal niet wenselijk meer, handmatige memory management en low-level controle kan in zeer beperkte omgevingen handig zijn, maar kost voor gebruikelijke toepassingen veel te veel programmeertijd.
Regelgeving sluit niet voldoende aan op praktijk
Door het inkorten van de toegestane werkzaamheden in de WBSO en het uitsluiten van valide programmeertalen, komen minder projecten in aanmerking voor de WBSO. Dit leidt de facto tot een inperking van de WBSO.
Innovatietrajecten in de meest geschikte programmeertaal; dát zou juist aangemoedigd moeten worden. Bovendien is het mijns inziens belangrijk dat men de ruimte krijgt voor een gedegen voorbereiding, hetgeen in de uitvoering weer tijd en dus geld zal besparen. De huidige wat paradoxale situatie beloont het echter om snel te beginnen met programmeren, omdat juist daar de subsidie ligt. De huidige regelgeving sluit mijns inziens dus niet goed aan op de praktijk.
Leidend zou moeten worden wat men doet en of dat innovatief is of niet. Minder belangrijk wordt dan welke tools hiervoor gebruikt worden. In een veranderend ICT-landschap, waarin open source en high-level talen steeds meer de norm worden, lijkt een hervorming van de WBSO mij noodzakelijk. Op termijn zal anders amper nog IT-ontwikkeling in aanmerking komen voor de belangrijkste innovatieregeling van Nederland.
Nils Kooijman – Senior Consultant
Meer weten over WBSO-ICT? Neem contact op!
Of bel direct naar: 088 495 20 00
