Velg en plattform som passer for din organisasjon
featureArticle.chapters
featureArticle.introduction
Din organisasjon er på jakt etter en ny plattform for å levere digitale opplevelser. Nå må du nøye vurdere et bredt utvalg av funksjoner som vil passe inn i deres eksisterende arkitektur og ferdighetssett.
Selvfølgelig vil det variere hva din organisasjon trenger, avhengig av størrelse og bransje. Men basert på 20 års erfaring og innspill fra våre kunder og partnere, har vi i Enonic inkludert de viktigste sakene og funksjonene du bør vurdere.
God lesning!
authorBox.aboutVegard Ottervig
Vegard Ottervig er innholdsansvarlig i Enonic, har en mastergrad i filmvitenskap og har jobbet med journalistikk og markedsføring siden 2010. Han elsker film, sykling, filosofi, spill og skriving.
Chapter 1
Sørg for at plattformen er fremtidssikker
Leverandørens legitimitet
Pass på at en potensiell leverandør er legitim og har en stabil økonomi. Undersøk alt du kan før du fortsetter anskaffelsesprosessen. Sjekk leverandørens nettsted, LinkedIn-bedriftsprofil, juridiske data, forretningsdata og attester.
Produktmodenhet
Utforsk fellesskapet, dokumentasjonen, kildekoden og kvalitetssystemene for å vurdere produktets modenhet. Hvilken versjon er det? Hva er den tekniske utgivelsesfrekvensen? Hvordan har leverandøren løst tidligere rapporterte produktønsker og feilrettinger?
Utviklingsplan
Finnes det en veikart tilgjengelig? Å lese hva som er planlagt for de neste månedene og årene, samt å sammenligne hva som var planlagt med hva som faktisk ble gjort, kan gi deg uvurderlig innsikt i leverandørens effektivitet og pålitelighet.
Composable CMS
Ikke legg alle eggene i én kurv, enten det er et klassisk CMS eller et headless CMS. Sørg for at plattformen har funksjonene til et composable CMS. Dette gir klassiske løsninger for redaktører og headless-løsninger for utviklere – med alle alternativer som er fullstendig valgfrie.
Produktvisjon
Er leverandøren en visjonær med fokus på agile arbeidsmetoder og moderne webteknologier, eller klamrer den seg til gamle systemer og "business som vanlig"?
Innholdsforrang
Selve lakmustesten for å angi en reell digital plattform for dagens og morgendagens flerkanalsverden. Vær sikker på at innholdet gis forrang. Plattformen bør prioritere fleksible innholdstyper og strukturert innhold, i motsetning til sidebygging og presentasjon.
Utover CMS: Apper, API-er, osv.
Har du andre behov enn CMS, som apper og API-er? En fremtidssikker plattform bør også støtte bygging av egendefinerte tjenester og API-er, samt brukergenerert innhold.
Begrensninger
Huk av dette hvis du har noen gjennomgående begrensninger i din organisasjon. Dette kan være integrasjoner til gamle systemer, CRM-er, ERP-er, designsystremer, eller valget av hvilke front-end-rammeverk du kan jobbe med.
Chapter 2
Funksjonssjekk
Hvilke funksjoner trenger ditt prosjekt? Sørg for at du ikke glemmer noe med vår praktiske sjekkliste.
UX for redaktører
Innholdsredaktører skal jobbe på plattformen daglig. Sørg for at den er brukervennlig, med responsiv design, ryddig organisering og logiske operasjoner.
Headless-muligheter
Hvis du ønsker å distribuere innholdet ditt i dagens fragmenterte digitale verden, må publiseringssystemet ditt støtte headless-løsninger gjennom API-er.
Søk
Å hente innholdselementer gjør det lettere å finne eksisterende ressurser og gjenbruke dem. Plattformen du velger bør derfor inkludere et raskt og kraftig søk, komplett med filtreringsmuligheter.
Lokalisering
Handel og kunnskapsutveksling kjenner ingen geografiske grenser. Muligheten til å tilby lokalisering av dine digitale tilbud bør derfor være en funksjon.
Mediehåndtering
Digitale tilbud inneholder mye mer enn rene tekster i dagens verden. En opplevelsesplattform bør tilby redigeringsmuligheter for bilder, dokumentforvaltning, samt enkel innbygging av f.eks. videoer.
Tilgjengelighet (for redaktører eller sluttbrukere)
Huk av for denne funksjonen for å sikre en grundig undersøkelse av om den potensielle plattformen støtter tilgjengelighetsstandarder og retningslinjer.
Enterprise-klar
Noen bedrifter har ekstra krav som ivaretar flere interessenter og markedsføringsteam spredt over hele verden. Merk av for hver funksjon som gjelder:
- Multi-site
- Flere brukere
- Komplekse roller og tillatelser
Personalisering
Å tilby en personlig opplevelse kan skille ut bedriften din på markedet. Hvis verktøy for personalisering eller integrasjoner er avgjørende, huk av for denne funksjonen.
Chapter 3
Arkitektur
Nå kommer de mer tekniske sakene. Selve de arkitektoniske kravene.
Investeringer
Hvor godt passer den potensielle plattformen sammen med den eksisterende teknologien i organisasjonen din? Med deres tunge investeringer?
Husk at ikke alt må kastes ut på grunn av at det bare er gammelt. Gode og smidige systemer er fortsatt akkurat det, uavhengig av alder.
Uansett, undersøk hvor godt den digitale plattformen passer med din nåværende teknologi, inkludert, men ikke begrenset til:
- Rammeverk
- Designsystem
- Integrasjoner
- Programmeringsverktøy
- Eldre systemer
Lokal vs. administrert tjeneste
Spørsmålet om å drifte deres digitale plattform lokalt eller via en administrert tjeneste i f.eks. skyen er viktig. Tenk på sikkerhet, vedlikehold, sikkerhetskopier, skalering og andre spørsmål fra DevOps-verdenen.
Lokalt
Lokal drifting gjør at din organisasjon beholder mer kontroll, men kan være dyrere på grunn av interne DevOps-team og maskinvareressurser.
Administrert tjeneste
En administrert tjeneste krever ikke behov for dyp forståelse av sikkerhetskopier, grunnleggende sikkerhet osv. Dette håndteres av DevOps-fagfolk.
Åpen kildekode vs. lukket kildekode vs. skybasert
I tillegg til å velge en passende driftsløsning for organisasjonen din, må du også vurdere et annet, noe overlappende aspekt. Spørsmålet om lisens og rammeverksteknologi.
Åpen kildekode
En løsning med åpen kildekode er det sikreste alternativet og gir deg full kontroll. Det kan imidlertid være kostbart avhengig av om verktøyet er fullt betjent og driftet eller ikke.
Lukket kildekode
En løsning med lukket kildekode lar leverandøren ha full kontroll, men låser kunden inne. Samtidig er utvikling og fremgang utelukkende avhengig av den juridiske eieren. Modellene varierer sterkt på løsninger med lukket kildekode, så sørg for å vurdere dem grundig.
Skybasert
Skybaserte løsninger er det samme som SaaS, som kan levere god ytelse. De gir imidlertid ikke sluttbrukeren noen kontroll og gjør en helt avhengig av leverandøren.
Suite vs. spisskompetanse
Enda et arkitektonisk aspekt å vurdere for digitale plattformer er hvilken type løsning organisasjonen din bør velge når det gjelder standardfunksjoner. Et klassisk alternativ er en full markedsføringssuite vs. en spisset, modulær løsning.
Full suite
En full suite tilbys vanligvis av store leverandører, for store bedriftskunder. En full suite med alt man tilsynelatende trenger høres lovende ut. Men sørg for å grundig undersøke hvor godt integrerte alle de forskjellige funksjonene virkelig er, da de ofte kommer som et resultat av M&A.
Spisskompetanse-integrasjoner
Et alternativ i møte med fullstendige markedsføringssuiter er en løsning som tilbyr en fleksibel kjerne og integrasjoner med de beste funksjonene på markedet. På denne måten kan du plukke ut separate systemer for f.eks. CRM, markedsføringsautomatisering og SEO. Det som passer dine krav best.
Kontinuerlig driftsetting
Jobber dine potensielle leverandører etter smidige utviklingsprinsipper og leverer kontinuerlig driftsetting av sin løsning, eller holder de seg til standardprosesser og faste utgivelsesvinduer?
SDK
Inkluderer den potensielle løsningen et programvareutviklingssett? Hva kreves for å starte utviklingen? Er det mulig å kjøre på alle maskiner? Hvordan er installasjonsprosessen? Kan utviklere bruke sine favorittrverktøy med SDK-en?
Mikrotjenester
Mikrotjenester er i vinden, men trenger organisasjonen din virkelig en slik arkitektur? Hvis "ja", hvordan passer det med din nåværende plan, og hvordan ønsker du å kjøre tjenester?
Bruks-caser
Selv om headless og composable CMS allerede er nevnt, er det nyttig å forestille seg et realistisk brukstilfelle for å vite nøyaktig hvilken løsning organisasjonen din trenger.
Klassisk
Et klassisk CMS er primært ment for å bygge og vedlikeholde nettsteder.
Headless
Et headless CMS er primært ment for apper.
Composable
Et composable CMS er ment for både nettsteder og apper.
Sikkerhet
Plattformens sikkerhet er essensiell av mange grunner, inkludert beskyttelse av kundedata og din merkevares omdømme. Kryss av disse for å garantere at sikkerhet er på agendaen.
Stresstestet
Hvor godt er løsningen testet? Har den gjennomgått flere dokumenterte stresstester, som demonstrerbart har styrket dens motstandsdyktighet mot trusler?
Identitets- og tilgangsstyring (IAM)
Hvor enkelt er det å delegere og tilbakekalle tilgang til involverte brukere i organisasjonen din og tredjeparter?
Kvalitet
Hvordan er kvalitetssystemet til de potensielle leverandørene? Sørg for at leverandøren du velger har dokumenterte prosesser for hver vesentlig operasjon den forplikter seg til, inkludert:
Automatisert testing
Testes løsningen automatisk hver dag for feil og kritiske problemer?
Brukervennlighet/kompleksitet
Hvor komplekst er kvalitetssystemet å verifisere?
Ytelse
Ytelsen til dine digitale opplevelser avhenger av en rekke faktorer. Men den underliggende plattformen kan bidra med følgende:
CDN
Støtter leverandøren en modell for innholdsleveringsnettverk?
Lokalt
Eller er bare lokal levering mulig med oppsettet?
Dataoppbevaring
Er løsningen basert på NoSQL eller en relasjonsdatabase? Relasjonsdatabaser kan være en flaskehals eller kreve mer ferdigheter for forvaltning og finjustering.
Skalerbarhet
Å skalere dine digitale opplevelser er viktig for å møte økte (eller reduserte) trafikkbehov på en sikker, forutsigbar og rimelig måte. En skybasert løsning betyr ikke nødvendigvis automatisk skalering, så sørg for å undersøke dette grundig.
Robusthet
Hvor robust er løsningen og hvordan håndterer den uventede hendelser? Som vanlig kommer det an på hva organisasjonen din trenger, og det er tradisjonelt dyrere med høyere krav. Skyen kan imidlertid løse mange av disse problemene.
Ruting
Hvordan administrerer du strukturen til dine digitale tilbud? Hvis du velger en ren headless-løsning, er URL-ruting ikke tilgjengelig rett ut av boksen.
URL-håndtering
Vanligvis assosiert med klassiske CMS-er, for håndtering av URL-en til en gitt nettside.
Ruting-app
Ettersom et headless CMS er en database med API-er, er det ingen iboende URL-håndtering. En dedikert ruting-app ville derimot være tillatt.
Webserver? Redaktører?
Andre viktige rutingspørsmål kan løses med et composable CMS.
Chapter 4
Ferdigheter
Kvaliteten på dine systemer og vedlikeholdet av dem avhenger av kvaliteten på ferdighetssettet i din organisasjon.
Programmeringsspråk som passer nåværende ferdighetssett
Selv om en digital plattform oppfyller alle dine formelle krav, kan den utgjøre en uoverstigelig utfordring hvis ingen av utviklerne dine har erfaring med det underliggende programmeringsspråket.
Front-end-rammeverk
Sjekk at din back-end-plattform er kompatibel med språket til ditt valgte front-end-rammeverk, for å unngå plattformanalfabetisme.
DevOps
Avhengig av om plattformen er fullstendig administrert eller selvadministrert, bør du forsikre deg om at dine eventuelle DevOps har de nødvendige ferdighetene også.
Dokumentasjon og opplæring
Hvor enkelt er det å lære seg selv og dine kollegaer løsningen?
Tilgjengelighet av utviklere
Hvor utbredt og kjent er den gitte løsningen på markedet? Finnes det flere byråer og utviklere tilgjengelig for å bistå med implementering og vedlikehold?
Partnernettverk
Har leverandøren et bredt og robust nettverk av kvalifiserte partnere for å bistå prosjektet ditt?
Chapter 5
Proof of Concept
Som en siste bemerkning anbefaler vi på det sterkeste at organisasjonen din utfører en proof of concept (PoC). Å gjennomføre en PoC er overlegent alle markedsføringsgimmicker og demonstrasjoner i verden.
I en PoC får du et fungerende produkt i et forsøk på å løse de spesifikke kravene til din organisasjon, og du kan virkelig få stresstestet før du kjøper.
Hver leverandør kan utføre en imponerende demonstrasjon, men det er kanskje ikke den beste måten å lære om et gitt produkt på. Å utføre en PoC gir deg imidlertid muligheten til å lære så mye som mulig om løsningen og hvordan den kan oppfylle dine krav.
