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 vaak op verouderde besturingssystemen. Upgraden naar een nieuw besturingssysteem blijkt te risicovol en de technische kennis om het betreffende CMS te beheren is laag. Ondertussen lijken 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 veelal 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 contentmanagementsystemendoor door de ICT-afdeling als logisch wordt beschouwd, terwijl er geen bewustwording lijkt te bestaan van het feit dat de eigen organisatie, en zeker de wereld eromheen, wellicht ook doorontwikkeld zijn. Of het bestaande systeem functioneel gezien nog voldoet en, belangrijker, nog actief wordt gebruikt,wordt niet gevraagd. Maar ondertussen kan er een afdeling bijgekomen zijn. En tien jaar geleden, bijvoorbeeld, was er nog geen behoefte om vanaf smart devices – iPhones, iPads – met een IT-systeem te werken.
Niets verbeterd
Uiteindelijk zal er vol trots een ‘nieuw’ CMS uitgerold worden 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, zoals:
• de structuur komt niet meer overeen met de huidige organisatie;
• de content lifecycle past niet meer in het huidige business–proces;
• 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/onjuiste metadata beschikt.
Het moge duidelijk zijn dat dit funest is voor de adoptie en daarmee 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 algemene 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 business–proces 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 doen aansluiten bij hun dagelijkse werkzaamheden.
Je zult merken dat er vanuit de gebruikers veel enthousiasme zal zijn om mee te denken en mee te helpen. Maar vooral dat ze een positieve bijdrage leveren aan de adoptie en dus een succesvolle contentmigratie.
