Derfor skal I prioritere fleksibilitet, når I bygger ny ecommerce-platform

De fleste der arbejder med ecommerce ved godt, at "i dag" sjældent danner grundlag for "i morgen". Der kommer konstant nye teknologier, nye markeder og dermed nye muligheder.

For at man kan gribe nye muligheder, skal man være i stand til at tilpasse sit eksisterende systemlandskab. Jo hurtigere udviklingen går, desto hårdere rammes de virksomheder, der har opbygget it-arkitekturer uden fleksibilitet.

En fleksibel it-arkitektur er en arkitektur, hvor forældede/dårligt performende/utilstrækkelige elementer kan udskiftes med nye, værdiskabende elementer.

Engagér dig i arkitekturvalg, og få et fremtidssikret setup

It-branchen er storproducenter af smarte forkortelser. Og det gør det mere krævende at engagere sig i arkitekturvalg, end det behøver at være.

Blandt de begreber, der fylder mest i samtalen i dag, kan vi fx nævne ”Composable DxP”, ”Headless”, ”Microservices”, ”MACH” {link til MACH her} og ”JAMStack”.

Begreber som dem vi nævner herover, er typisk opfundet i god tro. Af konsulenter. Som os. Indrømmet.

Typisk bliver begreberne opfundet og anvendt med et ønske om at hjælpe vores kunder med at træffe en oplyst beslutning, når de skal investere i nye it-løsninger.

I bund og grund bruger vi begreberne i et forsøg på at opfordre dig til, at du som systemejer involverer dig i de meget vigtige arkitekturvalg, der skal træffes, når I køber ny it-løsning.

Vores hypotese er, at mange it-projekter ender galt, fordi købersiden kun evaluerer featurelisten. Dermed går vigtige nuancer af valget tabt - fx hvordan valget af platform påvirker den samlede arkitektur, og mulighederne for at gribe nye muligheder i fremtiden.

Fra vores side af bordet oplever vi desværre ofte, at kunder vælger den lette udvej ”PLATFORM X – does it all at half the price”, da det er billigst at købe ind hos en one-stop-shop. I samme omgang får man endda alle sine feature-ønsker opfyldt. Smart!

Problemet med ”PLATFORM X”-løsninger er bare, at du typisk kun ender med at kigge på feature-listen og prisskiltet, og ikke på de bagvedliggende tekniske betingelser for fx skalering, integration og tilpasning, som platformen giver. Med andre ord får du en løsninger, der i dette øjeblik er tilstrækkelig, men der om et år eller to bliver en klods om benet for nye ambitioner.

Og det viser sig ofte, at der ikke findes en silver bullet – der er næsten altid ønske om og behov for tilpasninger og konfiguration af den nye platform.

De dyre lærepenge

Skrækscenariet er naturligvis, at I bruger værdifuld tid på at bygge en løsning, der er forældet inden den er færdig. Det kan fx være, at jeres virksomhed meget pludseligt finder det nødvendigt at gå ind i et nyt marked eller at supportere en ny kanal. Hvis jeres løsning ikke understøtter dette, eller blot understøtter dette på en uhensigtsmæssig måde, brænder i nallerne. Og dermed er hele den besparelse i gjorde i første omgang tabt på gulvet. Det er dyre lærepenge.

Vi forstår godt, at det er svært at navigere i den konsulentgenererede floskel-jungle. Vi holder dog fortsat fast i, at det er vigtigt at forsøge alligevel!

Før vi dykker ned i arkitekturvalg og begrebsafklaring, er det måske meget sundt, at vi præsenterer et eller andet overblik over den proces, en ecommerce-platform understøtter.

Vi køber ikke it-systemer fordi de har et flot navn, eller fordi de er sjove at bruge (selvom det hjælper!). Vi køber dem fordi de skal hjælpe os med at udføre en række opgaver.

I den forbindelse har ByteByteGo lavet en glimrende kortlægning af de processer, en ecommerce-platform typisk understøtter i større eller mindre omfang:

Fra en kunde besøger din side, til han/hun har sin ordre i hånden, skal platformen altså hjælpe med:

