Den findes ikke. Jeg har ledt og ledt, men ligegyldigt hvor meget jeg leder kan jeg ikke finde en bog om drift af webløsninger. Der findes naturligvis en bunke bøger om “web project management”, men det tætteste jer er kommet er Web Management in Practice.  Den virker ikke helt som om den dækket et team af webprofessionelle der
skal holde et eller flere websites af en rimelig størrelse i luften. Jeg syntes der mangler noget skalering.

Derfor har jeg selv gjort mig nogle tanker om drift af webløsninger i et EWCM (Enterprise web content management) perspektiv.

Første forsøg ser på definitionen af de arbejdsområder som driften skal dække. Jeg har lavet en lille
illustration, der naturligvis kan forbedres over tid, men here goes.

Jeg har forsøgt at lave en række aktiviteter der er løst koblet på tilsvarende arbejdsområder. Dette er gjort af to grunde. For det første vi jeg gerne kunne koble et arbejdsområde på en kompetenceprofil. Det er f.eks. sjældent man finder en udvikler der kan lave systemintegration, der også er dygtig til SEO/SEM. Derfor kan det være en god ide når man ser på organisationens kompetencelandkort, at de kompetenceprofiler jeg har redegjort for, kan dækkes i
weborganisationen.

1. Aktivitet: Monitor -> område: web content management system
2. Aktivitet: Produce -> område: Production
3. Aktivitet: Understand -> område: Usage
4. Aktivitet: Syndicate -> område: Syndication
5. Aktivitet: Integrate -> område: Integration
6. Aktivitet: Develop -> område: Backend
7. Aktivitet: Analyze -> område: Front end

• 1. aktivitet omhandler udelukkende det pågældende system man måtte bruge som CMS.
• 2. til 5. aktivitet omhandler de daglige arbejdsopgaver der vil være i en driftsorganisation
• 6. og 7. aktivitet fokuserer på henholdsvis frontend og backend.

Der vil naturligvis være noget overlap mellem de treområder, men de bibringer tre forskellige fokusområder man kan
strukturere driften i forhold til.

Aktivitet: Monitor -> område: web content management system

En monitorfunktion på content managementsystemet på være
internettets svar på en maskinmester. Der er de klassiste ting som
oppetid og broken links, men jo større en organisatione man får, jo
mere monitorering er der for webmasteren. Det kan være design
compliance, wgag compliance, workflow kontrol i systemet, bruger og
rollestyring o.s.v. Mange af de processer man normalt ville modellere i
et workflow skal sikkert også mionitireres her, gennem rapporter og
lignende.

Aktivitet: Produce -> område: Production

Dette er naturligvis en centralt element i modellen, der i
høj grad hænger sammen med alle andre elementer. Det der produceres,
syndikeres. Det der integreres skal også oparbejdes til egentlig
indhold - da det sjældent er muligt at publicere “as is”. Brugen af
websitet, og systemets levering af indhold har også en direkte relation
til produktionen, så egentlig burde området “produce” måske have en
mere central placering. Ofte vil det rå indhold være leveret fra andre
kilder end web-teamet selv. Her genner der sig en af de klassiske
web-problemstillinger. Hvis web-teamet ikke er med på sidelinjen
allerede fra starten kan det resultere i råmaterialer der ikke egner
sig til web, eller skal gennegå en stor forandringsprocess. En
klassiker blandt klassikere er reklamekampagner der 1½ dag før launch
bliver smidt på websitet, med materialer fra print -kampagnen, uden
stillingtagen til webmediet. Man kan ikke altid forvente at det indhold man producerer i sandhed er unikt, men hvis man sikrer at det er af en tilpas høj kvalitet, i relation til sine brugere, kan man stadig forvente at det kan være formålstjenesteligt. At kopiere sit marketingmateriale

Aktivitet: Understand -> område: Usage

Da alle brugsscenarier vedrører brugeren er der flere indgangsvinkler til at skabe sig en forståelse for brugen af systemet. Ofte er en bred vifte af forskellige metoder den bedste vej til at optimere webløsningen. Jeg vil ikke gå i detaljer med de enkelte metoder, men alt fra egentlige usability-studier men usabilitylabs m.m. til alm webanalyse og heuristisk evaluering kan være passende alt efter den konkrete situation. Jeg er selv fortaler for at teste “motorvejene” med brugerrepræsentanter, og benytte de erfaringer man får her i kombonation med ekspertevaluering som en slags “metode triangulering”, og basere sit daglige arbejde herpå. På denne måde kan man gøre de ofte dyre og komplekse, kvalitative brugerundersøgelser til selvstændige projekter, og sikre sig maksimal udnyttelse af resulteterne. Derudover er der en væsentlig mængde testværktøjer, som Lynx, firebug eller Web Accessibility toolbar der kan hjælpe i optimering af løsningerne. Jeg tror ikke på “guriella-test” der efter min mening kan er stattes af ekspertevaluering hvis man har et tilfredsstillende grundlag at vurdere ud fra.

