Traditioneel CMS veel te statisch

Laten we beginnen met te kijken naar de huidige rol van een CMS. Contentmanagementsystemen zijn ontstaan vanuit de behoefte om steeds omvangrijker wordende websites beter te kunnen onderhouden. Organisaties kregen door, dat het succes van een website sterk afhangt van de actualiteit van de informatie die erop te vinden is. Om niet steeds een programmeur nodig te hebben om content aan te passen, zijn systemen nodig die kunnen ondersteunen bij het proces van creëren, publiceren en onderhouden van content. Een modern CMS onderhoudt echter niet alleen content (en niet alleen content in de traditionele zin van het woord), het publiceert complete websites. Bovenstaande illustreert de huidige rol van een CMS: het is een op zichzelf staand systeem dat, los van andere systemen in de organisatie, het gehele proces verzorgt van publicatie van een website. In deze context is een website statisch, niet zozeer qua inhoud maar qua interactie met de eindgebruikers, de bezoekers van de site. Het tegenwoordige CMS ondersteunt dan ook niet de gebruikers van een website, maar vooral de beheerders ervan. Transparanter Maar de wereld verandert. Met name in onze westerse economieën verschuift het accent van industrie naar kenniseconomie. Het fenomeen kenniswerker doet zijn intrede: medewerkers die informatie nodig hebben uit veel verschillende bronnen over de traditionele zuilen van een organisatie heen, met als doel om zelfstandig complexe beslissingen te kunnen nemen. Bovendien worden organisaties steeds transparanter voor de buitenwereld. Hiermee wordt de communicatie met klanten, partners en leveranciers steeds belangrijker. Deze ontwikkelingen hebben hun weerslag op de wijze waarop informatie via internettechnologie wordt verspreid. Naast publieke websites zijn intranetten en extranetten steeds meer in opkomst. En deze vereisen veel meer interactie met de eindgebruiker dan traditionele websites. Een private-banking -extranet bijvoorbeeld biedt klanten van de bank inzicht in hun portfolio, biedt actuele koersinformatie en nieuwsberichten, toegang tot interne en externe publicaties. En biedt de mogelijkheid online te handelen. Een intranet van een IT-dienstverlener biedt bijvoorbeeld projectmedewerkers toegang tot onder andere klant- en projectinformatie, kennisdatabases, externe nieuwsgroepen, urenadministratie, documenten. Het begrip content wordt hiermee steeds dynamischer. Content kan van alles zijn: traditionele webcontent, documenten op een filesysteem of data uit een ERP-systeem. Of zelfs externe informatie, zoals nieuwsservices. Content is niet alleen maar informatief voor geïnteresseerden, maar wordt actief gebruikt, gezocht, gecombineerd en bewerkt. Wat betekent dit voor het CMS? Door deze ontwikkelingen kan een CMS niet meer losstaand opereren van andere systemen. Het systeem heeft namelijk geen alleenheerschappij meer over het begrip content, omdat content overal vandaan kan komen: uit ERP-systemen, documentmanagementsystemen, externe bronnen, websites, nieuwsgroepen et cetera. Een CMS zal daarom steeds meer een component worden in een groter geïntegreerd geheel, naast bijvoorbeeld een documentmanagementsysteem, een search engine, een business proces engine, en een Service Oriented Architecture-implementatie die toegang biedt tot businesssystemen. Oftewel: een CMS zal onderdeel uitmaken van een complete, geïntegreerde elektronische werkomgeving. Traditionele webcontent, het domein van het huidige CMS, is dus slechts een van de vele verschijningsvormen van content. En al deze vormen van content zullen op dezelfde wijze ondersteund moeten worden als het gaat om beveiliging, workflow, versiebeheer, gebruikersinteractie et cetera. Dit betekent dat de functionaliteit van een CMS zal veranderen omdat sommige functies worden overgenomen door andere componenten. Organisaties zullen bijvoorbeeld een generieke workflow of business process engine willen inzetten die alle processen ondersteunt: van contentcreatie tot updates naar een ERP-systeem. De consequentie hiervan is dat de proprietary workflowondersteuning van het CMS bij voorkeur niet meer gebruikt wordt, maar dat het CMS de standaard, de organisatiebrede workflow-tool, zal moeten ondersteunen. Of denk aan beveiliging: al deze verschillende vormen van content komen uit systemen die vaak hun eigen beveiligingsmechanismen gebruiken. Het traditionele CMS vormt hier geen uitzondering op. Er ontstaat behoefte aan een centrale identify-managementoplossing die de beveiligde toegang tot alle systemen in de organisatie regelt. Wederom een functie minder voor het CMS. Contentmanager De grootste gevolgen voor het traditionele CMS zijn echter te vinden in de gebruikersinteractie. Het CMS ondersteunt traditioneel de contentmanager. Maar met de nieuwe invulling van het begrip content is het creëren van content niet meer uitsluitend een formeel, door workflow begeleid proces van contentmanagers. Er zijn vele soorten gebruikers die allemaal bijdragen aan de content, vaak niet eens bewust, maar gewoon omdat ze hun werk doen. Iemand die bijvoorbeeld een offerte schrijft, is niet bewust bezig met een contentmanagementproces. Maar deze offerte kan wel relevante content opleveren voor iemand anders die een soortgelijke offerte moet schrijven. Een vastgelegde project evaluatie is nuttig voor medewerkers die een soortgelijk project uitvoeren. De discussie over een bepaald onderwerp kan relevante content opleveren voor anderen. Of denk aan bedrijfsmatige weblogs. De mensen die content bijdragen zijn dus steeds meer de gebruikers van de websites zelf. Deze nieuwe gebruikers moeten op een andere manier worden ondersteund. Zij hebben geen behoefte aan de aparte contentmanagementtool die de contentmanager tot zijn beschikking heeft. Mensen willen gewoon werken vanuit de omgeving waaraan zij gewend zijn. Contentcreatie moet dus transparant en geïntegreerd worden. Zowel op het gebied van de presentatie van content als de wijze van interactie van gebruikers met de content, zal het CMS dus terrein prijs moeten geven en wel aan de steeds meer in opkomst zijnde portal. Deze is speciaal ontworpen om de gebruiker gepersonaliseerd toegang te geven tot wijd verspreide informatie uit allerlei bronnen. De soort voorbeelden die we eerder in dit artikel aanhaalden, zoals het private-bankingextranet of het IT-dienstverlener-intranet, worden in toenemende mate met behulp van portaltechnologie gerealiseerd. En de functionaliteiten van een portal en CMS overlappen elkaar in grote mate: beide willen de sitestructuur (het navigatiemenu) bepalen, beide bieden de mogelijkheid om pagina’s aan te maken en in te delen en beide bieden personalisatie. Maar juist omdat het begrip content veel dynamischer is geworden, zal de portal hier de overhand krijgen: content is immers niet alleen meer afkomstig uit het CMS. Het CMS webpagina’s laten aanmaken bijvoorbeeld, levert grote problemen op omdat deze pagina’s ook content uit andere systemen bevatten. En dat kan het CMS niet aan. Personalisatie door het CMS? Nee, want niet alleen webcontent moet gepersonaliseerd worden aangeboden aan gebruikers, maar allerlei vormen van content. Na alle voorbeelden lijkt het wel of het CMS geen functie meer overhoudt. Ziet het er dan zo somber uit voor de CMS-leveranciers? Op korte termijn valt dat wel mee. Veel organisaties hebben een keuze gemaakt voor een standaard-CMS en willen daar nog niet van af. Organisaties die met portals aan de slag gaan, proberen dan ook veelal eerst het CMS en de portal met elkaar te integreren. De CMS-leverancier heeft dus nog wat adempauze. Weinig succes Er zijn echter maar weinig echte succesverhalen op dit gebied. En op langere termijn zullen CMS-leveranciers de veranderende rol van hun producten onder ogen moeten zien en erop reageren, willen ze kunnen overleven. Het CMS zal steeds meer worden teruggedrongen tot de kern van zijn taak: een content repository, een plek waar content efficiënt opgeslagen en beheerd wordt. Hiervoor zijn ook al ontwikkelingen gaande. De ontwikkeling van de JSR170-standaard in de wereld van de J2EE-technologie bijvoorbeeld. Deze beschrijft een standaardwijze waarop content repositories programmatisch aangesproken kunnen worden, met functies als opslag, check-in/check-out en versiebeheer van content. Systemen als een portal kunnen dan een groot deel van de gebruikersondersteuning voor hun rekening nemen en de content-repositoryfuncties overlaten aan elk JSR170-compliant CMS. Het CMS verliest dan enkele functies, maar kan op deze wijze wel succesvol geïntegreerd worden. En het voorkomt dat portal-leveranciers eenvoudigweg zelf content repositories ontwikkelen om toe te voegen aan hun productlijn, een ontwikkeling die overigens al gaande is. Spannende tijden breken dus aan voor de leveranciers van traditionele contentmanagementsystemen. De rol van hun systemen verandert en daarmee ook de systemen zelf. Bescherming van hun investeringen en hun markten leiden ertoe dat een reactie vooralsnog lijkt uit te blijven. Iets dat men niet eeuwig zal kunnen blijven volhouden. AUTEUR: Sjoerd Kessels Sjoerd Kessels is als portal-consultant werkzaam bij IT-dienstverlener e-office (Sjoerd.Kessels@e-office.com).