Kies in 9 stappen een CMS dat helpt bij je digitale strategie

De meeste websites en intranetten worden beheerd met een contentmanagementsysteem (CMS). Als dat CMS niet meer voldoet, is het tijd om een nieuwe tool te kiezen. Maar bij zo’n selectie kan er van alles mis gaan. Lees hoe je in negen stappen een CMS kiest dat wél helpt bij het bereiken van je digitale strategie.

Een contentmanagementsysteem (CMS) automatiseert het proces van het plannen, ontwikkelen, beheren, distribueren, evalueren en behouden van informatie. Het speelt daarmee een belangrijke rol in de zes fasen van de contentmanagement-levenscyclus.

Het selectieproces van een CMS bestaat uit negen stappen: de analyse, de marktverkenning, de informatieaanvraag met een weging van de antwoorden, de demonstratie, de online proeftuin, de offerteaanvraag met een weging van de offertes en het uiteindelijke advies.

Maak een project van je CMS-selectie

De selectie van een CMS is een project op zich. Stel een projectteam samen met uiteraard een projectleider, een marketing-/communicatiespecialist, een IT-professional, diverse contentprofessionals en een vertegenwoordiging van eindgebruikers. Een stuurgroep – waarin ook de projectleider deelneemt – fungeert als (gedelegeerd) opdrachtgever en bewaakt de voortgang van het project op hoofdlijnen. In het selectieproject zijn er verschillende ‘go/no-go’ momenten waarop de stuurgroep een besluit neemt om al dan niet door te gaan.

Betrek de eindgebruikers vanaf het begin

Essentieel bij elk selectieproject is de betrokkenheid van de (eind)gebruikers. Het gaat namelijk over een veranderingstraject waarvan het succes staat of valt met de acceptatie door de gebruikers. Betrek dus alle stakeholders (relevante doelgroepen) al vanaf het begin in het project, met name de mensen die uiteindelijk met de tool moeten gaan werken.

Waak ervoor dat met name de gebruikers van de tool het selectieproject al snel afdoen als: ‘Dat is mij allemaal te technisch!’. Het zwaartepunt van het selectietraject ligt namelijk bij het vaststellen van de ‘requirements’ (eisen en wensen) uit de organisatie en het beoordelen of het systeem aan deze requirements voldoet. Daar komt nog geen woord techniek aan te pas.

Het vaststellen van de business requirements en functionele requirements is een taak en verantwoordelijkheid van de ‘business’, waarbij de expertise van ICT’ers en andere (content)specialisten in de vertaling (alignment) tussen business en techniek natuurlijk wel gewenst is. De technische vertaling volgt dus de functionele en business-eisen, en niet andersom.

Denk aan de aanbestedingsregels

Ga in je selectieproces ook te rade bij de afdeling Inkoop. Zij kunnen je goed helpen met alle regels en afspraken rondom het inkopen van een CMS. Voor de overheid gelden er aanbestedingsregels, maar ook commerciële organisaties hebben vaak een inkoopbeleid.

Let er wel goed op dat je in de dialoog met inkopers het uiteindelijke doel niet uit het oog verliest: het selecteren van een CMS waar de organisatiedoelstellingen mee worden gehaald en waar de gebruikers mee willen werken. Je kunt wel eens verdwalen in de interpretatie van de aanbestedingsregels en houvast denken te vinden in het rigide opvolgen van het inkoopbeleid. Dat leidt maar al te vaak tot een tool waar niemand mee wil werken. Benoem dit risico in je project en bespreek met onder andere de inkopers hoe je hier binnen de aanbestedingsregels mee om kunt gaan.

Stap 1: Analyseer wat je nodig hebt

De eerste stap in het selectieproces is de de analyse. In de analysestap worden de bedrijfsdoelstellingen vertaald in eisen en wensen (‘requirements’). Het succes van een tool staat of valt met de eisen die eraan zijn gesteld. Het is dus van essentieel belang dat je de juiste eisen stelt. Deze komen onder andere voort uit een informatie- en procesanalyse en de contentstrategie.

