Skriver du stadig produktdata om? Sådan fungerer artikelsynkronisering mellem webshop og ERP i praksis

Den manuelle rutine

Hvert produkt en handlende sælger lever på mindst to steder. Webshoppen — Shopify, WooCommerce, Magento, Centra — behøver det for at sælge. ERP-systemet — Fortnox, Visma, Business Central, Specter — behøver det for at bogføre det, indkjøbe det og tælle det.

Uden en integration betyder ‘lever på to steder’ ‘skrives ind to gange.’ Et nyt produkt oprettes der arbejdet starter — ofte forretningssystemet, hvor indkjøb sker — og derefter genindtastes i webshoppen: navn, SKU, pris, beskrivelse. For en butik der lancerer en håndfuld produkter om året, er det en rutineopgave. For en der lancerer kollektioner, sæsonserier eller et voksende sortiment, er det et gentaget datainputjob med en deadline knyttet til hver lancering.

Den reelle omkostning er afvigelse

Genindtastningen virker som det lille problem. Det dyre er hvad der sker bagefter: to kataloger, vedligeholdt for hånd, holder langsomt op med at stemme overens.

En pris opdateres i ERP-systemet men ikke i butikken — og butikken sælger til den gamle pris indtil nogen bemærker det. En SKU får en stavefejl på den ene side — og fra den dag matcher lagerantal og ordrelinjer for det produkt ingenting. En beskrivelse forbedres i webshoppen — og ændringen lever kun der, usynlig for den der vedligeholder masterdata.

Ingen af disse fejl annoncerer sig selv. Afvigelse er stille af natur: hvert misforhold sidder stille til det dukker op som en forkert pris på en ordre, et lagerniveau der ikke kan passe, eller en times detektivarbejde ved inventartid. Forskningen citeret tidligere i denne serie — Politecnico di Milanos studie af SMV-er med frakoblede systemer — satte fejlraten for manuel datainput til 3–5 %. På et katalog med tusinde artikler er det ikke en afrundingsfejl; det er snesevis af produkter der er stille forkerte.

Et katalog behøver en ejer

Før nogen synkronisering er der en beslutning: hvilket system ejer produktsandheden?

Der er intet universelt svar. For nogle handlende er ERP-systemet masteren — produkter fødes i indkjøb, og webshoppen er en salgskanal der følger. For andre er webshoppen der produkter oprettes, beriges og prissættes, og forretningssystemet følger for bogføring og lager. Begge modeller er legitime; det der ødelægger tingene er at ikke vælge — to systemer hvor hvem som helst kan redigere hvad som helst er sådan afvigelse bliver politik.

Det er grunden til at retning er en førsteklasses indstilling i artikelsynkronisering, ikke en rekonfigurering. Den samme proces kører ERP-til-webshop for én handlende og webshop-til-ERP for den næste — et valg, per proces, besluttet ved onboarding.

Hvad artikelsynkronisering faktisk gør

Med en integrationsplatform mellem systemerne bliver produktkataloget et synkroniseret flow:

1. Et produkt oprettes eller opdateres i mastersystemet. Hvilken side der ejer sandheden — hændelsen er den samme: noget ved en artikel ændrede sig.

2. Ændringen hentes automatisk. Afhængigt af de involverede systemer, via hændelse eller efter en tidsplan — de fleste webshops pusher, de fleste forretningssystemer polles.

3. Artiklen oprettes eller opdateres i det andet system, matchet på SKU. SKU'en er nøglen der binder de to kataloger sammen — hvilket også er grunden til at SKU-disciplin betyder noget: synkroniseringen er præcis ligeså pålidelig som de identifikatorer den matcher på.

4. Et katalog, holdt i overensstemmelse. Nye produkter vises der de skal; ændringer spredes i stedet for at vente på at nogen husker dem.

Hvor det bliver sværere

De ærlige forbehold, som sædvanligt i denne serie:

Nye produkter behøver ikke gå live automatisk. Et forretningssystems artikelregister indeholder normalt mere end webshoppen bør vise — komponenter, interne artikler, udgåede varer. Derfor kan synkede produkter konfigureres til at ankomme i webshoppen som kladder eller deaktiverede, for at nogen gennemgår og publicerer. Synkroniseringen flytter dataene; salgsbeslutningen forbliver menneskelig.

SKU-hygiejne er en forudsætning. Dublerede SKU'er, eller identifikatorer med tegn et system ikke accepterer, er de klassiske grunde til at en artikel fejler i at matche eller synkronisere. En integration afslører disse som fejl — hvilket i praksis ofte gør det til det værktøj der finder katalogproblemer der allerede var der.

Rigt indhold har begrænsninger. Navne, priser og identifikatorer synkroniseres rent. Stærkt formaterede beskrivelser, billeder og kanalspecifikt indhold varierer mere mellem platforme — hvad der overføres afhænger af parringen, og webshop-siden berigelse forbliver ofte webshop-arbejde.

Hvad det betyder i praksis

Produktdata er definitionen af information der bør indtastes én gang og spredes — det er struktureret, regelbaseret, og enhver manuel kopi af det er en fremtidig afvigelse. Kataloget bliver ikke lettere at vedligeholde efterhånden som det vokser; det synkroniseres eller det afviger.

Hvis nye produkter i din virksomhed stadig betyder at skrive de samme felter ind i to systemer — eller hvis du nogensinde har fundet en pris der ikke stemte mellem butikken og bøgerne — er spørgsmålet det samme som denne serie bliver ved med at stille: