IT en WBSO: tips voor een kansrijke aanvraag

WBSO in een dynamisch IT-speelveld

De noodzaak om het wiel opnieuw uit te vinden of een eigen infrastructuur te beheren en te onderhouden zijn naar de achtergrond verdwenen. Development-teams kunnen zich wat dat betreft richten op ontwikkelingen die hun software de werkelijke toegevoegde waarde geven voor de eindgebruiker. Dit maakt teams tevens wendbaarder waardoor zij beter in staat zijn om in te spelen op veranderende klantwensen of nieuwe technologische inzichten die tijdens de uitvoering van een project ontstaan.

De flexibiliteit die kenmerkend is in moderne ontwikkeling, staat soms op gespannen voet met de mate van detail die wordt verwacht in een WBSO-project. Veelal bestaan er onzekerheden over de te maken technologiekeuzes in de beginfase. Het kan een worsteling zijn om al op voorhand concrete classes te benoemen die een rol spelen in het project. Bij de start richt een team zich vooral op het inventariseren van features. In welke classes deze uiteenvallen en hoe de onderlinge interactie uitpakt is vaak nog niet duidelijk. Wel is het essentieel om hier vooraf over na te denken voor een kansrijke aanvraag.

De opmars van no- en low-code development

Met de in opmars zijnde technologieën van Betty Blocks en Mendix, is een verplaatsing naar no- en low-code-development gaande. In plaats van programma’s in broncode te schrijven, maken deze technieken het mogelijk om het datamodel, de flow en de logica te configureren. Interpretatie naar de onderliggende programmacode, wordt hierbij abstract gemaakt voor de app-ontwikkelaar die deze technieken toepast. Hoewel aan het beschrijven van deze logica dikwijls veel denkwerk voorafgaat, komen deze innovaties niet voor WBSO in aanmerking.

Machine Learning en Big Data

Met de toegenomen beschikbaarheid van grote hoeveelheden (gestructureerde) data en de afgenomen kosten van computing-resources, komen ontwikkelingen op het gebied van machine learning en big-data voor een groot aantal ontwikkelaars binnen handbereik. Voor hen is het prettig dat er libraries voor omgevingen bestaan zoals R en Matlab, om algoritmen te ontwikkelen die voor verschillende use-cases getraind kunnen worden.

De praktijk toont dat deze ontwikkelingen zich meestal niet laten vertalen naar een kansrijke aanvraag. Dit kan als een paradox worden ervaren, temeer omdat de bedrijven deze ontwikkelingen bij uitstek als innovatief beschouwen.

Ontwikkeling in een formele programmeertaal

De oorzaak dat ontwikkelingen binnen bovenstaande contexten niet voor WBSO kwalificeren, is omdat de deliverables die ontstaan niet in een formele programmeertaal worden geschreven. Het aspect van de ‘formele programmeertaal’ is met ingang van 2016 toegevoegd aan de definitie van programmatuur in de wet. De toelichting op wat een formele taal dan is, ligt echter niet in de wet verankerd.

Met de ervaring die ik hierover heb opgedaan, is het redelijk te zeggen dat talen die een algemeen nut kunnen dienen (en voor een grote verscheidenheid aan ontwikkelingen worden ingezet) goed binnen WBSO te verantwoorden zijn. Denk hierbij aan Java, C#, C++, PHP, JavaScript, Ruby, Python en Go.

Een goed begin… is het halve werk!

‘Bezint, eer ge begint’. Belangrijk is dat de aanvraag op het juiste niveau van start gaat. De toepassing of de impact van een innovatie is niet direct relevant voor een slagende aanvraag. Van belang is dat je een doel voor ogen hebt met het project en dat je het onderscheidende karakter benadrukt in termen van de ontwikkeling van eigen nieuwe technische kennis en kunde. Belangrijk voor de aanvraag is dat je aantoont dat je voornemens bent één of meerdere software-componenten op te leveren. Zaken die bij het schrijven van een aanvraag niet aan onze aandacht voorbij gaan, zijn hieronder beschreven:

• Benadruk technische deliverables die de drijvende kracht achter de voorgenomen innovatie vormen, en niet de functionele componenten die leven in de wereld van de eindgebruiker.

• Beschrijf het technische knelpunt dat ontstaat bij de ontwikkeling. Het niet kunnen voldoen aan de snelheid of nauwkeurigheid van een berekening die door het component wordt uitgevoerd, vormt een onderdeel van het probleem, maar is niet het technische knelpunt. Dat moet gaan over waarom een reguliere programmeertechniek niet toereikend is om het component zo te ontwikkelen dat de berekening met de vereiste snelheid of nauwkeurigheid kan worden uitgevoerd. Belangrijk is de oorzaak van het knelpunt te benoemen; dit beargumenteert waarom het een knelpunt voor je is.

• Benoem in de voorgenomen technische oplossing welke aanpak je kiest om af te rekenen met het technische knelpunt. De oplossingsrichting zal hierbij een nieuw technisch werkingsprincipe moeten bevatten dat je gaat verwerken in de software. Het nieuwe werkingsprincipe is een belangrijk aspect van je beschrijving. Immers als je niet voornemens bent om een nieuw principe te ontwikkelen, dan betekent dit dat je voortborduurt op aloude routine (en hiervoor is WBSO-subsidie niet bedoeld).

• Je completeert de techniek van je aanvraag door aannemelijk dat maken dat de oplossingsrichting geen A-B-C’tje is, maar dat er technische risico’s zijn die het succes van de voorgenomen aanpak in gevaar brengen. Verlies tot slot niet de samenhang tussen bovenstaande onderwerpen uit het oog. Sommige onderwerpen zijn evident voor de technisch-geschoolde adviseurs van RVO die je aanvraag beoordelen. Ben je van mening dat het technische principe minder wijdverspreid is in de developer-community, licht het principe dan toe. Dit versterkt de inhoud van je aanvraag!