Maak scenario’s

Om te bepalen aan welke requirements de tooling moet voldoen, kun je gebruik maken van scenario’s.

Een scenario is een chronologische beschrijving van een reeks gebeurtenissen. Bijvoorbeeld een productmanager die zo snel mogelijk nieuwe producten op de website wil hebben staan. Of een online marketeer die de conversie van een online campagne wil meten. Scenario’s kunnen later ook worden gebruikt bij de leveranciersdemonstraties, de proeftuin, het Proof of Concept en de acceptatietests.

Bedenk dat scenario’s zowel vanuit het perspectief van de bezoeker als vanuit de redacteur of een andere gebruiker van het CMS kunnen worden beschreven. Maar om verwarring te voorkomen moet je die rollen niet in één scenario combineren.

Maak een businesscase

Als er nog geen businesscase is, dan wordt in deze fase alsnog een businesscase toegevoegd aan het projectplan. De stuurgroep bepaalt of deze businesscase het selectieproject verantwoordt. Deze eerste fase moet in elk geval de eisen en wensen (requirements) aan de tool opleveren in de vorm van een Programma van Eisen.

Volg de contentmanagement-levenscyclus

Het helpt om naar de eisen te kijken met de contentmanagement-levenscyclus in het achterhoofd. In de planfase worden de contentstrategie, de governance en de architectuur bepaald. Welke eisen stel je aan het CMS die hier bij kunnen helpen?

De volgende fase in de contentmanagement-levenscyclus is het ontwikkelen van de content. Daar stel je bijvoorbeeld eisen aan de redactieomgeving en de manier van metadatering. In de beheerfase stel je eisen aan de beveiliging, de werkstroom en de opslag. In de distrubueerfase is het belangrijk om eisen te stellen aan de publicatie en moet je rekening houden met de diverse kanalen waarover je content distribueert. In de evaluatiefase stel je eisen aan de manier waarop wordt gemeten en hoe je die resultaten toont in bijvoorbeeld de redactieomgeving. En in de beheerfase stel je eisen aan de mogelijkheden voor het langdurig bewaren en vernietigen van de content.

Door de levenscyclus te volgen, neem je de gebruikers en andere belanghebbenden meer mee in waar het bij een CMS werkelijk om gaat: het beheren van content over de hele levenscyclus. Dit staat veel dichter bij het dagelijkse werk dan het (sec) eisen stellen vanuit de techniek. Stem ook je scenario’s hierop af.

Bepaal de ‘Must Haves’

Vaak wordt voor het opstellen van eisen gebruik gemaakt van de methodiek van MoSCoW (Must Have, Should Have, Could Have en Won’t Have). Bepaal samen onder welke categorie de eisen moeten worden geplaatst. Concentreer je voor de volgende selectierondes op de Must Haves en eventueel de Should Haves.

Stap 2: Verken de CMS-markt

Als je requirements duidelijk zijn, doe je vervolgens onderzoek naar welke tools kunnen voldoen aan die eisen en wensen. Dit leidt dan tot een lijst van mogelijke kandidaten (‘Short list’).

Bij het beantwoorden van de vraag welke tool de organisatie nodig heeft, is het belangrijk om altijd van je eigen situatie uit te gaan.

Laat je niet te veel leiden door wat andere organisaties hebben aangeschaft en staar je al helemaal niet blind op ‘magische kwadranten’ en productanalyses van diverse internationale adviesbureaus die voornamelijk zijn gebaseerd op te ruime criteria en de commerciële daadkracht van de deelnemende leveranciers. Laat je informeren, maar blijf kritisch.

Misschien blijkt uit de requirements dat je meer nodig hebt dan alleen een CMS. Vaak is ook een zoekmachine vereist, of een communitytool, of een aparte tool voor analytics. Ga er niet vanuit dat het CMS al deze functionaliteiten biedt.