• Håndtering af produkter
• Håndtering af priser
• Visning af produkter og priser
• Håndtering af kampagner
• Lagerstyring
• Brugerhåndtering
• Kasse og kurv
• Ordrehåndtering
• Betalingssystem
• Shipping og transport

Disse funktioner og flere til, er altså omdrejningspunktet for de processer, en ecommerce-platform skal understøtte.

Valget af ecommerce-platform er i sagens natur meget vigtigt, da den bliver central for en lang række processer, data og i sidste ende kundeoplevelser. Alt sammen faktorer der er afgørende for jeres salg og branding.

En af de første overvejelser I bør gøre jer, at overvejelsen omkring ”samlet platform” vs ”komponentbaseret platform, som I selv bygger.  

I fagsprog kalder vi dette for valget mellem ”” og ”Best of Breed”, og der er selvsagt fordele og ulemper ved begge.

Der findes hverken rigtige eller forkerte it-løsninger. Der findes kun forkerte arkitekturvalg. Hvor en løsning er den helt rigtige for en type virksomhed, vil den være håbløs for en anden.

Når vi ser på hvilke arketyper, der findes på markedet for ecommerce-arkitekturer, ser vi i den ene ende af skalaen suiterne – de store platforme der tilbyder en komplet ecommerce-pakke uden brug af tredjepartsløsninger. Alle features i én pakke.

I den anden ende af skalaen har vi de skræddersyede platforme (”Best of Breed”), hvor hver funktion på platformen er  stand-alone løsninger (fx CMS, betalingsmodul, CRM og hosting), der sættes sammen til en komplet platform. Det vil sige, at CMS, betalingsmodul, CRM, PIM osv. udveksler data via API’er (et kommunikationsinterface systemer imellem). Vi vælger med andre ord det mest egnede system indenfor hver ”breed” (”race” på dansk).

Imellem disse to arketyper findes der et hav af varianter. I kan fx vælge at have 80% af jeres funktioner samlet i en suite, hvortil I bygger de resterende 20% (fx CMS’et) ind i løsningen. Det kan være en god middelvej, der sikrer at jeres forretningsbehov bliver mødt.

Derfor skal I vælge Best of Suite:

• I er villige til at gå på kompromis med jeres mulighed for at tilpasse løsningens funktioner, og kan leve med de vilkår for brug platformen ”fødes” med fra leverandørens side.
• I ønsker en løsning, der kræver mindre udvikling
• I gerne vil have det kortest mulige forløb frem mod lancering af jeres løsning

Derfor skal I vælge Best of Breed:

• I vil frigøre jer fra en suite, der har et teknisk roadmap (udviklingsplan for features og kernefunktioner), der ikke nødvendigvis går samme vej som jer
• I forstår at teknologien og jeres forretning udvikler sig, og ønsker frihed til at jeres ecommerce-platform følger med i et tempo, som I bestemmer
• I er villige til at investere ekstra midler her-og-nu til at bygge platformen med de komponenter og tjenester, som I har udvalgt
• I kan leve med en mere kompleks proces frem mod lancering af jeres platform – til gengæld med øget chance for, at de løbende omkostninger er lavere
• I ønsker en platform der kan understøtte en hastig skalering

Software er et uendeligt fleksibelt materiale, der kan formes og farves, som vi vil.

Det store spørgsmål ved udvikling af nye software bliver derfor som regel også, hvordan tid, pris eller kvalitet, påvirker graden af valgfrihed, I har i valget af en ny løsning.

Er budgettet ikke ret stort, kan en samlet pakkeløsning, typisk være en god løsning. Er

For at finde ud af hvor på skalaen I befinder jer (skal I vælge den samlede, den skræddersyede, eller en variant midt imellem?), er det fornuftigt at kigge på, hvad I allerede har af teknologier i jeres systemlandskab.

Ligesom det kan være en god idé at skifte gammel, utilstrækkelig teknologi ud, kan det også være en fordel at holde fast i de teknologier og løsninger, der enten er funktionelt tilstrækkelige (nogle bevægelige dele er ikke altid vigtige at udskifte ”bare fordi man kan”), eller er særligt værdiskabende.

