De fiscale stimulerings-regeling voor speur- en ontwikkelingswerk (WBSO) is sinds jaren het voornaamste instrument om innovatie te bevorderen. Een dikke 250 miljoen euro stroomt vanuit hier jaarlijks naar ict-projecten en dan vooral softwareontwikkeling.
In 2018 stelden we bij de evaluatie van de WBSO vast dat de definitie van programmatuur niet meer voldoet. Want ‘het niet-fysieke, logische deelsysteem van een informatiesysteem dat de structuur van de gegevens en van de verwerkingsprocessen bepaalt voor zover dat deelsysteem is vastgelegd in een formele programmeertaal’.
De kritiek is dat deze definitie te veel nadruk legt op het programmeren zelf, terwijl de stappen die hieraan vooraf gaan belangrijker zijn, zoals de software-architectuur en algoritmiek. Ook embedded en besturingssoftware valt buiten de regeling, een cruciale omissie. Een derde bezwaar is dat de definitie voorbijgaat aan de manier waarop we nu software ontwikkelen. De WBSO gaat van een lineair proces uit, terwijl software een meer iteratief (agile) ontwikkeling ondergaat.
Herdefiniëring
In opdracht van het ministerie kwamen Jan Friso Groote en Mariëlle Stoelinga, beiden software-hoogleraar, met een herdefiniëring. Die luidt: programmatuur is een precieze beschrijving van waaruit het gedrag van een computergestuurd systeem eenduidig is af te leiden. Deze programmatuur moet door mensen navolgbaar zijn. Daarbij is het technisch of mathematisch verifieerbaar dat het beoogde doel ermee wordt bereikt. Volgens Groote en Stoelinga mag de beschrijving compact zijn zolang een voldoende getraind expert alles kan begrijpen. Maar meestal zal voldoende en precieze documentatie nodig zijn.
Stoelinga noemt het belangrijk dat programmatuur meer behelst dan executeerbare programmacode. Ook nieuwe architectuur, uitgedrukt in een model, moet onder de definitie vallen. Volgens haar is het uitdrukkelijk de bedoeling dat alle programmatuur (en –modellen) verifieerbaar is. ‘Wie een brug bouwt, moet ook sterkteberekeningen doen om te zorgen dat deze niet in stort. Programmatuur dient in de eerste plaats begrijpelijk te zijn. Anders is deze niet toekomstbestendig. Daarnaast moet duidelijk zijn dat de software ook doet wat-ie geacht wordt te doen.’
Activiteiten die bewezen niet effectief zijn zoals niet-gedocumenteerde en onbegrijpelijke code, moeten van subsidie worden uitgesloten.
Groote en Stoelinga hebben bij de definiëring rekening gehouden met de voornaamste trends op softwaregebied: complexiteit, software integratie en low-coding, legacy, agile development, model-driven engineering, domein-specifieke talen, artificial intelligence en big data. Stoelinga vindt dat het verbeteren van legacy-code ook subsidiabel moet zijn. ‘Legacy is een enorm probleem. Onderhoud is belangrijk om software werkend, secure en up-to-date te houden.’ Simulatie en ict-tools zoals code-generatie uit modellen en low-coding-platforms, hebben zich volgens Stoelinga goed bewezen bij de ontwikkeling van software. De oude definitie van programmatuur sloot deze uit.
Kortom, voer voor discussie. Wat vindt u van deze nieuwe definitie? Is deze werkbaar? Hoeveel bewijsvoering moet de aanvrager erbij leveren? Hoe verifieerbaar moet alles zijn? En doet de definitie recht aan alle trends op softwaregebied? En hoe staat u tegenover de ondersteuning van modellering en simulatie door middel van ict-tools?
Ik heb er lang over nagedacht en ben tot de conclusie gekomen dat het me in het geheel niet kan boeien.
Kan het BIT dat niet gaan toetsen ? Maar dan niet bindend advies natuurlijk, zodat het RVO dat weer naast zich neer kan leggen.
Iedereen blij.
Laat me raden, achteraf gaan we weer klagen als de nieuwe Cobol-krassers zo’n 32% goedkoper blijken te zijn door een fiscale innovatie middels WBSO? De definitie van de lading is misschien niet interessant maar de jaarlijkse verdeling van zo’n €3 miljard aan gemeensschapsgeld voor het bedrijfsleven wel. Ik neem aan dat inspanning om tot andere definities te komen voortkomt uit de aanbeveling in het rapport betreffende de evaluatie over de doelmatigheid van WBSO regeling:
“We bevelen het ministerie van EZK dan ook aan om, met inzet van onafhankelijke expertise, de wijze waarop R&D in ICT en softwareontwikkeling in Nederland het beste gestimuleerd kan worden opnieuw te bezien.” – Paragraaf 6.3 punt 6 op bladzijde 182.
Betreffende de onafhankelijke expertise zijn er steeds meer maatschappelijke geluiden dat een wetenschappelijke besluitvorming aangaande het (fiscale) beleid leidt tot een technocratie, de slager die zelf het vlees aangaande de subsidies keurt blijkt tenslotte nog weleens tegenstrijdige deelbelangen te hebben in de verdeling van de subsisies. Want met subsidie een noodlijdend bedrijf overeind houden blijkt niet doelmatig en binnen Europees verband misschien zelfs wel onrechtmatig. Fiscale technocraten voeren dan ook discussie over nationale R&D tax incentives:
“For many years, the Netherlands has had several very attractive R&D incentives. This has resulted in the Netherlands being a favorable location for carrying out R&D activities, also for foreign companies. Combined with the favorable Dutch corporate tax regime, an educated and experienced workforce and easy access to the European market, the Dutch R&D incentives have proven to be very successful over the years.” – KPMG rapport EMEA tax R&D incentives.
Ik vraag me af voor wie dit fiscale beleid succesvol is want gezien toenemende klachten over arbeid als vlottende activa op de balans lijkt het erop dat Nederlandse R&D regeling misbruikt wordt door de ‘grote’ belastingplichtigen om zodoende immateriële activa fiscaal gunstiger in de boeken te zetten. De onbegrijpelijke proza van een bedot.com economie door boekhoudkundige innovatie maakt in elk geval duidelijk dat het doorgronden van de complexiteit een expertise vraagt die uiteindelijk weer gebonden is aan het belang van een bepaalde groep technocraten.
Het gaat dus om een domein-specifieke definitie ten behoeve van de verdeling van zo’n 250 miljoen WBSO-subsidies voor innovaties.
Niet alleen beperkt relevant, maar ook in hoge mate wetenschaps-filosofisch.
Software-onderhoud en -documentatie heeft niets met de definitie van doen. Software Re-Engineering, Prototyping en Mark-Up Languages lijken alweer buiten de definitie te vallen
En dan heb ik het nog maar niet eens over zaken als ISO9126 of het Quint/Extended ISO9126-model.