Kui müügitellimus saabub ERP-süsteemi, on kõik selle täitmiseks vajalik info juba olemas: tarneaadress, tooteread, kaalud ja lubatud tarnekuupäev. Kuid niipea kui tarne käivitatakse, lõpeb süsteemi roll. Meeskond prindib saatelehe, valib rippmenüüst vedaja ja märgib tellimuse lähetatuks — kuigi saadetist pole tegelikult kellegagi veel tellitud.

Seejärel peab keegi avama vedaja portaali, sisestama aadressi, esitama veotellimuse ja kopeerima jälgimisnumbri ERP-i tagasi. Järgmine saadetis käib täpselt samamoodi, lihtsalt teise portaali kaudu.

Nii toimib veoprotsess enamikus tootmisettevõtetes: osaliselt ERP-is, osaliselt väljaspool seda. Kui suures ulatuses ERP protsessi katab, sõltub kasutatavast süsteemist, selle hostimisviisist ja sellest, mis juhtub uuele versioonile üleminekul.


Mida ERP-i veomoodul teeb ja kus see peatub

ERP-i veomoodul on loodud tarnete registreerimiseks. See määrab vedaja, prindib saatelehe ja märgib tellimuse lähetatuks. Kui saadate kodumaiseid pakke ühe-kahe vedajaga, võib sellest piisata.

Kuid moodul pole kunagi mõeldud selleks, et enne veotellimuse esitamist võrrelda vedajate reaalajas hindu, tellida vedu otse vedajatelt, tõmmata automaatselt sisse jälgimisandmeid ega kontrollida veoarveid kokkulepitud hindade suhtes. ERP-i tarnijad ei plaani neid funktsioone ka lisada — vedajate ühendamine pole kunagi olnud nende toote osa. Lähemalt käsitleme neid puudujääke artiklis ERP vs TMS.


Kolm võimalust veo lisamiseks ERP-i

Kui standardmoodul enam ei piisa, valivad meeskonnad tavaliselt ühe kolmest võimalusest.

  • Jätkata standardmooduli kasutamist. Vedaja määramine, printimine ja lähetamine jäävad ERP-i. Ülejäänu toimub käsitsi vedajate portaalides. See ei nõua seadistamist, kuid toob kaasa suured jooksvad kulud: minutid, mis iga saadetisega kaovad, ja vead, mida märgatakse alles siis, kui klient helistab.
  • Paigaldada igale vedajale eraldi plugin. Üks DHL-ile, üks DSV-le, üks piirkondlikule vedajale. Kõik toimib hästi seni, kuni vedaja muudab oma API-t — ja siis saab probleemist teie mure. Viie vedajaga tuleb hallata viit liidestust, jälgida viit andmevormingut ja hoida käepärast viit tugikontakti.
  • Rakendada ERP-i peale veokiht. Ühendada ERP platvormiga, mis toetab kõiki vedajaid, ja hallata edaspidi vaid ühte ühendust. Uue vedaja lisamine on seadistamise küsimus või taotlus teenusepakkujale — mitte eraldi projekt.


Kuidas ERP-i veomoodul platvormiti erineb

Sama saadetist käsitletakse erinevalt sõltuvalt sellest, millist ERP-süsteemi kasutatakse. Alljärgnev tabel näitab, kuidas see erineb enamiku Euroopa tootjate kasutatavates süsteemides:

ERP

Mida veomoodul katab

Kus see peatub

Veokihi lisamisel

Microsoft Dynamics 365 (BC / F&O)

Business Central: vedajad, teenused ja saatelehed. F&O lisab transpordihalduse mooduli.

Veotellimuste esitamine ja hindade võrdlemine ei kuulu paketti ning F&O moodul on omaette projekt. Enamik keskmise suurusega tootjaid leiab, et see on vajalikust keerukam.

Valmis konnektorid nii BC kui ka F&O jaoks. Vedajate pool asub väljaspool ERP-i ja ühendus põhineb seadistamisel, mitte kohandatud arendusel.

SAP

Põhiline tarnedeklaratsioon; olemas on ka mahukas transpordimoodul, mis on suunatud suurettevõtetele.

Enamik tootjaid ei aktiveeri transpordimoodulit kunagi. Kui kasutate ECC-d, tuleb teil mingil hetkel migreerida (vt allpool olevat märkust).

Ühendub API või turvalise failivahenduse kaudu, olenemata sellest, kas teie SAP töötab pilves või kohapeal.

NetSuite

Ühtne pilvepõhine ülevaade tellimustest, laost ja rahandusest.

Natiivne vedajate tugi on suunatud peamiselt pakisaadetistele. LTL- ja FTL-veod mitme transpordiliigiga pole kunagi olnud selle põhieesmärk.

Üks liidestus ühendab kõik vedajad. SomnoMed vähendas kaubaetikettide loomise aega Prantsusmaal 90 minutilt päevas 20 minutile ning laiendas seejärel sama lahendust teistesse Euroopa keskustesse.

Odoo

Taskukohane ja paindlik, tarnekonnektor on suunatud peamiselt pakivedajatele.

Puudujäägid ilmnevad siis, kui hakkate liigutama kaubaplaate ja segakoormasid tegeliku vedajate nimekirjaga.

