Hoewel de WBSO-regeling op alle vlakken technologisch vernieuwende ontwikkelingen stimuleert, is de rol van programmatuurontwikkeling binnen deze regeling altijd een lastige geweest. Waar bij bijvoorbeeld machinebouw op tastbare wijze inzichtelijk kan worden gemaakt waar de technische belemmeringen liggen, is dit binnen programmatuurontwikkeling heel anders. Door gebruik van open-source componenten, bestaande frameworks en andere tooling is zelf ontwikkelde en bestaande technologie bijna per definitie met elkaar verweven. Hoe dan worden aangetoond dat er planmatig aan eigen speur- en ontwikkeling wordt gewerkt? Wanneer is een tekortkoming van een bestaande tool of techniek een aanleiding voor eigen ontwikkeling, en wanneer is dit een technische belemmering bij het realiseren van het einddoel? Dit spanningsveld is permanent aanwezig bij zowel het aanvragen als de uitvoering van de WBSO-regeling.

S&O binnen programmatuurontwikkeling door de jaren heen
Gedurende de afgelopen jaren is door verschillende ingrepen getracht meer duidelijkheid te brengen in de relatie tussen WBSO en programmatuur-ontwikkeling. In 1997 werden binnen een zogenaamde afbakeningsregeling extra voorwaarden aan programmatuur binnen de WBSO gesteld. In 2009 is de S&O-definitie uitgebreid met programmatuurontwikkeling t.b.v. ICT-diensten en in 2016 is programmatuurontwikkeling explicieter omschreven in de regeling S&O-afdrachtsvermindering zelf. In het kort kan S&O binnen programmatuur nu worden samengevat als planmatig (dus vooraf te beschrijven) technisch ontwikkelwerk aan een eigen oplossing, waarbij de ontwikkelaar tegen tekortkomingen van bestaande technologische tools/technieken aanloopt en de eigen oplossing die hiervoor wordt geprogrammeerd technisch risico's bevat. Een extra voorwaarde hierbij is dat in een formele programmeertaal wordt gecodeerd. Hoewel de exacte definitie hiervan niet wordt gegeven, moet hierbij worden gedacht aan talen als Java, C#, Python, PHP, Ruby.

Deze nieuwe en meer complete omschrijving schuurt soms nog steeds met de realiteit. Dit komt mede doordat de wereld op IT gebied zo ontzettend hard evolueert, dat regelgeving en beleid dit niet altijd kunnen bijhouden. Denk hierbij alleen al aan de voortdurend groeiende inzet van open-source projecten en de beweging naar cloud- en service-gerichte architecturen, waardoor de mix van eigen- en bestaande technologie steeds groter wordt. Maar ook de alsmaar grotere rol van DevOps en thema's als Continuous Integration/ Continuous Delivery zijn soms lastig binnen de definitie van S&O te plaatsen, terwijl hier gevoelsmatig voor een onderneming veel innovaties met technische risico's plaatsvinden. En tenslotte is natuurlijk ook de opkomst van ML en AI een urgent onderwerp. Data engineers ontwikkelen soms zeer complexe algoritmiek, maar omdat dit niet altijd in een formele programmeertaal gebeurt, roept dit bij beoordelingen vraagtekens op. Maar ook hier kan innovatieve technologie worden ontwikkeld.

Evaluatierapport en aanbevelingen
In het onafhankelijke evaluatierapport WBSO 2011-2017 (uitgekomen in april 2019) is aanbevolen nader te onderzoeken hoe ICT en softwareontwikkeling het beste kan worden gestimuleerd. Dit onderzoek is vervolgens door twee onafhankelijke experts uitgevoerd en afgelopen juli is een rapport met hun bevindingen uitgekomen.

Eén van de aanbevelingen is het wijzigen van de definitie van programmatuur zoals die binnen de WBSO wordt aangehouden, waardoor vernieuwende vormen van ontwikkeling ook in aanmerking zouden komen. Daarnaast worden enkele aanbevelingen gedaan t.b.v. verruiming van de activiteiten die passen binnen de WBSO. Zo wordt aangeraden ook hoogstaande toepassing van ML en AI toe te laten, waar nu alleen ontwikkeling van eigen AI en ML in aanmerking komt. Ook het uitbreiden van bestaande programmatuur met nieuwe functionaliteiten en maken van integraties met bestaande systemen mag volgens dit rapport toepasbaar worden gemaakt binnen de WBSO. Verder wordt voorgesteld om het geschikt maken van eigen programmatuur voor een ander platform, modelleren en simuleren, en kwaliteitsverbeteringen van eigen programmatuur als S&O-activiteit toepasbaar te maken.

Interessant wordt nu te zien in welke mate deze aanbevelingen zullen leiden tot aanpassingen in de WBSO zelf. Zoals de Minister in zijn kamerbrief van 15 september stelt, is de WBSO een generieke regeling. Dit betekent dat aanpassingen specifiek gericht op ICT en programmatuurontwikkeling wel moeten passen onder de algemene doelstellingen en richtlijnen van de regeling.

Wij zien zelf ook uitdagingen op het gebied van de uitvoerbaarheid en wenselijkheid bij sommige aanbevelingen; bijvoorbeeld het toelaten van herstructurering en documenteren van programmatuur. RVO, de uitvoerende dienst voor o.a. de WBSO, moet tijdens de beoordeling het technische risico van specifieke ontwikkelonderdelen inschatten en bij eventuele audits concreet aanwijsbare deliverables kunnen inzien. Het oplossen van een technisch probleem is hierbij de voorwaarde. Hoe wordt dit opgepakt als herstructurering van code of het inrichten van modellen ook worden meegenomen? De huidige kaders maken goede inhoudelijke beoordelingen door de IT-deskundigen van RVO mogelijk. Bij afvlakking van de definitie van S&O levert dit mogelijk problemen op. Als onderneming is het belangrijk zekerheid te hebben over activiteiten die mogen worden meegenomen, en de wijze van verantwoording achteraf. Wij zijn benieuwd naar de praktische uitwerking van deze aanbevelingen en volgen de ontwikkelingen dan ook op de voet. Wordt dus vervolgd…