7 tegn på, at kompleksiteten har overtaget din e-commerce

Problemet er bare, at gode grunde også kan hobe sig op. Her ser vi på, hvordan kompleksiteten viser sig i data, systemer, ansvar og den måde, I arbejder på.

På et tidspunkt begynder man at bruge sætninger som: “Det ligger vist i ERP’et.” “Spørg lige udvikling.” “Den integration skal vi helst ikke røre.”

Sådan ser mange modne e-commerce-setups ud. De er blevet bygget videre på i takt med, at forretningen har fået nye behov.

Men når det bliver sværere at forklare, hvor data bor, eller hvad en ændring påvirker, er kompleksiteten begyndt at påvirke måden, I arbejder på. Det er dér, tegnene begynder at vise sig.

Gå fra legacy til moderne e-commerce

1. Fejlfinding er noget af et detektivarbejde

En kunde ser den forkerte pris. Hvor leder du? Måske i ERP. Måske i commerce-platformen. Måske i integrationen mellem de to. Og måske viser det sig, at prisen faktisk er korrekt, men at kundens tilknytning til en bestemt prisgruppe ikke er det.

Det er ikke ualmindeligt, at en B2B-løsning består af flere systemer, der hver især har ansvar for forskellige dele af ordren. Antallet af systemer siger derfor ikke så meget i sig selv. Mere afslørende er det, hvor nemt det er at spore en fejl tilbage til det sted, hvor den opstod.

I et setup med mange afhængigheder kan det være overraskende svært.

Fejlen viser sig ét sted, årsagen ligger typisk et andet sted, og på vejen mellem de to har data måske været igennem flere integrationer. Fejlfinding bliver altså hurtigt en disciplin i at rekonstruere, hvad der egentlig er sket.

Det koster selvfølgelig tid, når noget går galt. Men det fortæller også noget om selve arkitekturen.

Hvis det kræver særlige kolleger og historisk viden at finde ud af, hvorfor en pris eller et produkt ser ud, som det gør, er der sandsynligvis mere kompleksitet i setuppet, end du lige kan se.

1. Fejlfinding er noget af et detektivarbejde

2. Flere versioner af den samme sandhed

Hvilket system bestemmer egentlig produktnavnet? Det burde være et simpelt spørgsmål, der er nemt at svare på.

Alligevel kan det med tiden blive lidt uklart, hvilket system der egentlig bestemmer hvad. Noget vedligeholdes i PIM. Noget kommer fra ERP. Noget kan overskrives i commerce-platformen. Og enkelte felter lever måske stadig i Excel, fordi det engang var den mest praktiske løsning.

Det samme kan ske med priser, lager, kunder, rabatter og ordrestatus.

Problemet opstår, når flere systemer har hver deres version af det samme. Så bliver selv små ændringer sværere at gennemskue, og fejl bliver sværere at spore tilbage til kilden.

Data må gerne ligge flere steder. Det afgørende er, at der stadig er et klart svar på, hvilket system der bestemmer hvad.

Det er især vigtigt, når flere teams arbejder med de samme data. For hvis én person retter i PIM, en anden i ERP og en tredje direkte i commerce-platformen, kan hurtigt ende med at rette symptomet ét sted uden at have løst årsagen.

3. Undtagelser får deres egne undtagelser

B2B er ofte fyldt med særlige regler for dette og hint. Og med god grund. Nogle kunder har særlige priser. Andre kunder må købe bestemte produkter, mens en tredje kundegruppe skal igennem et andet ordreflow.

Men du skal være nysgerrig, når undtagelserne også begynder at have undtagelser.

“Det gælder alle kunder i den gruppe, bortset fra dem med den gamle aftale.” “Den pris kommer fra ERP, medmindre varen tilhører den her kategori.”

Hvis forklaringen på en funktion indeholder “bortset fra”, “medmindre” og “lige præcis for dem her”, ville jeg stoppe op.

Kompleksiteten begynder for alvor at vokse, når en regel kun giver mening, hvis du også kender alle undtagelserne.

Forretningsregler skal selvfølgelig kunne være avancerede. Men jo flere undtagelser, der bliver bygget oven på tidligere undtagelser, desto sværere bliver løsningen at gennemskue, teste og ændre sikkert.

3. Undtagelser får deres egne undtagelser

4. Når du ikke ved, hvad en ændring påvirker

I et komplekst setup er det normalt, at systemerne hænger sammen. Problemet opstår, når det bliver svært at forudsige, hvad der følger med, når du ændrer noget.

En justering i produktdata kan påvirke en integration. Den kan igen påvirke regler i commerce-platformen eller data længere nede i flowet. Derfor bliver selv små ændringer hurtigt noget, der kræver ekstra test og flere mennesker omkring sig.

