Amikor egy értékesítési megrendelés beérkezik az ERP-rendszerbe, minden szükséges információ már rendelkezésre áll: a szállítási cím, a tételek, a súlyok és az ígért szállítási határidő. A kiszállítás indításával azonban a rendszer szerepe véget ér. A csapat kinyomtatja a szállítólevelet, kiválaszt egy fuvarozót a legördülő listából, és megjelöli a rendelést kiszállítottként – miközben a küldeményt még senkinél sem rendelték meg.

Ezután valakinek meg kell nyitnia a fuvarozó portálját, be kell vinnie a címet, meg kell rendelnie a szállítást, majd a nyomkövetési számot vissza kell másolnia az ERP-be. A következő küldeménnyel ugyanez ismétlődik – csak éppen egy másik portálon keresztül.

Így működik a szállítás a legtöbb gyártó vállalatnál: részben az ERP-en belül, részben azon kívül. Hogy az ERP mennyire fedi le a folyamatot, az a használt rendszertől, annak üzemeltetési módjától és attól függ, mi történik egy új verzióra való átálláskor.


Mit tud az ERP szállítási modulja – és hol ér véget?

Az ERP szállítási modulja a kiszállítások rögzítésére készült. Fuvarozót rendel a megrendeléshez, kinyomtatja a szállítólevelet, és kiszállítottként jelöli meg a tételt. Ha belföldi csomagokat ad fel egy-két fuvarozóval, ez elegendő is lehet.

Arra azonban soha nem tervezték, hogy foglalás előtt valós idejű árajánlatokat hasonlítson össze a fuvarozók között, közvetlenül foglaljon fuvarozóknál, automatikusan töltse be a nyomkövetési adatokat, vagy ellenőrizze a fuvardíjszámlákat a szerződéses árakkal szemben. Az ERP-szállítók nem is tervezik ezeket a funkciókat megvalósítani, mivel a fuvarozói kapcsolatok soha nem tartoztak a termékük hatókörébe. A hiányosságokat részletesen tárgyaljuk az ERP vs TMS cikkünkben.


Három módszer a szállítás ERP-hez adásához

Amikor az alap modul már nem elegendő, a csapatok általában három lehetőség közül választanak.

  • Az alap modul használatának folytatása. A fuvarozó kijelölése, a nyomtatás és a kiszállítás jelölése az ERP-ben marad. A többi manuálisan, fuvarozói portálokon keresztül történik. Ez a megoldás nem igényel beállítást, de magas üzemeltetési költségekkel jár: küldeményenként elvesztegetett percek és olyan hibák, amelyek csak akkor derülnek ki, amikor az ügyfél már telefonál.
  • Külön bővítmény telepítése minden fuvarozóhoz. Egy a DHL-hez, egy a DSV-hez, egy a regionális fuvarozóhoz. Mindegyik jól működik – egészen addig, amíg a fuvarozó meg nem változtatja az API-ját, és a probléma megoldása az ön feladata lesz. Öt fuvarozónál öt integrációt kell karbantartani, öt adatformátumot nyomon követni, és öt ügyfélszolgálati kapcsolatot kezelni.
  • Szállítási réteg kiépítése az ERP fölé. Az ERP-t egy olyan platformhoz csatlakoztatják, amely minden fuvarozót támogat, és ettől kezdve egyetlen kapcsolatot kell fenntartani. Egy új fuvarozó hozzáadása konfigurációs kérdéssé válik, vagy egyszerűen egy kérés a szolgáltatóhoz – nem egy újabb projekt.


Hogyan tér el az ERP szállítás az egyes platformokon?

Ugyanazt a küldeményt eltérően kezelik attól függően, hogy melyik ERP-rendszert használják. Az alábbi táblázat bemutatja, hogyan különbözik ez a legtöbb európai gyártó által használt rendszerekben:

ERP

Mit fed le a szállítási modul

Hol ér véget

Szállítási réteggel

Microsoft Dynamics 365 (BC / F&O)

Business Central: fuvarozói ügynökök, szolgáltatások és szállítólevelek. Az F&O egy szállításkezelési modullal egészül ki.

A foglalás és az árajánlat-összehasonlítás nem része a csomagnak, az F&O modul pedig önmagában is egy komoly projekt. A legtöbb közepes méretű gyártó számára szükségtelenül bonyolult.

Előre elkészített csatlakozók állnak rendelkezésre mind a BC-hez, mind az F&O-hoz. A fuvarozói oldal az ERP-en kívül él, a kapcsolat konfigurációalapú, nem egyedi fejlesztés.

SAP

Az alap szállítási dokumentum; létezik egy nagyvállalatoknak szánt, kiterjedt szállításkezelési modul is.

A legtöbb gyártó soha nem aktiválja a szállításkezelési modult. Ha ECC-t használ, valamikor migrálnia kell majd (lásd az alábbi megjegyzést).

API-n vagy biztonságos fájlcserén keresztül csatlakozik, legyen a SAP felhőalapú vagy helyszíni telepítésű.

NetSuite

Egyetlen felhőalapú nyilvántartás a megrendelésekről, a készletről és a pénzügyekről.

A natív fuvarozói támogatás inkább a csomagszállítás felé hajlik. Az LTL és FTL közötti többmódú teherszállítás soha nem volt igazán a hatásköre.

Egyetlen integráció köti össze az összes fuvarozót. A SomnoMed a franciaországi kaubaetikett-készítést napi 90 percről 20 percre csökkentette, majd a beállítást kiterjesztette többi európai telephelyére is.

Odoo

Megfizethető és rugalmas, kiszállítási csatlakozókkal, amelyek főként csomagfuvarozókra irányulnak.

