Egy ellátási lánc szimulációs játék (SCSG) során szerzett felhasználói tapasztalatok, a továbbfejlesztés lehetőségei és fő irányai Benyó Dániel*, Kokas Attila**, Kozák István András*** *BME, Közlekedésmérnöki Kar, Közlekedésüzemi Tanszék (e-mail:
[email protected]) ** BME, Közlekedésmérnöki Kar, Közlekedésüzemi Tanszék (e-mail:
[email protected]) *** BME, Közlekedésmérnöki Kar, Közlekedésüzemi Tanszék (e-mail:
[email protected]) Absztrakt: A SCSG FTP-s változata alatt szerzett felhasználói tapasztalatok rövid ismertetése. Példák a szakmai feladatok megoldására, az alkalmazott támogató eszközpaletta bemutatása, és a játék során fellelt problémák ismertetése. Egy új, webes alapú SCSG alkalmazásban rejlő lehetőségek feltárása, a fejlesztés kezdőlépései, a program tervezett felépítése, funkciói valamint a továbbfejlesztés tervezett irányai.
1. BEVEZETÉS A Budapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki Karának Közlekedésüzemi Tanszékén a 2009/2010 oktatási év második szemeszterében ellátási lánc szimulációs játék (SCSG – Supply Chain Simulation Game) folyt, a Közlekedésüzemi Tanszék tanárainak felügyeletével és logisztika szakos (BSc-s és hagyományos képzésben részt vevő hallgatók vegyesen) hallgatók részvételével. A játéknak kettős célja volt: az egyik, hogy a hallgatók az elméleti tudásukat egy szimulációs környezet segítségével a gyakorlatban is kipróbálhassák, a másik cél pedig a játék jövőbeni fejlesztéséhez szükséges üzemeltetési tapasztalat gyűjtése volt (Bóna, Kovács és Lénárt 2009). A mostani cikk írói a játék folyamán a legkiemelkedőbb eredményeket értek el, egyrészt a játék menedzselése, és ezen alapulva a „vállalati” működés hatékonysága terén. E miatt kerülhettek be a Tanszéken működő Innovatív Logisztikai Kutatások Tehetséggondozó Műhely programjába, amely ösztöndíjak és különféle egyéb juttatások formájában támogatja a három szerző munkáját, melynek végső célja egy webes platformon működő SCSG alkalmazás kifejlesztése. Jelen cikk a szerzők játék során szerzett tapasztalatait és alkalmazott megoldásait mutatja be, majd erre alapozva ismerteti a fejlesztés ez idáig elkészült részeit. 2. SZEMÉLYES TAPASZTALATOK 2.1 A kereskedő cégek működtetése Az SCSG során mindhárman egy kereskedő cég megalapítását, üzemeltetését és fejlesztését kaptuk feladatul. A feladatköröket a játék elején behatároltuk és kiosztottuk egymás között.
A játék során, mint kereskedőknek, a következők voltak a feladataink: -
kezdő készletek és a működéshez szükséges technikák meghatározása,
-
termékkatalógus elkészítése és frissítése,
-
az áruk disztribúciója,
-
az áruk készletezése, beszerzése,
-
az igények folyamatos nyomon követése,
-
a tendereken való részvétel,
-
a cég kontrolingje, a vállalatirányítási rendszer kifejlesztése, karbantartása
-
a tranzakciók virtuális végrehajtása, elektronikus dokumentálása, heti riportok készítése.
A fenti feladatok végrehajtása során több problémával is szembesültünk. Ezek egy része szakmai, a másik része napi, operatív szintű volt. A szakmai problémákat minden csapatnak magának kellett megoldania, mivel a feladatban a csapatok szabad kezet kaptak ezért a gondok leküzdésére sok, különböző megoldás született. Ezekre pár példát mutatnak be a következő bekezdések. Az első kereskedő vállalat esetében: Már a játék elején világos volt, hogy célszerű egy Excel fájlban nyilvántartani az összes adatunkat. Ennek eredménye lett az egész féléven át fejlesztett VIR. A VIR elnevezés a Vállalat Irányítási Rendszerből ered, a név a törekvésünket fejezi ki, hogy a játékban kapott feladatokat milyen irányelvek alapján oldjuk meg. Természetesen a mi rendszerünk nem veheti fel a versenyt a modern, nagy múltú vállalatirányítási rendszerekkel, de ezek példák voltak előttünk, hogy az egész vállalatunkat rendszer személeti alapok szerint
vezessük. Az a gondolatunk, hogy ha az adatainkat jól strukturáljuk, és azokra megfontoltan, tervezetten automatizálásokat írunk, az egyszerűbbé és hatékonyabbá teszi munkánkat, a játék végeredményekor és az értékeléskor beigazolódott. Erre egy jó példa a heti riportok kitöltése, amit a VIR-nek köszönhetően nem manuálisan kellett elkészítenünk, hanem azt az Excel fájlunk megtette helyettünk. A VIR a következő modulokból állt össze: a.) Az összes rendelés nyilvántartása. A kiskereskedőktől felénk, és tőlünk beszállítóink felé. A modul adatai bemenetek voltak a heti riportokhoz. b.) A gyárak árai és a beszállítások. Egyszerűen nyomon tudtuk követni a gyártók felé a megrendeléseinket és a tartozásainkat. A modul adatai bemenetek voltak a heti riportokhoz. c.) A kiskereskedők felé az áraink, a kiszállításokkal. Itt történt a rendelések kezelése, tehát a hozzánk érkezett megrendelések ütemezése, a teljesített és még nem teljesített szállítások és az ezekhez tartozó értékáramok felügyelete. A funkció adatai bemenetek voltak a heti riportokhoz.
f.) Heti riport, a fontosabb vállalati költségekről és a készletekről szóltak, mint már említettük, a kitöltése teljesen automatikusan történt, amelyet az Excelben nem egyszer 4-5 soros képlettel tudtunk megoldani. Bemenetei az a.), b.) és c.) modulok adatai voltak. g.) Körjárat és a kiszállítási távolságok. Ez az egyik legkomolyabb része a VIR-nek. Sokáig fejlesztettük, melynek eredménye egy félig automatizált rendszer lett. Erre azért volt szükség, hogy könnyen összeállíthatóak legyenek a kiszállítások körjáratai, valamint figyeljük közben azt, hogy egy kamion se haladja meg a napi futás limitet. Sikerült elérnünk, hogy a kamionjaink általában 95% fölött legyenek terhelve, valamint a fajlagos szállítási költségeink gyakorlatilag minimálisak legyenek. A feladat elején sok manuális munkával járt a távolság mátrix felvétele a telephelyünk és a 30 igénypont között. Majd erre a mátrixra alapozva már megfelelő algoritmusokkal időt, megtett utat és rakodási időt számoltattunk, tovább növelve az automatizáltságot.
d.) Forecast. Az előző év trendjét ismertük már a játék elején, illetve kaptunk információt az aktuális év várható trendjéről is a játékmestertől a játék elején. A kapott információkra támaszkodva az aktuális év általunk gyűjtött adataira egy lineáris regressziót is alkalmaztunk, hogy minél pontosabb előrejelzés álljon a rendelkezésünkre.
2. ábra: A körjáratok szervezése a söprő algoritmus alapján
1. ábra: Az igényekre fektetett regressziós egyenesek e.) Kiadás. Itt jelent meg az összes kiadás, napi szinten (üzemi költségek, tárolási költségek, beszerzések, rendelések, raktári dolgozók bére, kamionok költségei, sofőrök, rakodó munkások bére, kifizetések a gyártók felé, kötbérek, stb.), amelyek a Cash flow-hoz szolgáltak részben bemenetként.
3. ábra: A körjáratok jellemzőinek kiszámítása
h.) Tender. A vállalatunk elnyerte a két tender közül az egyiket, és ennek a nyilvántartását külön kellett vezetni egy negyedik új partner vállalat számára. A tender előnye volt, hogy meglehetősen nagy haszonra tettünk szert, a könnyen tervezhető és ütemezhető kiszállításokkal, de az új vevő és egy új termék megjelenése miatt, teljesen újra kellett képletezni az egész VIR-t.
A megrendeléseket folyamatosan figyeltük, amikor elég adat állt a rendelkezésünkre az idő és a játék múlásával, szabályszerűségeket, trendeket állapítottunk meg, és azok alapján töltöttük fel a raktárkészletünket. A játék végéig súlyozott mozgó átlag számításával történt a megrendelések előrejelzése, majd az utolsó hétre már csak igény szerint rendeltünk a gyártóktól, hogy a játék lezárásakor ne legyenek fölös lekötött javaink, és maximalizáljuk a hasznunkat.
i.) Cash flow modulban napi szinten ellenőrizhettük a vállalatunk működésének egyik legfontosabb mutatószámát, a pénzeszközeink változását. A bevételeket, kiadásokat összesítettük az egyenlegünkbe, valamint ezekből diagramokat származtatunk és jelenítettünk meg. j.) Raktár. Itt napi szinten monitoroztuk a készleteinket, így elkerültük, hogy készlethiány legyen, valamint ez sokat segített a kiadások számításában. k.) Kamionok. A napi futás teljesítményeket tartottuk nyilván, szintén a kiadások miatt. l.) Bevétel. Itt összesítettük a bevételeket. Az adatok bemenetek voltak a Cash flow-hoz.
6. ábra: A megrendelések előrejelzése táblázatos formában
A másik kereskedő vállalat esetében: Az áruk kiszállításához körjáratokat kellett szervezni, amelyek söprő algoritmus szerint kerültek kialakításra, a számításokhoz saját Exceles táblázatokat készítettünk, a táblázatokba beírt távolság értékek meghatározásához ingyenes internetes útvonalkeresőt használtunk.
7. ábra: A Szerkentyű termék előrejelzése diagramban
4. ábra: A körjáratok igényeinek kiszámítása
5. ábra: Ingyenes útvonal kereső használata
Az operatív jellegű problémáknál a vállalat mind külső, mind belső kommunikációja létfontosságú volt, a kialakult helyzetek gyors megoldásához. Az alábbi problémák merültek fel: -
Hibás megrendelések a partnerek felöl. A játékszabályokkal ellentétesen, hétvégén is volt megrendelés.
-
Az elektronikus dokumentumok hiányos kitöltése. A játék során az anyag-, és értékáram szimulálására használt Excel fájlban nem volt megadva a megrendelő és a szállító.
-
Az FTP szerveren tárolt dokumentumok hibás kezelése. Az anyag-, és értékáramot az említett Excel fájlban együtt kellett kezelni, még is volt olyan, hogy egy megrendelést több fájlba szedtek szét, külön egyet az anyagáramnak, és külön az értékáramnak. Figyelmetlenségből letörölt fájlok, amiket a partnertől kellett újra elkérni.
-
A gondok nagy része emberi hibából eredt, a pontatlan adatkezelésből, dokumentálásból, és a játékszabályok figyelmen kívül hagyásából. A hallgatók motiváltságát a játék továbbfejlesztésével és tanári eszközökkel lehet fokozni, de ezekkel szemben sokkal fontosabb volna, ha hallgatók saját hivatástudatukból merítenének. Akinél nincs meg a hivatástudat és saját maga által nem motivált, nem válhat jó szakemberré, felelős vezetővé. 2.2 A gyártó cégek működtetése Mivel nekünk nincsenek személyes tapasztalataink egy gyártó cég működtetésében, ezért megkérdeztük azokat a hallgató társainkat, akiknek ez volt a feladatuk. Véleményüket így összegeztük: Az Ellátási-, elosztási logisztika nevű tárgyból az egyik féléves feladatunk az volt, hogy a SCSG játékkal foglalkozzunk. A négy vállalat közül kettő gyártó, kettő kereskedő cég volt, amiket BSC-s és hagyományos képzésben tanuló hallgatók közösen irányítottak, működtettek. A gyártó cégek feladatai közül talán a legnehezebb a kezdéshez szükséges erőforrások meghatározása volt, és ezzel egy időben a gyártás megszervezése, hogy a játék indulásakor már be tudjuk indítani a termelésünket, hogy a kereskedők által generált igényeket kielégítsük. A félév során két tender került kiírásra, ezek során a kereskedő vállalatokkal kellett együttműködnünk, közösen meggyőzni a vevőket, hogy a mi pályázatunkat válasszák. Ezekre a kiemelt megrendelésekre külön meg kellett határozni a termékek árát, és a termelésirányításunkat is ehhez kellett igazítanunk, alárendelnünk. A termékek árát a lista árhoz képest csökkenteni tudtuk, mivel a biztos szállítások miatt a saját beszerzéseinket pontosan tudtuk ütemezni, és a termelési kapacitásunk is jobban ki volt használva. A két tendert a gyártó-kereskedő konzorciumok felváltva nyerték meg. A gyártó cégek vállalták a kockázatot, hogy a sikertelen tender esetén az előrerendelések miatt túl nagyra nő az alkatrészekből a készletük, és azért felesleges készlettartási költségeik lehetnek. A játék során felmerült problémák (a kereskedő vállalatoknál már ismertetetteken kívül): -
-
kezdéskor sok olyan hibát elkövettünk, amit a tanultak alapján csak a játék közben tudtunk kijavítani. Ez azonban jó lehetőség volt az alul- és a megfelelően támogatott logisztikai rendszer közötti minőségbeli különbség megértésére.
Egyes játékosok alacsony motiváltsága, emiatt a közös munka akadozása. A játékosok más tárgyak számonkéréseire hivatkozva nem töltötték be a vállalatukban vállalt szerepüket, ezzel akár más cégnek is hátrányt okozva.
A gyártó vállalatoknak a kezdő készletek meghatározásához és a gyártás megszervezéséhez szűkös a játék kezdése előtt adott egy hét. A félév során sok olyan gyakorlati eljárást, elméleti anyagot tanultunk a tárgy keretein belül, amit a játék elején már érdemes lett volna használni. A
-
Az ellátási láncában nem a gyártók a legelsők, ha az anyagáramlás irányából nézzük, de a játékosok között igen, ezért az ellátás biztonsága miatt, a szükséges és elégséges szinthez képest, arányaiban a gyártóknál a legnagyobbak készletek. Az ostorcsapás effektus legjobban a gyártókat sújtja.
Összességében a játék kitűnő lehetőséget nyújt arra, hogy olyan tapasztalatokra tegyünk szert, amire majd csak a munkánk során lesz szükségünk. 2.3 A cikkírók játékkal kapcsolatos benyomásai Benyó Dániel személyes élményei. A legelső pár napban nem igazán tudtuk, hogyan fogunk boldogulni a félév során. A feladatok közül a kiszállítások megszervezésével voltam megbízva. Nagy segítségemre volt a vállalat vezetője által fejlesztett VIR körjáratszerkesztő modulja. Ezt a csapat többi tagjával is egyeztetve folyamatosan fejlesztettük, így egyre jobban megkönnyítette a munkámat. A félév alatt egyre jobb eredményeket tudtunk elérni a kapacitás-kihasználás terén. A játék végére a cégünknek sikerült jelentős profitot realizálnia, amely a csapat által befektetett rengeteg munka után megérdemeltnek éreztük. Összességében számomra nagyon hasznos volt ez a játék, mert így több tantárgy anyagát végre használat közben is tapasztalhattam. Kokas Attila személyes élményei. Nagyon sok mindent lehetett tanulni a játék alatt, mely dolgokat később hasznosítani is lehet az életben. Sokat segíthet a játék abban, hogy a hallgatók megértsék egy vállalat működését és lássák, hogy zajlanak a folyamatok, illetve mennyi dologra kell figyelmet fordítani. Sokat lehet fejlődni az Excel használatában is, mert aki felelősség teljesen végzi a rá kiosztott feladatokat, igen sok időt kell eltölteni a saját maga vagy csapattársaival együtt kialakított táblázatokkal, segéd fájlokkal és elemzésekkel. A játék összetett, és sok mindenre már felkészít, hogy egy valódi vállalat életébe be tudjunk kapcsolódni, és ott már komplexebb problémákat is meg tudjunk oldani. Számtalan lehetőség is van a játékban: különböző szcenáriókat lehet vele szimulálni (pl. készletezési stratégiák, havária helyzetek) és ezekből igen komoly tanulmányokat, szakdolgozatokat, diplomamunkákat, stb. lehet írni. Emiatt is gondoltuk úgy, hogy megvalósítjuk egy sokkal szervezettebb formában a SCSG-t. Kozák István személyes élményei: Kijelenthetjük, hogy a játék során a félévközben és az előtte elsajátított tudásunkat komplex formában, egyszerre, egymással összefüggésben kellett használnunk. Megtapasztaltuk, hogy egy vállalat különféle funkciói, tevékenységei,
hogy függnek össze, hogy az igények előrejelzése milyen fontos a készletezésnél; a vállalat likviditása hogy befolyásolja annak lehetőségeit a piaci versenyben; a tevékenységek végrehajtásának színvonalát mennyire befolyásolja a technológia és technika. Ezek az összefüggések sokszor nyilvánvalónak tűnnek, de az SCSG keretein belül már a kötelező szakmai gyakorlat és a jövőbeli első munkahelyünk előtt, a “valóságban” megtapasztaltuk, hogy mennyire szem előtt kell ezeket tartani, ha a vállalatunkat gördülékenyen akarjuk vezetni. Mindhárman elmondhatjuk, hogy egy nagyon hasznos szimulációban vettünk részt. A cégen belüli csapatmunka, hatékony együttműködés, és a feladat komolyan vételének eredménye, hogy sikeresen zártuk a játékot, valamint viszonylag sok tapasztalatot szereztünk. Ezen kívül rengeteg ötlet fogalmazódott meg bennünk, hogy hogyan is lehetne „jobb”, illetve reprezentatívabb maga a szimuláció. Innen jött az ötlet, hogy a játéknak egy olyan keretet hozzunk létre, amivel könnyebben kezelhetővé, átláthatóbbá válik, ezáltal is ösztönözve a jövő hallgatóit a játékban való aktívabb részvételre. 3. WEBES ALAPÚ PLATFORM 3.1 Külföldi példák az ellátási lánc szimulációjára Miután az ötlet megszületett, hogy az FTP-s játékot tovább fejlesszük, elhatároztuk, hogy a következő Tudományos Diákköri Konferenciára pályamunkát készítünk. Ennek az első lépése az volt, hogy a Közlekedésüzemi Tanszéken, az Innovatív Logisztikai Kutatások Tehetséggondozó Műhely keretein belül meghirdetett pályázaton elindulunk. A pályamunkákhoz sikerült konzultációs, tárgyi és pénzügyi támogatást szereznünk. A fejlesztés következő fázisa az ötletelés volt, hogy ki, milyen funkciókra gondolt, mit lenne jó beleépíteni a majdani programba, ami elősegítené, hogy a tanulók minél jobban beleéljék magukat az játékba, hogy az említett operatív hibákat kiküszöböljük és az adminisztrátorok, vagyis a tanárok, munkáját könnyítsük. Az ötleteléshez külföldi példákat is megvizsgáltunk: Involvation holland tanácsadó cég Supply Chain játéka: Az Involvation egy holland tanácsadó cég, ami elsősorban az ellátási lánc fejlesztésével és menedzselésével foglalkozik. Egyik játékuk a Stock Game, amelyben kapunk egy igényeket előrejelző diagramot, 52 hét időtartamra, hetenkénti mennyiségben lebontva. Az ellátási szint, kezdőkészlet is meg van adva, és a feladat az, hogy a jelentésköteles készletszintet meghatározzuk (http://test.involvation.nl/en). Global Supply Chain Games: Global Supply Chain Games egy nemzetközi projekt, amiben külföldi felsőoktatási és kutató intézmények vesznek részt, a fejlesztő intézmények a Delft University of Technology, az University of Maryland és a R.H.
Smith School of Business, Supply Chain Management Center. A vezető fejlesztő Stijn-Pieter van Houten volt. A projekt egyik része a Distributor Games, amiben a játékosok kereskedőként vesznek részt, akik az összekötő kapocs szerepét töltik be a termelők és a vevők között, amiknek különböznek a viselkedési formáik, szokásaik. A játékosoknak többféle, értékükből gyorsan vesztő elektronikai termékekkel kell kereskedniük. A Distributor Games-nek is 3 fajta verziója van: Local vs. Global: egy nagyon erősen versenyző mód, a résztvevő csapatoknak el kell dönteniük, hogy globális, vagy helyi kereskedők lesznek-e, és hogy ez által a különböző készletezési stratégiák, termék portfóliók és beszerzési források közül mit választanak. Demand Surge: a játékosoknak különböző igény hullámokat kell kielégíteniük és ehhez kell megfelelő stratégiát választaniuk. X-treme Supply Chain: egy teljes vagy fél szemeszteren belül kell a tanulócsoportoknak egy gazdasági társaságot működtetniük. A játék 3 kontinensen folyik, azokon belül is egy-egy kisebb régióban, a régiókban több rivális cég működik. A cégeknek a játék során a közvetlen versenytársaikkal és a globális, másik kontinensen működő cégekkel is versenyezniük kell a gyorsan változó elektronikai piacon. A játékba a tisztességes versenyre és a megfelelő üzleti viselkedésre serkentő visszacsatolások lettek beépítve, például késedelmes teljesítés és fizetés esetére. A szállítási költségekben szerepelnek a konkrét üzemanyag és üzemeltetési költségeken kívül a vámok is, eltérő mértékben a kontinensek közötti és régión belüli szállításokra. (http://www.gscg.org) A külföldi példákból látszik, hogy a legegyszerűbb beer game-ből milyen összetett, a valóságot minél jobban leíró szimulációkig lehet eljutni. 3.2 A játékban lévő lehetőségek A külföldi példák vizsgálata után a saját ötleteinket összegyűjtöttük, és külön-külön átbeszéltük azok megvalósítási lehetőségeit. Meglátásunk szerint, a lehetőségek végtelen sorából a fontosak, és hasznosak: a)
A megrendelések feladása, a virtuális áruk leszállítása, az értékmozgások a leendő programban biztonságosan, adatvesztés, sérülés nélkül történjenek, de egyben egyszerűen legyen kezelhető a hozzájuk tartozó programfelület. A programnak tudnia kell kezelni a részteljesítéseket is.
b) Az esetleges emberi, gépelési hibák, hiányos kitöltések ellen a program védje meg a felhasználót. A tranzakciók csak akkor legyenek indíthatók, ha megfelelő adatok vannak megadva. Ilyenek például a megrendelő és szállító adatai, a teljesítés dátuma,
meghatározását. Akár ezt is meg lehetne vásárolni, egyfajta szolgáltatásként.
amiket kötelezően és jól kell kitölteni, hogy a tranzakció végrehajtódjon. c)
A gyártó cégeknél fontos, hogy mennyi idő alatt tudják legyártani a termékeket, hogy a megrendeléseket időben, a vállalt határidőre ki tudják elégíteni. A program a megadott gyártási paraméterek alapján, a legyártáshoz szükséges időt kiszámolja és közli a hallgatóval. A gyártás a programban történik, a közölt idő alatt. Ezzel a tisztességes versenyt is védjük, ha a játékosok esetleg teljesíthetetlen vállalásokat tennének.
d) Az FTP-s játék szabályzata szerint, egy cég a másik irányába egy nap egy fajta tranzakciót csak egyszer indíthat, vagy hajthat végre. Ezek alapján, a webes alapú program jegyezze meg, hogy egy nap már indítottak-e az adott fajta tranzakcióból, ha igen, újat már ne engedélyezzen. e)
f)
A kereskedőknek a saját járműparkjukkal kell megoldaniuk a megrendelések kiszállítását, ezeket körjáratokba kell szervezniük és a saját igényeik szerint optimalizálni, ami a saját belátásuk szerint történik. Az optimalizálásnak a kiskereskedők felé vállalt határidők betartásánál lehet fontos szerepe. Ennek a problémának megoldásában a korábban teljesített tárgyakban tanultakra tudnak támaszkodni, sőt, csak úgy tudják elvégezni a feladatot. A heti riportok leadását többféleképpen lehet ellenőrizni. Egyszerűen csak a meglétüket, és hogy időben leadták azokat, valamint összetettebb módon a tartalmukat is, hogy a leadott adatok megegyeznek-e a szimulációban lévő valósággal. Az utóbbi esetben, a programnak nem csak tárolnia kell az egyes tranzakciók, gyártások adatait, hanem azokat összegeznie, feldolgoznia is kell. Ez megnöveli a program bonyolultságát, de egy visszajelzési lehetőség is a vállalatok felé. Felvetődött, hogy az adminisztrátoroknak lehetőséget lehet adni az esetleges késedelmes leadások, hibák büntetésére, aminek egyik módja a „pénzbírság” lehetne.
g) Abban az esetben, ha a program az előzőek szerint folyamatosan nyomon követi a vállalatok működését, akkor a játékosoknak segítségképpen megadhatja a mindenkori felhasználható tőkéjük mennyiségét. Ezáltal a döntéseik helyességérő vagy helytelenségéről gyors visszacsatolást kapnának. h) A programban rejlő lehetőség lenne, hogy a tanulókat az igények előrejelzésében segítsük, számszerűsítve vagy diagram formájában, különböző trendvonalakkal, illesztett görbékkel. Az előrejelzéseket akár meg is vásárolhatnák, ezzel a versenyhelyzetet lehetne növelni. i)
További lehetőség és segítség lehetne, az előrejelzésekkel összefüggésben, egy készletezési stratégiai modul, segítve, vagy akár automatizálva a megfelelő raktárkészlet és biztonsági készletszint
j)
A tanulók számára fontos lenne, hogy a játékban keletkező adatokat valamilyen formában le tudják menteni, és saját maguk által készített vállalatirányítási rendszerükben azt felhasználják. Saját előrejelzéseket, elemzéseket végezzenek, nyomonkövessék a raktárkészletüket és pénzügyeiket, ha ezeket nem tehetik meg a programban. A lekérdezés végeredményének egy széles körben használt fájltípusban, jól strukturált adathalmaznak kell lennie.
k) A játékba automatizált büntetéseket lehet elhelyezni, hogy a játékosokat tisztességes versenyre ösztönözze. Ilyen esetek lennének a késedelmes, hibás teljesítések, ki nem fizetett tételek, és a már fentebb említetett, a heti riportok hibás, késedelmes leadása. Ezeknek a büntetéseknek a beállítása a játék elején az adminisztrátorok feladata és lehetősége lenne a tanulók ösztönzésére, irányítására. l)
Az adminisztrátorok számára minél szélesebb körű beállítási lehetőségeket érdemes adni, hogy a programot a mindenkori oktatási célokhoz lehessen igazítani. A beállítások két fajtája a különböző segítségek és büntetések.
m) Az adminisztrátorok eszközei a szimuláció befolyásolására nem csak a segítségek és büntetések meghatározása, hanem a játék közben az éppen folyó tranzakciókra is hatással lehetnének. Egy szállítmány kalóztámadása, egy havária a kiszállításoknál, egy sztrájk a gyártóknál mind életszerűbbé teszi az illúziót, és közelíti a valóságot a váratlan, előre nem számítható problémákkal. A webes alapú változatot úgy akarjuk elkészíteni, hogy a fentebb említett emberi hibákból eredő problémákat, már maga a program kialakítása orvosolja. A szakmai feladatok elvégzésében nem az egyes problémák teljes megoldását akarjuk adni a tanulók részére, a célunk az, hogy olyan részmegoldásokkal segítsük Őket, amikkel az egész feladat megoldásának minőségét növelhetik, és így értékesebb tapasztalatokat szerezzenek. 3.3 A TDK-ra kitűzött célok Az ötletelés és a lehetőségek feltérképezése után fel kellett mérnünk, mit tudunk a felsoroltakból megvalósítani a TDK pályamunka leadási határidejéig. A cél az volt, hogy egy olyan alapot hozzunk létre, amit a következő tavaszi félévben már használni lehet, de a további fejlesztéseket is könnyen hozzá lehessen kapcsolni. A legfontosabbnak ítélt feladatunk az, hogy az FTP-s kommunikációt kiváltsuk a programmal, hogy az információáramlást, anyagáramlást és értékáramlást a webes felületen lehessen intézni. A kommunikáció megbízható működése elengedhetetlen a többi feladat elvégzéséhez.
A kommunikációhoz több kezelői felületet terveztünk, a csapatok és a játékot felügyelők és működtetők munkáját egymástól jól elhatárolva. A gyártók és kereskedők, a játékosok felülete, a különböző tranzakciók lebonyolítására, a játékosok, a tanulók részére. A kiskereskedők és a beszállítók felületei, a tanárok, ahol az ellátási lánc végpontjain levő szereplők intézik a tranzakciókat. Az adminisztrátorok, szintén a tanárok, de ezen a felületen lehet felügyelni a szimulációt, mindent könnyen meg lehet nézni és praktikusan át lehet írni. A tanárok be tudnak avatkozni az éppen folyó játékba, látják a résztvevő vállalatok tranzakcióit, és azokat meg tudják változtatni. Amit úgy kell felfogni, mint a hatását egy vállalatokon kívül, a játékosok által nem befolyásolható eseményeket, például egy „kalóztámadás” vagy egy sztrájk a beszállítóknál. A tervek szerint, ez a felület majd a széleskörű tesztelések után lesz véglegesen kialakítva. A kommunikáción belül két fajta tranzakció változatot különítettünk el, az egyszerű tranzakciókat, amelyek a játék egész folyamán jelenlévő kiskereskedőkhöz, és a tender tranzakciókat, amelyek a tendereztető vállalatokhoz, vevőkhöz tartozik. A tranzakciók típusai: -
Megrendelés kezelés: ezen belül a megrendelések adása a partnernek, és ezek visszaigazolás.
-
Anyagáram.
-
Értékáram.
A tender tranzakcióknál a megrendelések visszaigazolására nincs szükség, mivel a tender nyertesének a megrendeléseket már a tender pályázati anyagában meg kell terveznie, és a sikeres tender után megkötött szerződésben azt rögzíteni kell. Mind a kétfajta vállalattípusnál, gyártóknak és kereskedőknek, egyaránt szükség van a Forecast-ra, a vállalat folyamatainak tervezéséhez, a Cash flow ismeretére, mint visszajelzés a döntéseikről és a raktárkészletük felügyeletére. A heti riportokat minden csapatnak folyamatosan vezetnie kell, a játék szabályai szerint, és az adatokat tudniuk kell lementeni, a saját elemzéseikhez. A gyártóknak szükséges egy külön alkalmazás, amivel a gyártásukat tudják felügyelni, a 3.1 részbeli felsorolás c.) pontjában leírtak szerint. Ezt későbbiekben egy komplett termelésirányítási rendszerré lehetne fejleszteni. Az alkalmazás alapja a BOM listák, amiket a gyártók a programban kapnak meg, a játék kezdetekor. A kereskedők számára a körjáratszervezés modul, a 3.1 részbeli felsorolás h.) pontjában leírtak szerint, fontos lenne, ám ezt idő hiányában nincs módunk elkészíteni a TDK pályázat határidejéig. A 8. ábra színrendszerében mutatjuk meg, melyek azok a funkciók, alkalmazások, amelyeket mindenképp el akarunk készíteni a pályamunkákban, és melyek azok, melyeket részben vagy egészben csak a későbbiekben tervezzük megvalósítani. Ezzel már előre is mutatunk, hogy gyakorlatilag egy kicsi vállalatirányítási rendszert szeretnénk a jövőben létrehozni, mely kommunikál a partnerek között és teljesen kiváltja az FTP-s változatban használt Excelt.
SCSG Kommunikáció Tranzakciók Megrendelés kezelés Megrendelés feladás Visszaigazolás Anyagáram Értékáram Tender tranzakciók Megrendelés Anyagáram Értékáram Termelés – Termelésirányítás Körjáratszervezés Forecast Cash Flow Raktárkészlet felügyelet Heti riport
Zöld: A TDK pályamunkában mindenképp elkészül Sárga: A TDK pályamunkából részben vagy teljesen kimarad Világoskék: A TDK pályamunka után tervezett
Adatmentés
8. ábra: A SCSG felépítése, a kommunikáció kirészletezésével
További fontos elemei, tulajdonságai lennének a programnak, amelyek korábban már ki lettek fejtve a 3.1-es pontban, most csak felsorolva ezeket: -
a program stabil, felhasználóbarát kialakítása, az tranzakciók könnyű kezelése,
-
a tranzakciók végrehajtásának szabályai (napi egy (rész)tranzakció egy típusból),
-
az adatok kivezetése.
A 10. ábrán jól látszik, hogy a gyártók felé történő megrendelések esetében, a kezelőnek a paramétereket listásan kell kiválasztania, egyedül a darabárat kell manuálisan bevinni, a darabárat és az összeget a rendszer automatikusan számolja. A paraméterek kiválasztását azért kell listából megadni, mert így az elgépelésekre nincs mód, valamint ha a paraméterek nincsenek megadva, a rendelést fel sem lehet adni. Ezt a logikát a program többi felületnél is előnyben részesítjük.
A program jelenleg is fejlesztés alatt áll, az egész rendszer alapját jelentő adatbázis elkészült, most a program tesztverziójának írása folyik. Miután ezzel elkészültünk, utána következik majd az aprólékos, minden részletre kiterjedő tesztelés, és ennek alapján majd a hibák kijavítása. Az adatbázis kialakításánál végig az volt a cél, hogy ha a játék során változtatni akarjuk a szereplők, termékek, alkatrészek számát, akkor gond nélkül, dinamikusan meg lehessen csinálni. Például ha meg akarjuk változtatni, hogy egy hallgató melyik cégben dolgozzon, akkor a munkát az új csapatában a következő héttől már ott folytathassa. Az adatbázis több táblából áll, II. normál formulás és a lehető legkevesebb redundanciát tartalmazza, amellett, hogy minden szükséges információt képes tárolni. Vannak, illetve kialakításra fognak még kerülni kiegészítő táblák, melyek a cégek napi készletét, esetleg a pénzmozgásokat fogják tárolni. Az előzetes felülettervek bemutatása: a most bemutatásra kerülő egyszerű felülettervek csupán segédeszközök, hogy adatbázis felépítésében és a tesztverzió megírásában segítsenek minket. A vizuális megjelenítése a felhasználói felületeknek és a hozzájuk tartozó eszközöknek, funkcióknak a rendszer összefüggéseinek könnyebb felismerésére szolgálnak.
10. ábra: A kereskedői felület korai változata, a rendelések feladásának módja A nyitott rendeléseknél intézhetjük a kifizetéseket a gyártók felé. Pontosan fel lesznek tüntetve a rendelések jellemzői, hogy a vállalat folyamatairól naprakész információk álljanak a játékosok rendelkezésére.
A játékosok és üzemeltetők felületei: a megtervezett felületek számán és azok funkcióin nem tervezünk változtatni, mivel a játéknak ezt a részét a szabályok jól behatárolják.
11. ábra: Nyitott rendelések
9. ábra: A felhasználói és üzemeltetői felületek A kereskedők felületén szeretnénk két példát bemutatni: a rendelések feladását a gyártók felé, és a nyitott rendelések listázását.
5. ÖSSZEFOGLALÁS A játék FTP-s változatában jó eredményt értünk el, és már előtte is ambíciónk volt egy TDK pályamunka elkészítése, de még külön-külön. A játék féléve során, már sokat beszélgettünk az azt felügyelő tanárokkal, így nyílván való lett, hogy a webes platformú változat elkészítése csapatmunkában valósulhat meg, terjedelme és összetettsége miatt. Az Innovatív Logisztikai Kutatások Tehetséggondozó Műhely leadott pályázatunkat már együtt készítettünk el, a közös munka azzal kezdődött el. Az pályázat elnyerése után, ahogy már az FTP-s játék elején, most is behatároltuk és kiosztottuk a feladatokat. A webes platform megvalósítása folyamatos, de a fejlesztés üteme szeptembertől fog megélénkülni, amint mindenki visszatér az Egyetemünk székhelyére. Reményeink szerint a TDK pályamunka után sem fog a SCSG fejlesztése befejeződni, a csapat tagjai a diplomamunkájuk és szakdolgozatuk keretei között képzelik el a további munkát. A távoli cél az, hogy minden, ami VIR-ben megtalálható, és ami a többi ötletünk közül most kimaradt, azt mindmind beleépítsük a programba. Egy olyan összetett rendszer létrehozása, amivel a hallgatók egy termelő vagy kereskedő vállalat működését belülről átélhetik, és a legfontosabb folyamatot irányíthatják, valamint egy olyan szimulációs közeg megalkotása, ahol a hallgatók és tanárok logisztikai kutatásokat folytathatnak, elméleteket próbálhatnak ki ellenőrzött körülmények között, és újakat alkothatnak meg. Kívánatos lenne, miután a csapatunk megvalósítaná a saját ötleteit, elképzeléseit, hogy legyenek további hallgatók, akik a munkánkat folytatnák, és saját fejlesztéseiket beleintegrálnák rendszerünkbe. Emiatt is volt fontos, hogy az adatbázis kialakítása lehetővé tegye ezeket a későbbi változtatások, és a rendszer működőképes maradjon azok után is. Így a későbbi hallgatóknak legyen egy erős alapjuk, amire majd tovább tudnak építeni.
6. HIVATKOZÁSOK Dr. Bóna Krisztián, Kovács Gábor, Lénárt Balázs (2009). Egy ellátási lánc szimulációs játék (SCSG) modellje és az egyetemi oktatásban végrehajtott tesztelés gyakorlati tapasztalatai. Innováció és Fenntartható Felszíni Közlekedés Konferencia, Budapest, 2009. szeptember 24. Internetes hivatkozások: http://test.involvation.nl/en http://www.gscg.org