Har I fx både et PIM- og et ERP-system i jeres nuværende arkitektur, som I ønsker at tilføje et commerce-lag ovenpå, er det ofte forhastet at investere i en suite, hvor de gamle løsninger enten skal skrottes eller have deres data migreret over I en ny løsning.

Når vi ser virksomheder vælge Suite-vejen, er forklaringen vi hører oftest, at kunden ”[…] gerne vil have det hele samlet i én løsning”, hvilket som nævnt også har sine fordele. Nuvel - det er typisk lidt dyrere, fordi data fra det gamle CMS eller den gamle PIM-løsning nu skal flyttes over på den nye platform, der ”kan det hele”, og den omkostning må man så æde.

Men lad os være ærlige – de fleste ender med kun at bruge halvdelen af de features, den nye platform tilbyder. Det kan også være fint nok, hvis man er villig til at acceptere, at man da betaler for funktionalitet, man ikke bruger.

I stedet for at tænke sin løsning som én stor one-size-fits-all platform, vil vi netop gerne slå et slag for, at man overvejer en mere eksperimenterende tilgang, som vi her vælger at kalde Minimum Viable Product-tankegangen (ja, undskyld for endnu et begreb),.

Tilgangen understøtter, at der KUN udvikles lige netop den funktionalitet, der er behov for her og nu. Dertil bygges der altid videre på den eksisterende arkitektur og de systemer, der allerede er.

Det er altså i tråd med den klassiske leg om prioritering af features der er ”need-to-have” vs. ”nice-to-have”.

Formålet med MVP-metoden er, at vi lærer os selv at sige ”Lad os få søsat noget der virker, og derefter kan vi arbejde videre på løsningen, ud fra det vi lærer i første iteration”.

Hvis du allerede har et PIM- og et ERP-system, så lad os blot bygge en ”Kurv” og et checkout-flow oven på. Måske virker det i første omgang. Måske fejler det miserabelt. Uanset hvad der sker, får vi hurtigt nogle erfaringer med afsæt i et komplet system.

Denne tilgang giver fleksibilitet, frihed og typisk også mindre udgifter til omkostningstunge licenser. Samtidigt giver det mulighed for at teste jeres hypoteser. I får altså be- eller afkræftet, om jeres prognoser og krav nu også er afspejlet i den faktiske brug af løsningen:

• Sparer vi tid i de forventede processer?
• Gjorde løsningen XYZ lettere/mere effektivt?
• Kunne vi sælge X til Y, eller var der nedbrud i processen?

Når vi nøjes med at bygge lige netop det, vi har brug for med en så lille investering som muligt – ja, så frigives ressourcer som regel også. Og de ressourcer kan så bruges på tests eller tilpasning af nye features.

Så skal I blot bruge en håndfuld simple features, så siger vores erfaring os, at det er billigere og mere fleksibelt at vælge en MVP-tilgang.

De første trin i processen kunne derfor med fordel være som følger:

1. Kortlæg jeres eksisterende it-landskab – hvad har I? Hvad virker? Hvad virker ikke så godt?
2. Hvor meget skal skiftes ud? – skal alting skiftes ud, bør I overveje fordele og ulemper ved en Suite. – fungerer jeres eksisterende løsninger, bør I identificere de største ”huller”
3. Evaluér mulige løsningsmodeller – er suiten eller den skræddersyede platform umiddelbart det mest oplagte valg
4. Skitsér den nye arkitektur, og søg sparring på jeres visioner og ambitioner

Uanset om I vælger en ren Best of Breed-løsning, eller om I tager udgangspunkt i en komplet ecommerce-suite, som I selv tilpasser, bør I starte med KUN at gøre lige netop nok til, at I kan teste jeres vigtigste hypoteser.

Hos PicoPublish har vi fx gode erfaringer med at bruge ”Proof of Concepts” som motoren i en MVP-tilgang. Her udvælger vi en håndfuld processer, kategorier og systemer der vurderes til at være centrale for succesen af jeres nye platform. Herefter bygger vi med mindst mulig indsats en version af platformen, som vi derefter tester. Det giver os en række gode erfaringer, og sparer jer tid og penge på sigt.

Uanset om udgangspunktet er en simpel commerce-løsning eller en kompleks multi-market løsning, vil vi anbefale, at I forsøger at bygge MVP’en på baggrund af den nuværende arkitektur.

