SAP Basic Shipping esettanulmány

Zöldmezős SAP S/4HANA bevezetést hajtott végre egy Nyugat-magyarországi gyártó profilú partnerünk. Az udvaruk kisebb területe miatt, ahova naponta körülbelül 50-60 kamion lép be, az SAP advanced TM (Transportation Management) helyett annak egyszerűsített változatát, a Basic Shipping modult választották. Mivel ez a sztenderd S/4HANA csomag része, így a licenszelési problémákat is elhárították.

A cég nem rendelkezik saját járműflottával a fuvarozási feladatok ellátásához, hanem azt teljes egészében külső partnerekre bízza. Ezért a szállítmányozásirányítási rendszerük egyik kulcsfontosságú funkciója – a tehergépjárművek útvonalának és rakományának tervezése mellett – a díjszámítás, amire elemzésünk is fókuszálni fog.

Az üzleti folyamat összefoglalása

A folyamat a core S/4HANA és a beágyazott EWM rendszerekkel integrált.

A folyamat egy értékesítési vagy beszerzési rendelés létrehozásával kezdődik a fő ERP rendszerben. Ebből jön létre a kimenő- vagy bejövő szállítás. Import esetén az EWM rendszer soha nem integrált a TM megoldással, exportnál azonban a fő folyamat integrált forgatókönyv alapján zajlik. A szállítás létrehozása után, ha az a TM számára releváns, automatikusan létrejön egy fuvaregység, illetve ha az EWM is érintett, a szállítás elosztásra kerül.

A csomagolási folyamat és a késztermékek profilja miatt a kiszállításhoz szükséges méretek szabványosítása nem lehetséges, ezért a tervezési folyamat első lépése a ládaméter meghatározása a felelős üzleti személyek által. Ezt a feladatot az SAP rendszeren kívül hajtják végre, azonban a szükséges információk egy egyedi, szerkeszthető kimutatásban rendelkezésre állnak, ahol az eredmények elmenthetők.

A megadott méretadatok, a be- és kirakodási helyszínek, illetve a fuvaregységek időpontjai alapján egy fuvarrendelés hozható létre. A fuvarrendelés egy teherautót szimbolizál és több fuvaregységet is tartalmazhat. A szállítási utasítás fuvarozóhoz történő elküldése után az EWM rendszerben a fuvarrendelés alapján egy szállítási egység jön létre. A rendszer megkeresi a korábban elosztott szállításokat, illetve hozzárendeli azokat egy szállítási egységhez.

Az EWM és a TM közötti kapcsolat

Az EWM (Extended Warehouse Management) az SAP komplexebb raktárak kezeléséhez készített modulja, amellyel minden anyag kezelhető a raktárba lépés pillanatától a kilépésig.

Eredetileg egy webszolgáltatáson keresztül integrálódik a TM-be, egy XML-üzenet generálódik amikor a fuvarrendelés átkerül a TM-ből, majd egy másik, amikor visszaérkezik. Ettől a két esettől eltekintve nincs kommunikáció a két rendszer között, ami azt jelenti, hogy az egyik rendszerben végrehajtott változtatás nem lesz elérhető a másikban.

Az SAP 2020-as verziójával azonban megjelent egy egyszerűsített megoldás, ahol a két modul zökkenőmentesen integrálódik, anélkül, hogy az EWM-ben a szállítási egység létrejönne.

A komissiózás, csomagolás, rendelkezésre bocsátás, majd a rakodás és anyagkiadás mind az EWM rendszerben történik, majd miután a kamion elhagyja a gyárat a folyamat visszakerül a TM megoldásba. Ha a kiszállítás nem releváns az EWM szempontjából, akkor a beérkezés és a le- vagy felrakodás a TM rendszeren belül történik a vonatkozó státuszok módosításával.

A szállítás alapú műveletek, mint például a rakodási pontra érkezés, a TM rendszeren belül kezelhetők. Miután a teherautó elhagyta az utolsó célt, a díjszámítás megkezdhető.

A költség a ládaméteren és a célállomások zónáján alapul – egy zóna több helyszínt is tartalmazhat, egy helyszín pedig egy üzleti partnernek felel meg. Fontos, hogy a számítás pontos legyen, mivel a jelentősebb fuvarozóknál a fizetés egy önszámlázási folyamaton alapul.

A motorháztető alatt: BOPF

Hasonlóan a legtöbb SCM (Supply Chain Management) termékhez (mint péládul az APO vagy az EWM) az SAP Transportation Management modul az SAP BOPF (Business Object Processing Framework) technológián alapul. Minden korábban említett TM dokumentumnak megvan a megfelelő üzleti objektuma.

A BOPF egy objektumorientált (OO) ABAP keretrendszer, egy általános szolgáltatás- és funkciócsomag, amely egy adott üzleti objektumra, esetünkben például egy fuvarrendelésre és a kapcsolódó műveletekre fókuszál. Az SAP eredeti céljai szerint ez felgyorsíthatja és standardizálhatja a fejlesztést.