Kies een implementatiepartner

Vaak kies je bij een CMS-selectie niet alleen voor een leverancier, maar ook voor een implementatiepartner (‘system integrator‘). Als je implementatiepartners vraagt om te helpen bij de selectie van een tool, moet je er rekening mee houden dat deze partijen waarschijnlijk alleen leveranciers voorstellen waar zij zelf (prijs- en implementatie)afspraken mee hebben gemaakt.

Het is de vraag of je daarmee de tool krijgt die het beste bij de eisen en wensen van de organisatie past. Maar aan de andere kant is een implementatiepartner die goed naar je luistert en over specifieke (markt)kennis beschikt vaak belangrijker dan het gekozen CMS.

Stap 3: Vraag om informatie

Als het Programma van eisen eenmaal is opgesteld, kan het worden verzonden naar een selectie van leveranciers in de Short list. De informatieaanvraag (ook wel ‘request for information‘ of ‘RFI‘ genoemd) is geschikt als eerste verkenning van de markt.

Concentreer je bij de informatieaanvraag niet te veel op de puur technische eisen, maar besteed met name aandacht aan het profiel van de leverancier, de gewenste functionaliteit en de gebruiksvriendelijkheid van het systeem. Stel hier expliciet vragen over en vraag om het toesturen van gebruikersdocumentatie.

Vraag ook niet: ‘Is het CMS gebruiksvriendelijk?’ We moeten de leverancier nog tegenkomen die daar ‘Nee’ op antwoordt. Beschrijf zelf wat je onder gebruiksvriendelijkheid verstaat en vraag de leverancier om aan te tonen hoe dat werkt in zijn CMS.

Ga een gesprek aan

Het is in deze fase zeker aan te raden om de aangeschreven partijen uit te nodigen voor een gesprek. Dit kan voor of na de ontvangst van de antwoorden op de informatieaanvraag. Maak de partijen wel duidelijk dat het niet gaat om een productdemonstratie, maar om een open gesprek. Dit open gesprek kan misverstanden over de scope van het project en het doel van de webomgeving voorkomen. Dat komt de beantwoording van het Programma van eisen alleen maar ten goede.

Ook bij Europese aanbestedingsregels is het mogelijk om het gesprek aan te gaan met de diverse partijen. Dat kan in de vorm van een raadpleging waarbij je alle leveranciers tegelijkertijd uitnodigt of in de vorm van afzonderlijke gesprekken. In dat laatste geval moet je wel borgen dat je iedereen dezelfde vragen stelt en dat je iedereen op dezelfde manier behandelt en weegt.

Stap 4: Weeg de antwoorden

Een informatieaanvraag wordt afgesloten met een beoordeling van de binnengekomen antwoorden.

Een praktische tip is om je te concentreren op de zogenaamde ‘knock out criteria’ of Must Haves. Als je echt alle eisen en wensen stuk voor stuk gaat wegen, kost het dagen werk. Categoriseer de eisen en wensen die bij elkaar horen en beoordeel ze groepsgewijs.

Je kunt de ene groep requirements ook zwaarder laten wegen dan de andere. Stel dit wel van tevoren vast.

Laat vervolgens elk lid van het projectteam de beoordeling doen. Tel die wegingen bij elkaar op en deel ze door het aantal mensen. Bespreek ook met elkaar de scores. En noteer welke vragen je nog hebt. Die kun je bijvoorbeeld nog tijdens de demonstratie of de offerte-aanvraag stellen.

Geef terugkoppeling aan de kandidaten

De partijen die positief uit de weging komen, nodig je uit voor een demonstratie. Laat elke leverancier die niet doorgaat naar de volgende ronde zo snel mogelijk weten dat deze is afgevallen. Zeker na afronding van het selectieproject kun je elke partij die af is gevallen terugkoppeling geven over het waarom. Dit is waardevolle informatie voor de leverancier die vaak veel tijd heeft besteed aan de beantwoording van de informatieaanvraag.

Stap 5: Laat het CMS demonstreren

Een demonstratie kan meer inzicht geven in het product dan een ingevuld Programma van eisen waarin de leverancier zelf de antwoorden heeft gegeven. Zorg er wel voor dat je de controle houdt op de demonstratie door een agenda te maken van de demonstratie en door een scenario en een scorelijst te verspreiden onder de deelnemers. Stel de leveranciers van tevoren op de hoogte van deze werkwijze.

Onze ervaring is dat je in een dag drie demonstraties kunt laten geven, inclusief de eindevaluatie. Dit zijn intensieve dagen die je projectgroep en de betrokkenen behoorlijk belasten. Maar aan de andere kant is het een ideale manier om elkaars wensen en de systemen beter te leren kennen.

Laat gebruikers meekijken en meetoetsen

Het is van groot belang dat de uiteindelijke gebruikers van het CMS de demonstraties bijwonen. Zij kunnen hier al hun vragen stellen en bepalen wat er wordt gedemonstreerd. Met een scorelijst beoordelen zij de demonstratie en na afloop geven zij een cijfer aan elke demonstratie. Doe dit aan het eind van de dag, want een dag later weet men vaak niet meer wie ook al weer wat liet zien.

Stap 6: Doe zelf de proeftuin

Een proeftuin is een omgeving waarin de leverancier het CMS ter beschikking stelt om te toetsen.

Een proeftuin onderscheidt zich van een demonstratie, doordat de gebruikers zelf de handen aan het toetsenbord hebben. Waar gebruikers in de demonstratie lovend waren over de gebruiksvriendelijkheid van het systeem, zouden zij op basis van de proeftuin wel eens tot heel andere conclusies kunnen komen.

Maak gebruik van de eerder beschreven scenario’s als leidraad voor de proeftuin. Begeleid deze proeftuin zelf als projectteam en laat de leverancier geen leidende rol spelen. Het is namelijk niet de bedoeling dat dit een vervolg op een demonstratie wordt.

De deelnemers aan de proeftuin vullen ook hier weer een scorelijst in en geven elk CMS een rapportcijfer. Dit wordt allemaal verzameld en meegenomen in de weging.

Bezoek referenties

Een referentiebezoek aan andere organisaties kan veel waardevolle informatie opleveren. Vraag de leveranciers naar contactpersonen bij hun klanten en probeer zelf ook organisaties te vinden die gebruik maken van CMS’en die in de selectie zijn overgebleven. Voer de referentiebezoeken uit voordat de offerteaanvraag begint of in elk geval voordat de offertes worden gewogen.

Stap 7: Vraag een offerte aan

Leveranciers die de demonstratie en de proeftuin goed zijn doorgekomen, stuur je een offerteaanvraag (ook wel ‘request for proposal’ of RFP genoemd). In deze offerte zijn de aanpak, de benodigde investering en de planning opgenomen.

Als de selectieprocedure het toelaat, raden we je aan om een open gesprek te hebben met de leverancier om de wederzijdse bevindingen en verwachtingen op tafel te krijgen. Dit kan veel misverstanden in de offerte voorkomen.

Om een goede prijs en een passende planning te kunnen overleggen, moet de leverancier zich goed geïnformeerd weten. Een Functioneel ontwerp als blauwdruk van de omgeving is daarbij handig. Zonder dit document zal de leverancier teveel moeten raden naar de uiteindelijke werkzaamheden. Dit kan leiden tot misverstanden en dus een verkeerde offerte.

Dat kan zich weer wreken in de uiteindelijke implementatie en oplevering. Het is ook raadzaam om niet alleen een Functioneel ontwerp van de webomgeving, maar ook van de redactieomgeving van het CMS zelf te maken. Daarin geef je aan hoe het CMS moet werken, bijvoorbeeld de redactieomgeving, de notificatie of het analytics dashboard.

Maak ook een ontwerp bij een agile werkwijze

Zo’n functioneel ontwerp of interactie-ontwerp hoeft zeker niet tot op detailniveau te zijn uitgewerkt en in steen te zijn gebeiteld. Veel organisaties – en zeker implementatiepartners – werken ‘agile‘ volgens bijvoorbeeld de scrum-methode. Dit in tegenstelling tot de watervalmethode waarin bijna alles van tevoren vast staat. Maar ‘agile’ wil niet zeggen dat er van tevoren niets is bepaald.

De eisen en wensen alleen zijn niet genoeg voor de aanbieder om te bepalen wat de organisatie nu precies nodig heeft. De contentstrategiëen, de scenario’s, een metadataset en andere documentatie helpen ook om een beeld te vormen van de verwachte webomgeving en de rol die het CMS daarin moet spelen.

Je huurt mensen in, geen organisatie

Een CMS-project is mensenwerk, ook als je de implementatie van het CMS uitbesteedt. Zorg ervoor dat je de juiste mensen selecteert die deze klus voor je gaan uitvoeren.

Vraag daarom altijd om de cv’s van de mensen die worden voorgesteld en kijk goed naar relevante ervaring. Laat de leveranciers garanderen dat deze mensen ook daadwerkelijk worden ingezet, inclusief de projectleider. Neem in elk geval de tijd om kennis te maken met deze projectleider.

Proeve van bekwaamheid

Voorafgaand of parallel aan de offerteaanvraag is het in sommige gevallen raadzaam om een ‘Proof of Concept‘ (PoC) of Proeve van bekwaamheid uit te laten voeren door de leverancier.

Laat de leverancier bijvoorbeeld een bepaalde functionaliteit realiseren die voor de organisatie een Must Have is en die niet of maar gedeeltelijk in de tool van de leverancier zit. Vaak zal de leverancier een vergoeding – vaak tegen kostprijs – vragen voor deze inspanning. Het is de investering meer dan waard, omdat het inzicht dat je hiermee krijgt in het CMS en het functioneren van de leverancier van onschatbare waarde is. Bovendien kun je de gebouwde functionaliteit vaak hergebruiken.

Breng de leverancier tijdig op de hoogte van de opdracht om een PoC op te leveren, zodat deze rekening kan houden met het beschikbaar stellen van resources. Stel van tevoren een scenario en een lijst van criteria op waarop je het PoC beoordeelt. Leg de resultaten en conclusies voor aan de stuurgroep en breng een advies uit.

Stap 8: Weeg de offertes

De offertes van de leveranciers gaan uit van bepaalde aannames waarover je misschien nog van gedachten wilt wisselen. Deze wegingsfase biedt een uitstekende gelegenheid om het hierover te hebben.

Verder is de prijs altijd bespreekbaar, maar let er wel op dat een ‘goedkope’ offerte met een te beperkte set aan functionaliteiten en inspanningen veel meerkosten achteraf kan opleveren. Neem het resultaat van de onderhandeling mee in het uiteindelijke advies aan de stuurgroep en laat de leverancier de licentie- en onderhoudskosten voor de komende vijf jaar uitwerken in een bijlage.

Weeg de offertes van de leveranciers op basis van een Wegingsmatrix, waarbij de nadruk ligt op de referenties, de prijs, de planning, de kwaliteit van de offerte en het onderhoudscontract.

Let op ALLE kosten

Als projectgroep moet je alle kosten boven tafel krijgen. Met alle kosten bedoelen wij niet alleen de kosten voor licentie, onderhoud, implementatie en training, maar ook de beheerkosten voor de eigen IT-afdeling, de hardwarekosten, de reservering voor jaarlijkse uitbreidingen aan het systeem, de interne kosten van eigen medewerkers die het project begeleiden en de kosten voor aanvullende systemen.