Den rigtige arkitektur for jer, er nødvendigvis den arkitektur, hvor I med færrest ressourcer bliver i stand til at gribe de muligheder, der skaber værdi for jeres forretning. Og dette skal gøres UDEN at kompromittere jeres evne til at gribe de nye muligheder, der måtte opstå i morgen.

Risikoen ved at købe store og dyre standardløsninger er og bliver, at I skal gå på kompromis med jeres fleksibilitet, hvilket ender med at spænde ben for jeres mulighed for at reagere på ændringer i markedet.

Virkeligheden byder i 2022 på, at der skal håndteres mere data, flere komplekse data og understøttes flere kanaler. Af den grund ender vi ofte med at anbefale en arkitektur, der bygger på MACH-principperne.

Det gør jeg udsatte overfor konkurrenter i markedet, der hurtigt kan flytte fokus og features.

Flere udbydere af suite-løsningerne er dog ved at modernisere deres platforme, og har indset, at de skal gøre det muligt fx at tænde/slukke for moduler på platformen. Det vil blandt andet betyde, at de virksomheder der har investeret mange penge i deres suite-løsning, ikke er tvunget til at skrotte HELE deres løsning.

Denne snak om arkitekturvalg er ikke kun knyttet til valg af ecommerce-platforme.

De præcist samme principper kan anvendes ved valg af CMS, når I fx bygger en ny kundeportal, et nyt kundecenter eller noget helt tredje. Lige netop i forhold til valg af CMS, der fortsat er vigtigt værktøj i forhold til indholdsredigering, opfordrer vi i dag til, at det er dine redaktører og understøttelse af deres processer, der skal være afgørende for, hvilket CMS du vælger.

Igen

Den rigtige arkitektur for jer, kunne altså både være bygget med afsæt i fx et gratis Umbraco CMS, der tilbyder et brugervenligt redaktørinterface, eller det kunne være en DynamicWeb-løsning hvor CMS-funktionalitet kan udvides med fx PIM og ecommerce-features.

Igen er vores anbefaling, at I bygger en MVP, så I ikke bygger hele ”rumraketten” på et forkert grundlag. Med en MVP eller POC får vi sammen mulighed for at finde ud af:

• hvordan en ny løsning kan blive bedre end udgangspunktet
• hvor stort budget der er nødvendigt, for at indfri jeres mål
• hvor de største risici (og muligheder) er i projektet
• hvilke dele af den eksisterende infrastruktur, der eventuelt skal bibeholdes

Når I skal vælge ny ecommerce-platform, er desværre ikke så simpelt, at der er en ”one size fits all”-løsning. Når det kommer til valg af ny teknologi og nye it-systemer, skal I være superfokuserede på at kortlægge jeres behov så præcist som muligt, så I ved, hvad en ny løsning skal kunne, og hvilke funktioner der er vigtigst.

Først og fremmest skal I passe på med at være ukritiske i forhold til suite-udbydernes løfter om, hvordan alle de hundredvis af features de har, er lykken. Specielt hvis I rent faktisk kun har behov for fem af disse.

Her kan suiten så hævde at være ”fremtidssikret” - for skulle behovet opstå, så er der jo 95 andre features, der kan tages i brug. Desværre oplever vi sjældent, at det er så nemt.

Hvis I ønsker at fremtidssikre jeres ecommerce-platform, er vores bedste bud, at I investerer i et fleksibelt setup, der tillader jer at tilføje ny funktionalitet på jeres præmisser. Det vil sige når I skal bruge dem, uden behov for at ændre hele platformen og uden at gå på kompromis med funktionaliteten. Dermed slipper I for at vente på store releases fra udbyderen af den suite, I ellers kunne have bundet jer til.

I nogle tilfælde kan en ecommerce-suite dog være et godt valg. Hvis I har en klar forventning om, at jeres behov forbliver nogenlunde uændrede, og kan leve med at være mindre digitalt manøvredygtige, så kan en suite være et godt udgangspunkt. I får mulighed for at holde jeres omkostninger lave, og får løbende tilbudt nye funktioner, som suiterne beslutter at opdatere deres platform med nye features.