Cargosoni valmis konnektor võimaldab veomahtu suurendada ilma iga vedaja jaoks eraldi pluginat haldamata.

Monitor

Tootmisplaneerimine, MRP ja tootmispõranda haldus.

Mitme vedajaga vedu pole kunagi olnud selle põhieesmärk.

Sobib hästi peale pandava kihiga, mis haldab hindu, veotellimusi, kaubaetikette ja jälgimist ning saadab kulud tagasi Monitori.


Pilv vs kohapealne ERP: mida see veo jaoks muudab

Kui teie ERP töötab pilves, muutub kaks asja.

  • Tarnija kontrollib väljalaskegraafikut. Uued versioonid ilmuvad nende ajakava järgi, mitte teie oma järgi — seega peab teie veoühenduse haldaja jälgima iga väljalasket. Uurige enne lepingu allkirjastamist, kes vastutab ühilduvuse eest.
  • Kaubaetikett tuleb ikkagi pakendusjaamas printida. Olenemata sellest, kas ERP on pilvepõhine või mitte, vajab laadimisalal töötav inimene õiget kaubaetiketti ja veo dokumenti. Veoseadistus peab suunama selle teabe kohalikku printerisse, ilma et iga vedaja jaoks tekiks eraldi töövoog.


Mis juhtub teie veoseadistusega ERP-i vahetuse korral

Olukord on teistsugune, kui teie vedajalepingud, veoreeglid, kaubaetiketid ja jälgimine asuvad eraldi kihis, mitte ERP-is. Sellisel juhul tähendab süsteemivahetus vaid ühe ühenduse ümbersuunamist, mitte kogu vedajatega seotud töö uuesti tegemist.

Stokker, tööriistade ja masinate hulgimüüja, puutus selle probleemiga kokku täpselt siis, kui nad läksid üle uuele ERP-ile. Selle asemel et iga veopartneriga liidestused eraldi uuesti üles ehitada, ühendas Stokker need kõik Cargosoni kaudu — seadistusaeg lühenes nädalatelt minutitele. Nüüd töötlevad nad 15 000 saadetist kuus vaid kahe töötajaga.


Kes vastutab ERP-i veomooduli eest pikemas perspektiivis

ERP-i veo liidestamine pole ühekordne seadistus. ERP-e uuendatakse. Vedajad muudavad kaubaetikettide formaate, teenuskoode ja API versioone oma ajakava järgi, teiega konsulteerimata. Ja inimene, kes teab, millises portaalis milline parool on, võib ühel päeval lahkuda.

Seega pole küsimus ainult selles, kas ühendus on olemas, vaid selles, kes seda ühendust üleval hoiab. Veokihi puhul haldab teenusepakkuja vedajate ühendusi tsentraalselt. Kui vedaja muudab oma API-t, on selle parandamine teenusepakkuja ülesanne, mitte muudatustaotlus teie ERP-i vastu. Cargosonis kuulub vedajate ühenduvus toote põhiosasse ega ole lisatasu eest saadav lisateenus — ja kui soovite ühendada vedajat, kes pole veel liidestatud, teeb Cargoson seda tasuta.


Integreeritud lähenemine ja kust edasi uurida

Teie ERP haldab tellimust. Peale pandav veokiht hoolitseb transpordi eest: reaalajas hinnad teie vedajatelt, veotellimuste esitamine, kaubaetiketid ja dokumendid, jälgimine ning veokulud — nii jääb finantsarvestus täielikuks. Meeskond sisestab saadetise vaid korra ega pea selleks ühtegi portaali avama.

Meie TMS-ERP liidestuse juhend selgitab, kuidas andmed liiguvad ja milliseid küsimusi tuleks enne otsuse tegemist igalt tarnijalt küsida. Küsimust, kas ERP-i moodul on iseenesest piisav, käsitleb artikkel ERP vs TMS. Käesolev artikkel kirjeldab sama kihti ERP-i vaatenurgast.

Cargoson on loodud ainult veotellijatele, tootjatele ja hulgimüüjatele — mitte vedajatele ega 3PL-idele. Iga funktsioon on mõeldud logistikameeskonna probleemi lahendamiseks, mitte veokorraldaja jaoks. Kuna platvorm on sõltumatu ega kuulu ühelegi vedajale, jäävad teie läbirääkimiste teel saavutatud hinnad teie omaks. Cargosonil on valmis konnektorid Microsoft Dynamics, Dynamics 365 F&O, NetSuite ja Odoo jaoks ning see ühendub enam kui 2000 vedajaga otse API ja EDI liidestuste kaudu. Hind algab 199 eurost kuus — murdosa sellest, mida maksab traditsiooniline suurettevõtte juurutus. Ja kui teil pole suurt IT-meeskonda, on hea teada, et tugi on see aspekt, mida meie kliendid arvustustes kõige kõrgemalt hindavad.


Saate seda proovida oma ERP-i ja vedajate andmetega enne otsuse tegemist. Broneerige tasuta ja kohustuseta 30-minutiline konsultatsioon meie ekspertidega. Vaatame üle meie funktsionaalsuse, teie praeguse seadistuse ning arutame, kas ja kuidas Cargoson teid aidata saaks.

Broneeri tasuta konsultatsioon