Een WBSO- of MIT-aanvraag met een technisch verhaal dat klopt

Je bouwt zelf software, een apparaat of een slimmer productieproces, en iemand heeft gezegd dat daar WBSO voor bestaat. Misschien heb je al eens een aanvraag gedaan die werd afgewezen omdat de omschrijving te algemeen was. Of je kreeg een toekenning en zit nu met een urenadministratie waar niemand in je team van weet hoe die precies moet worden bijgehouden. Het probleem is zelden de regeling zelf. Het probleem is dat de aanvraag geschreven wordt door iemand die de techniek niet kent, en dat de techniek beschreven wordt door iemand die de regeling niet kent.

Wat WBSO en MIT eigenlijk belonen

WBSO is een regeling van de Rijksdienst voor Ondernemend Nederland voor speur- en ontwikkelingswerk. Het gaat om werk waarbij je zelf iets technisch nieuws ontwikkelt en daarbij knelpunten tegenkomt waarvan je vooraf niet weet of en hoe je ze oplost. Programmatuur telt mee, net als fysieke producten en productieprocessen. Wat niet meetelt: een standaardpakket inrichten, een bestaande koppeling configureren, een website bouwen met bestaande bouwstenen. De grens ligt bij technische onzekerheid, en precies die grens moet je in de aanvraag kunnen aanwijzen.

MIT staat voor MKB-innovatiestimulering Regio en Topsectoren en werkt anders. Het is geen korting op loonkosten maar een subsidie op een afgebakend project, zoals een haalbaarheidsonderzoek of een samenwerking met een andere onderneming. Er zijn vaste openstellingen en er wordt beoordeeld op de inhoud van het projectplan. Waar WBSO vooral vraagt om een goede administratie achteraf, vraagt MIT om een plan dat vooraf overtuigt. Voor allebei geldt dat de technische kern helder moet zijn, en dat is het deel dat wij voor je doen.

Waarom de techniek het verhaal moet dragen

De meeste afwijzingen en correcties die wij zien hebben dezelfde oorzaak. De aanvraag beschrijft wat het product straks kan, niet wat er technisch aan lastig is. Een zin als wij ontwikkelen een slim platform voor planning zegt de beoordelaar niets. Een zin als wij weten nog niet hoe we tienduizend leveringen binnen een seconde opnieuw kunnen inplannen als één vrachtwagen uitvalt, wel. Het tweede is een technisch knelpunt. Het eerste is een verkooptekst.

Dat verschil kun je alleen goed opschrijven als je de code, het schema of het productieproces echt begrijpt. Onze ontwikkelaars zitten dagelijks in dat werk. We weten welke stap in een integratie routine is en welke stap niemand eerder zo heeft gedaan. Die kennis gebruiken we om per project op te schrijven wat nieuw is, waarom het onzeker is en welke oplossingsrichting je gaat onderzoeken. Zo kan een beoordelaar zonder jouw vakkennis toch volgen waarom dit ontwikkelwerk is en geen routine.

Zo helpen we bij de aanvraag

We beginnen met een gratis intake waarin we door je ontwikkelplannen voor het komende jaar lopen. Van elk project zeggen we eerlijk of we er een technisch knelpunt in zien. Zien we dat niet, dan vertellen we je dat direct. Een aanvraag voor werk dat bij een controle als routine wordt aangemerkt kost je meer dan hij oplevert. Van de projecten die wel kansrijk lijken schrijven we de technische omschrijving, in gewone taal, met de knelpunten en de aanpak erin. Die tekst kun je zelf indienen of aan je subsidieadviseur geven.

Wij blijven bij de techniek; het indienen en de bedragen liggen bij je subsidieadviseur of je accountant. Zo werkt ieder aan het deel dat hij het beste kent. Werken we bovendien al aan je software of je product, bijvoorbeeld als Developers op locatie, dan kennen we de knelpunten al uit de eerste hand en is de omschrijving een kwestie van opschrijven wat er toch al gebeurt. Ook een project op het gebied van Green IT & duurzaamheid, zoals een meetopstelling voor het energieverbruik van je serverpark, kan ontwikkelwerk bevatten waar je zonder technische blik overheen kijkt.

Een administratie die bij een controle standhoudt

Bij WBSO is de toekenning het begin, niet het einde. Je moet per project bijhouden wie welke uren aan het ontwikkelwerk heeft besteed en wat er in die uren is gedaan. Na afloop van de periode geef je de gerealiseerde uren door, en RVO kan jaren later nog komen kijken of dat klopt. Een spreadsheet die aan het einde van het kwartaal uit het geheugen wordt ingevuld houdt dat niet. Een administratie die meeloopt met het werk wel.

We richten die administratie in op de manier waarop je team al werkt. Meestal betekent dat: de projectcodes uit de aanvraag terug laten komen in je ticketsysteem of je urenregistratie, zodat een ontwikkelaar één keer boekt en daar zowel de facturatie als het WBSO-dossier van klopt. Elk kwartaal kijken we mee of de geboekte uren nog overeenkomen met wat er daadwerkelijk is gebouwd, en of er nieuwe knelpunten zijn opgedoken die in de volgende aanvraag horen. Zo ligt er bij een controle een dossier waarin de omschrijving, de uren en de code hetzelfde verhaal vertellen. Je bent de eigenaar van dat dossier, en het blijft bruikbaar als je later met een andere adviseur of zelf verder gaat.