Asynkron webkommunikation

Selvom PowerPoint tit udråbes som et ondt program af folk, der ved bedre, er det alligevel standarden for kommunikation ved mange møder i erhvervslivet. Specielt hvis der skal sælges noget.

Derfor kan man lige så godt lære at bruge PowerPoint godt:

• Edward Tufte har skrevet en dybt begavet tekst om brug af PowerPoint: “The Cognitive Style of PowerPoint”
• Presenters University har stor samling artikler om PowerPoint (og andre præsentationsværktøjer)
• Doc Searls har skrevet den mest inspirerende artikel, jeg nogensinde har læst, om præsentationer: “The Problem With Presentations”. Læs denne før noget andet. Faktisk før du henter den næste kop kaffe…

Jeg er i gang med at lave en generisk kravspecifikation for funktionelle krav til et Content Management System (CMS) på Synkron. Skabelonen er tænkt som en hjælp til dem, der ikke har formuleret en kravspecifikation, men skal til at henvende sig til CMS-leverandører. Skabelonen kunne tjene til sammenligning af de forskellige produkter, man som kunde er interesseret i.

Jeg forestiller mig ikke, at en generisk kravspecifikation, der fokuserer på funktionelle behov, alene kan gøre det. Som kunde må man først have klarlagt, hvad de forretningsmæssige behov er, fordi de funktionelle behov netop er afledte af disse. Tænk derfor mere på min skabelon som en model for, hvordan man kan undersøge leverandøreres produkter, når først de forretningsmæssige behov er afklarede.

Er du i gang med at skrive en kravspecifikation for et CMS, er der mere god inspiration om “det idelle CMS” på Afkalkeren og på IT- og Telestyrelsen. Læs også Eat my Shorts’ tanker om at lave kravspecifikation.

På FDIHs arrangementet i går om weblogs var vi alle rørende enige om, at weblogs er en strålende ting. Men mange af os har haft den erfaring, at når man forsøger at indføre weblogs ad officiel vej i den virksomhed, man arbejder i, så støder det på problemer.

Sagen er, at det kan være en vanskelig opgave at overtale sin direktør eller chef til, at virksomheden skal bruge weblog-formatet fordi:

1. Chefen aner ikke, hvad du taler om
2. Chefen associerer weblogs med følsommme dagbogsoptegnelser
3. Det konflikter med den traditionelle opfattelse af relationen mellem en virksomhed og dens omgivelser

De første to problemer er banale, mens det tredje er helt centralt.

Hvad er umiddelbart lyder som en simpel opgave – at installere en weblog – rammer helt ind i hjertet af den gennemsnitlige chefs opfattelse af virksomheden og dens relation til kunder, partnere, presse, konkurrenter – omgivelserne i det hele taget. Der er nemlig typisk en dem-og-os-opfattelse med tilhørende behov for lukkethed og behov for kontrol over kommunikationen.

Kommunikationen bliver styret i så faste formater og med en så firmaagtig stemme, at man som kunde mister interessen for virksomheden. Læs for eksempel en pressemeddelelse og genfortæl den 10 minutter efter. Man har glemt det på grund af ligegyldighed. Hører man derimod et engageret menneske fortælle brændende om sit produkt, kan man huske det hele.

Der er meget faste grænser for, hvad man fortælle omverden, fordi konkurrenter eller kunder kan misbruge informationen. Virksomheder har en opfattelse af sig selv i krig mod kunderne. Man angriber markedet og taber eller vinder sager.

En weblog undergraver fuldkomment muligheden for at opretholde en – fiktiv – mur mellem firmaet og dets omgivelser, og det gør det umuligt at kontrollere kommunikationen.

Well, hvis din ambition er, at der skal indføres weblogs i din virksomhed – fordi en åbenhed er positiv for forretningen – kan du overveje at gribe det an sådan:

