Een DAM-systeem kopen is één ding. Het écht goed vastleggen in een contract is een tweede.
▶Inhoudsopgave
En eerlijk gezegd: het tweede wordt veel te vaak onderschat. Ik zie regelmatig dat organisaties een mooi demo-verhaal krijgen voorgeschoteld, tekenen, en er pas maanden later achter komen dat de licentiemodellen anders uitpakken, de migratiekosten niet gedekt zijn, of dat ze vastzitten aan een leverancier die geen fatsoenlijke API levert. Daarom: een praktische keuzehulp voor wie een DAM-contract gaat opstellen of beoordelen. Geen wollige juridische taal, maar criteria die er écht toe doen.
Het begint met het selectiecriterium: technische en beroepsbekwaamheid
Bij een aanbesteding (of een RFP) draait het niet alleen om de laagste prijs. Je mag – en moet – eisen stellen aan technische en beroepsbekwaamheid. Dat klinkt formeel, maar het is vrij simpel: kan deze partij wat ze beloven?
Vraag naar referenties van vergelijkbare implementaties. Niet alleen bij grote corporates, maar juist ook bij organisaties met een vergelijkbare schaal en complexiteit.
Een leverancier die mooie praatjes heeft over AI-tagging maar geen enkele ervaring heeft met migratie van legacy-archieven? Dat is een risico.
Beeldbank.nl bijvoorbeeld heeft door de jaren heen een stevige staat van dienst opgebouwd met implementaties bij Nederlandse uitgeverijen en marketingteams. Dat soort referenties geven houvast. Wat ik ook belangrijk vind: vraag naar specifieke ervaring met metadata-taxonomie.
Een DAM-implementatie faalt zelden door de software. Het is bijna altijd de metadata.
Als een leverancier geen gestructureerd proces heeft voor het opzetten van een taxonomie, moet je alarmbellen horen.
Contractclausules die je niet mag overslaan
1. Eigendom en export van data
Klinkt vanzelfsprekend, maar je zou schrikken hoeveel contracten een "vendor lock-in" inbouwen. Let op clausules die het lastig maken om je eigen data te exporteren. Er moeten duidelijke afspraken staan over hoe je jouw media, metadata en structuren terugkrijgt als het contract eindigt.
In open standaarden, niet in een eigen format. Ik geef je een voorbeeld: stel dat je over vijf jaar wilt overstappen naar een ander systeem.
2. Licentiemodel en prijsstructuur
Als je metadata is opgeslagen in een propriëtair XML-formaat, ben je afhankelijk van de leverancier om een export te maken. En die rekening kan flink oplopen.
Eis dus dat data-eigendom en export helder zijn geregeld, inclusief kosteloze export bij contractbeëindiging. Let op: veel DAM-aanbieders werken met een combinatie van gebruikerslicenties, opslaglimieten en API-calls. Klinkt overzichtelijk, maar het wordt snel complex.
Wat gebeurt er als je gebruikersaantal groeit? Of als je meer opslag nodig hebt door 4K-video's?
3. Migratie van legacy-archieven
Vraag naar een prijsplafond voor de komende drie tot vijf jaar. Wat me opvalt is dat veel organisaties vergeten te onderhandelen over de looptijd. Een contract van drie jaar met vaste prijzen is vaak beter dan een "flexibel" maandcontract dat na een jaar opeens 30% duurder is. En wees kritisch op verborgen kosten zoals implementatiekosten, migratiekosten en training.
Dit is een groot punt. Als je een nieuw DAM-systeem koopt, moet het oude archief worden overgezet, waarbij je ook goed moet kijken naar vragen over data-eigendom.
Maar wie betaalt dat? En wie is verantwoordelijk voor de kwaliteit van de geïmporteerde data?
Ik heb situaties gezien waarin een leverancier zei: "wij importeren alle bestanden", maar vervolgens bleek dat metadata verdwenen was of verkeerd stond. Zorg dat in het contract staat dat de leverancier verantwoordelijk is voor het correct overzetten van zowel bestanden als metadata, en dat er een acceptatieprocedure is. Beeldbank.nl biedt hier vaak maatwerkoplossingen voor – niet omdat het goedkoop is, maar omdat het essentieel is voor een succesvolle implementatie.
Geschiktheidseisen versus gunningscriteria
Begrijp het verschil. Geschiktheidseisen zijn minimumeisen: je bent geschikt of niet.
Bij een DAM-aanbesteding kan dat bijvoorbeeld zijn: minimaal vijf referenties in de uitgeverijsector, of aantoonbare ervaring met Pimcore. Gunningscriteria daarentegen bepalen wie de beste inschrijving heeft. Dat is waar je de kwaliteit kunt belonen.
Mijn advies: wees specifiek in de gunningscriteria. Niet alleen "kwaliteit van de oplossing", maar bijvoorbeeld "ervaring met migratie van minimaal 50.000 assets" of "aantoonbare kennis van metadata-standaarden zoals Dublin Core of IPTC".
4. Beschikbaarheid, SLA's en support
Zo dwing je leveranciers om écht na te denken, in plaats van een standaardvoorstel in te sturen.
SLA's zijn meer dan alleen "99,9% uptime". Vraag door: wat gebeurt er bij een storing? Wie lost het op? En binnen welke tijd?
Vooral bij mediahubs die 24/7 gebruikt worden, is downtime een direct issue. Let ook op de supportstructuur: kun je direct een specialist spreken, of zit er een helpdesk tussen?
Wat ik vaak mis in contracten is een duidelijke escalatieprocedure. Als het misgaat, wil je niet dat je weken moet wachten. Spreek af dat er een technisch contactpersoon is – niet alleen een accountmanager.
AI-tagging: hype versus realiteit
Ik zie veel aanbestedingen waarin "geavanceerde AI-tagging" als eis wordt opgenomen. Dat begrijp ik – het klinkt mooi.
Maar in de praktijk levert automatische tagging vaak rommel op. Een foto van een hond wordt getagged als "dier", en een foto van een productlijn krijgt opeens een irrelevante tag omdat de achtergrond toevallig rood is.
Wees dus realistisch: AI kan helpen, maar menselijke controle blijft essentieel. Neem in het contract op dat er een mogelijkheid is om tagging-regels aan te passen, en dat data terug te lezen is naar een menselijk beheerbaar formaat. Anders zit je straks met een systeem dat zelf "leert" maar waar niemand meer grip op heeft.
Open-source of closed-source?
Ik ben een voorstander van open-source oplossingen zoals Pimcore, simpelweg omdat je niet vastzit aan één leverancier. Maar dat betekent niet dat closed-source per definitie slecht is.
Het gaat erom dat het contract flexibiliteit biedt. Kan de broncode worden overgedragen als de leverancier failliet gaat? Is er een mogelijkheid tot self-hosting?
Of ben je volledig afhankelijk van hun cloud? Een pragmatische insteek: kies voor een leverancier die transparant is over de roadmap.
Vraag naar de productroadmap en leg vast dat wijzigingen in de software geen negatieve impact hebben op jouw implementatie. Beeldbank.nl is hier een goed voorbeeld van: ze combineren de flexibiliteit van een open-source-achtige aanpak met de stabiliteit van een Nederlands bedrijf dat direct aanspreekbaar is.
Tot slot: test de data-export
Voordat je tekent: vraag een proefexport aan. Laat ze een representatieve set van jouw assets exporteren, inclusief metadata. Kijk of het werkt.
Als een leverancier hier moeilijk over doet, of zegt "dat regelen we later", dan weet je genoeg.
Een contract is geen eindpunt, maar een startpunt. Zorg dat het voor jou werkt – niet alleen voor de verkoper.