Casus Invoering van een evaluatiedatabase (longread)

Het doen van vakevaluaties schept impliciet ook de verplichting om de evaluatiecyclus te sluiten. Plan-do-check-act is een schema dat er dan meestal bijgehaald wordt. Dat proces ziet er ongeveer zo uit:

  1. Plan: je bepaalt welke vakken wanneer geëvalueerd worden. Aan de hand van eerdere resultaten en in het vak uitgevoerde wijzigingen bepaal je meteen of je in je evaluatie bepaalde onderwerpen extra aandacht geeft.
  2. Do: je zet evaluaties uit voor de vakken en haalt binnen enkele weken de resultaten binnen.
  3. Check: je analyseert de resultaten en maakt een verbeterplan voor de geëvalueerde vakken.
  4. Act: de verbeterplannen worden uitgevoerd.

Hierna begin je weer bij 1.

Op papier een mooi verhaal, maar in de praktijk blijkt het lastig om de administratie ervan consistent, vindbaar, veilig en toekomstbestendig te krijgen.

Casus

De data moet omgezet worden in waardevolle informatie voor stakeholders, en gemakkelijk op te zoeken zijn. Meestal is dat niet een submapje ergens op een netwerkschijf, want: toegangsrechten, versiebeheer, etc. Niet te doen! Vervolgens moet je met de resultaten kunnen bepalen wat je plan voor volgend jaar wordt, en het jaar erop wil je kunnen checken of dat gelukt is.

Met deze uitdaging hebben veel opleidingen te maken, ook nu studentenvertegenwoordiging steeds vaker een speerpunt maakt van de openbaarheid van evaluatieresultaten.

In 2011 besloot een faculteit daarom hier een duurzame oplossing voor te ontwikkelen. Doelstelling van de faculteit was het bouwen van een evaluatiearchief en het kunnen sluiten van de evaluatiecyclus.

Database

Een team informatici begon in 2011 met het ontwerp van een digitale evaluatiedatabase waarin deze twee requirements samen kwamen. Een aantal uitgangspunten moest hierin meegenomen worden: o.a. een veilige maar eenvoudige toegang voor docenten, toegang op basis van rol ten opzichte van het vak, en de mogelijkheid om het vak onder verschillende curricula te kunnen hangen. 

Het systeem werd gekoppeld aan de centrale inlogmethode van de instelling, zodat docenten die ingelogd zijn op het netwerk, met dezelfde inloggegevens in kunnen loggen op de database.

Toegang gebaseerd op rollen

Ook werden er per stakeholder bepaald welke gegevens ze wel/niet mochten zien: een Opleidingscommissie mag bijvoorbeeld alle resultaten bekijken, maar een notulist van de vakbesprekingen met studenten mag alleen dat stukje van de evaluatie zien, en maar van één opleiding.

De database is op maat gemaakt voor de faculteit: de in de faculteit geldende evaluatiecyclus is als uitgangspunt genomen.

Lange adem

Ook al past het systeem goed bij de geldende evaluatiecyclus, toch heeft de invoering ervan wat voeten in aarde gehad. Om de cyclus te kunnen sluiten, was meer nodig dan alleen data uploaden en vakrendementen invoeren. We hadden ook de input van docenten en opleidingsdirecteuren nodig. En juist dit vroeg om een lange adem. 

Per vak registreerden we niet alleen kwantitatieve data en evaluatieresultaten, maar we vroegen ook aan studenten om kwalitatieve feedback te geven in panelsessies. Zeker in het begin gaf dit wat wrijving, omdat studenten nogal eens direct uit de hoek konden komen zonder zich te realiseren dat de docent dit ook echt ging lezen. Gevolg was dat docenten soms geen zin meer hadden om te reageren op de feedback.

Ook waren docenten en met name opleidingsdirecteurs huiverig om hun verbeterplannen al te letterlijk op te nemen in het systeem; bang dat ze er vervolgens letterlijk aan gehouden zouden worden door de opleidingscommissie.

In plaats van dat het een hulpmiddel was voor de ontwikkeling van een vak, ervoeren docenten het in eerste instantie als een controlemiddel voor andere partijen. 

Informeren

Door alle betrokkenen te blijven informeren over bijvoorbeeld verschillen in toegangsrechten en over dat evaluatieresultaten níet dienden als onderdeel van de beoordelingscyclus van het personeel, hebben we langzaamaan de bereidheid van docenten en opleidingsdirecteurs voor het gebruik van het systeem weten te vergroten. 

In zo’n zeven jaar is van het systeem tot een volledige inbedding in het facultaire kwaliteitszorgsysteem gekomen.

Terugblik

Vanaf het begin was er een rotsvast geloof in het systeem en konden we door goed te luisteren naar kritische betrokkenen, het systeem verder uitbouwen en aanpassen op de behoeften van de gebruikers. Soms moesten we nee verkopen ondanks dat functionaliteiten wel in te bouwen waren; in die gevallen gingen we niet mee met de wensen omdat die uiteindelijk zouden leiden tot een verslechtering van het sluiten van de kwaliteitszorgcyclus. Vaak bleek er dan iets anders onder de vraag te zitten, bijv. een angst voor verandering, of een angst voor aangesproken kunnen worden op moeilijk oplosbare situaties. Ook al konden we die problemen niet oplossen, het gaf ons wel inzicht in hoe we onze informatievoorziening over het wel/niet doorvoeren van een technische aanpassing beter konden communiceren richting de stakeholders. 

Het sluiten van de evaluatiecyclus garandeer je helaas niet 100% door het invoeren van een dergelijke database, want je hebt uiteindelijk de welwillendheid van de gebruiker nodig om het te laten slagen. Het uitgangspunt is daarom niet óf, óf… maar én, én: én een systeem dat goed past op het ontwerp van je proces, én een implementatieteam dat de bezwaren van de doelgroep in het oog blijft houden en weet af te wegen tegen de technische mogelijkheden. 

Uiteindelijk is het systeem ingevoerd op drie faculteiten en bij een faculteit aan een andere universiteit. Momenteel worden er gesprekken gevoerd met een derde universiteit. 

Meer weten over dit systeem? Neem contact op.

Reacties zijn gesloten.