Ko v vaš ERP sistem prispe prodajni nalog, so v njem že vse informacije, potrebne za izpolnitev naročila: naslov dostave, postavke, teže in obljubljeni datum dostave. Ko pa se sproži dobava, se vloga sistema konča. Vaša ekipa natisne dobavnico, iz spustnega seznama izbere prevoznika in označi nalog kot odpremljen – čeprav pošiljka še ni bila naročena pri nobenem prevozniku.
Nato mora nekdo odpreti portal prevoznika, vnesti naslov, naročiti pošiljko in tracking številko prekopirati nazaj v ERP. Naslednja pošiljka se obdela enako, le prek drugega portala.
Tako pošiljanje deluje v večini proizvodnih podjetij: delno znotraj ERP-a in delno zunaj njega. Koliko procesa pokriva vaš ERP, je odvisno od sistema, ki ga uporabljate, od tega, kje je nameščen, in od tega, kaj se zgodi ob selitvi na novo različico.
Kaj pokriva modul za pošiljanje v ERP-u in kje se ustavi
Modul za pošiljanje v ERP sistemu je zasnovan za evidentiranje dobav. Dodeli prevoznika, natisne dobavnico in označi nalog kot odpremljen. Če pošiljate domače pakete z enim ali dvema prevoznikoma, je to lahko dovolj.
Nikoli pa ni bil zasnovan za primerjavo cen prevoznikov v realnem času pred naročilom, neposredno naročanje pri prevoznikih, samodejno pridobivanje podatkov o sledenju ali preverjanje prevoznih računov glede na dogovorjene cene. Tega ponudniki ERP sistemov tudi ne nameravajo razviti, saj povezljivost s prevozniki nikoli ni bila del njihove ponudbe. Podrobneje o tem pišemo v članku ERP vs TMS.
Trije načini, kako dodati pošiljanje v ERP
Ko izvorni modul ne zadostuje več, se ekipe navadno odločijo za eno od treh možnosti.
- Nadaljujete z uporabo izvornega modula. Dodeljevanje, tiskanje in odprema ostanejo v ERP-u, vse ostalo pa poteka ročno prek portalov prevoznikov. Ta možnost ne zahteva nobene nastavitve, a prinaša visoke tekoče stroške: izgubljene minute pri vsaki pošiljki in napake, ki ostanejo neopažene, dokler ne pokliče stranka.
- Namestite vtičnik za vsakega prevoznika posebej. Enega za DHL, enega za DSV, enega za regionalnega prevoznika. Vsak deluje brezhibno – dokler prevoznik ne spremeni svojega API-ja, in takrat postane problem vaš. Pri petih prevoznikih vzdržujete pet integracij, sledite petim podatkovnim formatom in hranite pet kontaktov za podporo.
- Nad ERP-om vzpostavite sloj za pošiljanje. ERP povežete s platformo, ki podpira vse prevoznike, in od takrat naprej vzdržujete eno samo povezavo. Dodajanje novega prevoznika postane vprašanje konfiguracije ali zahtevka ponudniku, ne pa nov projekt.
Kako se pošiljanje v ERP-u razlikuje po platformah
Ista pošiljka se obdela različno glede na to, kateri ERP sistem se uporablja. Spodnja tabela prikazuje, kako se to razlikuje med sistemi, ki jih uporablja večina evropskih proizvajalcev:
ERP | Kaj pokriva modul za pošiljanje | Kje se ustavi | S slojem za pošiljanje |
Business Central: špediterji, storitve in dobavnice. F&O dodaja modul za upravljanje prevozov. | Naročanje in primerjava cen nista del paketa, modul F&O pa je sam po sebi obsežen projekt. Večina srednje velikih proizvajalcev ga ocenjuje kot preveč zapletenega za svoje potrebe. | Vnaprej pripravljeni priključki za BC in F&O. Stran prevoznikov je zunaj ERP-a, povezava pa temelji na konfiguraciji, ne na razvoju po meri. | |
SAP | Osnoven dobavni dokument; obstaja obsežen transportni modul, namenjen velikim podjetjem. | Večina proizvajalcev transportnega modula nikoli ne aktivira. Če uporabljate ECC, boste morali na neki točki opraviti selitev (glejte opombo spodaj). | Povezava prek API-ja ali varnega prenosa datotek, ne glede na to, ali je vaš SAP v oblaku ali na lastnih strežnikih. |
Enotna evidenca naročil, zalog in financ v oblaku. | Izvorna podpora prevoznikom je usmerjena predvsem v paketno pošiljanje. LTL in FTL tovorni promet nikoli ni bil v ospredju. | Ena integracija poveže vse prevoznike. SomnoMed je ustvarjanje etiket v Franciji zmanjšal s 90 minut na dan na 20, nato pa nastavitev razširil na ostala evropska vozlišča. | |
Cenovno dostopen in prilagodljiv, z dostavnimi priključki, usmerjenimi predvsem v paketne prevoznike. | Pomanjkljivosti se pokažejo, ko začnete prevažati palete in mešan tovor prek resničnega seznama prevoznikov. | Vnaprej pripravljen Cargosonov priključek vam omogoča razširitev pošiljanja brez vzdrževanja ločenega vtičnika za vsakega prevoznika. | |
Monitor | Načrtovanje proizvodnje, MRP in upravljanje delovnih mest. | Pošiljanje prek več prevoznikov nikoli ni bil njegov namen. | Idealna rešitev je sloj na vrhu, ki skrbi za cene, naročanje, etikete in sledenje ter stroške pošilja nazaj v Monitor. |
ERP v oblaku ali na lastnih strežnikih: kaj to pomeni za pošiljanje
Ko vaš ERP deluje v oblaku, se spremenita dve stvari.
- Ponudnik določa urnik posodobitev. Nove različice se izdajajo po njihovem urniku, ne vašem, zato mora tisti, ki vzdržuje vašo povezavo za pošiljanje, slediti vsaki posodobitvi. Preden podpišete pogodbo, ugotovite, kdo je odgovoren za združljivost.
- Etiketo je treba natisniti na mestu pakiranja. Ne glede na to, ali je ERP v oblaku ali ne, nekdo pri nakladalni rampi potrebuje pravilno etiketo in prevozni dokument. Nastavitev pošiljanja mora te informacije usmeriti na lokalni tiskalnik, ne da bi za vsakega prevoznika ustvarila ločen delovni tok.
Kaj se zgodi s pošiljanjem ob selitvi ERP-a
Situacija je drugačna, če so vaše pogodbe s prevozniki, pravila pošiljanja, etikete in sledenje shranjeni v ločenem sloju in ne v ERP-u. V tem primeru selitev pomeni le preusmeritev ene povezave, ne pa ponovnega vzpostavljanja vsega dela s prevozniki.
Stokker, veletrgovec z orodji in stroji, se je s točno to težavo soočil ob prehodu na nov ERP. Namesto da bi integracijo z vsakim prevoznikom vzpostavljal posebej, je vse prevoznike povezal prek Cargosona, kar je čas nastavitve zmanjšalo s tednov na minute. Zdaj obdelajo 15.000 pošiljk na mesec z le dvema zaposlenima.
Kdo skrbi za pošiljanje v ERP-u dolgoročno
Integracija pošiljanja v ERP ni enkratna nastavitev. ERP sistemi se nadgrajujejo. Prevozniki po svojem lastnem urniku in brez posvetovanja z vami spreminjajo formate etiket, kode storitev in različice API-jev. In oseba, ki ve, kateri portal hrani katero geslo, bo morda nekoč odšla.
Vprašanje torej ni le, ali je povezava vzpostavljena, temveč kdo jo vzdržuje. S slojem za pošiljanje ponudnik centralno vzdržuje povezave s prevozniki. Če prevoznik spremeni svoj API, je to ponudnikova naloga, ne zahtevek za spremembo v vašem ERP-u. Pri Cargosonu je povezljivost s prevozniki del produkta in ne dodatni strošek – in če sodelujete s prevoznikom, ki še ni vključen, ga Cargoson poveže brezplačno.
Celostni pristop in kje izvedeti več
Vaš ERP sistem upravlja nalog. Sloj za pošiljanje na vrhu skrbi za prevoz: cene prevoznikov v realnem času, naročanje, etikete in dokumente, sledenje ter stroške prevoza, tako da finančna evidenca ostane popolna. Vaša ekipa pošiljko vnese le enkrat in ne prek portala.
Naš vodič o integraciji TMS in ERP pojasnjuje, kako se ti podatki prenašajo in katera vprašanja zastaviti ponudniku pred odločitvijo. Ali je vaš ERP modul sam po sebi zadosten, obravnavamo v članku ERP vs TMS. Ta članek opisuje isti sloj z vidika vašega ERP-a.
Cargoson je zasnovan izključno za pošiljatelje, proizvajalce in veletrgovce – ne za prevoznike ali 3PL podjetja. Vsaka funkcija je zasnovana tako, da rešuje težavo logistične ekipe, ne špediterja. Ker je platforma neodvisna in ni v lasti nobenega prevoznika, pogajane cene ostanejo vaše. Vključuje vnaprej pripravljene priključke za Microsoft Dynamics, Dynamics 365 F&O, NetSuite in Odoo ter se poveže z več kot 2.000 prevozniki prek neposrednih API in EDI integracij. Cena se začne pri 199 € na mesec, kar je le delček stroškov klasične implementacije za velika podjetja. In če nimate velike IT ekipe, vas bo pomirilo dejstvo, da stranke v ocenah najvišje ocenjujejo prav podporo.
Preizkusite rešitev s svojimi podatki o ERP-u in prevoznikih, preden se odločite. Rezervirajte brezplačno, nezavezujoče 30-minutno posvetovanje z našimi strokovnjaki. Skupaj bomo pregledali naše funkcije, vašo nastavitev in razpravljali o tem, ali in kako vam Cargoson lahko pomaga.
LinkedIn
Cargoson
