Welke softwarekennis moet een onderwijsorganisatie zelf in huis hebben?

Een organisatie die technisch vrijwel niets begrijpt, merkt ook moeilijker wanneer er specialistische hulp nodig is. Het wordt lastiger om te zien of een advies deugt en wat de gevolgen van een technische keuze later kunnen zijn. Daarom is er wel een intern minimum. Een onderwijsorganisatie moet genoeg technologisch begrip hebben om:

• te herkennen wanneer een vraag niet alleen over functionaliteit gaat, maar ook over gegevens, beveiliging, toegankelijkheid, continuïteit of afhankelijkheid;

• te beoordelen of een voorgestelde oplossing past bij het probleem én bij de organisatie;

• door te vragen naar beheer, toegang, overdraagbaarheid en de gevolgen van technische keuzes;

• te weten wie uiteindelijk beslist en welk risico daarbij wordt geaccepteerd.

Zonder die basis verschuift de regie al snel naar de partij die de techniek wel begrijpt. Formeel ligt de beslissing nog bij de organisatie, maar in de praktijk wordt de afweging dan elders gemaakt.

Hoeveel kennis hiervoor intern nodig is, verschilt sterk. Een grote onderwijsorganisatie kan een deel van die rol zelf dragen. Bij een kleinere organisatie met bijvoorbeeld een parttime ict-coördinator zal meer kennis collectief of extern worden georganiseerd. Dat hoeft geen probleem te zijn. Intern moet wel duidelijk zijn wie de afweging kan volgen, welke belangen worden ingebracht en wie beslist.

Hetzelfde geldt voor software die medewerkers zelf maken. In een apart artikel beschrijven we wanneer zo’n experiment niet meer alleen van de maker is, maar een verantwoordelijkheid van de organisatie wordt.

Specialistische kennis kan prima buiten de organisatie zitten. Die kennis moet dan wel bruikbaar worden in de besluitvorming. Een externe specialist die alleen een antwoord geeft, laat veel van de afweging buiten beeld. De mensen die verantwoordelijk zijn voor de beslissing moeten begrijpen waarom een keuze wordt voorgesteld en wat de gevolgen ervan zijn.

Er speelt nog iets: afhankelijkheid. Als essentiële kennis, toegang of beslismacht bij één partij terechtkomt, is het probleem vooral verplaatst. Voor een technische partner betekent dat dat code, data, documentatie, accounts en toegang zo georganiseerd moeten zijn dat de klant de samenwerking kan beoordelen, met een andere partij kan voortzetten of uiteindelijk kan beëindigen.

Je moet bij een leverancier blijven omdat de samenwerking werkt, niet omdat vertrekken technisch niet meer kan. Vendor lock-in ontstaat meestal in de keuzes die veel eerder worden gemaakt.

Je hoeft hiervoor niet morgen een technisch team op te bouwen. Drie vragen maken snel duidelijk waar het gat zit:

• Wie kan intern technisch advies voldoende begrijpen om het af te wegen tegen onderwijsbelang, risico en lange termijn?

• Welke specialistische kennis kunnen we snel betrekken wanneer onze eigen kennis niet voldoende is?

• Kunnen we verder als een leverancier, medewerker of externe specialist wegvalt?

Als één van die vragen geen duidelijk antwoord heeft, is daar extra aandacht nodig. Dat betekent niet dat de organisatie zelf software moet gaan bouwen. Het betekent wel dat er te weinig basis is om verantwoordelijkheid voor die software te dragen.

Software kun je laten ontwerpen, bouwen en beheren. Specialistische kennis kan ook buiten de organisatie zitten. De afweging zelf kun je niet uitbesteden.