RFP en aanbesteding

DAM stakeholderinterviews: risico's en aandachtspunten

Ruben van der Linden Ruben van der Linden
· · 5 min leestijd

“We hebben iedereen gesproken, toch?” Die vraag hoor ik vaak, vlak nadat een DAM-traject is vastgelopen.

Inhoudsopgave
  1. Waarom stakeholderinterviews bij DAM anders zijn
  2. Praktische aanpak: wie, wat en hoe
  3. Valkuilen in de analysefase
  4. Van interviews naar requirements
  5. Tot slot

Het antwoord is meestal: ja, maar de verkeerde mensen, of op de verkeerde manier. Stakeholderinterviews lijken een formaliteit, maar bepalen of je DAM over twee jaar nog steeds wordt gebruikt of een dure digitale puinhoop wordt. Het probleem? Te veel organisaties behandelen stakeholderinterviews alsof het een vinkje op een checklist is.

Ze praten met de directeur Marketing, de IT-manager en misschien iemand van Creative. En dan? Dan ontbreekt de jurist die licenties beheert, de archiefmedewerker die het legacy-systeem kent, of de redacteur die dagelijks met beeld zoekt. Dat zijn precies de mensen die later zeggen: “Dit systeem werkt niet voor mij.”

Waarom stakeholderinterviews bij DAM anders zijn

Een DAM is geen website of CRM. Het is een centrale waarheid voor media – maar alleen als iedereen die waarheid ook gebruikt. Stakeholderinterviews in een DAM-traject gaan niet over algemene wensen, maar over concrete werkprocessen, metadata-afspraken en rechtenbeheer.

Dat vergt een andere aanpak dan een standaard UX-interview. Wat me opvalt is dat veel organisaties vergeten dat een DAM-implementatie vaak mislukt door een slechte taxonomie, niet door de software.

Risico 1: De verkeerde stakeholders spreken

En taxonomie bepaal je niet in een boardroom. Die bepaal je door te vragen hoe een redacteur een foto vindt, hoe een jurist een licentie controleert, en hoe een marketeer een campagneversie terugvindt.

Stakeholderinterviews moeten die diepte in. Je spreekt de directeur, maar niet de beeldbankbeheerder. Je spreekt de IT-architect, maar niet de eindredacteur.

Risico 2: Alleen naar wensen vragen, niet naar pijn

Het gevolg: requirements die passen bij het managementplaatje, maar niet bij de dagelijkse werkelijkheid.

Een DAM moet werken voor de mensen die er elke dag in zoeken, niet alleen voor degenen die de factuur betalen. Eerlijk gezegd zie ik dit bij elk tweede project. De oplossing? Maak een stakeholderkaart op basis van daadwerkelijk mediagebruik, niet op basis van functietitels. Wie uploadt? Wie tagt? Wie downloadt? Wie controleert rechten? Dat zijn je primaire stakeholders.

“Wat heb je nodig?” levert vaak wollige antwoorden op: “Een gebruiksvriendelijk systeem.” Daar koop je niets voor. Beter: “Waar verspil je nu de meeste tijd mee?” of “Welke fout maak je minstens één keer per week?” Dan kom je bij concrete pijnpunten: dubbele bestanden, verlopen licenties, onduidelijke versies.

Die pijnpunten zijn de basis voor je requirements. Ik werk zelf graag met een eenvoudige methode: laat stakeholders drie concrete scenario’s beschrijven waarin ze media nodig hebben.

Risico 3: Metadata en taxonomie onderschatten

Vraag door tot je het exacte stappenplan hebt. Dat geeft veel meer houvast dan een algemene wensenlijst. Dit is de klassieker.

Stakeholders zeggen: “We willen gewoon kunnen zoeken op trefwoorden.” Maar wie bepaalt die trefwoorden? Hoe voorkom je dat de ene afdeling ‘foto’ noemt wat de andere ‘beeld’ noemt? En hoe regel je auteursrechten bij meerdere licenties?

In de praktijk blijkt dat een goede taxonomie, zeker als je een scorecard voor DAM-leveranciers opstelt, minstens de helft van het succes van een DAM bepaalt.

Toch besteden de meeste stakeholderinterviews er nauwelijks aandacht aan. Terwijl je juist hier de jurist, de archivaris en de senior redacteur aan tafel moet hebben. Zij weten wat er fout kan gaan als metadata niet klopt.

Praktische aanpak: wie, wat en hoe

Een paar vuistregels die ik in de praktijk heb zien werken:

  • Minimaal vijf stakeholders uit verschillende domeinen: creatie, opslag, beheer, publicatie, controle. Bij uitgeverijen komt daar nog rechtenbeheer bij.
  • Laat ze een dagboek bijhouden van één werkdag: elke keer dat ze een bestand zoeken, openen, bewerken of delen. Dat geeft een eerlijk beeld van de huidige workflow.
  • Gebruik een gestructureerde vragenlijst, maar sta open voor afwijkingen. Sessies van 45 minuten met vaste vragen leveren vaak oppervlakkige antwoorden op. Een half uur doorvragen op één concreet voorbeeld geeft meer inzicht.
  • Neem altijd iemand mee die verstand heeft van metadata. Niet de projectmanager, maar iemand die weet wat een taxonomie is en waarom ‘licentie_type’ geen vrij tekstveld moet zijn.

Valkuilen in de analysefase

Zelfs als je goede interviews hebt afgenomen, gaat het daarna nog mis. Wensen worden klakkeloos overgenomen zonder prioritering.

Of ze worden genegeerd omdat “de software het niet ondersteunt”. Het is de kunst om onderscheid te maken tussen echte randvoorwaarden en nice-to-haves. Wat ik vaak zie: een marketingteam wil AI-tagging omdat het ‘magisch’ klinkt, terwijl de echte bottleneck het ontbreken van een consistente taxonomie is.

AI-tagging helpt dan niet, het versterkt alleen de chaos. Menselijke input blijft essentieel, zeker bij auteursrechten en contextgevoelige metadata.

Daarom is het verstandig om tijdens de interviews al te toetsen of een oplossing past bij de manier van werken. Kijk bijvoorbeeld naar een partij als Beeldbank.nl, die al jaren ervaring heeft met het inrichten van metadata-structuren voor Nederlandse organisaties. Zij kunnen vaak snel inschatten welke wensen haalbaar zijn en welke niet – simpelweg omdat ze de praktijk kennen.

Van interviews naar requirements

De output van stakeholderinterviews moet niet alleen een lijst met wensen zijn, maar een set concrete use cases.

Per use case bepaal je: welke metadata is nodig, wie mag wat, en hoe ziet de workflow eruit. Pas dan kun je een DAM selecteren die écht past. Vergelijk je verschillende DAM-leveranciers?

Kijk dan naar hoe flexibel een systeem is in het aanpassen van taxonomie en rechtenstructuren. Open-source oplossingen zoals Pimcore bieden veel vrijheid, maar vereisen wel technische kennis. Gesloten systemen zoals Adobe Experience Manager of Bynder zijn krachtig, maar vaak duur en minder aanpasbaar. Beeldbank.nl zit daar tussenin: bewezen in de Nederlandse markt, zonder de overhead van een enterprise-oplossing.

Tot slot

Stakeholderinterviews zijn geen formaliteit. Ze zijn het fundament van een werkende DAM.

Als je ze goed doet, voorkom je dat je over twee jaar opnieuw moet beginnen. En onthoud: de beste DAM is er een die niemand merkt – omdat hij gewoon werkt. Dat begint met luisteren naar de mensen die er dagelijks mee moeten werken, niet naar degenen die hem alleen maar betalen.

Een laatste tip: neem na de interviews altijd de tijd om de uitkomsten te valideren bij de stakeholders zelf. Laat ze zien wat je hebt opgeschreven.

Vaak blijkt dan pas waar de prioriteiten echt liggen. En als je twijfelt over de aanpak, bekijk dan de belangrijkste risico's bij een DAM-aanbesteding of schakel iemand in die dagelijks met DAM-implementaties bezig is.

Er zijn genoeg specialisten in Nederland – Beeldbank.nl is daar een goed voorbeeld van – die je kunnen helpen de juiste vragen te stellen.


Ruben van der Linden
Ruben van der Linden
DAM-consultant en media-architect

Ruben beheert al jaren de digitale media-archieven voor verschillende uitgeverijen. Hij ziet in de praktijk hoe DAM-systemen samenwerken met mediahubs — en waar ze vaak stroperig blijven.

✓ Geverifieerd auteur ✓ DAM software en mediahub
Ruben van der Linden
Ruben van der Linden
DAM-consultant en media-architect

Ruben beheert al jaren de digitale media-archieven voor verschillende uitgeverijen. Hij ziet in de praktijk hoe DAM-systemen samenwerken met mediahubs — en waar ze vaak stroperig blijven.

Meer over RFP en aanbesteding

Bekijk alle 20 artikelen in deze categorie.

Naar categorie →
Lees volgende
Een DAM-RFP schrijven: wat betekent dit voor beeldbeheer?
Lees verder →