Som webbureau får vi af og til henvendelser omkring flere leverandører til en webløsning. Typisk har vores kunder forskellige grunde til disse ønsker. Det kan f.eks. være den tekniske ekspertise mangler hos det eksisterende bureau.


Multileverandørstrategi

Som webbureau får vi af og til henvendelser omkring multileverandørstrategier. Typisk har vores kunder forskellige grunde til disse ønsker, det kan være kapaciteten ved den nuværende leverandør, det kan være at kunden har deres egen udvikler som de vil have til at lave noget, eller det kan være den tekniske ekspertise mangler hos det eksisterende bureau. Det er ikke systemerne som giver problemerne, men artiklen her vil tage udgangspunkt i vores verden, som er baseret på Sitecore. De samme problemer vil også være at finde ved fx Umbraco og SharePoint løsninger.

Hvorfor overhovedet en multileverandørstrategi?

Set ud fra vores kunders synsvinkel er det ønskværdigt, og der er flere grunde til, at man ønsker en multileverandørstrategi til sit website.

  • Leveringstid fra bureauet kan være lang. Måske ønsker kunden en selvbetjeningsportal mens bureauet er i gang med at udvikle et nyt website, og dette har bureauet ikke ressourcer til.
  • Benchmarking og konkurrence. Får jeg det optimale produkt? Jeg kan overveje to leverandørers tilbud på løsninger og få den billigste eller bedste
  • Specialisering. Jeg vil have det bedste bureau til at løse en speciel opgave. Teknisk tunge løsninger kræver specialister på området. På branding sites er der andre specialister end på det tekniske.

En multileverandør-strategi kan dog give en række problemer, både for dem der arbejder med websitet i det daglige, redaktører og administratorer, men det kan også give store problemer for slutbrugeren – De besøgende på dit site.

Som webbureau er vi både entreprenør og arkitekt

Den letteste måde at forklare problemerne ved en sådan løsning er via en analogi.

“Det at bygge og designe et website kan ses som det at bygge et hus. Som webbureau er vi både arkitekterne og entreprenøren bag. ”

Vi tegner huset, og derefter bygger vi det. Vi sørger for, at vores beslutninger undervejs i processen giver anledning til, at tingene gøres på samme måde ved en evt tilbygning – så passer byggestil og teknik sammen. Vælges der ny leverandør ved en tilbygning kan der pludselig være mange nye materialer, systemer og løsninger i spil. Dette giver problemer for slutbrugeren, redaktøren og administratorer, hvis vi vender tilbage til webverden.

Hvad går helt konkret galt?

For det første er det vores erfaring, at det hurtigt bliver rodet hvis der ikke benyttes samme standard i Sitecore eller andet CMS software.

Har du styr på struktur og standarder i dit CMS?
Der bliver rod i hvor og hvordan man retter tekster, opbygningen af felter og skabeloner bliver anderledes, således vil strukturen og navngivning af felter blive svær at finde rundt i.Teknisk vil det f.eks. få betydning for normalisering af felter. Når du retter titelnavnet på et felt, så rettes det automatisk på hele sitet. Denne standard kan der dog blive brudt med, hvis ikke den samme standard benyttes, og så står man med håret i postkassen den dag man ønsker at omdøbe et felt. Det lyder måske ikke så slemt, men snart har man 10 af disse ”hovsa”-løsninger og det begynder at blive uoverskueligt for alle parter.

Har du styr på dine filer?
Ikke blot i CMS’et kan der forekomme uligheder i hvordan ting gribes an. Måden hvorpå et CMS programmeres på forventes det ofte at der placeres visse filer i visse mapper og strukturer. Placeres filerne i de korrekte mapper i din løsning betyder det, at vedligeholdelsen af løsningen bliver lettere og dermed billigere.

Hvad gør denne knap, og denne kodestump?
Måden man skriver et dokument på i word, med afsnit, punktform, overskrifter og lignende er med til at gøre dokumentet mere læsbart. På samme vis er det vigtigt at kode for løsningen struktureres ens uanset hvilken leverandør der har skrevet det, så kan man lettere danne sig et overblik over hvad den enkelte kodestump gør.

Få dig en ”Best Practice”.

CMS’er giver ofte mulighed for at gemme værdier, som har noget med konfigurationen af sitet at gøre, og altså ikke noget man som CMS redaktør har adgang til. Eksempelvis kan det tænkes at man skal have fat i en bestemt nyheds liste på siden, som altid har et bestemt ID. Skrives dette ID ind som en del af koden er det besværligt at rette, hvis der skal trækkes fra en anden nyheds liste. Derfor er det vigtigt at der er en best practice til CMS’et. En best practice som beskriver hvordan man bør udforme forskellige løsninger.

Hvordan håndteres en multileverandørstrategi i praksis

Der er flere ting som skal overvejes, hvis man ønsker en multileverandør strategi som skal virke i praksis.

  • Kildekode ejerskab – hvem har den nyeste kildekode til sitet – Hvem har ansvaret for denne?
  • Hvem kan og må lægge nye ting ud? Hvis flere forskellige leverandører har adgang til dette kan det medføre store problemer. Begge leverandører kan ende med at fraskrive sig ansvaret og sige ”Det er ikke os” hvem skal så have ansvaret?

Ønsker du stadig en multileverandørstrategi?

Vi anbefaler, at du kun kaster dig ud i en multileverandør-strategi hvis:

  • Det virkelig er noget du vil, og mener skaber værdi for din organisation eller virksomhed
  • Er det et brandsite projekt, som kun kræver 40 timers arbejde, og du vil prøve en anden leverandør, så lad være, det kan ikke betale sig i forhold til problemerne og omkostninger.
  • Hvis du gerne vil forskellige leverandører, så overvej at bruge forskellige leverandører på forskellige løsninger. Du vil stadig støde på udfordringer, men det er nemmere med hver sin leverandør, på hver sin løsning. Hermed holdes løsningerne teknisk set adskilt.

Sådan bør du gøre ved multileverandørstrategi

  1. Benyt kun én hovedleverandør. Udpeg en leverandør som har hovedansvaret for stabil drift og håndtering af kildekode. Andre leverandører skal levere deres færdigudviklede projekter til netop denne leverandør, som så lægger det live. Vi anbefaler derudover også at afsætte en del tid til review og tests fra hovedleverandørens side – hver gang der kommer noget fra den anden leverandør. Det er værd at bemærke, at det samlede overhead er relativt stort.
  2. Benyt kun faste leverandører. Problemerne kommer især af, at forskellige leverandører løser ting forskelligt. Derfor er det vigtigt, at have så få leverandører som muligt. Og ikke mindst – så faste leverandører som muligt. Arbejder to leverandører sammen over en længere årrække er det (måske) tid nok til at kunden høster nogle fordele.

Detaljeret Sitecore standard

For at imødekomme udfordringerne, er det nødvendigt med en detaljeret Sitecore standard, som skal:

  1. Beskrive generelle formaterings- og navngivnings standstandarder
  2. Beskrive strukturen i Sitecore
  3. Beskrive minimum krav og hvordan almindelige problemstillinger løses ens, på tværs af leverandører.

Det er en teknisk dygtig og kyndig person indenfor Sitecore som skal udarbejde en sådan standard. Bemærk dog at bureauer sjældent vil give dette væk, især til konkurrenter.