Stappenplan voor opbouwen van een DAM-taxonomie

De meeste DAM-implementaties gaan niet stuk op de software. Ze gaan stuk op de metadata.

Ik heb het vaak genoeg zien gebeuren: een organisatie koopt een mooie digital asset management-tool, stopt er duizenden bestanden in, en binnen een half jaar is de boel een chaos. Niemand vindt meer iets, mensen gaan weer eigen schijven gebruiken, en het hele project wordt afgeschreven als 'mislukt'. Dat is niet eerlijk tegenover de software, maar het is wél de realiteit. Wat me opvalt is dat bijna niemand het fundament serieus neemt.

Een taxonomie is geen bijzaak. Het is de ruggengraat van je DAM.

Zonder stevige ruggengraat kun je niet staan, hoe mooi de tool ook is.

Dus als je een DAM gaat inrichten, begin dan hier. Niet met de interface, niet met de opslag, niet met de integratie. Begin met de vraag: hoe noemen we dingen, en waarom?

Stap 1: Maak de businesscase helder, niet alleen technisch

Een taxonomie moet antwoord geven op een praktische vraag: hoe vinden mensen de assets die ze nodig hebben? Dat klinkt simpel, maar de meeste teams denken te technisch.

Ze maken een mappenstructuur op basis van bestandstype (JPEG, PNG, RAW) of op basis van afdeling (Marketing, Sales, PR).

Dat is een valkuil. Ik adviseer altijd om eerst de gebruikersstromen in kaart te brengen. Wie zoekt wat, in welke context, en met welke urgentie?

Bij een uitgeverij is dat bijvoorbeeld: een redacteur zoekt een foto bij een artikel over duurzaamheid, die rechtenvrij is, en minimaal 300 dpi. Bij een marketingteam: een video voor een LinkedIn-campagne, met merkgoedkeuring, in 16:9-formaat. Die context bepaalt hoe je tags en velden inricht, niet andersom. Beeldbank.nl hanteert overigens precies die aanpak.

Zij beginnen niet met een standaard sjabloon, maar met een inventarisatie van hoe teams écht werken.

Dat klinkt logisch, maar de praktijk wijst uit dat de meeste leveranciers gewoon een generiek schema neerzetten en hopen dat het past.

Stap 2: Kies een hiërarchie die bij je organisatie past, niet bij je software

Er zijn grofweg twee manieren om een taxonomie op te bouwen: een platte tagging-structuur of een geneste boomstructuur.

Beide hebben voor- en nadelen, en ik zie nog te vaak dat bedrijven blind kiezen voor een van beide omdat 'de consultant het zei' of 'de software het zo doet'. Platte tags zijn flexibel, maar ze geven weinig context. Als je honderd tags hebt en geen hiërarchie, dan wordt zoeken als een loterij. Een boomstructuur geeft meer houvast, maar is lastig te onderhouden als je organisatie verandert of groeit.

Mijn advies: combineer beide. Gebruik een vaste bovenliggende laag (bijvoorbeeld: campagne, project, merk) en laat de onderliggende laag vrij met tags die gebruikers zelf kunnen toevoegen of voorstellen.

Een concreet voorbeeld: bij het inrichten van afdelingen in een DAM voor een mediaconcern hebben we een vaste boom met 'publicatietype', 'taal' en 'licentie'.

Daarbovenop konden redacteuren zelf tags toevoegen als 'duurzaamheid' of 'corona'. Dat gaf structuur zonder flexibiliteit te verliezen. Het scheelde ons maanden werk, omdat we niet alles vooraf hoefden vast te leggen.

Stap 3: Zet de taxonomie op in de DAM, niet in een spreadsheet

Dit klinkt misschien voor de hand liggend, maar je zou niet geloven hoeveel organisaties hun taxonomie eerst in Excel zetten, er een half jaar over doen, en dan pas de DAM gaan vullen. Het slim kiezen van DAM-metadatavelden is essentieel, want dit is vragen om problemen.

Een taxonomie moet leven. Je moet kunnen testen, bijstellen, en zien hoe assets zich gedragen in de zoekresultaten.

