Syötätkö tuotetietoja vieläkin uudelleen? Näin artikkelisynkronointi webshoppin ja ERP:n välillä toimii

Manuaalinen rutiini

Jokainen tuote, jota kauppias myy, elää vähintään kahdessa paikassa. Verkkokauppa — Shopify, WooCommerce, Magento, Centra — tarvitsee sen mydäkseen. ERP-järjestelmä — Fortnox, Visma, Business Central, Specter — tarvitsee sen kirjatakseen sen, ostaakseen sen ja laskeakseen sen.

Ilman integraatiota ‘elää kahdessa paikassa’ tarkoittaa ‘kirjoitetaan kaksi kertaa.’ Uusi tuote luodaan siellä missä työ alkaa — usein toiminnanohjausjärjestelmässä, jossa ostot tapahtuvat — ja sitten syötetään uudelleen verkkokauppaan: nimi, SKU, hinta, kuvaus. Kaupalle, joka lanseeraa muutaman tuotteen vuodessa, se on pakollinen vaiva. Kaupalle, joka lanseeraa kokoelmia, sesonkisarjoja tai kasvavaa valikoimaa, se on toistuva tiedonsyöttötyö, johon liittyy määräaika jokaisen lanseerauksen yhteydessä.

Todellinen kustannus on ajautuminen

Uudelleensyöttäminen vaikuttaa pieneltä ongelmalta. Kallis asia on se mitä tapahtuu sen jälkeen: kaksi luetteloa, käsin ylläpidettyinä, lakkaavat hitaasti pitämästä yhtä.

Hinta päivitetään ERP:ssä mutta ei kaupassa — ja kauppa myy vanhaan hintaan kunnes joku huomaa sen. SKU saa kirjoitusvirheen toisella puolella — ja siitä päivästä lähtien varastomäärät ja tilausrivit eivät täsmää mihinкään. Kuvaus parannetaan verkkokaupassa — ja muutos elää vain siellä, näkymättömissä sille joka ylläpitää perustietoja.

Mikaan näistä virheistä ei ilmoita itsestään. Ajautuminen on luonteeltaan hiljaista: jokainen ristiriita istuu hiljaa kunnes se ilmenee väärässä hinnassa tilauksessa, varastotasossa joka ei voi pitää paikkaansa, tai tunnin etsivöintityönä inventaarion aikaan. Aiemmin tässä sarjassa mainittu tutkimus — Politecnico di Milanon tutkimus pk-yrityksistä irrallisilla järjestelmilllä — asetti manuaalisen tiedonsyötön virheasteeksi 3–5 %. Tuhansien artikkelien luettelossa se ei ole pyöristysvirhe; se on kymmeniä tuotteita, jotka ovat hiljaa väärin.

Yksi luettelo tarvitsee yhden omistajan

Ennen mitään synkronointia on päätös: kumpi järjestelmä omistaa tuotetotuuden?

Universaalia vastausta ei ole. Joillekin kauppiaille ERP on pääjärjestelmä — tuotteet syntyvät ostoissa, ja verkkokauppa on myyntikanava joka seuraa. Muille verkkokauppa on paikka jossa tuotteet luodaan, rikastetaan ja hinnoitellaan, ja toiminnanohjausjärjestelmä seuraa kirjanpitoa ja varastoa varten. Molemmat mallit ovat oikeutettuja; mikä rikkoo asiat on valinnan tekemättä jättäminen — kaksi järjestelmää joissa kuka tahansa voi muokata mitä tahansa on se miten ajautumisesta tulee käytäntö.

Siksi suunta on ensiluokkainen asetus artikkelisynkronoinnissa, ei uudelleenrakennus. Sama virta kulkee ERP:stä verkkokauppaan yhdelle kauppiaalle ja verkkokaupasta ERP:hen seuraavalle — valinta, per virta, päätetty käyttöönottovaiheessa.

Mitä artikkelisynkronointi oikeasti tekee

Kun integraatioalusta on järjestelmien välissä, tuoteluettelosta tulee synkronoitu virta:

1. Tuote luodaan tai päivitetään pääjärjestelmässä. Kumpi puoli omistaa totuuden — tapahtuma on sama: jotain artikkelin osalta muuttui.

2. Muutos noudetaan automaattisesti. Riippuen mukana olevista järjestelmistä, tapahtuman kautta tai aikataulun mukaan — useimmat verkkokaupat lähettävät, useimpia toiminnanohjausjärjestelmiä kyselään.

3. Artikkeli luodaan tai päivitetään toiseen järjestelmään, sovitettuna SKU:lla. SKU on avain joka sitoo kaksi luetteloa yhteen — minkä vuoksi myös SKU-kurinalaisuüs on tärkeää: synkronointi on täsmälleen yhtä luotettava kuin identifikaattorit joilla se sovittaa.

4. Yksi luettelo, pidetty yhdenmukaisena. Uudet tuotteet ilmestyvät sinne minne pitää; muutokset leviavät sen sijaan että joku joutuisi muistamaan ne.

Missä se muuttuu vaikeammaksi

Rehelliset varaumat, kuten tavallisesti tässä sarjassa:

Uusien tuotteiden ei tarvitse mennnä suoraan julkiseksi. Toiminnanohjausjärjestelmän artikkelirekisteri sisältää yleensä enemmän kuin verkkokaupan pitäisi näyttää — komponentteja, sisäisiä artikkeleita, käytöstä poistettuja tuotteita. Siksi synkronoitavat tuotteet voidaan konfiguroida saapumaan verkkokauppaan luonnoksina tai poistettuina käytöstä, jotta joku tarkistaa ja julkaisee. Synkronointi siirtää datan; myyntipäätös pysyy ihmisenä.

SKU-hygienia on ennakkoedellytys. Duplikaatti-SKU:t tai identifikaattorit merkeilllä joita järjestelmä ei hyväksy ovat klassisia syitä siihen miksi artikkeli ei onnistu täsmäyttämään tai synkronoimaan. Integraatio paljastaa nämä virheiksi — mikä käytännössä usein tekee siitä työkalun joka löytää luettelo-ongelmia jotka olivat jo olemassa.

Rikkaalla sisällöllä on rajoitukset. Nimet, hinnat ja identifikaattorit synkronoituvat siististi. Raskaasti muotoillut kuvaukset, kuvat ja kanavakohtainen sisältö vaihtelevat enemmän alustojen välillä — mitä siirretään riippuu parinnuksesta, ja verkkokauppapuolen rikastaminen pysyy usein verkkokauppatyönä.

Mitä tämä tarkoittaa käytännössä

Tuotedata on tiedon määritelmä joka pitäisi syöttää kerran ja levittää — se on rakenteellista, sääntöpohjaista, ja jokainen manuaalinen kopio siitä on tuleva ristiriita. Luettelo ei muutu helpommaksi ylläpitää kasvaessaan; se synkronoidaan tai se ajautuu.

Jos uudet tuotteet yrityksessäsi tarkoittavat vieläkin samojen kenttien kirjoittamista kahteen järjestelmään — tai jos olet koskaan löytänyt hinnan joka ei täsmää kaupan ja kirjanpidon välillä — kysymys on se jonka tämä sarja pitää esittämässä: