Contentmigraties: zo gaan ze geheid verkeerd (en zo niet)

Het is een bekend scenario: een organisatie beschikt over een verouderd contentmanagementsysteem (CMS) en vooral de ICT-afdeling wil hier vanaf. Want los van de licentiekosten draaien deze systemen veelal op verouderde besturingssystemen. Upgraden naar een nieuw besturingssysteem blijkt te risicovol en de technische kennis om het betreffende CMS te beheren is laag. Ondertussen blijken er, na onderzoek door diezelfde ICT-afdeling, zogenaamd uitstekende alternatieven voorhanden te zijn die minstens dezelfde functionaliteit bieden als het huidige systeem.

Kortom, alle lichten staan op groen om het ‘verouderde’ CMS te vervangen en de bestaande content te migreren. Uiteraard zo veel mogelijk een-op-een, opdat de gebruiker er zo weinig mogelijk hinder van ondervindt. Zie hier de ingrediënten van een contentmigratietraject dat bij voorbaat al bijna gedoemd is te mislukken!

Technische evolutie

De gemiddelde technische levensduur van informatiesystemen bedraagt tussen de vijf en acht jaar. De leverancier stopt dan met zijn technische ondersteuning. Systemen die op het moment van uitrol prima pasten bij de toen geldende bedrijfsprocessen, worden na die periode dus vervangen. Bij contentmanagementsystemen is het niet veel anders.

Het is dan ook opmerkelijk om te constateren dat de technologische evolutie van contentmanagementsystemen door de ICT-afdeling als logisch wordt beschouwd, terwijl zij zich er niet van bewust is dat de eigen organisatie, en zeker de wereld eromheen, wellicht ook doorontwikkeld is. Er wordt niet gevraagd of het bestaande systeem functioneel gezien nog voldoet en, belangrijker, nog actief wordt gebruikt. Dat is jammer, want ondertussen kan er bijvoorbeeld best een afdeling bijgekomen zijn. En tien jaar geleden was er ook nog geen behoefte om vanaf smart devices – iPhones of iPads – met een IT-systeem te werken.

Niets verbeterd

Vaak wordt er daarom vol trots een ‘nieuw’ CMS uitgerold waar de content ‘as is’ naartoe is gemigreerd. Het nieuwe CMS zal echter door de gebruikersorganisatie ontvangen worden als oude wijn in nieuwe zakken. Erger nog, de functionele problemen die de gebruikers ervoeren in het oude CMS blijken ook terug te komen in het nieuwe CMS. Dit zijn bijvoorbeeld:

• De structuur komt niet meer overeen met de huidige organisatie.
• De content lifecycle past niet meer in het huidige businessproces.
• Er is te veel dubbele en/of verouderde content door het ontbreken van een retentiebeleid.
• Content is nog steeds lastig vindbaar, doordat te veel content over geen, weinig en/of verouderde of onjuiste metadata beschikt.

Het moge duidelijk zijn dat dit funest is voor de adoptie en daarmee voor het succes van het nieuwe CMS. Als het al niet in een eerder stadium is gebeurd, zal een gebruikersorganisatie op zoek gaan naar ‘eigen’ oplossingen die tegenwoordig vaak in de cloud te vinden zijn, ongeacht het feit of die wel binnen het beleid van de organisatie passen.

Voorkomen is beter

Het bovenstaande scenario is te voorkomen door een contentmigratie niet als een technisch ICT-feestje te beschouwen. Betrek in een vroeg stadium de eindgebruikers. Als geen ander kunnen zij het huidige businessproces beschrijven, de tekortkomingen van het huidige CMS aangeven, aangeven welke maatregelen zij genomen hebben om hiermee om te gaan en welke wensen ze hebben om het CMS nog beter te laten aansluiten bij hun dagelijkse werkzaamheden.

Je zult merken dat er vanuit de gebruikers veel enthousiasme is om mee te denken en mee te helpen, en dat ze een positieve bijdrage leveren aan de adoptie en dus een succesvolle contentmigratie.

Door: Marco Kievit (foto), Business Productivity Consultant bij Salves