CMS, WCM EN ECM
advertisement
COntent Implementatie- en SelectieMEThodiek Door Roy Wasse (Red.) COMET Pagina 2 van 45 Inhoudsopgave INLEIDING ...................................................................................3 CMS, WCM EN ECM .........................................................................5 Focus op Web Content Management ................................................................. 5 WCM en ECM .............................................................................................. 5 De visie van Sogeti op Contentmanagement ........................................................ 8 1 2 3 4 5 VOORONDERZOEK CMS ..............................................................9 1.1 Bepaal de functionele meerwaarde van CMS ............................................. 10 1.2 Afwegen van voor- en nadelen .............................................................. 11 SELECTIE CMS ...................................................................... 15 2.1 Samenstellen van de projectgroep ......................................................... 16 2.2 Identificeren van Stakeholders .............................................................. 17 2.3 Bepaal het doel van CMS ..................................................................... 18 2.4 Specificeer de eisen aan CMS ................................................................ 18 2.5 Uiteindelijke selectie van CMS ............................................................. 20 DE IMPLEMENTATIE ................................................................ 22 3.1 Samenstelling van de nieuwe projectorganisatie ........................................ 23 3.2 Opstellen van het ontwerp ................................................................... 24 3.3 Uitvoeren van de implementatie ........................................................... 26 3.4 Standaardfaseringsmodel ..................................................................... 30 OPLEVERPROCES ................................................................... 33 4.1 Testen van de implementatie ............................................................... 34 4.2 Opleveren van de documentatie ............................................................ 34 4.3 Schaduwdraaien ................................................................................ 35 4.4 In productie gaan .............................................................................. 35 4.5 Acceptatie ...................................................................................... 36 4.6 Beheer ........................................................................................... 36 4.7 Issuetracking .................................................................................... 36 HET MANAGEN VAN CONTENT ................................................... 37 5.1 Richtlijnen voor content ..................................................................... 38 5.2 Lifecycle van content ......................................................................... 38 5.3 Opnemen van nieuwe functionaliteit ...................................................... 39 6 BEGRIPPENLIJST ................................................................... 41 7 NAWOORD .......................................................................... 44 8 REFERENTIES ....................................................................... 45 COMET Pagina 3 van 45 INLEIDING Voor u ligt de CMS-selectie- en implementatiemethodiek van Sogeti onder de titel COMET. Deze methodiek gaat uitgebreid in op vele aspecten van selectie, implementatie en beheer van een CMS (Content Management Systeem). De methodiek is tot stand gekomen op basis van ervaring, literatuur en uitgebreide kennisuitwisseling binnen en buiten Sogeti. COMET weerspiegelt onze visie op de succesvolle implementatie van een CMS. COMET sluit aan bij andere succesvolle – door Sogeti ontwikkelde - methodische benaderingswijzen binnen de ICT. Enkele bekende namen: TMap®, Regatta®, Dya® en Mikado™1. Een aantal van deze methodieken geldt momenteel als de facto standaardaanpak voor testen, opzet van een architectuur en uitvoering van een migratie. De inzichten uit deze methodieken zult u wellicht herkennen binnen COMET. Zo biedt Sogeti’s implementatiemethodiek Regatta een werk- en denkmodel dat als één van de uitgangspunten heeft gediend voor de vormgeving van het implementatieproces. COMET biedt u een uitstekend handvat bij een groot aantal soorten CMS-trajecten. Het is een ideaal instrument voor een CMS business fit, een migratietraject, een nieuwe implementatie of voor efficiënt beheer van een CMS. Hierover u leest meer in de volgende hoofdstukken. Deze gaan achtereenvolgens in op het vooronderzoek van een CMS-traject, het selectieproces, de implementatie/migratie en tot slot het beheer. COMET is ontwikkeld als methodiek voor CMS-projectmanagers, consultants, adviseurs en ontwikkelaars. Ieder hoofdstuk vertegenwoordigt een fase in het CMStraject; de structuur van de hoofdstukken is zodanig opgezet dat u in elk willekeurig hoofdstuk kunt instappen. Figuur 1 op de volgende bladzijde geeft een overzicht van de verschillende fasen van COMET, waarbij elke fase voor een hoofdstuk staat. Achterin vindt u een begrippenlijst, waarin de specifieke termen worden toegelicht. Zie www.tmap.net, www.sogeti.nl/tpi, www.dya.info, http://mikado.sogeti.nl; websites van Sogeti Nederland bv. online op 15-9-2006 1 COMET Pagina 4 van 45 Figuur 1 De Fasen van COMET CMS, WCM EN ECM In dit hoofdstuk worden de raakvlakken van een Content Management Systeem omschreven. Bij vele ICT-systemen is het namelijk niet altijd duidelijk onder welke noemer een specifieke technologie kan worden ondergebracht. Dat geldt ook voor CMS-software. Contentmanagement is vaak van groot belang voor veel bedrijfsprocessen. Denk hierbij aan het delen van tekstdocumenten, het beheer van grafische afbeeldingen, versiebeheer van juridische documenten enzovoorts. Focus op Web Content Management Doel van deze methodiek: verstrekking van algemene richtlijnen voor de uitvoering van alle projecten op het gebied van contentmanagement. Er wordt echter grote nadruk gelegd op Web Content Management. Deze focus is gekozen om de leesbaarheid te bevorderen en komt ook ten goede aan de algehele diepgang van de methodiek. Vooral de geschetste fasering is toepasbaar op contentmanagement in de brede zin van het begrip. Eerst wordt nu nader beschreven wat Web Content Management precies is en hoe het zich verhoudt tot Enterprise Content Management. WCM en ECM ECM staat voor Enterprise Content Management, een begrip dat vele beschrijvingen kent. De originele definitie van de AIMM, een organisatie die zich toelegt op het vaststellen van normen voor contentmanagement, luidt als volgt: ECM: Enterprise Content Management are the technologies used to Capture, Manage, Store, Preserve, and Deliver content and documents related to organizational processes.2 Uit deze beschrijving blijkt dat ECM vele aspecten raakt die qua content zijn gerelateerd aan bedrijfsprocessen door de gehele organisatie heen. Zie ook http://www.aiim.org/; AIMM is een onafhankelijke organisatie, die publiceert over contentmanagement. Online op 18-8-2006 2 COMET Pagina 6 van 45 Figuur 2 ECM-Architectuur Voorbeelden uit de afgelopen jaren hebben aangetoond dat het vaak complex is om één enkele totaaloplossing te bieden voor ECM. Daarom ligt de focus tegenwoordig vaak op ECM-deeloplossingen. De belangrijkste deeloplossingen zijn DM (document management), Records Management, Digital Asset Management en WCM (Web Content Management). ECM kan dus als de benadering worden aangemerkt. De ECM-totaaloplossing wordt tegenwoordig vaak in modulaire vorm aangeboden. Voorbeelden van een modulaire aanpak zijn de systemen van Stellent3 en OpenSesame4. Van benadering naar architectuur De visie op contentmanagement van een leverancier is vaak zichtbaar in de architectuur van het pakket. Een ECM-totaaloplossing heeft vaak een architectuur zoals in Figuur 2 aangegeven. Deze architectuur toont een abstracte businesslaag voor contentmanagement; deze verricht de basiswerkzaamheden die alle deeloplossingen binnen een ECM-pakket Zie http://www.stellent.com/nl/Producten/Universal_Content_Management/Content_Ser ver/index.htm. Website van CMS leverancier Stellent. Online op 15-9-2006 4 Zie http://www.openims.nl/openims2_com/112ee0bce837cda25ed7d7816165ef4c.php. Website van CMS leverancier OpenSesame, het figuur toont de architectuur. Online op 15-9-2006 3 COMET Pagina 7 van 45 kunnen gebruiken. Deze oplossing is schaalbaar en uitbreidbaar, maar vergt een organisatiebrede benadering, die al snel complex kan worden. Een andere visie op contentmanagement is zichtbaar in Figuur 3. Hier valt te zien dat een deeloplossing in het vorige plaatje nu een totaaloplossing is. De architectuur in deze figuur is weliswaar minder complex, maar tegelijkertijd ook minder schaalbaar. De CMS-pakketten Tridion5 en Mamboserver6 omvatten een dergelijke architectuur. Web Content Management WCM staat dus voor Web Content Management. De definitie is eenvoudig af te leiden van die van ECM: WCM: Technologie die is gerelateerd aan het beheren, aanbieden, verwerken en opslaan van alle webcontent in een organisatie. Figuur 3 WCM Architectuur Zie http://www.tridion.nl/Producten/R5/Overview.asp#2905. Website CMS leverancier Tridion. Online op 15-9-2006 6 Zie http://www.mamboserver.com/index.php?option=com_content&task=view&id=81&I temid=86. Website open source pakket Mambo. Online op 15-9-2006 5 COMET Pagina 8 van 45 De visie van Sogeti op Contentmanagement De technologie die nodig is voor WCM, wordt nadrukkelijk aangeboden in een CMS. CMS staat voor Content Management System. Het beheert webgerelateerde business content. Maar wat is contentmanagement nu precies? De meeste pakketleveranciers (vendors) hebben een eigen visie, die in ieder geval zichtbaar wordt via de architectuur van het pakket. In deze paragraaf laten we u graag – in beknopte vorm – kennismaken met de visie van Sogeti op Contentmanagement. Content? Waarschijnlijk heeft u ooit kennis genomen van de begrippen data, informatie & kennis vanuit een discipline als bedrijfskunde, filosofie, IT of communicatie. Zo ja, dan voelt u de bui vast al hangen7; wéér een extra begrip, dat zich positioneert tussen deze op zich al multi-interpreteerbare concepten. Geen zorgen; voor een CMS maakt het namelijk niet uit wat nu precies het verschil is tussen data, informatie of kennis. Zolang de materie digitaal beschikbaar is, kan deze altijd onder de noemer content worden geschaard. Content is namelijk niets meer of minder dan de verzamelterm voor het geheel van tekst, beeld, geluid en video dat beschikbaar is voor de gebruiker. Toegespitst op een CMS kan content worden omschreven als: Content: Het geheel van tekst, beeld, geluid of video, ontsloten naar een gebruiker8. Op basis van deze beschrijving is content binnen een Web Content Management System dus alles wat u op een webpagina kunt zien, lezen en horen. Die materie kunt u dus met een CMS managen ofwel beheren. Managen klinkt nog wat algemeen; vandaar de volgende omschrijving van contentmanagement: Contentmanagement: Het ontwikkelen, beheren, opslaan, verrijken, archiveren, ontsluiten en presenteren van content. Een WCMS is een systeem voor webcontent. Zo’n systeem kan één of verschillende van bovengenoemde taken automatiseren door middel van een vooraf of dynamisch bepaalde structuur. Volledig uitgeschreven wordt de definitie van een managementsysteem voor webcontent vervolgens: Web Content Management Systeem: Een systeem dat het ontwikkelen, beheren en/of presenteren van content binnen een webomgeving automatiseert. Als u deze definitie op uw netvlies houdt, kunt u instappen in elk willekeurig hoofdstuk van de methodiek. Zie bijvoorbeeld Boisot, M (1998). Knowledge Assets: Securing Competitive Advantage in the Information Economy. Blz 10-15. Oxford: Oxford University Press. 8 Zie gids Content Management Systemen 2006, blz. 9 7 1 VOORONDERZOEK CMS Deze fase start op het punt waarop uw organisatie heeft gehoord over de mogelijkheden van Content Management Systemen. Waarschijnlijk zijn er al goede redenen om aan te nemen dat uw businessprocessen via CMS kunnen worden geoptimaliseerd. Voordat echter wordt besloten om een CMS-selectietraject in gang te zetten, is het van belang dat de meerwaarde nader kan worden omschreven. Grondig inzicht in die meerwaarde verkrijgt u door de in dit hoofdstuk beschreven subfasen te doorlopen. COMET start bij de hoofdfase ‘Vooronderzoek’. Deze bestaat uit twee deelfasen, waarmee u over een instrument beschikt om de voor- en nadelen expliciet in kaart te brengen. Deelfase 1 behandelt de punten waarop een CMS meerwaarde kan toevoegen aan uw organisatie; deelfase 2 geeft vervolgens nader aan welke kosten en baten een rol spelen bij implementatie, onderhoud en gebruik van een CMS. Figuur 4 brengt deze fasering in beeld. Figuur 4 Verloop van Fase 1 COMET 1.1 Pagina 10 van 45 Bepaal de functionele meerwaarde van CMS Een CMS biedt vele voordelen, maar vergt ook een uitgebreid implementatietraject. Daarom is het van belang om de vraag te stellen of uw organisatie werkelijk baat heeft bij een CMS. Deze paragraaf geeft een opsomming van de verschillende functies die beschikbaar kunnen worden gemaakt en die wellicht interessant zijn. Ook wordt weergegeven binnen welke scenario’s een CMS kan worden ingezet. 1.1.1 Verschillende functies van CMS Een Content Management Systeem biedt verschillende functies voor het beheren van content; via deze functies kan content duidelijk worden gestuurd. De volgende facetten van een CMS zijn het meest prominent: - het is mogelijk om een uniforme lay-out toe te passen op verschillende content; - het is mogelijk om dezelfde content te presenteren met een verschillende layout; - het is mogelijk om dezelfde content binnen verschillende applicaties te laten terugkomen dankzij een scheiding van functionaliteit, lay-out en inhoud. Door deze facetten uit elkaar te trekken, bestaat er binnen CMS een aantal afgescheiden deelprocessen. Die deelprocessen kunnen door verschillende typen gebruikers worden beheerd, waardoor bijvoorbeeld de volgende rolverdeling mogelijk wordt: - redacteuren die content produceren; - ontwerpers die verantwoordelijk zijn voor de algemene lay-out (sjabloon); - technische beheerders die toegestane lay-outkenmerken beheren; - beheerders die gebruikersmanagement en onderhoud uitvoeren; - ontwikkelaars die de logica inbouwen zoals navigatie, systeemkoppeling, automatische archivering etc; - auditoren die content goedkeuren, rapportages genereren en statische analyses uitvoeren vanuit een marketingperspectief. Deze rollen hoeven niet volgens strikte definities gescheiden aanwezig te zijn; een enkele gebruiker kan verschillende functies gebruiken of bedienen. De functies zijn organisatieafhankelijk. Voor uw specifieke situatie zal moeten worden ingeschat welke meerwaarde een opsplitsing biedt. 1.1.2 Wanneer biedt een CMS meerwaarde? In de volgende gevallen kan een CMS interessant zijn: - u wilt regelmatig up-to-date content plaatsen op één of verschillende websites; de eigenaren van de content moeten zonder HTML-kennis content online kunnen plaatsen; de content van de website moet eenvoudig kunnen terugkomen in een nieuw ontwerp van de website; verschillende redacteuren behoren uiteenlopende mogelijkheden te hebben binnen een website; COMET - Pagina 11 van 45 content uit het systeem moet beschikbaar kunnen worden gemaakt voor andere systemen; het is wenselijk dat omvang en aantal van uw websites eenvoudig kunnen worden uitgebreid. Een CMS biedt minder voordelen in de volgende situaties: - bij actiematige websites op basis van een eenmalige lay-out (bijvoorbeeld voor een tijdelijke reclamecampagne); - statische websites die worden beheerd door een gering aantal technisch onderlegde gebruikers (een zelden voorkomende situatie); - websites met een geringe hoeveelheid content met weinig onderhoud (bijvoorbeeld een website die dient voor de presentatie van een statisch onderwerp). 1.1.3 Go/No Go? Om te bepalen of een CMS interessant is, dient u een beeld te hebben van de hoeveelheid en het type content, en van de daarmee verbonden dynamiek. Indien u één of meer functies of scenario’s uit deze paragraaf wenselijk acht, dan is het van belang om de kosten en baten van een CMS tegen elkaar af te wegen en deelfase twee op te starten. Op die manier kunt u bepalen of de kosten opwegen tegen de functionele voordelen. 1.2 Afwegen van voor- en nadelen Als een CMS interessant lijkt voor uw organisatie, kan een kosten/batenvergelijking inzicht geven in de uiteindelijke meerwaarde. Deze paragraaf gaat eerst in op de kosten en daarna op de baten. 1.2.1 Kosten De kosten van een CMS kunnen worden opgedeeld in kosten voor opstart en operationele kosten. De opstartkosten worden gevormd door: - licentiekosten; - hardwarekosten; - implementatiekosten; - migratiekosten; - opleidingskosten voor redacteuren en beheerders. Licentiekosten De licentiekosten kunnen behoorlijk uiteenlopen; ook het model voor de licentie is nogal variabel. U kunt het CMS zelf hosten, hiervoor een ASP (Application Service Provider) inschakelen óf zelf een CMS ontwikkelen. In de regel hangen de licentiekosten af van de gekozen opties, het aantal websites, het aantal gebruikers en het type support. Hardwarekosten Vaak worden er één of meer nieuwe webservers aangeschaft bij de overgang naar een nieuw CMS. Vaak betekent een nieuw CMS namelijk een nieuwe COMET Pagina 12 van 45 softwareomgeving, toenemend internetverkeer en een aanpassing van uw architectuur. Implementatiekosten De meeste CMS’en werken niet out-of-the-box; meestal moeten ze op maat worden ingeregeld voor een organisatie. De kosten die doorgaans worden gemaakt tijdens een implementatietraject, gelden vaak ook voor een CMS-implementatie. Denk hierbij aan het maken van een functioneel, technisch en grafisch ontwerp, projectmanagement, inrichting en aanpassing van het CMS. Maar ook aan: het invoeren van content, installatie van software, testen, nazorg enz. Migratiekosten Een niet te onderschatten factor zijn de migratiekosten. Deze kosten vloeien voort uit het overzetten van gegevens van het ene systeem naar het andere. Hiervoor heeft Sogeti zelfs haar eigen methodiek ontwikkeld: Mikado™. Inmiddels beschikt vrijwel elke organisatie al over één of meer websites en vaak is het wenselijk dat de content en/of lay-out van deze websites worden gemigreerd naar het nieuwe CMS. Opleidingskosten Gebruikers moeten vertrouwd raken met een CMS. Daarom moeten er stakeholders (belanghebbenden) worden betrokken bij de implementatie, redacteuren worden getraind, documentatie worden opgeleverd en dient het technisch onderhoudsteam te worden ingewerkt voor het technisch managen van het CMS. De operationele kosten worden gevormd door: - onderhoudscontract; - technisch beheer; - functioneel beheer; - redactioneel beheer. Onderhoudscontract De CMS-software zal van tijd tot tijd moeten worden voorzien van updates en patches. Een deel van de updates - bijvoorbeeld voor bugfixing - zal vaak gratis zijn. Een nieuwe release van de software brengt daarentegen vaak nieuwe kosten met zich. Het type licentie bepaalt meestal hoe het onderhoudscontract eruit ziet; vaak betreft het een percentage van de kosten van de aanschafprijs. Technisch beheer De kosten voor technisch beheer hebben te maken met het onderhoud dat nodig is om storingen te voorkomen en te verhelpen. Dat onderhoud kan worden uitgevoerd door de CMS-leverancier, een partner of door uw eigen ICT-beheerorganisatie. Functioneel beheer Bedrijfsprocessen zijn vrijwel altijd dynamisch van aard. Van tijd tot tijd worden werkwijzen aangepast, of wordt zelfs de gehele organisatiestructuur gewijzigd. Ook op andere gebieden kunnen zich veranderingen voordoen: aanpassing van de huisstijl, een fusie met een ander bedrijf etc. Het CMS zal dan moeten worden aangepast; de hiermee gemoeide kosten vallen onder functioneel beheer. Redactioneel beheer Naast technisch beheer vindt er ook altijd redactioneel beheer plaats; dit kan worden uitgevoerd door een eindredacteur of de CMS-applicatiebeheerder. Hierbij gaat het COMET Pagina 13 van 45 om beheer van toegangsrechten, inhoudelijke controle van content en bewaking van de huisstijl. 1.2.2 Baten De baten van een CMS zijn op te splitsen in directe en indirecte baten. Directe baten vloeien voort uit aanwijsbare procesverbeteringen; indirecte baten volgen uit kwalitatieve verbeteringen. Belangrijkste directe baten die kunnen worden gerealiseerd: - besparing op de inzet van redacteuren plus ICT- & redactiebeheer; - vervallen van een webmasterfunctie; - korter implementatietraject voor nieuwe websites; - verschuiving van print naar internet; - hergebruik van content. Besparing inzet redacteuren/beheer & webmaster De redacteuren kunnen de content van een website op een eenvoudige en beheersbare manier – en bovendien zelfstandig - managen; het businessproces dat ten grondslag ligt aan het publiceren van een artikel wordt op die manier aanzienlijk vereenvoudigd. De functie van ondersteunende webmaster wordt vaak overbodig. Nieuwe websites Functionaliteit en content zijn binnen de lay-out van een CMS in de regel gescheiden. Daarom kan vaak snel een nieuwe website met dezelfde lay-out en andere content (en vice versa) worden gerealiseerd. Verschuiving print naar internet Dankzij een up-to-date intra-, inter- of extranet is het niet nodig om papieren memo’s en nieuwsbrieven te gebruiken. Ook is het minder vaak nodig om mededelingen per mail te doen. Hergebruik van content Door dezelfde content uit het CMS te hergebruiken in verschillende websites, maar ook in nieuwsbrieven, RSS, PDA, Print en TV, kan een aanzienlijke kostenbesparing worden bereikt. Belangrijkste indirecte baten die kunnen worden gerealiseerd: - grotere klanttevredenheid dankzij actuele en juiste informatie; - hogere arbeidsproductiviteit door snellere beschikbaarheid van informatie; - hogere opbrengstkosten door snellere time-to-market; - consistente presentatie huisstijl/merk; - betere migratiemogelijkheden. Grotere klanttevredenheid Uw website is up-to-date is en zal vaker dan voorheen een lay-out op maat te zien geven; u kunt dan ook gemakkelijk een extra themawebsite met content op maat creëren. Hierdoor zal de klanttevredenheid van de bezoekers toenemen. Directe spin-off: klanten weten uw producten en diensten beter te vinden en ze zullen er dus vaker gebruik van maken! Hogere arbeidsproductiviteit COMET Pagina 14 van 45 Dankzij uw CMS wordt er méér werk verzet in minder tijd, ofwel: verhoging van de arbeidsproductiviteit. Snellere time-to-market U zult uw producten en diensten sneller kunnen aanbieden, zodat u daaruit eerder inkomsten kunt genereren. Consistente presentatie Een CMS kan vaak zo worden ingericht dat de huisstijl op een enkele plek is gedefinieerd en terugkomt op verschillende sites. Hiermee is een consistente layout gewaarborgd; de presentatie van uw bedrijf wordt daardoor verbeterd en uw merk of dienst wordt beter herkenbaar. Betere migratieopties Het is steeds belangrijker dat applicaties gegevens kunnen uitwisselen en dat deze kunnen worden overgezet naar andere systemen, bijvoorbeeld CRM-systemen, betalingssystemen, webshops etc. Een CMS biedt vaak import- en exportmogelijkheden die deze bewegingen vergemakkelijken, waardoor een forse kostenbesparing binnen een migratietraject haalbaar is. Een CMS dat volgens SOA werkt, kan de integratie en migratie aanzienlijk vergemakkelijken. COMET 2 Pagina 15 van 45 SELECTIE CMS Deze fase gaat in op het selectieproces van een CMS. Dankzij de algemene opzet zijn de beschreven stappen universeel toepasbaar. Voordat er concrete pakketten kunnen worden beoordeeld, moet een aantal fasen worden doorlopen om tot een goede beoordeling te komen. In de eerste fase wordt de selectieprojectgroep voor het CMS samengesteld. In de tweede fase worden de belanghebbenden geïdentificeerd. Hierna kunnen doel (derde fase) en eisen (vierde fase) worden bepaald. Tot slot kan in fase vijf gericht een selectie worden gemaakt op basis van offertes en demonstraties van verschillende leveranciers. Figuur 5 geeft deze fasen weer. Figuur 5 Verloop van Fase 2 COMET 2.1 Pagina 16 van 45 Samenstellen van de projectgroep Om de juiste fit voor de business te bepalen moeten de juiste mensen uit de verschillende lagen van uw organisatie in een projectgroep bij elkaar worden gebracht. De projectgroep is in deze fase vaak een andere dan tijdens de implementatie en nazorg. De projectgroep moet tijdens de selectiefase worden samengesteld uit de stakeholders ofwel belanghebbenden van de verschillende lagen in het bedrijf. Doorgaans zijn hierin vertegenwoordigd: - ICT; Marketing of Communicatie; hoofdredacteur; projectleider. Daarnaast kan eventueel een implementatiepartner deelnemen aan de projectgroep. In de volgende paragrafen wordt de rol van bovengenoemde projectleden omschreven. 2.1.1 ICT-afdeling Meestal is de ICT-afdeling verantwoordelijk voor de aanschaf van nieuwe systemen en deze stelt dan een aantal eisen op voor open standaarden, infrastructuur, support en onderhoudbaarheid. Ook moeten systemen vaak vanuit het budget van de ICTafdeling worden bekostigd. De ICT-afdeling bepaalt niet uitsluitend de primaire eisen. Het systeem moet door vele afdelingen binnen de organisatie worden gedragen. Daarnaast is ICT vaak een middel voor de business; de functionaliteit van het systeem moet aansluiten op de wensen, en niet andersom. Niettemin is de expertise van de ICT-afdeling zeer belangrijk voor het bepalen van de praktische haalbaarheid van een systeem op het vlak van implementatie en kwaliteitsaspecten. De ICT-afdeling zou daarom in de projectorganisatie moeten zijn vertegenwoordigd. Zo kan het hoofd van de ICT-afdeling optreden als vertegenwoordiger, of een Enterprise Applicatie Architect met beslissingsbevoegdheid. 2.1.2 Marketing & Communicatie De vorm van content, de beheersing van communicatiekanalen en management van informatie worden vaak ingevuld door de marketing- en communicatieafdeling. De functionele wensen voor CMS worden vaak door deze afdeling opgesteld. 2.1.3 Hoofdredacteur Ten aanzien van contentmanagement heeft een hoofdredacteur inzicht in de huidige businessprocessen. Ook zal hij of zij een visie hebben op de eventuele optimalisatie daarvan. Door de hoofdredacteur al in dit stadium te betrekken, kan tijdig worden gesignaleerd of een CMS aansluit bij de (gewenste) contentflow in een organisatie. COMET Pagina 17 van 45 2.1.4 Projectleider De projectleider fungeert als spil van het project. Hij of zij moet zoveel mogelijk zonder eigen agenda de verschillende belangen van de business afstemmen en bovendien de belangrijkste concepten van CMS kennen. Daarom verdient het aanbeveling om de projectleider in de gelederen van de eigen organisatie te zoeken. 2.1.5 Implementatiepartner Indien de organisatie zelf geen deskundigheid heeft op het gebied van CMS-selectie, kan er voor worden gekozen een implementatiepartner te laten deelnemen in het project. Een voordeel hiervan kan dan weer zijn dat hij of zij geen directe belangen binnen de organisatie heeft en daarom de rol van objectieve projectleider op zich zou kunnen nemen. Let wel: een implementatiepartner heeft zelf vaak directe relaties met pakketleveranciers van CMS. Hierdoor beschikt hij of zij over een gedegen pakketkennis, maar kan de mening over de juiste keus tevens gekleurd zijn. 2.2 Identificeren van Stakeholders Wanneer uw projectgroep eenmaal heeft vastgesteld dat een CMS voordelen kan bieden voor de organisatie, is het van belang dat er via een methodische aanpak wordt uitgezocht welk CMS de juiste fit heeft met uw organisatie. Ook dit moet de projectgroep bepalen. Een cruciale stap hierin is het identificeren van de belanghebbenden; zij moeten bij de projectgroep aangeven wat hun wensen zijn. Om dit proces in goede banen te kunnen leiden, dienen de leden van de projectgroep een goed begrip te hebben van de mogelijkheden van het CMS. Dit inzicht zou geborgd moeten zijn doordat een van de deelnemers aan de projectgroep kennis heeft van de belangrijkste CMS-concepten. Doorgaans zullen de volgende partijen een bepaalde vorm van belang hebben: - projectsponsors; - Marketing; - Communicatie; - Sales; - Redactie; - ICT; - externe partners; - helpdesk; - interne eindgebruikers; - externe eindgebruikers; - externe partners. 2.2.1 Raadpleging van de achterban De leden van de projectgroep moeten tijdens de selectieprocedure de wensen en eisen van de betrokkenen afwegen. Van de verschillende partijen moet inzichtelijk worden gemaakt hoe vaak, waarvoor en waarom ze het systeem kunnen gaan gebruiken. COMET Pagina 18 van 45 De achterban wordt geraadpleegd door middel van informatiebijeenkomsten, waarin mogelijke CMS-scenario’s worden geschetst. Op die manier wordt in een zeer vroege fase betrokkenheid binnen de organisatie verkregen. 2.3 Bepaal het doel van CMS Vanuit de projectgroep moet inzichtelijk worden gemaakt wat het doel is van het CMS. Wellicht zijn er verschillende doelen en deze moeten in een zo vroeg mogelijk stadium expliciet worden gemaakt. Het succes kan dan achteraf succes goed worden gemeten en tevens wordt er een basis gelegd voor verdere wensen. 2.3.1 Brown Papersessie Als input voor de bepaling van de doelen kunnen de verzamelde wensen uit de achterban worden gebruikt, in samenhang met een eigen visie. Een goede methode om de doelen te bepalen is het de zogenaamde brownpapersessie. Tijdens een dergelijke sessie kunnen ideeën op een laagdrempelige manier worden verzameld, gegroepeerd en geprioriteerd. Uiteindelijk kunnen hieruit één of verschillende doelen worden vastgesteld. 2.3.2 - - 2.4 Tips voor het bepalen van het doel Formuleer het doel als productdoelstelling, niet als procesdoelstelling. Het doel zou bijvoorbeeld moeten luiden: “Uniforme communicatie naar bezoekers van verschillende websites” in plaats van: “Het ontwikkelen van een CMS waarmee uniforme communicatie mogelijk wordt” Door het doel als productdoelstelling te formuleren komt u minder snel in de verleiding om het doel te specificeren vanuit de functionaliteiten van een CMS dat u al bij voorbaat in gedachten heeft. In deze fase is het van belang om te denken vanuit de wensen van de organisatie. Stel vast of uw content eenvoudig via verschillende kanalen - zoals print, email en DTP - beschikbaar moet komen. Bedenk hierbij ook of het CMS de gegevens hiervoor beschikbaar moet stellen aan andere applicaties, of zelfs direct moet kunnen aanbieden aan de gebruiker. Specificeer de eisen aan CMS Zodra duidelijk is geworden wat het doel is van het CMS, moeten de functionele, technische en organisatorische eisen worden uitgewerkt. Deze moeten worden afgeleid van het doel en dit moet de betrokkenen tijdens het specificeren permanent voor ogen blijven staan. 2.4.1 Formulering van de eisen Ook hier kan een brownpapersessie of een vergelijkbare brainstormtechniek de projectgroep helpen om de randvoorwaarden, eisen en wensen inzichtelijk te maken. Uit de vraag: “Hoe bereik ik mijn doel?” vloeien wensen, eisen en randvoorwaarden voort, die kunnen worden uitgeselecteerd naar de uiteindelijke eisen. Nadat mogelijke eisen en randvoorwaarden zijn genoteerd, kan met behulp van MoSCoWprioritering een nadere opsplitsing worden gemaakt. COMET Pagina 19 van 45 MoSCoW staat voor Must have, Should have, Could en Would like to have, but won’t have this time. Deze prioritering wordt gemaakt binnen geldende randvoorwaarden zoals het budget en in het licht van het eerder opgestelde doel 9. Hierna zou een document moeten worden opgesteld waarin het doel en de eisen staan beschreven; dat document dient vervolgens door alle betrokken expliciet te worden goedgekeurd. 2.4.2 Het in kaart brengen van de eisen De wensen die spontaan naar voren komen, hebben meestal betrekking op functionele en technische aspecten. Het gaat dan bijvoorbeeld om wensen zoals: - snel en eenvoudig content online zetten; - consistent contentbeheer over verschillende websites; - doeltreffende Disaster Recovery; - een redactiesysteem dat content-auditing mogelijk maakt; - eenvoudig en snel sjablonen kunnen definiëren om de lay-out van de content te bepalen; - uitwisselbaarheid met andere systemen (bijvoorbeeld naar e-mailsystemen); - een beheersbaar systeem met een uitgebreid rechtenmodel; - uitbreidbaarheid naar verschillende websites; - notificatiemogelijkheden; - schaalbaarheid CMS. Het is tevens van groot belang dat organisatorische eisen in kaart worden gebracht. Denk daarbij aan eisen die voortvloeien uit zaken zoals: - compliance; - beveiliging van de gegevens; - toegankelijkheid (voor mensen met een handicap); - minimaal driejarig bestaan in Nederland; - compatibiliteit met andere producten (zoals een databasepakket); - open standaarden tegenover gesloten standaarden; - service (kan bijvoorbeeld niet aanwezig zijn bij een Open Source CMS). Indien met dergelijke zaken geen - of slechts beperkt - rekening wordt gehouden, dan zou dit ook expliciet moeten worden benoemd en vastgelegd. 2.4.3 Bepaal de structuur van uw content Naast het opstellen van de hiervoor genoemde eisen is het van belang om uw content te analyseren en uzelf bewust de volgende vraag te stellen: Wat is de structuur van mijn content? Het uiteindelijk door u gekozen CMS dient content in de door u gewenste structuur te kunnen opslaan. Een voorbeeld: een CMS-pakket als Tridion slaat content op in de vorm van XML-componenten en dwingt daarmee een bepaalde contentstructuur af. Als gevolg daarvan kan het minder geschikt zijn om content op te slaan die bestaat uit meerdere “bladzijden”. Andere CMS-varianten kunnen bijvoorbeeld beperkingen Zie ook http://www.dsdm.nl/nl/dsdm/timeboxing.asp. Website van de DSDM foundation, methodiek om succesvol IT projecten uit te voeren. Online op 15-9-2006 9 COMET Pagina 20 van 45 opleggen aan zaken als de lengte of benaderbaarheid van content en standaardisatie. NB: mogelijkerwijs voldoet een bepaald CMS-pakket aan alle van toepassing zijnde functionele en organisatorische eisen, maar is het niet geschikt om uw content op de juiste manier op te slaan. 2.5 Uiteindelijke selectie van CMS Nadat de projectgroep onderlinge afstemming over het doel, de eisen en wensen heeft bereikt, kan worden gestart met het selectieproces. Aan de hand van de hieruit voortgekomen lijst kunt u een geprioriteerd overzicht opstellen en aangeven welke randvoorwaarden gelden. Indien u deze lijst naar de verschillende leveranciers stuurt, zal ongetwijfeld blijken dat een groot aantal van hen aan uw wensen tegemoet kan komen. Daarom is het van belang dat u een stapsgewijze aanpak kiest om de voor u interessante partijen te kunnen bepalen. 2.5.1 Van longlist naar shortlist Op basis van een snelle marktscan kunt u zich al snel een aardig beeld vormen van CMS’en die in aanmerking komen. Een prima bron is de “Gids Content Management Systemen”, die jaarlijks door Entopic wordt uitgegeven 10. In deze gids is, naast de grote partijen, ook een aantal kleinere spelers opgenomen die interessante pakketten bieden. RFI Na deze voorselectie kunt een longlist maken. De bedrijven op deze lijst kunt u een vragenlijst sturen; de vakterm voor een dergelijke “questionnaire” is RFI (Request For Information). Op basis van de feedback die u hierop ontvangt kunt u een shortlist maken met vermelding van 3 producten. RFP De pakketleveranciers op de shortlist kunt u om een RFP vragen. RFP staat voor ”Request For Proposal” ofwel offerteaanvraag. Tijdens het offertetraject wordt extra gedetailleerd ingegaan op alle aspecten en hierbij kunt u extra nadruk leggen op support en licenties. Als ondersteuning van uw selectie tussen de drie partijen kunt u vragen om productdemonstraties. Wellicht is een proof of concept nog beter. Een proof of concept is een op uw organisatie toegespitste proefimplementatie, die de sterke en minder sterke punten van een product uitstekend inzichtelijk maakt. Voor een proefimplementatie wordt overigens meestal een bepaald bedrag in rekening gebracht. 2.5.2 Geen geschikte leverancier Het kan voorkomen dat een geschikt pakket voor uw wensen en eisen niet bestaat. In dat geval kunt u kiezen voor compleet maatwerk. Die noodzaak kan zich voordoen Hylkeman T, Postma H, Straver F, Simons J: Gids Content Management Systemen 2006. Entopic. 10 COMET Pagina 21 van 45 in twee “extreme” situaties: u heeft minimale functionele wensen, die met minimale inspanningen van een ontwikkelteam kunnen worden gerealiseerd, of uw wensen zijn zó bijzonder en complex dat geen enkel pakket daaraan tegemoetkomt. In het laatste geval dient u er rekening mee te houden dat het leveren van compleet maatwerk een zware druk legt op uw organisatie en dat de met maatwerk gemoeide kosten in de regel een veelvoud zijn van de kosten voor een kant-en-klaar pakket. 2.5.3 Het contract Wanneer u eenmaal een keuze heeft gemaakt, dient er een contract te worden opgesteld. Wellicht moet er tevens een contract worden aangegaan met de implementatiepartner. Overtuig u er van dat u de referenties van de implementatiepartner ook zorgvuldig heeft bestudeerd; hierbij verdient het aanbeveling om de partner in te lichten dat u zijn referenties wil controleren. Zodoende verlopen de contacten op de juiste wijze. Ook is het van belang om te controleren of de kwaliteit van de CV’s van de CMS-consultants die voor u aan de slag gaan, voldoende is. Voor het contract kunnen verschillende constructies van toepassing zijn. Zo kunt u een proefperiode afspreken, een leaseconstructie opstellen waarbij u een ingerichte server in bruikleen neemt of bijvoorbeeld eigendom van de broncode bedingen. Algemeen advies: laat het contract opstellen door een jurist met kennis van ICT. Het is raadzaam om onderstaande onderwerpen mee te nemen: - functionele specificaties; - snelheid en configureerbaarheid; - doorlooptijd (start tot ingebruikneming; wordt doorgaans te positief ingeschat); - lengte van de acceptatieperiode; - onderhoud en beheer (SLA); - performance van het systeem; - opleiden van de gebruikers; - testen van het systeem; - documentatie. Per onderwerp moeten de verwachtingen expliciet worden beschreven op een meetbare wijze; dit wordt aangeduid als het definiëren van KPI’s. Ook moeten de sancties bij niet-nakoming worden vastgelegd. U kunt van tevoren afspreken dat de kwaliteit van de implementatie aan het eind van het traject door middel van een audit van een derde partij wordt gecontroleerd. Dit is vooral aan de orde als er wordt gewerkt met implementatiepartners. Door de audit te laten uitvoeren door de vendor (CMS-leverancier) zelf, vergroot u de kans op een kwalitatief goede controle. 3 DE IMPLEMENTATIE De implementatie van een CMS wordt in de praktijk al snel onderschat. De meeste CMS’en zijn namelijk geen out-of-the-boxpaketten, hoewel die indruk kan worden gewekt bij een eerste kennismaking. Onder het mom van de gevleugelde woorden “even een website ontwikkelen” kan gemakkelijk een al te simplistische opvatting van het implementatietraject ontstaan. In dit hoofdstuk wordt ingegaan op de verschillende fasen van het implementatieproces en worden belangrijke valkuilen en tips beschreven. Er wordt voor elke implementatiefase aangegeven waar specifiek op moet worden gelet tijdens een CMS-implementatie. De inzichten zijn dan ook toepasbaar binnen verschillende specifieke implementatiemethoden, zoals het watervalmodel, DSDM en RUP. Eerst wordt ingegaan op de voorbereidende fase, daarna op de ontwerpfase en vervolgens op de daadwerkelijke implementatiefase. Figuur 6 geeft deze fasen weer. Figuur 6 Verloop Fase 3 Voor elke subfase is een generieke structuur gedefinieerd, die aangeeft op welke wijze de subfasen efficiënt kunnen worden gestructureerd. Dat proces is in de laatste paragraaf weergegeven. COMET 3.1 Pagina 23 van 45 Samenstelling van de nieuwe projectorganisatie Tijdens de voorbereidende fase wordt een nieuwe projectorganisatie gerealiseerd. De projectorganisatie wordt vaak mede bepaald door de procesmethodiek, bijvoorbeeld Prince211. Afhankelijk van de schaal kunnen verschillende groepen worden gedefinieerd om specifieke subprocessen ten aanzien van infrastructuur, ontwerp, content en implementatie uit te werken. De volgende rollen/groepen dienen aanwezig te zijn: 3.1.1 Projectleider Vaak is de projectleider in deze fase dezelfde als tijdens de selectiefase, hoewel dit niet noodzakelijk is. De (technische) projectleider zorgt voor afstemming binnen de projectgroepen en verzorgt vaak de communicatie met de buitenwereld. Het is essentieel dat de projectleider ervaring heeft met de processen die spelen bij de implementatie van een CMS. 3.1.2 Stakeholders Gedurende het project moet er met regelmaat aan de stakeholders (belanghebbenden) worden gerapporteerd over de voortgang. Daarom is het praktisch om hen van meet af aan in het project te betrekken. Ook kunnen functionele keuzes op deze wijze snel worden kortgesloten en worden verrassingen uitgesloten. 3.1.3 Implementatiegroep De implementatiegroep bestaat voor zover mogelijk uit (ervaren) CMSontwikkelaars. Als deze ervaring niet op het gewenste niveau ligt en deze lacune dient te worden gecompenseerd, dan kan bijvoorbeeld ook de pakketleverancier deel uitmaken van de projectgroep. De ontwikkelaars moeten minimaal kennis hebben van de talen die binnen het pakket worden gebruikt en een redelijke kennis van HTML en CSS. Daarnaast verdient het de aanbeveling om in de projectgroep iemand op te nemen met kennis van design. Maar al te vaak wordt namelijk een ontwerp van een extern reclamebureau aangepast; zodra dat wordt gewijzigd, ontstaan er veel extra overheadkosten. Binnen de implementatiegroep kan een teamleider/architect worden aangesteld. Deze kan alle ontwerpfacetten monitoren en over de voortgang rapporteren aan de projectleider. 3.1.4 Infrastructuurgroep Voor het beheer van de infrastructuur is de afdeling ICT-Beheer meestal verantwoordelijk. Het is daarom zeer belangrijk dat ICT-Beheer gedurende het Prince2 is een projectmanagementmethodiek, zie ook http://nl.wikipedia.org/wiki/Prince2 (online op 11-8-2007) 11 COMET Pagina 24 van 45 gehele project betrokken blijft. Aangezien zij de applicatie uiteindelijk dient te beheren, is het belangrijk om ontwerpkeuzes telkens te toetsen aan de randvoorwaarden van die afdeling (bijvoorbeeld ten aanzien van het openstellen van technische communicatiekanalen, SLA’s enzovoort). Dit is bijvoorbeeld aan de orde zodra er met externe systemen moet worden gecommuniceerd, als er een technische keuze moet worden gemaakt voor een bepaalde techniek etc. 3.1.5 Contentgroep De eigenaren van de content moeten gedurende de implementatie hun content vaak alvast aanmaken, klaarmaken voor een migratie of opschonen. Er moet worden gewaakt voor een situatie waarin content niet tijdig gereed is om te worden opgenomen in een nieuw systeem. 3.2 Opstellen van het ontwerp De ontwerpfase bestaat uit een aantal deelfasen: het opleveren van een designvoorstel, het HTML-ontwerp, Functioneel Ontwerp (FO) CMS en een Technisch Ontwerp (TO) CMS. Hierna zetten we de visie van Sogeti uiteen. Een website wordt geïmplementeerd in een CMS Sogeti hecht veel waarde aan deze statement; een toelichting hierop vindt u in de rest van deze paragraaf. 3.2.1 Designvoorstel Binnen onze visie is het beginnen met design van groot belang. Hierdoor wordt het eindproduct immers inzichtelijk voor alle betrokkenen, waardoor er beter kan worden geanticipeerd op de gewenste functionaliteit. Hierdoor is de projectgroep beter in staat om de specificaties voor het CMS te expliciteren voor het functionale ontwerp. Tijdens de meeste ICT-projecten ontstaan door voortschrijdend inzicht aanvullende wensen, die niet van te voren zijn opgesteld met de implementatiepartner. Om moeilijkheden uit te sluiten, dient deze situatie zo veel mogelijk te worden voorkomen. Het design dient te worden gemaakt door een gespecialiseerd bureau of door een professional; het kan bestaan uit een aantal screenshots. 3.2.2 Clickable Model Na het uitwerken van het designvoorstel is het wenselijk om een clickable HTMLmodel van de website op te leveren. Immers: De werking en attractiviteit van een website is een resultante van de usability (gebruikerservaring), het design en functionaliteit. Een begrip als usability laat zich niet gemakkelijk omschrijven binnen een functioneel ontwerp. Een clickable model van de website biedt echter zonder meer uitkomst. Het opleveren van zo’n model kost immers meestal niet veel tijd, aangezien er geen of weinig functionaliteit hoeft te worden geïmplementeerd. COMET Pagina 25 van 45 Andere voordelen van het opleveren van een clickable model zijn: - tijdig signaleren van technische moeilijkheden bij het realiseren van het CMSontwerp; - beschikbaarheid van een concreet tussenresultaat. Het is van belang dat de voltallige projectgroep zich kan vinden in het model; dit dient dan ook te worden goedgekeurd door de gehele groep. Het design biedt vaak een gezamenlijk begrippenkader voor de groep, waardoor het abstractieniveau afneemt. 3.2.3 Functioneel ontwerp De functionele specificaties moeten door de gehele projectgroep worden gedragen. Een aantal specificaties staat al vast; deze staan omschreven in de RFP (offerte). Overigens dienen deze specificaties nog wel tot in detail te worden uitgewerkt. Eén of meer brownpapersessies met de gehele projectgroep kunnen enorm helpen om alle wensen en eisen inzichtelijk te maken. Ook helpen dergelijke sessies om de communicatie binnen de projectgroep te verbeteren. Bij een groot CMS-project worden de wensen en eisen veelal in een afzonderlijke fase verzameld; dit proces staat bekend als requirements-analyse. Na het verzamelen van alle wensen en eisen moet worden vastgesteld welke elementen er uiteindelijk worden meegenomen tijdens de realisatie van het systeem; dit onderdeel wordt ook wel aangeduid als scoping. In elk geval moeten alle onderdelen van de RFP tot in detail worden uitgewerkt in een functioneel ontwerp. Dit document vormt de blauwdruk voor het op te leveren systeem. De inhoudsopgave van een functioneel ontwerp voor een CMS bevat vaak de volgende onderdelen. Managementsamenvatting Samenvatting die - zonder vakspecifieke termen - beschrijft waarvoor het ontwerp is gemaakt, wat de belangrijke functies van het CMS zijn en hoe het systeem door de organisatie kan worden gebruikt. Scope Door het opnemen van de scope van het systeem kan worden gecontroleerd of alle elementen zijn omschreven in het ontwerp dat dient te worden gerealiseerd. Contentplan Beschrijving van de content die op de website moet verschijnen. Paginatypen Omschrijving van de paginatypen die vanuit het CMS worden gepubliceerd. Navigatie Beschrijving van de werking van de navigatie en de rangschikking van de content op de website. Redactiemodel COMET Pagina 26 van 45 Overzicht van personen die de content gaan creëren, beschikbare rollen en opbouw van het rechtenmodel. Processen Omschrijving van bedrijfsprocessen in en rond het systeem, bijvoorbeeld van een geautomatiseerde workflow. Typische CMS-processen zijn het publicatieproces, goedkeuring van content en archivering van content. 3.2.4 Technisch ontwerp Met behulp van het FO zijn alle functionele wensen en eisen die moeten gerealiseerd, vastgelegd. Ook over design en usability is overeenstemming bereikt. Op basis hiervan kan het technische ontwerp worden opgesteld. Het technische ontwerp moet in elk geval worden gekeurd door ICT-Beheer en de implementatiegroep. Onderstaand een opsomming van de doorgaans belangrijke onderdelen van een technisch ontwerp voor een CMS. Codeerstandaarden Beschrijving van de manier waarop naamgeving van variabelen, sjablonen en constanten wordt uitgevoerd. Daarnaast kan worden beschreven op welke manier technisch commentaar moet worden toegevoegd, wat de structuur van functies is, CSS, HTML enzovoort. Dataontwerp De structuur van content kan worden opgesplitst in velden zoals titel, datum, rijke tekst, numerieke velden en automatisch berekende velden. Per type veld kan worden aangegeven of er een verplichting is om dit te vullen, of het wordt gevuld vanuit een vaste lijst van waarden en of er een standaardwaarde is. Functionele blokken Beschrijving op technisch niveau van de geautomatiseerde functies van het systeem en van de technische werking van de paginatypen (templates). Kwaliteitsrichtlijnen Beschrijving van de performance en beschikbaarheid van het systeem, compatibiliteit met webbrowsers en webstandaarden die worden nageleefd (bijvoorbeeld ten aanzien van toegankelijkheid). Architectuur Beschrijving van de systeemarchitectuur. Infrastructuur Beschrijving van de serverinfrastructuur en communicatieprotocollen. 3.3 Uitvoeren van de implementatie Tijdens de implementatiefase wordt datgene wat in de ontwerpfase is vastgelegd, gerealiseerd. Deze fase neemt normaal gesproken de meeste tijd in beslag en kan COMET Pagina 27 van 45 worden opgesplitst in drie implementatiefasen: organisatorisch, content en technisch. 3.3.1 Organisatorische implementatie De organisatorische implementatie heeft betrekking op de impact van het maatwerk op uw organisatie. Hieronder wijzen we op een aantal aandachtspunten en activiteiten die uw aandacht verdienen. Definieer een planning met mijlpalen Een aantal van deze deelfasen kan gelijktijdig verlopen en deze fasen zijn bij voorkeur zo gedetailleerd mogelijk vastgelegd in een planning. Het verdient aanbeveling om een aantal mijlpalen in de planning op te nemen. Een mijlpaal markeert de gewenste oplevering van een subsysteem; u kunt hierbij denken aan een deelapplicatie zoals een forum, navigatiestructuur, voltooiing van een migratie enzovoort. Ontwikkel een rollback-scenario Het is van belang dat u, voordat u begint met de implementatie, een rollbackscenario of disaster recovery plan opstelt. U heeft nu nog alle gelegenheid om rekening te houden met alle relevante aspecten tijdens de implementatie. Opleiding van gebruikers De toekomstige gebruikers van het CMS moeten op een vroeg tijdstip in het proces worden betrokken. Zodra het systeem het toelaat, kan er een eerste kennismaking worden georganiseerd. Hieruit volgen doorgaans suggesties ter verbetering; deze kunnen eventueel direct worden meegenomen, zeker als het quick wins zijn. De training kan worden gegeven door de teamleider of een presentatievaardige ontwikkelaar. Beiden zijn op de hoogte van de status van het systeem, kunnen de werking toelichten en de gebruiker snel op weg helpen. Communicatieplan Tijdens de ontwikkelingsfase zult u de betrokkenen in de organisatie willen raadplegen of informeren. Door vast te stellen op welk moment welke boodschap wordt gecommuniceerd, en met welk doel, bereikt u dat de status van het project altijd helder is. Heldere communicatie over het project voorkomt vragen achteraf en verkeerde verwachtingen; tevens weten betrokkenen dan wanneer er een bepaalde actie van hen wordt verwacht. 3.3.2 Contentimplementatie De invoer van content, ontwikkeling van nieuwe content of migratie van content is vaak een ingrijpende operatie, die dan ook zorgvuldig moet worden gepland. Nieuwe Content Invoeren Invoer, controleren en bewerking van content legt namelijk vaak een zware druk op de organisatie en kan de uiteindelijke oplevering vertragen. De meeste redacteuren hebben immers geen zitting in de projectgroep en moeten - naast hun normale werkzaamheden - het systeem voeden met de juiste content. COMET Pagina 28 van 45 Verder is het belangrijk om te beseffen dat er nu een kans ligt om de bestaande content te optimaliseren, controleren en up-to-date te maken. De hiermee gemoeide tijd neemt daardoor uiteraard alleen maar toe; anderzijds wordt de kwaliteit tegelijkertijd verbeterd. Test van content voor het maatwerk Daarnaast kan het functioneren van het maatwerk alleen goed worden getest als het systeem representatieve content bevat. Het is daarom verstandig om voor een select aantal redacteuren een spoedcursus CMS op te zetten, zodat deze de ontwikkelaars kunnen voorzien van een representatieve testset van content. Bijkomend doel van een dergelijke cursus is dat aan de redacteuren duidelijk wordt gemaakt hoe ze kunnen meewerken aan de implementatie. Migratie Vaak wordt er ook een migratie van content uitgevoerd vanuit een oud systeem. Deze migraties zijn meestal behoorlijk complex en vergen in het beste geval een beperkte hoeveelheid handmatige controle. Dit kost vaak veel tijd; wanneer u een contentmigratie moet uitvoeren, is het dan ook verstandig om deze door specialisten te laten uitvoeren. Sogeti heeft de Mikado migratiemethodiek ontwikkeld en deze kan bij dergelijke operaties uitstekende handvatten bieden. 3.3.3 Technische implementatie De technische implementatie kan worden opgesplitst in de implementatie van de hardware met geïnstalleerde CMS-software en daarnaast het maatwerk zelf. Hardware en pakketinstallatie De initiële installatie van het CMS gebeurt vaak door de pakketleverancier zelf. Het inregelen van de configuratie (zoals gebruikersrechten) moet nauwkeurig worden afgestemd met ICT-Beheer. Het is belangrijk om voor de aanvang van deze fase alle benodigde ontwikkelomgevingen te hebben ingeregeld (programmatuur + hardware) en voor autorisaties te hebben gezorgd. Denk daarbij ook aan zaken als: - DNS-registraties; - Disaster Recovery; - afstemming met eventuele hosting partners. Zie ook het kopje maatwerk voor de benodigde systemen. Maatwerk Het programmeerwerk komt voor rekening van de implementatiegroep. De teamleider en projectleider monitoren het proces nauwkeurig en meten de voortgang. Het is belangrijk om technische problemen tijdig te signaleren en mogelijke oplossingen of work around te definiëren. Het is van belang dat deze keuze duidelijk wordt gedocumenteerd (in bijvoorbeeld een beslisdocument). Bij voorkeur wordt er gewerkt volgens OTAP; zie Figuur 7. Dit houdt in dat de Ontwikkeling, Test, Acceptatie en Productie van het maatwerk wordt uitgevoerd in verschillende omgevingen. COMET Pagina 29 van 45 Figuur 7 OTAP-omgeving De ontwikkelaars hebben bij voorkeur de beschikking over een gescheiden omgeving waarop het maatwerk kan worden geprogrammeerd; voor de testers wordt voorkeur gegeven aan een omgeving waar de voltooide functies worden aangeboden door de ontwikkelaar. De acceptatie van geteste functies kan door een derde groep betrokkenen worden verstrekt in een aparte omgeving, waarna het systeem in productie kan worden genomen. COMET 3.4 Pagina 30 van 45 Standaardfaseringsmodel Bij het opstellen van deelplannen voor de drie subfasen kan telkens gebruik worden gemaakt een standaardstructuur. Regatta® staat garant voor een uitstekend model, dat een handvat geeft voor het voltooien van de subfasen12; zie Figuur 8. Figuur 8 Standaardfaseringsmodel Het model helpt om het proces in elke subfase beheersbaar te maken voor de verschillende betrokken partijen. Denk hierbij aan partijen zoals de leverancier, implementatiepartner, communicatieafdeling en ICT-beheerorganisatie. Het model zorgt voor een controleerbaar en voorspelbaar verloop van de subfasen. Door de verschillende partijen bijvoorbeeld tijdig te betrekken bij belangrijke communicatie, kunnen de benodigde middelen en resources ook op de juiste tijdstippen beschikbaar worden gesteld. Ook hier geldt weer: het faseringsmodel kan parallel met methoden zoals (D)SDM worden gebruikt, maar ook parallel met de functionele en technische implementatie van een pakket. In paragraaf 3.1.1 wordt ingegaan op de inhoud van de deelfasen; in paragraaf 3.1.2 komen de implementatieaspecten aan de orde die tijdens elke deelfase moeten worden geanalyseerd. Reinder Koop, Ruud Rooimans, Martijn de Theye. Regatta: ICT Implementaties als uitdaging voor een vier-met-stuurman, blz 100-103. 12 COMET 3.4.1 Pagina 31 van 45 Toepassing van het standaardfaseringsmodel Hieronder worden de stappen beschreven die tijdens elke subfase van de implementatie kunnen worden uitgevoerd. Planning & Beheersing Op basis van de uit te voeren activiteiten wordt allereerst een detailplan voor de subfase opgesteld. Dit omvat een tijdsplanning en een omschrijving van de oplevermomenten van tussen- en eindproducten; dit wordt vervolgens vertaald naar de benodigde resources. Mits deze planning vergezeld gaat van een goede rapportagestructuur, worden afwijkingen tijdig gesignaleerd. De bij deze fase behorende activiteiten vinden plaats vóór en tijdens de deelfasen voorbereiding, uitvoering en afronding. Voorbereiding Tijdens de voorbereidingsfase worden de specificaties van het eindproduct gedefinieerd. De eisen en acceptatiecriteria van de ontvangende partij worden vastgelegd. Ook wordt vastgesteld welke middelen nodig zijn voor de verschillende implementatieaspecten mens, informatie, proces, middelen en sturing (zie volgende paragraaf) Uitvoering Deze is vaak afhankelijk van de gekozen ontwikkelmethodiek. Het is in elk geval belangrijk om permanent controle te houden op de succes- en risicoaspecten. Afronding Tijdens deze fase worden de producten opgeleverd en kan het systeem worden overgenomen door de groep die verantwoordelijk is voor de ingebruikneming. Hierna kan formele decharge worden verleend voor het deelaspect. Deze decharge is vooral uitermate belangrijk voor grote projecten; hierdoor blijft immers helder waar de verantwoordelijkheden precies liggen. 3.4.2 Implementatieaspecten In Regatta® worden vijf belangrijke aspecten genoemd waarmee rekening dient te worden gehouden tijdens de voorbereiding van elke fase: Mens, Proces, Informatie, Middelen en Sturing. Mens Het vaststellen van de betrokkenen. In hoeverre hebben ze kennis over CMS, wat wordt hun rol, en hoe kan hij of zij het beste worden benaderd? Proces Bij elke fase is het belangrijk om na te gaan welke bedrijfsprocessen worden geraakt. De uitkomst van dit proces kan binnen een CMS-traject worden vertaald naar workflows in het systeem voor autorisatie, of naar een publicatiemodel. Informatie Welke informatie is nodig; op welke wijze dient deze te worden gecommuniceerd? Middelen Welke middelen zijn nodig? Denk hierbij aan CMS-software en -hardware, maar ook aan materiaal voor presentaties, werkplekken et cetera. COMET Pagina 32 van 45 Sturing Met dit aspect wordt gedoeld op coördinatie van de input voor bovenstaande implementatiepunten. Wie is het meest geschikt voor welke coördinatie? COMET 4 Pagina 33 van 45 OPLEVERPROCES Zodra de implementatiefase is voltooid, volgt een aantal fasen die leiden tot de overdracht van het systeem naar ICT-Beheer en de helpdesk. Deze fase dient vooral niet te worden onderschat; uiteindelijk kan het succes van een CMS staan of vallen met een geslaagde introductie in uw organisatie! Ook is het uitermate belangrijk om de juiste procedures in te regelen voor onderhoud aan het systeem. De fasen die na implementatie aan de orde komen, zijn zichtbaar in Figuur 9 en worden in dit hoofdstuk nader toegelicht. Figuur 9 Verloop van fase 4 COMET 4.1 Pagina 34 van 45 Testen van de implementatie Zodra de projectgroep heeft vastgesteld dat de implementatiefase is afgerond, kan het testproces beginnen. Testen is een expertise op zich en kan daarom het beste door (onafhankelijke) specialisten worden uitgevoerd. Voor dit traject is Sogeti een partij bij uitstek, mede dankzij het testen op basis van de veelgebruikte en in eigen huis ontwikkelde aanpak TMap®13. Het testen dient in ieder geval plaats te vinden door middel van een testplan, waarbij rekening wordt gehouden met bijzondere situaties, randgevallen et cetera. Na het testproces kunnen de testresultaten worden verwerkt. In de regel betekent dit dat de implementatiegroep een aantal aanpassingen of uitbreidingen in het systeem zal doorvoeren. 4.2 Opleveren van de documentatie Zodra het systeem is voltooid, moet er aandacht worden besteed aan de bijbehorende documentatie. Globaal zijn er twee typen te onderscheiden; technische documentatie en gebruikersdocumentatie. Bij een CMS-pakket wordt bovendien vaak documentatie volgens diezelfde tweedeling meegeleverd. De technische documentatie heeft vaak de vorm van naslagwerken, terwijl de gebruikersdocumentatie vaak in de vorm van werkinstructies beschikbaar wordt gesteld. 4.2.1 Technische documentatie De technische documentatie is als naslagwerk op het gebied van configuratie en maatwerk beschikbaar voor beheerders en ontwikkelaars. Typisch technische documentatie omvat: - technisch ontwerp; - architectuurontwerp (structuur webservers, contentmanagementservers, clients); - ontwikkelstandaarden (overdrachtdocumentatie voor ontwikkelaars/beheerders); - beheerdocumentatie (beschrijving architectuur en onderhoudsmatige acties); - documentatie van de source code. De technische documentatie moet volgens de standaard van de ICT-organisatie worden genummerd en gearchiveerd. Het kan van belang zijn om deze documentatie niet openbaar toegankelijk te maken in verband met informatie die de stabiliteit of veiligheid in gevaar zou kunnen brengen. 4.2.2 Gebruikersdocumentatie Voor een CMS-systeem is brede documentatie zeer wenselijk. Aangezien een CMSpakket op maat wordt geconfigureerd en er dus vaak maatwerk is verricht, zal de documentatie van de leverancier niet voldoende zijn. Deze kan echter wel uitstekend als input dienen voor de op te leveren documentatie. Martin Pol, Ruud Teunissen & Erik van Veenendaal (2000). Testen volgens TMap®. Tuthein Nolthenius. ISBN 90-72194-58-6. 13 COMET Pagina 35 van 45 Voor verschillende gebruikers kunnen werkinstructies op maat worden opgeleverd. Het is raadzaam om een stapsgewijze structuur te kiezen, ruim voorzien van schermafbeeldingen. Tevens is het aan te bevelen om waar maar enigszins mogelijk maximaal online (contextgevoelige) hulpfuncties in het systeem te verwerken en de betrokkenen tijdens de trainingsperiode te oefenen in het gebruik van hulpfuncties. Documenten die worden opgeleverd zijn: - redacteurenhandleiding; - eindredacteurhandleiding; - FAQ voor de helpdesk. Deze documentatie moet breed toegankelijk zijn, bijvoorbeeld via een intranet, netwerkshare of CD-ROM. Het is van groot belang om een versienummering in de documentatie te gebruiken en om bij te houden welke documenten naar wie moeten worden gedistribueerd (verzendlijst). Hierdoor kan er bij een nieuwe release voor worden gezorgd dat alle oude versies worden vervangen. 4.3 Schaduwdraaien Nadat de testresultaten zijn verwerkt, wordt er in de regel een aantal weken voor de geplande livegang schaduwgedraaid. Tijdens deze fase kunnen de gebruikers controleren of het systeem in de praktijk goed functioneert. Eventuele oneffenheden en afwijkingen kunnen tijdig worden aangepast. Denk vóór het ingaan van deze fase ook goed na over het rollback-scenario (zie hoofdstuk 3.3.1). Stel dat het nieuwe systeem onverhoopt niet voldoet, hoe kan er dan worden teruggeschakeld en hoe communiceert u deze boodschap? 4.4 In productie gaan Na het schaduwdraaien kan het systeem in productie worden genomen. Hiervoor moet echter nog wel een aantal voorzieningen worden getroffen. Bevriezing maatwerk Het kan verstandig zijn om de maatwerkcode van tevoren te bevriezen. Dit voorkomt dat er naderhand onduidelijkheid ontstaat over de oorzaak van haperingen in het systeem en de kwaliteit van de oplevering. Stresstest Na bevriezing van de broncode kan de performance van het systeem pas goed worden getest; de zogenaamde stresstest kan dan worden uitgevoerd. In het beste geval zijn er van te voren afspraken over de minimale performance gemaakt met de pakketleverancier en de implementatiepartner. Synchronisatie verschillende omgevingen Voordat in productie wordt gegaan is het van groot belang dat de verschillende omgevingen (test, ontwikkeling, acceptatie en productie) worden gesynchroniseerd. Hierdoor worden functionele verrassingen en vergissingen met versies uitgesloten. Daarnaast is het zonder meer verstandig om toekomstige synchronisaties tussen de omgevingen in te plannen met het oog op betrouwbaar onderhoud aan het systeem. COMET Pagina 36 van 45 Voorbereiden beheerorganisatie Voordat in productie wordt gegaan, dient de ICT-helpdesk te worden geïnformeerd en geïnstrueerd. De deelnemers aan de implementatiegroep kunnen gedurende deze periode als tweedelijnshelpdesk fungeren. Het communicatieproces rondom de livegang is zeer belangrijk en mag zeker niet worden overhaast. Vergeet niet dat het systeem vaak wordt afgerekend op de eerste ervaring van de gebruiker! 4.5 Acceptatie Pas nadat het systeem een paar weken in productie is, wordt het ter acceptatie bij ICT-Beheer aangeboden. Het is belangrijk dat deze afdeling van tevoren een lijst van acceptatiecriteria heeft opgesteld; op die manier kan namelijk worden gemeten of het systeem voldoet. 4.6 Beheer Na deze acceptatie van het systeem wordt dit definitief overgedragen aan de beheerorganisatie. Het is belangrijk dat er goede afspraken worden gemaakt over de ondersteuning bij storingen in het systeem. Hierbij moet nauwkeurig worden beschreven wie welke storing verhelpt en onder welke voorwaarden ondersteuning van de implementatiepartner wordt verleend. Dit wordt doorgaans in een contract vastgelegd; een dergelijk type contract wordt aangeduid als SLA. 4.7 Issuetracking Na het opleveren van het systeem zullen er in de loop van de tijd aanpassingsverzoeken worden gedaan die buiten het beheer vallen. Het is belangrijk dat alle issues worden verzameld en dat de prioriteiten worden afgestemd met de projectgroep/stakeholders. Deze punten kunnen vervolgens worden opgepakt door de implementatiegroep. Een aantal issues kan in een servicerelease (bundeling van updates) worden geïmplementeerd. Daarmee wordt de druk op de organisatie verminderd. De aanpassingen kunnen immers in één keer worden getest en geaccepteerd; bovendien komt de beschikbaarheid van het systeem minder in gevaar. COMET 5 Pagina 37 van 45 HET MANAGEN VAN CONTENT Dit hoofdstuk gaat in op de redactie van een Content Management Systeem; het bevat een aantal handige tips en praktische richtlijnen. In paragraaf 5.1 zijn richtlijnen voor design opgenomen, in paragraaf 5.2 komt de lifecycle van content aan de orde en in paragraaf 5.3 wordt ingegaan op verbetering van uw Content Management Systeem door middel van een releasematige aanpak. Figuur 10 illustreert de drie pijlers die van belang zijn voor het managen van uw content. Figuur 10 De pijlers van content management COMET 5.1 Pagina 38 van 45 Richtlijnen voor content Content die wordt gepresenteerd op een website, dient weloverwogen te worden aangemaakt. Hieronder treft u een aantal tips en richtlijnen aan voor de ontwikkeling van content. 5.1.1 Bepaal de boodschap Realiseer u terdege welke doelgroep u aanspreekt, welk kennisniveau deze heeft en welke boodschap uw tekst dient te bevatten. 5.1.2 Houd rekening met het medium Het gekozen medium bepaalt meestal het formaat van de content. Wordt uw content gelezen op een PDA, dan moet deze toegankelijk zijn voor mensen die kleurenblind zijn. Als de content wordt weergegeven bij een resolutie van 1024x768, streef er dan naar om de lengte van uw tekst zodanig aan te passen dat de bezoeker niet hoeft te scrollen. 5.1.3 Structureer uw content Het is van belang dat u uw content goed structureert, zodat u content effectiever kunt hergebruiken en terugvinden. Enkele tips die hierbij kunnen helpen: - scheid hoofdzaken van bijzaken; - let op gebruik van kolommen en alinea’s; - zorg voor voldoende plaatjes; - gebruik tussenkopjes; - accentueer belangrijke begrippen; - zorg voor uniformiteit; gebruik binnen een website overal hetzelfde lettertype en een consistente lettergrootte, pas consequent koppen toe etc.; - splits lange teksten op in verschillende artikelen; gebruik hiervoor bijvoorbeeld links lees meer/verder; - wanneer u in uw tekst verwijst naar bronnen, maak van deze verwijzing dan een rechtstreekse link, die opent in een nieuw venster. 5.2 Lifecycle van content Het is van groot belang onderhoud dat u uw content onderhoudt. Content die niet accuraat, actueel of relevant is, dient te worden aangepast, verwijderd of gearchiveerd. Hoe u dit moet bepalen, is van vele factoren afhankelijk; denk bijvoorbeeld aan de verschillen tussen nieuws, een technisch artikel, mission statement en een juridische waarschuwing. Als hulpmiddel kunt u een content-lifecycle opstellen. Hierin kunt u vastleggen wat de verschillende statussen van content binnen uw organisatie kunnen zijn. Een voorbeeld van een dergelijke lifecycle is zichtbaar in Figuur 11. Naast de hier getoonde statussen kan content op een gegeven moment bijvoorbeeld “verlopen” zijn en daarom worden verwijderd of gearchiveerd. Hiervoor kunnen bijvoorbeeld vanuit het oogpunt van compliancy richtlijnen worden COMET Pagina 39 van 45 opgesteld. Daarnaast kan de content de status “bestemd voor intern gebruik” hebben, dient de effectiviteit van de content te worden gemeten enzovoort. Met behulp van een lifecycle wordt u zich beter bewust van de noodzaak voor verschillende betrokkenen in uw organisatie om op enig moment actie te ondernemen om content te onderhouden. In een zogenaamde workflow kunt u de verschillende review- en updatemomenten van content expliciet maken binnen uw Content Management Systeem. Het systeem kan bijvoorbeeld automatisch archiveren, u een seintje geven als content de houdbaarheiddatum overschrijdt etc. Figuur 11 Voorbeeld van een Content Lifecycle 5.3 Opnemen van nieuwe functionaliteit Van tijd tot tijd is nieuwe functionaliteit gewenst. Uw bedrijfsprocessen veranderen doordat uw bedrijf groeit, uitbreidt, van koers verandert enzovoort. Daarnaast komen er telkens nieuwe technieken in beeld, die vereenvoudiging of verrijking van uw contentmanagementprocessen noodzakelijk kunnen maken. Dit beeld van verandering geldt in hoge mate voor een web-CMS. Het product van het systeem - uw website(s) – dient als onlinevisitekaartje voor uw bedrijf. Het aanbod van een stabiele en goed verzorgde omgeving is daarom essentieel. In het geval van een WCMS kunt u denken aan het beschikbaar maken van nieuwe functionaliteit rondom web 2.0, Ajax, Wiki’s etc. Bovendien kan het interessant zijn om van tijd tot tijd een actiematige lay-out te gebruiken voor uw website bij speciale COMET Pagina 40 van 45 commerciële gelegenheden, of u wilt bijvoorbeeld een anderstalige website opleveren ten behoeve van uw Duitse klanten. Elke nieuwe functionaliteit vereist een aantal fasen: ontwerp, implementatie, test en overdracht. Aangezien dit proces vrij veel tijd vergt, is het raadzaam om updates in releases uit te brengen. Dit verkort de totale doorlooptijd en daarnaast gelden de volgende voordelen: - door bundeling van gewenste aanpassingen kunnen deze worden geprioriteerd; - het ICT-budget kan beter worden beheerst; - gebruikers van content zullen een nieuwe release bij een aantal gebundelde updates duidelijk herkennen als een kwaliteitsverbetering; - gebruikers leren er sneller mee omgaan. COMET 6 Pagina 41 van 45 BEGRIPPENLIJST Ajax Ajax is een term voor het ontwerp van interactieve webpagina’s, waarin asynchroon gegevens worden opgehaald van de webserver. Zie bijvoorbeeld: Wikipedia, http://nl.wikipedia.org/wiki/Ajax_(webdesign). Online op 15-92006 Brownpapersessie Een brainstormtechniek waarbij ervaringen, behoeften en ideeën over een bepaald onderwerp interactief vanuit verschillende invalshoeken worden genoteerd op een groot vel (bruin) papier. Clickable Model Een clickable model geeft de werking - met daarnaast eventueel de look en feel – weer van een (web)applicatie. Content flow De manier waarop content wordt gecreëerd, gereviewed, gepubliceerd en gearchiveerd. CRM Customer Relationship Management. Een werkwijze waarbij het optimaliseren van alle contacten met de klant centraal staat. CSS Cascading Style Sheets. Techniek waarmee de structuur van een webpagina in een website kan worden gescheiden van de lay-out. Digital Asset Management Het opslaan, beheren en distribueren van digitale bestanden (audio, video, foto’s, teksten, documenten, e-mails, etc.) Document Management Een database waarin (veelal gescande) documenten worden opgeslagen en zoekbaar zijn aan de hand van aan indexkenmerken gerelateerde metadata zoals auteur, documentdatum, categorie en status. DSDM Dynamic Systems Development Method. Een iteratieve ontwikkelmethodiek voor software. DTP Desktop Publishing. Software waarmee kwalitatief hoogwaardige documenten worden gecreëerd voor print. DyA Methodiek om een werkbare, pragmatische architectuur in uw organisatie te introduceren. Zie ook: www.dya.info, online op 15-9-2006. COMET Pagina 42 van 45 ECM Enterprise Content Management. Een benadering van contentmanagement met als insteek een generieke oplossing voor contentmanagement binnen verschillende bedrijfsprocessen. FO Functioneel Ontwerp. Een document bedoeld voor ICT-projecten waarin wordt beschreven aan welke functionele eisen een geplande oplevering dient te voldoen. KPI Key Performance Indicators. Indicator die aangeeft of een bedrijfsdoelstelling wordt gehaald. Mikado Migratiemethodologie van Sogeti. Zie ook: http://mikado.sogeti.nl, online op 15-9-2006. OTAP Ontwikkel, Test, Acceptatie & Productie. OTAP referereert aan een ontwikkelen opleverarchitectuur voor ICT-projecten. Elk stap is opgesplitst in een aparte omgeving. Prince2 Prince2 is een projectmanagementmethode. "Prince" staat voor PRojects IN Controlled Environments. Zie ook http://nl.wikipedia.org/wiki/Prince2, Wikipedia over Prince2, online op 11-8-2007. Records Management Het identificeren, classificeren, archiveren, bewaren en soms vernietigen van records. Een record is de informatie die wordt gemaakt, ontvangen en onderhouden als bewijs en informatie over bedrijfsactiviteiten en transacties. RSS Really Simple Syndication. Een webtoepassing om korte samenvattingen van websiteartikelen aan te bieden aan speciale RSS-leesapplicaties. RUP Rational Unified Processing. Iteratieve software ontwikkelmethodiek, oorspronkelijk afkomstig van IBM. Zie ook http://nl.wikipedia.org/wiki/Rational_Unified_Process, online op 11-8-2007. Sjabloon Model dat lay-out en gedrag voorschrijft aan content. SLA Service Level Agreement. Contract waarin de mate van support en ondersteuning wordt beschreven die beschikbaar is voor een product of dienst. SOA Service Oriented Architecture. Moderne architectuurbenadering waarin applicaties een interface bieden waarmee eenvoudig kan worden gecommuniceerd met andere applicaties. COMET Pagina 43 van 45 Stresstest Een test waarbij wordt gemeten of een bepaalde applicatie of server een bepaalde hoeveelheid belasting zonder problemen kan verwerken. TMap Een benadering voor het succesvol testen van applicaties. Zie ook www.tmap.net. Online op 15-9-2006. TO Technisch Ontwerp. Een document bedoeld voor ICT-projecten, waarin wordt aangegeven hoe functionele eisen technisch worden gerealiseerd. Tweedelijnshelpdesk Een helpdesk bedoelt voor directe productondersteuning, vaak bezet door ontwikkelaars. Usability Volgens de ISO-norm (ISO 9241) is usability: de mate waarin een interactief systeem (website, software e.d.) de gebruiker in staat stelt om zijn taak effectief, efficiënt en comfortabel in een gegeven omgeving te voltooien. Zie bijvoorbeeld: Universiteit van Leiden, http://www.arbodienst.leidenuniv.nl/index.php3?c=139 online op 1-9-2006 WCM Web Content Management. Contentmanagement voor het beheren van teksten op websites. WCMS Web Content Management System. Zie WCM. Web Content Management Zie WCM. Wiki Een systeem om met een gemeenschap online teksten te administreren en publiceren. Workflow Het mechanisme dat wordt gehanteerd voor reviewing, auditing en publiceren. COMET 7 Pagina 44 van 45 NAWOORD De totstandkoming van COMET heeft primair te maken met best practices, uitgebreide ervaring in contentmanagementprojecten en brainstormsessies. Deze methodiek kan dan ook worden gekarakteriseerd als een uiterst pragmatische methode, die breed inzetbaar is en tevens een onmiskenbare afspiegeling van de hoogwaardige kwaliteit van Sogeti. Dit is de plaats om dank uit te spreken aan het adres van iedereen die een bijdrage heeft geleverd aan de totstandkoming van deze methodiek. In willekeurige volgorde: Geoff Kuis, Remko Spaan, Marjolein Ahsmann, Wim Hofland, Mario van der Hoeven, Rudi van Es, Roland van Veldhoven, André Kennis en Paul Aris. Heeft u opmerkingen, suggesties voor verbetering of andere feedback? We horen heel graag van u via het adres [email protected]. COMET 8 Pagina 45 van 45 REFERENTIES Boisot, M (1998). Knowledge Assets: Securing Competitive Advantage in the Information Economy. Oxford: Oxford University Press. DSDM Consortium (2003). Framework for Business Centred Solutions Handbook. Aquarius Press limited. ISBN 0-9544832-0-0 H.B. Eilers (1990).Systeemontwikkeling volgens SDM. Academic Service. ISBN 906233-177-7 Koning de, Jan-Willem (2006). Content Management. Academic Service. ISBN 9012-116236-6 Laura Ettema, Oscar Mulders (2006). Portals: Handboek voor het plannen en ontwerpen van de bedrijfsportal. Den Haag: SDU uitgevers. ISBN 90-5261-547-0 Martin Pol, Ruud Teunissen & Erik van Veenendaal (2003). Testen volgens TMap®. Tuthein Nolthenius. ISBN 90-72194-58-6. Reinder Koop, Ruud Rooimans & Martijn de Theye (2003). Regatta - ICT implementaties als uitdaging voor een vier met stuurman. Ten Hagen Stam Uitgevers. ISBN 90-440-0575-8 Sintemaartendijk, Ron. Requirements Development: methode van werken. Beschikbaar via Sogeti Nederland B.V. Theo Hylkema, Hans Postma, Frans Straves (2005). Gids Content Management Systemen 2006 Entopic. ISBN 97-8908-066-5354 Tridion. Tridion Implementation Methodology. Beschikbaar via Tridion B.V.