Det fortæller en del om, hvor godt I kender afhængighederne i arkitekturen.

Hvor meget skal dit team undersøge, før de tør ændre noget? Hvis svaret ofte er ‘en hel del’, bruger I allerede tid på usikkerheden, før selve ændringen er gået i gang.

Og usikkerheden gør noget ved måden, man arbejder på. Man tester bredere, involverer flere og bliver mere forsigtig. Konsekvenserne er simpelthen blevet sværere at forudsige.

Det afgørende er, om I kan forudsige konsekvenserne, når noget ændrer sig.

4. Når du ikke ved, hvad en ændring påvirker

5. Flere systemer løser næsten det samme

Det her sker oftere, end du måske tror.

Man køber en app, fordi der lige mangler en funktion. Senere får commerce-platformen noget af det samme som standard. En gammel specialløsning får lov at leve, fordi den stadig løser en lille del af opgaven. Og pludselig har man flere steder, der kan næsten det samme.

Så kommer spørgsmålene. Hvilken løsning bruger vi egentlig? Hvilken skal vi investere videre i? Hvor vedligeholder vi data? Og kan vi slukke noget uden at skabe problemer et andet sted?

Det er ofte her, kompleksiteten sniger sig ind. Udfordringen er, at der aldrig rigtig bliver taget stilling til, om alt det gamle skal ud igen.

Det er jo typisk meget nemmere at tilføje endnu en løsning end at beslutte, om noget kan undværes.

Og hvis nyt konsekvent kommer ind, mens gammelt får lov at blive for en sikkerheds skyld, ender systemlandskabet med at vokse.

Et sundt setup skal også kunne tåle, at man fjerner noget.

5. Flere systemer løser næsten det samme

6. Det er uklart, hvem der har ansvaret

E-commerce-teamet kender platformen. IT kender integrationerne. ERP-teamet har styr på ERP. Og måske er der også eksterne leverandører, som hver især kender deres del af løsningen rigtig godt.

Det fungerer fint, så længe opgaven holder sig inden for de enkelte områder.

Men det gør e-commerce bare ikke altid.

En fejl i webshoppen kan skyldes data fra ERP. Et problem med produktinformationen kan ligge et sted mellem PIM og commerce-platform. Og en ændring, der ser teknisk ud, kan ende med at påvirke en arbejdsgang hos salg eller kundeservice.

Så begynder det at blive lidt mere uklart, hvem der egentlig tager den videre.

Det er en af de mere menneskelige konsekvenser af et komplekst systemlandskab. Jo flere systemer, teams og leverandører der er involveret, desto flere overgange er der også mellem dem. Det er ofte i overgangene, at ansvaret falder mellem stolene.

Og det er typisk også der, opgaver begynder at tage længere tid. Ofte fordi flere først skal finde ud af, hvem der egentlig skal gøre hvad. Den slags koordinering er nemt at overse, når man vurderer kompleksiteten i et setup.

Og så melder et andet spørgsmål sig: Hvem har egentlig overblikket over det, der sker mellem systemerne?”

7. Ingen er helt sikre på, hvad der kan fjernes

Forestil dig, at du støder på en gammel integration, et script eller en service, som tilsyneladende ikke længere er i brug. Kan du slukke den?

Eller tør du ikke, fordi du ikke helt ved, om den bliver brugt længere. Det er faktisk et ret godt tegn på kompleksitet.

For systemlandskabet består ikke kun af det, I aktivt bruger. Det består også af gamle forbindelser, logik og komponenter, som ingen længere er helt sikre på, om nogen stadig er afhængige af.

Og så bliver det svært at rydde op.

Det er ofte sådan teknisk kompleksitet får lov til at blive hængende. Du ved godt, at noget ser overflødigt ud. Du ved bare ikke nok til at turde tage det væk.

Et godt setup skal du kunne bygge videre på, men du skal også turde rydde op i det.

Se alle services inden for integration og dataflow

7. Ingen er helt sikre på, hvad der kan fjernes

Hvor komplekst er for komplekst?

Det er svært at sætte et tal på. Ti integrationer kan fungere helt gnidningsfrit, mens tre kan give hovedpine hver uge. Det samme gælder apps, specialudvikling og forretningsregler.

Så antallet siger ikke så meget i sig selv.

Mere afslørende er det, hvor nemt du kan svare på de helt almindelige spørgsmål: Hvor kommer den her pris fra? Hvad sker der, hvis vi ændrer det her? Hvem tager den videre, når problemet går på tværs af systemer? Bruger vi stadig den integration? Kan vi slukke den?

Hvis svarene kræver, at du leder i gammel dokumentation eller finder den ene kollega, der kan huske, hvorfor noget blev bygget sådan i sin tid, så har kompleksiteten allerede fået en lidt for stor betydning.

Og det er måske også en nemmere måde at tænke kompleksitet på. En moden B2B-forretning må gerne have et avanceret setup. Der kan være gode grunde til både særregler, integrationer og specialudvikling.

Men du og dit team skal stadig kunne finde rundt i det.

Så i stedet for at starte med et stort oprydningsprojekt, kan det give mening at begynde der, hvor overblikket mangler. Få styr på, hvilket system der bestemmer hvad. Få tegnet de vigtigste afhængigheder op. Find ud af, hvem der tager ansvaret, når noget går på tværs. Og tag fat i de steder, hvor svaret lidt for ofte er: “Det ved jeg faktisk ikke helt.”

Der dukker sikkert både ting op, der skal blive, ting der kan forenkles, og noget, hvor du ærligt må spørge: Bruger vi overhovedet det her længere?

Det er nok en meget god målestok for kompleksiteten: Har du og dit team stadig styr på, hvorfor jeres setup ser ud, som det gør?

Gå fra legacy til moderne e-commerce

FAQ

Hvad skaber kompleksitet i et e-commerce-setup?

Kompleksitet opstår typisk, når flere systemer, integrationer, specialtilpasninger og forretningsregler skal arbejde sammen. I B2B e-commerce kan et setup eksempelvis bestå af en commerce-platform, ERP, PIM, CRM, betalingsløsninger og en række integrationer mellem dem. Det er ikke nødvendigvis et problem. Kompleksiteten bliver først en udfordring, når det bliver svært at forstå afhængighederne, placere ansvaret eller gennemføre ændringer uden at påvirke andre dele af løsningen.

Hvornår er et e-commerce-setup for komplekst?

Antallet af systemer eller integrationer afgør ikke i sig selv, om et setup er for komplekst. Et avanceret systemlandskab kan fungere effektivt, hvis ansvar, data og afhængigheder er tydelige. Tegn på for stor kompleksitet kan være vanskelig fejlfinding, uklart dataejerskab, mange undtagelser, overlappende systemer og usikkerhed om konsekvenserne ved ændringer.

Hvordan skaber integrationer kompleksitet i B2B e-commerce?

Integrationer forbinder typisk commerce-platformen med blandt andet ERP, PIM og CRM og er derfor ofte nødvendige i B2B e-commerce. Kompleksiteten opstår, når der er mange afhængigheder mellem systemerne, eller når det er uklart, hvor data kommer fra, og hvad der sker, hvis noget ændres.

Hvilket system skal eje data i et e-commerce-setup?

Det afhænger af jeres arkitektur og forretning. Det vigtige er, at der er et klart defineret source of truth for de forskellige typer data. ERP kan eksempelvis være master for priser og lager, mens PIM er master for produktinformation. Commerce-platformen bruger derefter data fra de systemer.

Hvordan reducerer man kompleksiteten i en e-commerce-løsning?

Start med at skabe overblik, før I begynder at fjerne systemer eller integrationer. Kortlæg de vigtigste systemer, dataflows, integrationer og forretningsregler og identificér, hvem der ejer de enkelte områder. Derefter kan I undersøge, hvor funktionalitet overlapper, hvilke specialtilpasninger der stadig skaber værdi, og om gamle integrationer eller komponenter kan fjernes.

Hvad er forskellen på nødvendig kompleksitet og teknisk gæld?

Nødvendig kompleksitet udspringer af reelle forretningsbehov. Det kan eksempelvis være kundespecifikke priser, forskellige markeder, produktkataloger eller avancerede ordreflows. Teknisk gæld opstår derimod, når tidligere tekniske valg, workarounds og specialløsninger gør løsningen vanskeligere at vedligeholde eller ændre. De to kan eksistere samtidig. Derfor bør målet ikke være at fjerne al kompleksitet, men at skelne mellem den, der skaber forretningsværdi, og den, der primært skaber ekstra arbejde.

Skal man skifte e-commerce-platform for at reducere kompleksiteten?

Ikke nødvendigvis. Kompleksiteten kan ligge i integrationerne, dataarkitekturen, specialudviklingen eller arbejdsprocesserne omkring platformen frem for i selve e-commerce-platformen. Derfor bør I kortlægge den eksisterende arkitektur og finde årsagerne til kompleksiteten, før I beslutter jer for et platformsskifte.

Vis mere

Hvor gemmer kompleksiteten sig hos jer?

Måske er det integrationerne. Måske data, specialudvikling eller arbejdsgange, der er vokset frem over tid. Vi hjælper med at kortlægge jeres e-commerce-setup og finde ud af, hvad der fortsat skaber værdi.