Is een omschrijving per uur verplicht?
Nee. RVO vraagt in de urenadministratie onderscheid per dag, per project en per medewerker. De inhoud van het werk hoort in de projectadministratie: verslagen, ontwerpen, testresultaten en dergelijke.
Toch is een korte omschrijving per dag verstandig. Bij een controle moet je kunnen laten zien dat de uren bij het werk in de projectdocumenten horen. Een regel ‘6 uur, project A’ dwingt je dat achteraf uit te zoeken. Een regel met ‘warmtetest prototype 3’ wijst direct naar het testverslag van die dag.
Wat maakt een omschrijving goed?
Een goede WBSO-omschrijving is kort en concreet. Ze is geschreven voor iemand die het project niet kent maar wel technisch kan volgen.
Schrijf de omschrijving op de dag zelf. Dan weet je nog welke test je draaide en wat eruit kwam. Een week later wordt het vanzelf ‘verder gewerkt aan project A’, en daar heeft niemand bij een controle iets aan.
- Het onderwerp: welk onderdeel of welk probleem.
- De handeling: ontwerpen, testen, meten, analyseren, bouwen van een prototype.
- Het resultaat of de vervolgstap: werkte het, wat bleek, wat probeer je nu.
- Een spoor naar documenten: een testnummer, prototypeversie of naam van een ontwerp, waar dat vanzelf kan.
Vuistregel: als een collega met de omschrijving het bijbehorende document kan vinden, is ze goed genoeg.
Voorbeelden: van zwak naar beter
De voorbeelden hieronder zijn verzonnen, maar herkenbaar. De betere versie is niet langer dan nodig: één zin met onderwerp, handeling en uitkomst.
| Soort project | Zwak | Beter |
|---|---|---|
| Software | Programmeren | Synchronisatie-algoritme voor offline wijzigingen ontworpen, conflictafhandeling bij gelijktijdige edits getest |
| Software | Bugs fixen | Geheugenlek in beeldherkenning onderzocht, oorzaak in buffer-hergebruik gevonden, alternatief ontwerp uitgeprobeerd |
| Software | Overleg | Architectuuroverleg over event-opslag: keuze tussen twee opslagmodellen op basis van loadtest-resultaten |
| Productontwikkeling | Prototype | Prototype 4 behuizing geprint met dunnere wand, valtest uit 1,5 m uitgevoerd, scheur bij scharnier |
| Productontwikkeling | Testen | Batterijduur gemeten bij -10 °C, 30% korter dan berekend; isolatievariant B ontworpen |
| Procesontwikkeling | Machine afstellen | Nieuwe lasparameters voor dunwandig aluminium beproefd, porositeit per instelling gemeten |
| Procesontwikkeling | Onderzoek | Droogtijd coating bij hogere luchtvochtigheid gemeten, model voor droogcurve bijgesteld |
Hoe beschrijf je technische knelpunten?
In S&O-werk gaat het meestal om technische problemen die je oplost en waarvan de uitkomst vooraf niet vaststaat. Schrijf die problemen op als je ze tegenkomt, niet pas bij de realisatiemelding. Een knelpunt dat je in maart vastlegt, is overtuigender dan een terugblik in december.
Een bruikbare opbouw voor een notitie in je projectadministratie:
- Het probleem: wat lukt technisch niet, en waarom is de oplossing niet bekend of niet direct toepasbaar.
- De aanpak: welke oplossingsrichtingen je probeert.
- De uitkomst: wat je hebt gemeten of gezien, ook als het mislukte.
- De volgende stap: wat je nu gaat proberen.
Mislukte pogingen horen erbij. Een test die niet werkte, laat juist zien dat de uitkomst niet vaststond.
Welk werk telt meestal niet als S&O?
Niet alles wat een ontwikkelteam doet, is S&O. Wat wel en niet meetelt, staat in de Handleiding WBSO van RVO; lees die voor je eigen situatie na. In de praktijk wordt werk zoals hieronder vaak niet als S&O gezien.
- Routinematig onderhoud en beheer van bestaande systemen.
- Opleiding en training van medewerkers.
- Verkoop, marketing en klantcontact.
- Werk dat bestaande kennis en technieken toepast zonder technisch nieuw probleem.
- Algemene administratie en projectmanagement dat niet het technische werk zelf is.
Twijfel je over een activiteit, boek haar dan niet als S&O en leg vast waarom je twijfelde. Uren die je niet kunt onderbouwen, zijn bij een controle een risico.
Zo doet Half5 het
In Half5 heeft elke registratie een ‘Beschrijving’, die ook in de CSV-export staat. Wie uren goedkeurt, krijgt een waarschuwing bij registraties zonder beschrijving. Op de Tijdlijn ziet een medewerker zelf zijn commits, bestandswijzigingen en AI-sessies van die dag, wat helpt om een concrete omschrijving te schrijven; met Premium kan de desktop-app een beschrijving voorstellen (‘Automatische beschrijving met AI’). Die voorstellen controleer je zelf.
Half5 beoordeelt niet of iets S&O is. Dat blijft een keuze van jou: je boekt het werk op de activiteit ‘WBSO’ of niet. Meer over de opzet in WBSO-uren automatisch bijhouden.
Veelgestelde vragen
Hoe lang moet een WBSO-omschrijving zijn?
Eén zin is meestal genoeg: onderwerp, handeling en uitkomst. Langere uitleg hoort in de projectadministratie, bijvoorbeeld in een testverslag of ontwerpdocument.
Mag ik dezelfde omschrijving elke dag gebruiken?
Het mag, maar het helpt niet. Een omschrijving die elke dag gelijk is, maakt het onmogelijk de uren aan specifieke documenten te koppelen.
Moet ik mislukte experimenten opschrijven?
Ja, juist die. Een mislukte poging laat zien dat er een technisch probleem was waarvan de oplossing niet vaststond.
Telt overleg mee als S&O?
Dat hangt af van de inhoud. De Handleiding WBSO beschrijft wat meetelt; boek je technisch overleg als S&O, omschrijf dan concreet waarover het ging.
Mag een AI-tool mijn omschrijvingen schrijven?
Een voorstel van een tool kan helpen, maar jij bent verantwoordelijk voor wat er staat. Lees het na en pas het aan zodat het klopt met het werk en de documenten.
Bronnen
- RVO, S&O-administratie bijhouden · geraadpleegd op
- RVO, WBSO · geraadpleegd op