Start indefra-og-ud. Weblogs er en fin erstatning for det intranet, der aldrig kom til at fungere. Lad medarbejdere tale åbent med hinanden (del viden) på interne weblogs. Næste skridt: Tal med eksisterende kunder i weblogs. Du vil hurtigt opleve, at de er loyale og vil give dig en masse værdifuld feedback på det, du fortæller dem. Det er slet ikke farligt, vel? Tal nu med virksomhedens partner i weblogs og tag til sidst skridtet og tal åbent med omgivelserne i weblogs.

Uanset hvad du gør, så lad for guds skyld ikke marketingafdelingen styre projektet. Marketingfolk kan ikke tale som almindelige mennesker. Det er noget, man lærer som en del af uddannelsen.

På Synkron søger vi en studentermedhjælper til vores kommunikationsafdeling i København. Arbejdet er på omkring 15 timer/uge og kan tilrettelægges flexibelt. Opgaverne består i vedligeholdelse af websites, opfølgning på henvendelser, produktion af indhold (pressemeddelelser, cases, produktmateriale), let DtP, bestilling af kontorartikler og tryksager, planlægning og praktisk afvikling af seminarer og lignende. En masse forskellige opgaver…

Du er muligvis studerende på CBS, en kommunikationsuddannelse, IT-Universitetet eller noget helt tredje. Du skal være god til kommunikation, have skrevet indhold til nettet og have sans for planlægning og organisation.

Interesseret? Ring til mig (26 20 32 21) eller send en mail (andreas@synkron.com) med det samme! Vi har brug for dig nu.

Update! Stillingen er besat

Som mange andre weblogs har denne være plaget af alt for meget kommentarspam. Jeg har forsøgt forskellige midler mod spammerne – blandt andet Jay Allens MT-blacklist. Men med tiden blev der simpelthen for mange spamkommentarer at rense ud i hele tiden.

Inspireret af Dalagers posting om spam-frustrationerne, har jeg smøget ærmerne op. Processen har været:

1. Opgradering af Movable Type fra version 2.64 til version 3.1. Ja, jeg har betalt for softwaren, fordi den er god. Installation af opgraderingen gik efter instruktionerne: hurtigt og smertefrit.

2. Afinstallation af MT-Blacklist, fordi versionen til MT før 3.0 ikke længere er kompatibel (og forhåbentlig unødvendig).

3. Implementering af et captcha-trick. Pointen med en captcha-test er at lave en lille test, der afgør, om der sidder et menneske eller en computer i den anden ende – for eksempel ved at stille et spørgsmål, som kun mennesker kan forstå. Med Movable Type 3.1 kan du nemt og effektivt forhindre spambotter og ikke-dansktalende menneskespammere ved at følge denne vejledning:

1. Åbn filen lib/MT/App/Comments.pm
2. Indsæt følgende kode fra linie 247 (med tak til Strang’s blog):
   unless ($q->param('spam') eq 'Æ') {
return $app->handle_error($app->translate("Indtast bogstavet for anti-spam præcis om angivet."));
}
3. Indsæt følgende kode i alle MT-templates, hvor der kan skrives kommentarer:
   <label for="spam"><b>Anti-spam! Indtast bogstavet "Æ" i dette felt</b> </label> <input id="spam" name="spam" size="1"/><br /><br />

Nu skal man være et menneske med et dansk tastatur for at kunne sende en kommentar ind. Det var konens forslag med et tegn, der ikke findes på et amerikansk tastatur. Clever.

Det har været vigtig for mig at finde en metode, der både er effektiv OG ikke bliver for bøvlet for almindelige mennsker, der bare vil lægge en kort kommentar.

Man får meget hurtigt en mistake om, at Sony’s direktion opfatter Internet som en sjov lille dille, som nok snart forsvinder igen.

Sony’s webshop har i hvert fald været nede to dage nu, og de reagerer ikke på henvendelser – hverken telefon eller mail. Kan man forestille sig en forretning i den fysiske verden, der bare har lukket to dage på grund af en tilfældig teknisk fejl? Vel at mærke en pan-europæisk forretning. Herregud, hvis det bare er en dille, hvorfor så tro at man kan omsætte noget i en webshop?

Sikkerhedscertifikatet er udløbet, hvilket giver en rimelig teknisk fejlmeddelelse til besøgende – med risiko for, at de forsvinder på grund af utroværdig sikkerhed. Bevars, kunderne er nok ligeglade med sikkerheden.

Endelig må Sony’s jurister have haft en fantastisk dag, da de skrev betingelserne for brug af Sony’s site. Læs for eksempel denne passus:

Adgangen til dette website og anvendelsen af dette, herunder også betragtning, download, mangfoldiggørelse, fremstilling, positionering (posting) og offentliggørelse af data, grafik, billeder, lysbilleder, udkast, beskrivelser, informationer og tekst, video-, audio-, musik- og tonesammenstillinger, utilities, software (herunder også fra Apples) og softwaresammenstilling, drivere og andre tjenesteprogrammer (utilities (som defineret efterfølgende), indholdet af et hvilket som helst e-mail-newsletter eller lignende meddelelser som er transmitteret af Sony eller på Sonys vegne med henblik på dette website og/eller anmeldelse af brugeren eller abonnementet hertil, samt af øvrige indhold på dette website der er fremstillet og transmitteret direkte af Sony, af foretagender associeret med Sony eller af disses produkt-, support- eller serviceproviders (i det følgende kaldet website-indhold), er forbudt såfremt det ikke udtrykkeligt er tilladt i henhold til nærværende betingelser.

Du må faktisk som udgangspunkt slet ikke bruge sitet…

Sony, tag springet ind i år 2004. Jeres kunder vil købe jeres produkter på nettet – trygt og sikkert. De vil tages seriøst, når de henvender sig til jer. De vil bruge jeres site, linke til det, klippe billeder og sende til venner, fordi de synes, at jeres produkter er spændende.

(Hvis du genkender noget her, er det nok fordi, Sony ikke er ene om miste et enormt potentiale for loyale kunder og forretning ved at lade være med at tage nettet seriøst).

Da jeg overtog ansvaret for fabrikkens sites, aftalte jeg med mig selv, at der skulle slettes mindst en side per dag det næste kvarte år. Vi har simpelthen haft den ambition, at besøgende skulle have al den information, vi overhovedet kunne grave frem og kaste efter dem. Hvilket ikke nødvendigvis er hensigtsmæssigt…

Mange konsulentrapporter argumenterer med, at CMS er nødvendigt, for mængden af virksomhedens indhold stiger exponentielt, og derfor har man brug for et CMS til at holde styr på det. Jeg er frygter, at kausaliteten er omvendt: Mange virksomheders sites vokser, fordi CMS’et gør det let at lægge nyt indhold på sitet. CMS’er markedsføres typisk som effektive værktøjer til at importere Office-dokumenter, importere data via ODBC eller XML og med muligheden for selv den mindst IT-begavede til at lægge nye websider på. Peg-og-klik. WYSIWYG. Se mor, helt uden hænder…

Er det muligt, at det simpelthen er *for* nemt at publicere indhold med CMS? Eller er sagen måske mere, at CMS’er i højere grad må må blive bedre til at håndterere indhold i en komplet livscyklus, der både drejer sig om at få indhold ind og publicere det – men også følge op på det og afpublicere samt arkivere senere. Både CMS-leverandører, ditto-konsulenter samt kunder må være bedre til at forstå dette og komme ud over den enøjede fokus på, at det bare skal være nemt at kaste indhold på et site.

Jeg holder foredrag om desigeren og CMS på Den Grafiske Højskole i dag. Her er præsentationen som PDF og som PPT.

Konference om betydningen af IT i dag på Børsen med Nicholas G. Carr. Arrangeret af FDIH og HTS. Betyder IT overhovedet noget idag? Jeg deltager for at finde ud af, om der er en fremtid i softwarebranchen

Følg med i live-blogging på it.fdih.dk.

Web-magasinet eJour har i dette nummer en række gode artikler. Jeg skriver det ikke kun, fordi jeg selv har bidraget til en af dem *ahem*.

Computerworlds artikel om VTU, standarder og tilgængelighed slutter i øvrigt med en interessant udtalelse af Anne Skov:

“Vores egne sider er lagt over på en Oracle-platform, og i den forbindelse gik det op for os at blandt de mest udbredte cms-platforme var der ingen, herunder Oracle, der opfylder kravene om tilgængelighed, som vi har stillet i forbindelse med bedst på nettet.”

Anne Skov har helt korrekt iagttaget, at ingen CMS-platforme af sig selv er tilgængelige. At forvente, at CMS-platforme skulle være tilgængelige af sig selv svarer altså til at sætte sig med en hammer i hånden og vente på, at der bliver bygget et hus. Jeg har prøvet det, og det virker ikke.

Et CMS er intet andet end et værktøj, som kan bruges til at bygge et site, der *kan* publicere med valid kode og i et tilgængeligt format. Det afhænger alene af implementeringen, ikke af CMS’et (medmindre det da ligefrem aktivt forhindrer en tilgængelig og valid implementering, men den tid er ved at være ovre).

Center for Digital Forvaltning har testet 2033 offentlige websites og konkluderer, at kun 3% har valid HTML/XHTML. Det betyder samtidig, at maksimalt 3% af løsningerne kan regnes for tilgængelige, da valid kode et et af de grundlæggende tilgængelighedskrav.

Videnskabsministeriet (VTU), der blandt andet er ansvarlig for at fastsætte fælles standarder (såsom HTML/XHTML), opfylder heller ikke kravet om valid HTML/XHTML. Det er jo spøjst nok set udefra, men i Bredgade er der åbenbart nogen, der har fået en underlig smag i munden, for det har fået chefkonsulent Anne Skov til at svare igen i Computerworld med, at den manglende opfyldelse af standarder er at “skyde over målet”. Der er tale altså om “uskyldige fejl”, når man ikke opfylder kravene om valid kode, mener hun. HTML og XHTML er jo bare to ud af 146 standarder, så problemet må jo være til at overse. Sølle 1,37%…

For det første er det aktivt forkert. I den mest anerkendte definition af tilgængelighed – W3C’s WAI – indgår valid kode som et kriterium. VTU peger selv på WAI som den tilgængelighedsstandard, offentlige myndigheder skal leve op til. W3C siger, at tilgængelighed kun kommer med valid kode.

For det andet er det direkte ubegavet (undskyld, jeg kunne ikke finde et bedre ord). VTU gør langt hen ad vejen et meget stort stykke arbejde for at få oftentlige myndigheder til at leve op til fælles standarder for IT. Referenceprofilen er et stærkt værktøj. Hvis VTU nu begynder at bøje standarderne ved at hævde, at “uskyldige fejl” er ok, så skrider det hele. Anne Skov, hvilke fejl er konkret uskyldige? Jeres manglende LABEL-attribut på INPUT-tag? Jeres brug af ugyldige attributter på BODY-tagget? Vil VTU påtage sig at forklare de offentlige myndigheder, *præcist* hvilke dele af standarderne, der er ok at bryde (“uskyldige fejl”), og hvilke der ikke er.

Hvis offentlige myndigheder skal tage VTU og Referenceprofilen seriøst, skal VTU anlægge en helt anden, og mere seriøs holdning til standarderne. Det nytter intet at relativisere standarderne, blot fordi man er taget med tilgængelighedsbukserne nede.

…er telefonnummeret.

Kender du situationen? En af dine venner ringer. Han sidder i en bil, der er brudt sammen et eller andet sted i Jylland. Han ved du er på arbejde og dermed sidder med en browser åben. Han beder dig slå Falcks nummer op på deres site, så han kan ringe til dem.

Det er nu din opgave. Find nummeret til Falck på deres site.

Ja ja, det ligger derinde et sted, og man *kan* godt finde det. Men hvorfor hulen ikke lægge det med store, fede typer midt på forsiden. Der er overvejende sandsynlighed for, at mange besøg på sitet har til formål at finde kontaktinformation. Mange site-ejere glemmer, at mange besøgende slet ikke kommer for at læse om “Kompetenceområder”, “Virksomhedens historie”, “Management” eller lignende. De kommer, fordi de skal i kontakt med virksomheden. Hjælp dem.

(Tak til brormand for case)

Det forpligter, hvis du bruger dit website til andet end envejskommunikation. Lige så snart der kommer en mailadresse eller en formular på sitet, forpligter du dig til at svare på de henvendelser, der *vil* komme. Hvis du gør det dårligt, mister du forretning, og hvis du gør det godt, får du forretning. Så er der frit valg.

Det er en god idé at bruge en formular fremfor et almindeligt maillink, fordi man med en formular kan bede om de nødvendige oplysninger, og fordi man undgår at eksponere en mailadresse, der siden kan høstes af spammere.

Her er derfor et par tips til dig, der har ansvaret for et site, hvor besøgende kan kontakte din virksomhed via en formular eller simpelt maillink:

1. Brugeren forventer svar i dag
Brugeren forventer et svar samme dag. Kan du ikke klare det, så få din mailserver til at sende en automatisk mail med besked om, hvornår brugeren kan regne med at få et rigtigt svar i stedet. Hvis det drejer sig om en forespørgsel om et af dine produkter, kan du regne med, at brugeren (aka dit kundeemne) sender samme forespørgsel til flere af dine konkurrenter. Venter du et par dage med at svare, har brugeren allerede fået et tilfredsstillende svar fra en konkurrent og lagt sin forretning der.

2. Brugeren vil gerne have en kopi af det sendte
Ofte vil brugeren foretrække at sende en henvendelse via et almindeligt mail-program, fordi man så har en kopi af det sendte. Skal der sendes via en formular, så hjælp brugeren og send automatisk en kopi af det sendte til ham/hende selv. Lad eventuelt brugeren vælge, om han/hun ønsker at modtage en kopi.

3. Gør det indlysende, hvem der kan sendes til
Flere sites giver mulighed for, at brugere kan sende til forskellige afdelinger hos virksomheden. Det er bare ikke altid, at det er indlysende for brugeren, hvem der skal sendes til. Hvis der for eksempel er noget galt med en side, skal man så sende til Salg, Support eller Administration? Vær sikker på, at brugeren altid har mulighed for at sende en henvendelse, også når han/hun er i tvivl om, hvem der skal modtage den. Hav eventuelt en “opsamlingskategori”, der kan hedde “Generelt” eller “Reception”.

4. Lad være med at spørge om for meget
Bruger du en formular, så vær opmærksom på, at en formular med flere felter vil blive brugt mindre end en formular med færre felter. Begræns derfor felterne til det nødvendige. Hvis brugeren kan angive sin mail-adresse til kontakt, hvorfor skal der så også nødvendigvis indtastes telefonnummer?

5. Validering minimerer støj
Mange site-ejere er bekymrede ved, at der skal komme for meget støj ind på udfyldte formularer, fordi folk bare vil prøve formularen for sjov eller lignende. Hvis der sættes validering på felter, sikrer du dels, at du får den nødvendige information, og at drillepinde ikke gider at sende formularer med “asdf asdf asdf”-agtigt indhold.

6. Hav klare interne procedurer for behandling af henvendelser
Der bør være én og kun én ansvarlig for modtagelse af henvendelser fra sitet. Går de til en fælles adresse, hvor en gruppe af medarbejdere kan kigge fra tid til anden, vil alle forvente, at en af de andre håndterer henvendelsen. Én ansvarlig for behandling af henvendelserne er *nødvendig* for at sikre svar til brugerne. Opstil interne regler for:
- hvem modtager henvendelser?
- hvor lang tider der må gå, før der svares?
- hvem behandler og svarer?
- hvem arkiverer henvendelser og følger eventuelt op senere?
Læs resten af artiklen… »

Når du laver e-handelstjenester på nettet, er det afgørende, at brugerne får en tryg oplevelse. Brugere er generelt nervøse ved at afgive personlige oplysninger og kreditkortinformationer, fordi de frygter, at det kan misbruges. Ikke mindst de mange historier i medierne om svindel på nettet bidrager til denne nervøsitet.
Mange netbutikker giver imidlertid en alt for utryg oplevelse. En utryg oplevelse betyder, at færre kunder bruger systemet, og du tjener færre penge. Det kræver vist ingen doktorgrad at gennemskue.

Her er et par vigtige punkter om tryghed, som kan uddrages af historien, der følger:

1. Vær 100% eksplicit med din/leverandørens identitet.
Som kunde har man brug for den tryghed, det er at vide, hvem man handler med. Får man ikke det, er der stor risiko for, at transaktionen ikke bliver til noget.
Brug ikke forskellige navne på dine websider og på kvitteringer. Angiv altid en fysisk adresse for din virksomhed. Angiv også meget gerne et telefonnummer. Stræb efter, at adressen i browserens adressefelt ikke skifter til en anden. Det sker ofte, fordi selve transaktionen håndteres teknisk fra en anden server.

2. Søg for, at sikkerhedscertifikater er gyldige.
Transaktioner bør beskyttes med krypteret forbindelse og et sikkerhedscertifikat (SSL bruges ofte) for at sikre brugeren mod misbrug af hans/hendes kreditkortoplysninger eller andre personlige oplysninger. Hvis certifikatet ikke er gyldigt, kommer der en alvorligt lydende advarsel, selvom der typisk ikke er praktiske problemer. Alt for mange sites sjusker med dette, typisk fordi man ikke holder styr på udløb af certifikatet, og det får mange til at afbryde transaktionen i usikkerhed.

3. Tal dansk!
Mange sites blander sprog, enten fordi der er flere sprogversioner af sitet, og der er links på tværs, eller fordi indholdet leveres af forskellige delsystemet på forskellige sprog.
Lad være med at blande sprog fra side til side eller på samme side. Det svækker brugerens tillid til leverandørens site, og mange vil være tilbageholdende med at købe noget hos en leverandør, hvor der roder i butikken.

4. Tag højde for at det går galt.
Specielt ved transaktioner kan meget gå galt, og risikoen for at transaktionen ikke bliver gennemført kan være stor af samme årsag. Brugernavn/password kan være forkert indtastet, en konto kan være udløbet, brugeren kan have en forkert browser, leverandørens server kan være overbelastet, et sikkerhedscertifikat kan være udløbet og tusind andre ting. Hvis noget går galt, så forklar brugeren præcist, hvad der gik galt, og hvordan han/hun skal komme videre. Er der et nummer, man kan ringe på? Skal man prøve igen? Brug almindeligt sprog til at forklare, og lad ikke udviklere formulere fejlmeddelelserne.

5. Giv en ordentlig kvittering for transaktionen.
Brugere har ofte brug for at kunne dokumentere en transaktion enten til eget regnskab eller til refusion. Forklar eksplicit, hvordan brugeren får fat i kvitteringen. Optimalt er at sende den til en mailadresse, brugeren har angivet og give den som downloadmulighed i PDF. Sørg naturligvis for, at den opfylder formelle regnskabsmæssige krav til kvitteringer, og forvent ikke, at brugere kommer tilbage, hvis den slags ikke er i orden.

Læs videre om brugeroplevelser og transaktioner på nettet:

• E-mærket
• Good Experience
• Vividence: “Stop Loosing Customers On The Web”
• 37signals om “contingency design”
• Jakob Nielsen: “Beyond the Buy Button in E-Commerce”
• Nielsen Norman Group Report: “E-commerce User Experience: Design Guidelines for Trust and Credibility”

Læs resten af artiklen… »

IT- og Telestyrelsens officielle website om Digital Signatur tager egen medicin.

…adgangen til hjemmesiden er endvidere sikret via en SSL-forbindelse (128 bit), der skaber en krypteret forbindelse mellem hjemmesiden og de enkelte brugere. De enkelte brugere kan dermed også skabe tryghed ved, at det er IT- og Telestyrelsens server de har fat i.

Hvis man som bruger kan være så tryg ved styrelsens server, hvorfor får jeg så følgende advarsel smidt i hovedet, når jeg prøver at se sitet:

Åh ja, humor – det har de, og hvis jeg ikke tager meget fejl, er dette et eksempel på metacertifikathumor…

Forudsætningen for en succesfuld implementering af et Content Management System er, at man har skrevet en god kravspecifikation. Jeg har de sidste 7 år arbejdet med at udvikle og sælge CMS, og derfor har jeg i tidens løb set både gode og dårlige eksempler på, hvordan kravspecifikationer bliver skrevet. Her er et par råd, der er baseret på mine erfaringer:

1. Fokuser på behovene – ikke funktionerne
Mange kravspecifikationer beder om meget konkrete funktioner. Problemet med dette er, at det tvinger leverandørerne til at lave tilbud baseret på en udvikling, der ligger fuldkomment op ad det beskrevne. Dermed er der risiko for, at andre – og muligvis billigere – løsninger bliver overset, selvom de opfylder samme behov for kunden.

2. Fokuser på værktøjet – ikke websitet
Selvom de fleste interne diskussioner hos kunden forud for kravspecifikationen typisk drejer sig om, hvordan det nye website skal se ud og fungere, skal man som kunde tænke på, at det sikkert ændrer sig, lige så snart den første implementering er gennemført. Derfor er det langt vigtigere at bruge ressourcerne på at afklare krav til det værktøj, der skal publicere websitet i flere generationer fremover end på den føreste implementering.

3. Lav en god vejledning til dem, der skal besvare kravspecifikationen
Det er vigtigt at hjælpe leverandører ved at forklare dem, hvordan de skal besvare kravspecifikationen. Er der et fast skema, der skal udfyldes? Hvordan forstår I selv nøglebegreber? Hvor meget dokumentation skal leveres med?

4. Fortæl hvad der er krav, ønsker og rart at have
Alle jeres krav er sandsynligvis ikke missionskritiske, så hjælp leverandørerne ved at angive, hvilke krav der *skal* opfyldes, hvilke der *ønskes* opfyldt og hvilke, der blot er *rare* at få opfyldt. Leverandører vil nemlig lægge mere energi i at få beskrevet, hvordan de vil opfylde de obligatoriske krav end dem, der er blot er rare at få opfyldt.

5. Opstil krav til performance – men angiv forudsætninger
Det er vigtigt, at det opstilles krav til systemet performance (antal samtidige brugere, responstid for sidevisninger og operationer med videre), men kravene er meningsløse for leverandørerne, hvis forudsætningerne ikke er angivet præcist. Hvor “tung” antages en side at være (i kb)? Hvor mange besøgende er på serveren samtidig? Hvilke typer af operationer? Hvilken server antages være stillet op (processor, RAM og så videre)? Jo flere forudsætninger du angiver, desto mere præcist vil leverandører være villige til at svare. Hvis du ikke angiver forudsætninger for performancekrav, vil leverandører bare svare fuldkomment uforpligtende i stil med “systemet antages at kunne opfylde de beskrevne krav”…

6. Brug use cases for de vigtigste brugsscenarier
Use cases er gode, fordi de støtter beskrivelsen af krav. Det gør det væsentligt nemmere for leverandører at forstå, hvilke problemer der skal løses i hvilken kontekst. Men lad være med at drukne kravspecifikationen i use cases – brug dem for de vigtigste brugsscenarier.

7. Beskriv leverancens omfang detaljeret
Der er meget stor prismæssig forskel på at købe et CMS og implementere det selv og så at købe et system med fuld implementering – og der er uendeligt mange varianter i mellem. Beskriv hvad I vil have leverandøren til at levere, og hvad I selv vil klare. Bed eventuelt leverandørerne estimere opgaver, I selv vil løse, så I får en idé om, hvor vanskeligt og ressourcekrævende de forskellige dele af implementeringsarbejdet er for de tilbudte systemer.

8. Beskriv det videre forløb
Leverandører er interesserede i at vide, hvordan den videre proces forløber. Kan der stilles spørgsmål til kravspecifikationen? Hvornår skal tilbud indleveres? Vil der være mulighed for at præsentere systemet efter tilbud er afleveret? Hvornår forventes beslutning at træffes?

9. Hvilke standarder skal overholdes?
For mange kravspecifikationer indeholder ingen krav til standarder, men det er vigtigt at forklare hvilke standarder, der skal overholdes, fordi det får betydning for, hvilke andre systemet CMS’et kan bindes sammen med. XML? SOAP? XHTML? tilgængelighed?

10. Få hjælp!
Det er vigtigt at få eksterne øjne på en kravspecifikation i udarbejdelsesfasen, men det behøver ikke at betyder, at den nødvendigvis skal skrives fuldstændigt af eksterne konsulenter. Eksterne øjne sikrer, at kravspecifikationen ikke kommer til at indeholde indforståede begreber, og at I får diskuteret jeres forretningsmæssige mål grundigt. Endelig er eksterne øjne oftest den bedste garant mod “politiske/symbolske” krav, der kommer med, blot fordi en chef uden reel grund insisterer på det.

Hvis du leverer et feed fra din blog eller site i det hele taget (RSS, altså) til den måbende offentlighed, så er det smart at melde den til den nye danske oversigt over feeds, Feeds.dk. Godt initiativ, dér. Vi har savnet det…

Bo Juni skriver på Bitconomy’s udmærkede site, at blogs er farlige for din virksomhed. Det er nemlig dybt problematisk, hvis medarbejderen afslører forretningshemmeligheder, krænker 3. parts rettigheder, skriver dårligt om chefen eller afslører insiderviden, der påvirker aktiekurser.
Jeg er helt enig. Det er meget problematisk. Men er det virkelig blogs, der er udgør den egentlige trussel her? Er det i virkeligheden ikke medarbejderne, der er problemet. Jeg mener, medarbejderne behøver jo ikke en blog for at afsløre forretningshemmeligheder eller for at tale skidt om chefen. Det kan jo lige så godt ske i mails, i telefonsamtaler, i debatfora eller lignende. Er vi så ikke fremme ved, at der må gribes ved ondets rod, og at medarbejderne må afskaffes helt, hvis vi vil problemet til livs?
(Eller kan det tænkes, at virkeligheden er, at virksomhedens medarbejdere i forvejen har enorm kontakt omverden, og virksomhedslederen skal se dette som en uvurderlig ressource og ikke et slem trussel? Jeg spørger bare.)

Sitet CMS-finder står overfor at blive lukket ned, og det er trist, fordi der er en masse muligheder i det. Sitet består at oplysninger om 75 CMS-produkter på det danske marked.
Systemet er oprindeligt lavet af en arbejdsgruppe under FDIH med repræsentanter fra Dynamic Systems, MOC Company, Composite og Synkron.
FDIH har trukket sig fra projektet, og vi mangler nu nogen, der kan “eje” sitet og udføre redaktionelle opgaver (opdateringer, nyhedsbreve og så videre). Vi har aftalt en model, hvor der kan genereres indtægter fra de deltagende leverandører, så “ejerskabet” kan selvfølgelig finansieres. Det giver sig selv, at en kommende “ejer” vil være nødt til at have uafhængighed i forhold til CMS-leverandørerne.
Kender du nogen, der vil kunne videreføre CMS-finder? Din virksomhed/organisation? Nogen andre? Sig til med det samme (send mig en mail på andreas.joh[at]nnsen.dk) – ellers lukker vi snart sitet…