Uitgevers en content management systemen
Twitter
Facebook
Delicious
Digg
Stumble
Reddit
“Ow, u wilt ook nog vier wielen onder uw auto?”. Steeds vaker kijk ik de zogenaamde ict-consultants en projectleiders aan alsof ze gek zijn. Welke functionaliteit stelt u zich voor bij een rss-feed? Kunt u schetsen wat u bedoelt met ‘de mogelijkheid om te reageren op berichten’, dan maak ik een ureninschatting om dat bouwen. U wilt FAQ-functionaliteit, dat stond niet in het Functioneel Ontwerp, dus dat moet er eerst komen waarna we het gaan bouwen en dat is natuurlijk wel boven begroting en we halen dan de deadline ook niet. U wilt een datum boven nieuwsberichten, ja dat kost toch wel 6 uur om het te realiseren… Alsof ik in dit soort onzin trap.
Het lijkt wel alsof de (commerciële) content management systemen zo uit de doos helemaal niets kunnen en dat alles op maat gebouwd moet worden tegen een fiks uurtarief. Alsof je een motor koopt en dat de auto er omheen voor iedere klant helemaal op maat gemaakt wordt. En als die dure internetbureaus gisteren de gewenste functionaliteit voor een andere klant gebouwd hebben, dan beginnen ze voor u weer helemaal opnieuw. Ze hebben geen checklists op basis van eerdere ervaringen waarop u kunt aangeven welke functionaliteit u wenst. Het is immers veel beter dat u het wiel opnieuw uitvindt, dan krijgt u vooral wat u niet wilt en verbouwen zij wel weer tegen een schappelijk uurtarief.
10:40
Alhoewel ik me kan vinden in de algemene strekking, wil ik graag een paar nuances aanbrengen omdat de praktijk soms erg weerbarstig is.
Veel uitgevers zijn namelijk net mensen, en willen voor een dubbeltje op de eerste rang zitten. Maar ze willen geen kopie van de site of het systeem van hun concurrent, het moet anders. En alles dat afwijkt van wat al bestaat kost energie om te creeren.
Het is inderdaad belangrijk om met checklists te werken, maar dat geldt niet alleen voor het internetbureau, dat zou ook voor de klant (uitgever) moeten gelden. Want in tegenstelling tot wat hierboven beweerd wordt, ben ik van mening dat maar heel weinig ‘vanzelfsprekend is’. Ik weet uit ervaring dat je uren kan discussieren of er datum, datum en tijd of helemaal niets bij een nieuwsbericht getoond moet worden. En dat wil de klant van alles een uitgewerkt voorbeeld ‘om te zien hoe het eruit ziet’ Dat hij uiteindelijk niet koos voor het tonen van een datum kwam omdat de nieuwsberichten maar 1 keer per week ingevoerd werden, en dat wilde hij niet zichtbaar hebben op internet. En zo gaat een discussie over een datum opeens over werkprocessen en verandering van taken en dagindeling.
Of dat je eerst moet uitleggen *wat* een RSS-feed is. Dan maak je wat waarschijnlijk goed is (maar niemand bij je klant gebruikt de feed zelf), om dez feed dan na een jaar te moeten aanpassen omdat er teveel informatie inzit ipv te weinig.
Kortom: veel heeft te maken met het kennisniveau van de klant. Maar ook het feit dat klant en internetbureau bereid moeten zijn een langere relatie met elkaar aan te gaan.
Als je als ict-leverancier (internetbureau) netjes een fixed price systeem hebt gebouwd en opgeleverd, is het niet raar dat je naderhand voor extra werk extra uren berekent. Het gat niet zozeer om de techniek (die rss-feed lag toch al klaar), maar het gaat om de keuze welke info er in die feed moet. Dat doe je op basis van ervaring (en soms klantwensen, maar vaak weet de klant niet wat hij wil). Maar als de klant zich bedenkt en na oplevering iets anders wil, dan kost dat tijd en dus geld. Meestal zijn dat neuzeldingetjes van een half uurtje dit en een kwartiertje dat. Het beste om deze vorm van voortschrijdend inzicht in een commercieel vat te gieten is het afsluiten van een servicecontract (SLA). Dan maak je van te voren afspraken met de klant dat je een x-aantal uren per maand beschikbaar bent om dingen te veranderen, verbeteren en op te lossen. Aan het eind van het jaar evalueer je het aantal uren en pas je de overeenkomst aan.
Door een contract af te sluiten zijn de verantwoordelijkheden van *beide* partijen beter zichtbaar en voorkom je dat je voor elk wissewasje een offerte moet aanvragen/uitbrengen (met de overhead die daarbij hoort).
Ik ben het met Ferdinand eens dat er veel ict-consultants, projectleiders en internetbureaus zijn die doen alsof ze gek zijn. Belangrijk is dan ook om met partners samen te werken die niet alleen verstand hebben van techniek, maar ook van het werk, de branche en de belevingswereld van hun klanten/opdrachtgevers. Dat voorkomt een hoop ellende.
13:21
Ferdinand, ik herken veel in je verhaal. Laatst was er hier nog iemand die voor het uitvoeren van een pilot met een contextual targeting tool 14K wilde hebben. De implementatie van zijn tool met onze site moesten we namelijk niet onderschatten. Een dag later kon het ook voor de helft, maar helaas.
22:07
@Huub Wat een flauwekul om de schuld in de schoenen van de klant te schuiven. Feit is dat de reguliere CMS-bakkers en de bijbehorende bureaus de web 2.0-boot volledig gemist hebben.
Alles wat tegenwoordig (of liever gezegd al lang) standaard in systemen als WordPress zit, kan je tegen uurtje-factuurtje laten bijbouwen, zoals Ferdinand terecht aangeeft.
Ik vind het gewoon ongelooflijk dat er CMS-en op de markt zijn zonder bijvoorbeeld ingebouwde reactie-mogelijkheid, rss-feed en embedfunctionaliteit, om maar een paar basics te noemen.
02:36
@anton: Ik schuif de ‘schuld’ niet in de schoenen van de uitgevers, ik stel vast dat het kennisniveau vaak te laag is.
Kijk, als de uitgever en zijn team goed weten wat er speelt hebben ze met een hoop moderne web 2.0 tools niet eens een internetbureau nodig. Dan zet een redacteur een blogje online, dan twittert een journalist op een middag gezellig met zijn lezers, dan wordt bij een artikel een leuke mashup gemaakt waar dat allemaal bij elkaar komt, etc.
Maar – nogmaals – de praktijk is vaak anders. De uitgever weet niet precies wat hij wil en heeft al helemaal geen mensen in dienst die hem daarbij helpen of web-praktijkervaring hebben. En dan is het de taak van zijn internetbureau / ict-partner / consultant om hem goed voor te lichten, zodat er slimme keuzen gemaakt worden. En daar gaat het vaak mis, zoals Ferdinand schetst. Want tegen slechte adviseurs is geen kruid gewassen. Als die verkeerde tools adviseren, dan houdt het snel op.
Overigens: om nog even inhoudelijk te reageren op je stelling over rss, reactiemogelijkheden en cms-sen: er zijn tal van cmssen die geen rss en reactiemogelijkheid kennen, en daareen goede reden voor hebben. Dat komt simpelweg door het feit dat de term ‘cms’ door jan en alleman gebruikt wordt voor applicaties die iets met content doen. Er zijn ook niet zoveel mensen die hier *echt* verstand van hebben. Er zijn een hoop cms-sen die niet voor websites bedoeld zijn, of die je beter ‘redactiesystemen’, ‘xml-editors’ of ‘workflowsystemen’ kan noemen. Het is niet raar als klanten (uitgevers) in dat bos de bomen niet zien. Het is wel raar als duurbetaalde adviseurs, etc. de verkeerde tools adviseren.
Wat jouw voorbeeld betreft: WordPress inzetten als cms kan net zo verkeerd aflopen als een cms adviseren dat geen rss ondersteunt. Het ligt er maar net aan wat de klant nodig heeft.
En dan kom ik weer bij mijn punt: als een klant onvoldoende kennis in huis heeft om prachtige web 2.0 ambities waar te maken, dan los je dat niet op met (gratis of commerciele) techniek. Een goed(e) adviseur of internetbureau zorgt ervoor dat de klant de aanvullende kennis krijgt die nodig is om goede beslissingen te nemen, zodat de klant zelf kan zeggen dat 6 uur bouwkosten voor een datum boven nieuwsberichten, of het aanpassen van een rss-feed volslagen kolder is.
09:16
@Huub In de praktijk kom ik leveranciers van web CMS-en (en dan heb ik het niet over document management systemen) tegen die te weinig feeling hebben met wat de klant echt nodig heeft.
Een publisher snapt zijn eigen business namelijk wel heel goed: hij zit in een zeer snel veranderende omgeving waarin links en rechts concurrenten opduiken, waarin Google een hele belangrijke trafficdriver is en waarin je min of meer gedwongen wordt om content te sharen om kosten te drukken. Om maar enkele voorbeelden te noemen.
Dat geldt niet alleen voor traditionele uitgevers, maar voor tal van organisaties, die immers op het web allemaal een soort uitgeversrol hebben.
Daartegenover staan dan CMS-leveranciers (de goede niet te na gesproken) die – om maar wat te noemen – niet standaard Google-vriendelijke URL’s aanbieden en geen enkele moeite hebben genomen om het delen van content met externe partijen makkelijk te maken.
Je herhaalt dat er bij klanten onvoldoende kennis is. Naar mijn idee ligt het andersom: aan de leverancierskant is te vaak onvoldoende begrip van de business van hun klanten.
11:13
Ben het helemaal eens met de eerste reactie op dit bericht, die van Huub dus.
11:58
Wat een onzin verhaal. alsof alle klanten blijkbaar op de hoogte zijn van de laatste web 2.0 technologie. Laten we eerlijk zijn, zelfs de meeste ICT-leveranciers kunnen dat niet allemaal bijhouden, het veld is simpelweg te breed. Het is leuk dat er 1000-en innovaties plaatsvinden per jaar op webdevelopment gebied maar vind maar eens een partij die dit allemaal binnen een dag in het pakket heeft zitten. Driewerf neen, de schrijver van dit artikel heeft weinig kaas gegeten van hoe het er in het dagelijkse leven aan toe gaat. Swa, natuurlijk zal er op termijn wel enige vorm van standaardisering komen.
Met het scala van pakketten, de steeds veranderende technieken, de toenemende mogelijkheden van internet en de continue stroom van nieuwe servers, webservers,ontwikkelplatformen,vernieuwingen binnen HTML/XML/SQL/Javascript etc..not very likely on short term
Net zoals bij de auto’s heeft dit lang geduurd. jaartje of 80) Maar uiteindelijk mag je dan ook niet meer zeuren over aanpassingen. Sterker nog, meedenken over het ontwerp of over de vormgeving is dan natuurlijk uitgesloten.
Net als een pak melk in de supermarkt koop ik dan uiteindelijk een standaardproduct, maar heb daar dan vervolgens ook geen enkele inspraak meer.
de meerwaarde zit hem juist in het aansluiten van de applicatie op het werkproces van de klant. Als we het werkproces van de klant zouden standaardiseren, komen we er ook wel met de applicatie. tot die tijd…
Als ik een auto wil hebben met 6 deuren heb ik keihard pech of zal ik vele malen de som neer moeten leggen die een standaard-auto zal kosten.