Ügyféligények

Számos ügyfélspecifikus igénybe ütköztünk, ahol a megszokott kereteken kívül kellett gondolkodnunk, hogy olyan megoldásokat találjunk, amelyek még kielégítik az igényeket, de nem térnek el túlságosan a sztenderd folyamattól.

Csillagpontos költségszámítás

Az első problémát, amellyel találkoztunk, a lokációk kezelésmódja okozta. Az eredeti beállítás szerint a díjat a ládméteren kívül a kiindulási és a célzóna együttes figyelembevételével számították ki.

Ez a megoldás azonban két okból nem működhetett. Az egyik probléma az volt, hogy ez azt jelentette volna, hogy minden egyes zónából az összes többibe egy-egy szállítási kapcsolatot kellett volna kialakítani. Mivel majdnem ezer ilyen lett volna, ez óriási többletmunkának tűnt.

A másik ok az volt, hogy a bevezetés alatt új szerződéseket kötöttek a fuvarozókkal a következő évekre, ahol a költségeket úgy számolták ki, mintha az ő üzemük lenne az egyes szakaszok kiindulási állomása (illetve import esetén a célállomás). Tegyük fel például, hogy van egy fuvarrendelés, amely három szakaszból áll, az egyik az üzemünkből (központ) az A helyszínre, majd az A helyszínből a B helyszínre, végül pedig a B helyszínből a C helyszínre. A tervezéshez szükségünk van ezekre a szakaszokra, azonban a díjszámításhoz úgy tekintjük a kiszállítást, mintha minden célállomásra a mi üzemünk lenne a kiindulási hely, így a három szakasz az üzemünktől az A, az üzemünktől a B és az üzemünktől a C helyszínig tartó útvonalak lesznek.

Ennek megoldása az volt, hogy a díjszámítási mátrixból a kiindulási hely eltávolításra került (import szállítások esetén a célállomás), vagyis a három változó kettőre lett csökkentve. Így az útvonaltervezés nem változott, a díjkalkuláció pontos költségeket produkált, vagyis az önszámlázási folyamat megfelelően működhetett. A költségfelosztás azonban hibássá vált, mivel az utolsó helyszínre kerülő termék minden korábbi helyszínre is utazik, ahol az adott költség minden odakerülő termék között megoszlik. Mivel ez elhanyagolható különbséget jelent, az ügyfél elfogadta a megoldást.

Ládaméter

További problémát okozott a ládaméter kezelésének módja. Először minden egyes külön fuvaregységre kiszámításra kerül a teljes hossz az ügyfelektől kapott csomagolási utasítások alapján, hogy lehetséges legyen a fuvarrendelés felépítése. Miután a fuvarrendelés elkészült, és kiderült, hogy melyik fuvaregység utazik az adott tehergépkocsival, a hossz újra meghatározásra kerül, mivel előfordulhat, hogy a különböző kiszállításokból származó termékek egymásra rakhatók. A csomagolás az EWM rendszerben történik, és miután a fuvarrendelés ismét elérhető a TM-ben, a ládaméter alapján elindulhat a díjszámítás.

Amellett, hogy a standard mező nem pontosan a ládaméter, hanem egy általános hossz mező, több probléma is volt vele:

• A sztenderd folyamat során az értéke automatikusan az anyagtörzs alapján kerül meghatározásra és kézzel nem módosítható. A késztermékek jellege és az ügyféligények miatt azonban egy fix érték meghatározása nem lehetséges.
• Ez a mező minden cikkhez külön is meghatározható, azonban a termékek egymásra rakhatósága miatt egy fejléc szintű értékre volt szükség.
• A csomagolás befejezése után az EWM rendszerben a teljes cikkszerkezet rekonstruálásra kerül a FE > termékből a FE > csomag > termék lesz. Elképzelhető, hogy egy cikksoron egy adott termékből tíz darab összesen három méter hosszú volt, de miután ezek az EWM-ben tíz különálló kezelési egységbe kerültek, a TM-be különböző tételsorokban kerülnek vissza, miközben mindegyik megőrzi az eredeti hosszát, vagyis az összesen három méterből tízszer három méter hossz lett.

E problémák leküzdésére először a sztenderd eljárást próbáltuk módosítani, azonban az annyira bonyolulttá vált, hogy úgy döntöttünk, egy másik irányba indulunk el.

Megállapítottuk, hogy sokkal ideálisabb megoldás, ha a standard hossz mező helyett egy új, egyedi mezőt hozunk létre az igényeinkre szabott tulajdonságokkal.

A BOPF struktúra és a Fiori Floorplan Manager képességeit felhasználva a megfelelő FBI nézetekkel lehetővé vált egy új egyedi mezőt hozzárendelni a fuvaregységhez. Ez az új érték az egyedi igényekhez került igazításra; ennek megfelelően a szállítási egység fejléc szintjére került és függetlensége következtében manuálisan szerkeszthető, illetve nem esik szét az EWM feldolgozás után.