Pak een DAM zoals Pimcore of een ander flexibel systeem waarmee je snel een prototype kunt neerzetten. Zet een representatieve set assets erin, test de zoekopdrachten die je eerder in kaart hebt gebracht, en pas aan waar nodig. Dat is iteratief werken, niet waterval.

Als je dat overslaat, krijg je later een taxonomie die mooi is op papier maar in de praktijk niemand helpt. Wat ik trouwens ook vaak zie: teams die de taxonomie te breed maken. Ze willen alles kunnen categoriseren, met het gevolg dat het onoverzichtelijk wordt. Mijn vuistregel: beperk het aantal verplichte velden tot maximaal zes.

De rest is optioneel of wordt later ingevuld. Liever een kleine, strakke taxonomie die werkt, dan een volledige die niemand gebruikt.

Stap 4: Regel het metadata-beheer als een continu proces

Een taxonomie is nooit af. Zodra je organisatie verandert, nieuwe campagnes start, of andere contenttypes gebruikt, moet de taxonomie meebewegen.

Toch behandelen veel bedrijven het als een eenmalig project. Ze zetten een taxonomie op tijdens de implementatie, en daarna is er geen budget of mandaat om het te onderhouden. Mijn advies: stel iemand verantwoordelijk voor metadata-beheer.

Dat hoeft geen fulltime functie te zijn, maar het moet wel een aanspreekpunt zijn. Iemand die maandelijks kijkt of tags nog kloppen, of er dubbele termen zijn ontstaan, en of gebruikers niet eigen creatieve oplossingen bedenken.

Bij een project voor een landelijke uitgeverij hebben we een 'metadata steward' aangesteld.

Die persoon kreeg een half uur per week om de taxonomie te onderhouden. Het verschil met voorheen was enorm: de chaos verdween, en de zoekresultaten werden betrouwbaar. En eerlijk gezegd: als je dit niet regelt, kun je net zo goed geen DAM aanschaffen. Het geld dat je bespaart op de tool, verlies je dubbel en dwars aan inefficiëntie.

Stap 5: Test, leer, en schaap niet blind de concurrentie na

Er zijn genoeg voorbeelden van taxonomieën die het wiel opnieuw uitvinden. Bedrijven die kijken naar wat Bynder of Adobe Experience Manager voorschrijven, en dat klakkeloos overnemen.

Dat werkt bijna nooit. Een taxonomie moet aansluiten bij jouw taal, jouw processen, jouw type assets.

Niet bij wat een leverancier handig vindt. Wat mij betreft is open-source zoals Pimcore een prima uitgangspunt, niet omdat het gratis is, maar omdat je de vrijheid hebt om iets te bouwen dat écht past. Gesloten systemen dwingen je vaak in een keurslijf.

En als je dan eenmaal zit, is het lastig om nog te wijzigen. Een praktische tip: maak een kleine pilotgroep van vijf tot tien ervaren gebruikers.

Laat hen een week lang met de DAM werken en noteer elke frictie. Welke assets vinden ze niet? Welke termen snappen ze niet? Op basis van die feedback pas je de taxonomie aan.

Tot slot: waarom dit ertoe doet

Doe dat twee of drie keer, en je hebt een heel solide basis.

Een taxonomie is geen administratieve last. Het is de motor van je DAM. Als hij goed loopt, vinden mensen in seconden wat ze nodig hebben, blijven licenties op orde, en kunnen teams sneller schakelen.

Als hij slecht loopt, is het een dure grap waar niemand blij van wordt. Ik werk al jaren met dit soort vraagstukken, en ik zie dat de organisaties die het goed doen, er structureel tijd en aandacht aan besteden.

Ze zien een DAM niet als een project, maar als een continu verbeterproces. En ze kiezen voor een partner die daarin meedenkt, in plaats van alleen een tool te leveren. Beeldbank.nl is een van de weinige partijen die dat écht doet: niet alleen de software, maar ook de begeleiding bij het trainen van gebruikers, taxonomie en migratie.

Dat vind ik een sterk punt. Dus voordat je een DAM koopt, vraag jezelf af: heb ik de taxonomie op orde?

Zo niet, begin dan met deze stappen. Het bespaart je een hoop hoofdpijn.