Bepaal ook van tevoren volgens welk model je wilt belonen: vaste prijs (‘fixed price‘), op nacalculatie (‘time and material‘), of een andere variant.

Let op het dienstenniveau

Bespreek al tijdens de onderhandeling het Service Level Agreement (SLA) of de dienstenniveauovereenkomst (DNO). Met name het niveau van de dienstverlening, de manier waarop de dienstverlening wordt gemeten en beoordeeld en de bonus/malusregeling bij goede of slechte dienstverlening moeten erin worden opgenomen.

Benoem ook iemand in de interne organisatie die dit SLA bewaakt op de naleving ervan.

Spreid de betaling en de opdrachtverstrekking

Neem in het contract op dat de betaling wordt opgedeeld, bijvoorbeeld in een eerste betaling bij de start, een volgende betaling bij oplevering van het prototype of de proeflancering en de laatste betaling na de acceptatie.

Maak ook van tevoren duidelijke afspraken over het oplossen van de laatste ‘issues’. Deze worden in de praktijk vaak binnen het onderhoudscontract of de bonus/malus-regeling opgelost om te voorkomen dat er geen decharge kan worden gegeven aan het project omdat er geen 100% oplevering heeft plaatsgevonden.

Vergeet de laatste ‘issues’ niet

Maar maak van uitstel geen afstel! Die ‘laatste issues’ zijn vaak zaken waar de gebruikers van het CMS dagelijks last van hebben. Zorg dat er nog tijd, budget en energie is om die dagelijkse ergernissen op te lossen. Dat komt de acceptatie van het CMS alleen maar ten goede.

Stap 9: Geef advies over CMS

Na de weging van de offertes brengt de projectgroep een advies uit aan de opdrachtgever of de stuurgroep. Dit advies kan bestaan uit een beschrijving van het afgelegde traject, een investeringsmodel en een keuze voor een leverancier.

Implementatiescan

Na de onderhandeling wordt meestal direct overgegaan tot de implementatie van het systeem. Onze ervaring leert echter dat het verstandig is om hier nog één fase te doorlopen voordat de leverancier de opdracht krijgt om het systeem te implementeren.

Adviseer de stuurgroep om de overgebleven partij de opdracht te geven tot het uitvoeren van een implementatiescan. In deze scan voert de leverancier een technische analyse van de werkelijke situatie uit, waarbij bijvoorbeeld de nadruk kan worden gelegd op zaken als veiligheid (‘security‘), schaalbaarheid en prestatie van het systeem (‘performance‘). Dit moet resulteren in een technisch ontwerp (TO) dat de projectgroep beoordeelt op haalbaarheid.

Vaak komen er in deze fase nog zaken aan het licht die van invloed zijn op de benodigde investering en doorlooptijd van het project. Zaken die je liever in deze fase wilt weten en niet tijdens het implementatieproject zelf. Omdat de leverancier de klus nog niet geheel ‘binnen’ heeft, stelt hij zich in deze fase vaak luisterend op en neemt hij echt de tijd voor een goede analyse door ervaren mensen in te zetten.

Na de analyse en een goedgekeurd technisch ontwerp kun je de stuurgroep adviseren om opdracht te geven tot de aanschaf van het CMS en het uitvoeren van de implementatie.

De weg naar succes

We hebben laten zien hoe je in 9 stappen een CMS kiest dat helpt bij je digitale strategie. We geven toe: het zijn veel stappen en soms is het een lange weg. Maar uit onderzoek blijkt dat veel IT-projecten mislukken doordat de requirements niet compleet en onvoldoende duidelijk zijn. Of omdat de gebruikers onvoldoende zijn meegenomen in het hele traject.

Door dit stappenmodel te volgen, voorkom je dat je verderop in het CMS-project wordt geconfronteerd met een mislukking. Voorkomen is beter dan achteraf genezen.