Testreszabható felhasználói felület: FPM és FBI

Az SAP Transportation Management a Floor Plan Manager (FPM) megoldást használja a felhasználói felületeinek megvalósításához. Az FPM egy Web Dynpro ABAP alkalmazás, amely keretrendszert biztosít az SAP UI irányelveivel összhangban lévő új Web Dynpro ABAP alkalmazásfelületek fejlesztéséhez. Az FPM használatával a felhasználói felületek kódolás nélkül konfigurálhatók.

A Floor Plan Manager BOPF Integration (FBI) az SAP Transportation Management alkalmazásban az FPM és a BOPF-alapú Business Objects elemek integrálására szolgál. Az FBI általános FPM alkalmazás adagoló osztályokat („feeder class”) biztosít a megfelelő alkalmazás konfigurációval együtt, amely lehetővé teszi a BOPF-ben modellezett Business Objects szolgáltatások igénybevételét.

A BOPF struktúra adta lehetőségeket kihasználva egy tömeges karbantartási riportot tudtunk készíteni, ahol – egyéb attribútumokon túl – egyszerre több dokumentumra is meg lehetett határozni a ládamétert, így nem kell minden bizonylatot egyenként megnyitni. Ez a táblázatos strukturált lekérdezés egy POWL listán alapul, ami nagymértékben testre szabhatóvá teszi mind a back-end rendszerből egyszerűen beállítható általános beállításokkal (például a mezők karakterhossza és adattípusai), mind a felhasználóspecifikus módosításokkal (például személyre szabott elrendezések), amelyet a felhasználói felületen mindenki elvégezhet magának.

A riportkészítés modern módja: POWL

A POWL (Personal Object Worklist) elődje az Universal Worklist (UWL) volt, amely általános munkalistaként volt használva, azonban a felhasználói szintű konfiguráció hiánya miatt az SAP úgy döntött, hogy lecseréli a Personal Object Worklistra, amely egy webes tervező környezetbe van ágyazva.

Ez lehetővé teszi a felhasználók számára a munkájuk kezelését azáltal, hogy egybegyűjti a különböző rendszerek objektum-hozzárendeléseit, amelyek maguk nem részei a munkafolyamatnak (beleértve az értesítéseket, a tudásmenedzsment (KM) értesítéseket és a kollaborációs feladatokat).

Fontos volt az is, hogy a ládaméter adatokat ki tudjuk küldeni fuvarozóinknak. A TM rendszerből kinyomtatott űrlapok testreszabása is lehetséges volt, így az egyes helyszínekre vonatkozó összesített hossz értékek megjelennek a szállítási utasításon, amelyek emailben kerülnek kiküldésre az SAP PPF technológiájával vezérelt tervezési folyamat során.

A kimenet egyszerűbb kezelése: PPF

A TM a PPF-et (Post Processing Framework) használja az űrlapok (pl. CMR, szállítási utasítás) nyomtatásához és kiküldéséhez. Olyan programlogika végrehajtását végzi, amely egy bizonyos üzleti folyamatlépést követő műveletnek számít.

A PPF-ből csak olyan kimeneteket lehet küldeni, amelyek már léteznek, vagyis a tervezés során a szükséges lépések megtörténtek, így minden adat rendelkezésre áll. Ez megakadályozza, hogy a felhasználó előzetesen küldje ki a dokumentumokat, illetve a továbbítást követően eltávolítja azt az aktív adatbázisból, vagyis – szándékos manuális beavatkozás nélkül – nem lehet kétszer küldeni egy dokumentumot.

A modern SAP megoldások, mint például a PPF technológia vagy a BOPF struktúra képességeit kihasználva az egyedi igények sztenderd folyamatokba illesztése szabványosabb és könnyebben elérhető módon történhet. Ezeket felhasználva egy kifejezetten egyedi díjszámítási folyamathoz tudtunk egy nagymértékben testreszabott megoldást készíteni, szinte kompromisszumok nélkül.

Záró gondolatok az SAP Basic Shipping csillagpontos hálózat ládaméteren alapuló fuvardíj számításáról

Egy ekkora komplexitású gyártó vállalatnak is le-lehet fedni a fuvarköltség elszámolás igényeit az S/4HANA által natív módon kiszállított Basic Shipping funkcionalitással, minimális custom development kiegészítéssel.

Tovább előnye, hogy licensz optimalizációt is támogatja, tehát első körben javasolt ezt vizsgálni, és csak utána tovább lépni a külön licenszes SAP fejlett TM (Transportation Management) termék felé.

Fuvardíj számítással vagy hasonló kihívással néz szembe az S/4HANA megoldásában? Lépjen kapcsolatba velünk most és kérjen konzultációt szakértőinktől!

Tekintse meg további bejegyzéseinket!