A hiányosságok akkor válnak láthatóvá, amikor raklapokat és vegyes árut kell mozgatni egy valódi fuvarozói listán keresztül.

Az előre elkészített Cargoson csatlakozóval fuvarozónként külön bővítmény karbantartása nélkül bővíthető a szállítás.

Monitor

Gyártástervezés, MRP és üzemi irányítás.

A több fuvarozós szállítás soha nem volt a rendeltetési célja.

Természetes illeszkedés egy felette lévő réteghez, amely kezeli az árajánlatokat, a foglalást, a címkéket és a nyomkövetést, majd visszaküldi a költséget a Monitorba.


Felhőalapú vs. helyszíni ERP: mit változtat ez a szállításon?

Ha az ERP felhőben fut, két dolog változik.

  • A szállító határozza meg a kiadási ütemtervet. Az új verziók az ő menetrendjük szerint jelennek meg, nem az ön igényei szerint – ezért aki a szállítási kapcsolatot karbantartja, minden kiadást nyomon kell kövessen. Még a szerződés aláírása előtt tisztázza, ki felelős a kompatibilitás fenntartásáért.
  • A címkét a csomagolóállomáson kell kinyomtatni. Függetlenül attól, hogy az ERP felhőalapú-e vagy sem, a rakodóhelyen valakinek szüksége van a megfelelő szállítási címkére és fuvarokmányra. A szállítási beállításnak fuvarozónként külön munkafolyamat létrehozása nélkül kell eljuttatnia ezt az információt egy helyi nyomtatóhoz.


Mi történik a szállítással ERP-migráció esetén?

A helyzet egészen más, ha a fuvarozói szerződések, szállítási szabályok, címkék és nyomkövetési adatok nem az ERP-ben, hanem egy különálló rétegben találhatók. Ekkor a migráció egyetlen kapcsolat átirányítását jelenti – nem az összes fuvarozói munka újrakezdését.

A Stokker, egy szerszám- és gépipari nagykereskedő, pontosan ezzel a problémával szembesült, amikor új ERP-re váltott. Ahelyett, hogy minden fuvarozóval egyenként építette volna újra az integrációkat, a Stokker az összeset a Cargosononon keresztül kötötte össze – így a beállítási idő hetekről percekre csökkent. Ma mindössze két munkatárssal dolgoznak fel havi 15 000 küldeményt.


Ki felel az ERP szállításért hosszú távon?

Az ERP szállítási integráció nem egyszeri beállítás. Az ERP-k frissülnek. A fuvarozók a saját menetrendjük szerint változtatják a szállítási címke formátumokat, a szolgáltatáskódokat és az API-verziókat – anélkül, hogy erről egyeztetnek önnel. És aki tudja, melyik portálhoz melyik jelszó tartozik, előbb-utóbb elhagyhatja a céget.

A kérdés tehát nem csupán az, hogy a kapcsolat működik-e, hanem az is, hogy ki tartja azt fenn. Egy szállítási réteg esetén a szolgáltató központilag karbantartja a fuvarozói kapcsolatokat. Ha egy fuvarozó megváltoztatja az API-ját, a javítás a szolgáltató feladata – nem egy változtatási kérelem az ERP ellen. A Cargosonnál a fuvarozói kapcsolatok a termék részét képezik, nem külön díjat terhelnek, és ha olyan fuvarozóval dolgozik, amely még nincs csatlakoztatva, a Cargoson azt is díjmentesen csatlakoztatja.


Az integrált megközelítés – és hol mélyedhet el tovább

Az ERP kezeli a megrendelést. A felette lévő szállítási réteg intézi a szállítást: valós idejű árajánlatokat kér a fuvarozóktól, elvégzi a foglalást, kezeli a szállítási címkéket és dokumentumokat, a nyomkövetést és a fuvardíjakat – így a pénzügyi nyilvántartás mindig teljes marad. A csapatnak csak egyszer kell rögzítenie a küldeményt, és nem egy portálon keresztül.

A TMS–ERP integráció útmutatónk elmagyarázza, hogyan mozognak az adatok, és milyen kérdéseket érdemes feltenni bármely szállítónak a döntés előtt. Azt, hogy az ERP modul önmagában elegendő-e, az ERP vs TMS cikk tárgyalja. Ez a cikk ugyanezt a réteget az ERP szemszögéből mutatja be.

A Cargoson kizárólag szállítókat, gyártókat és nagykereskedőket szolgál ki – nem fuvarozókat vagy 3PL-eket. Minden funkció egy logisztikai csapat problémájának megoldására készült, nem egy fuvarozó szervezőére. Mivel a platform független és nem fuvarozó tulajdonában van, az ön által megtárgyalt árak az öné maradnak. Előre elkészített csatlakozók állnak rendelkezésre a Microsoft Dynamics, a Dynamics 365 F&O, a NetSuite és az Odoo rendszerekhez, és közvetlen API- és EDI-integráción keresztül több mint 2000 fuvarozóhoz csatlakozik. Az ár havi 199 €-tól indul, töredéke egy hagyományos nagyvállalati bevezetés költségének. Ha nincs nagy IT-csapata, megnyugtathatja, hogy az ügyfélszolgálat az a terület, amelyet ügyfeleink a legtöbbre értékelnek a véleményekben.


Saját ERP- és fuvarozói adataival is kipróbálhatja, mielőtt dönt. Foglaljon egy ingyenes, kötelezettségmentes 30 perces konzultációt szakértőinkkel. Áttekintjük a funkciókat, az ön beállításait, és megbeszéljük, hogy és hogyan segíthet a Cargoson.

Ingyenes konzultáció foglalása