Aktivitet: Syndicate -> område: Syndication

Der forekommer flere former for syndikering, men generelt handler det om at få sit indhold ud på andre domæner, og derfra linke ind til ens landingpages / funnels. Den klasiske syndikering kan være er RSS feed, der er koblet på www.Technorati.com eller www.pingomatic.com. Der er mange bud på mere integreret syndikring. De bedste eksempler er når to eller flere parter deler indhold eller funktionalitet, der beriger begge parter. Simple “gensidige links” fungerer ikke i dette setup, da det ikke giver værdi for parterne, og søgemaskinerne sjældent giver point for gensidig eller reciprok linking. Et nutidigt eksempel er www.boligsiden.dk, hvor (næsten) alle ejendomsmæglere har deres aktuelle ejendomme til salg. Brugeren får værdi, da men ikke skal søge bolig ved hver eneste ejendomsmægler, og ejendomsmæglerne får værdi, ved at kunne tiltrække flere besøgende. Ejendomsmæslerforeninger får også værdi i den forstand at de fremstår som det “samlede boligmarked”, hvorved foreningens legitimitet styrkes, så alternative mæglere presses ind i foreningen. Traditionelle eksterne bannerkampagner kan også ses som en form for syndikering, men dette skal naturligvis ses i et mere marketingorienteret perspektiv.

Aktivitet: Integrate -> område: Integration

Der er umiddelbart to veje i integrationen. Indfra og ud, samt udefra og ind. I indefra og ud scenariet har vi klassisk systemintegration. Integrering af back-office i et webmiljø forudsætter naturligvis kraftig involvering af traditionelle IT-udviklere. Her vil den overordnede “enterprise arkitektur” på IT området have stor betydning for de muligheder man har for at levere indhold fra de eksisterende miljøer. Et typisk eksempel er integratione til supprt, produktkataloger, manualer / drivere o.s.v. Alle manuelle processer i denne forbindelse er dømt til, på et eller andet tidspunkt, at fejle, hvorved man mister systemintegritet. Redundans er (næsten) altid af det onde her, og bør bekæmpes. Det er ofte i integrationen af eksisterende data, en webløsning skaber værdi. I det tilfælde hvor integrationen er det centrale, virker webløsningen som en platform til formidling. Udefra og ind integration forudsætter en god processhåndtering i systemerne. Er der f.eks. tale om håndtering af kundekontakter, vil et være vigtigt at både kontaktdatabaser, notifikation/email og website fungerer i en veldefineret process med målbare KPI’er og normer. Derfor må man altid sikre sig at der er et organisatorisk setup der kan understøtte disse systemet og processer.

Aktivitet: Develop -> område: Backend

Ren udvikling, kan naturligvis hænge sammen med både produktion og integration. Ja - for så vis alle områderne i modellen. Når de alligevel er taget us om et selvstændigt område, er det fordi rollen “webudvikler” allerede er en veldokumenteret del af et web-team. I websammenhænge er der naturligvis ikke behov for at udvikle nye metoder. Webudvikling er udvikling på linje med alle andre former for udvikling. Det største forskel er at websuvikling ofte indeholder væsentligt mere interaktivitet og brugergrænseflade. Derfor er der behov for at der i analysefasen er et let øget fokus på wireframes, mockups og de processer der ligger der. Forudsat at webudvikleren indgår i et samarbejde med en frontendudvikler eller en webdesigner, vil der ikke være et behov for store interfacekonpetencer, men det kræver at der er stor forståelse for dem, og et meget proaktivt samarbejde. Udviklingsarbejdet vil også foregå med et API til et CMS eller i et framework. Dette er ofte koblet på en udviklingsmodel som f.eks. Rational Unified Process, eller tilsvarende modeller.

Aktivitet: Analyze -> område: Front end

Marketingkoordinatorer, webmasters, accountmanagers, projektledere, usabilityspecialister. Der er mange roller der har haft fingrene nede i denne kategori. Det er den klart mindst web-tekniske del af hele driften, og er derfor en udemærket vej for “ikke-kodere”. Den hænger sammen med “understand -> usage”, og “monitor -> WCM” men knytter sig mere til de forretningsorienterede dele, og eksterne kilder. At finde de rigtige kilder til kampagner, at håndtere SEM, at sikre “inbound linking”, og at man ikke havner i et “bad neighbourhood”, der kan have negativ værdi i søgemaskinerne. At overvåge konkurrenter, at finde nye muligheder i markedet (web 2.0 / 3.0 - hype), og etablere samarbejder på tværs af domæner. Man kan sige at forretningsudvikling sigende for området, krydret med en god analytisk og markedsføringsmæssig tæft.