Termelésütemezés-II

A KKV szektor esetén a kulcskérdés az, hogy milyen bonyolultságú ütemezést képes a cég elviselni. Ennek eldöntésére hoztam létre a „Tanulmányrendszert”, amely többszintű ütemezési és elszámolási eljárást tartalmaz. Segítségével ERP, – ill. termelésirányítási rendszer nélkül lehet megszervezni a digitális termelést.

Termelésütemezés feladata a munkák hozzárendelése a cég erőforrásaihoz, melyeket azok főbb adatainak megadásával modellezzük. A figyelembe veendő erőforrások általában a személyek, csoportok, kompetenciák, munkarendek, műszakok, gépek, gépcsoportok, munkahelycsoportok, munkahelyek, szerszámok, nyersanyagok, alkatrészek, fődarabok, részegységek, félkész termékek és kapacitások valamint maga a technológia.

Alapjaiban határozza meg az ütemezést (és annak sikerét) az is, hogy mit tekintünk elvégzendő munkának, mi a szervezési egysége, amit egyébként pontosan meghatároz a cég gyártási és értékesítési stratégiája.

A „PULL” rendszerű gyártásban (vevői megrendelésre történő gyártás) a termelési egység egy megrendelés. A vállalkozási (rendelési és szállítási) egység tartalmazhat több terméket is, de egy gyártási egység (egy batch) tipikusan egy termékfajta legyártását tartalmazza. A termékek komponensekből (beépülő egységekből) szoktak állni, ezért az ütemezésnek valahogy tartalmazni kell a beépülő egységek (alkatrész, főalkatrész, részegység, félkésztermék) gyártási előírását és ennek sorrendjét is.

A gyártásba-adásnál több lehetőségre kell készülni.

• Ha az igényre történő gyártásnál a cél a magas forgási sebesség elérése, akkor a teljesítést végszereléssel kezdjük és a szükséges elemeket raktárról biztosítjuk. Ilyenkor nincs optimalizálás, így ez a vállalkozási stratégia általában magasabb árat igényel, de ez általánosan elfogadott a piacon. A megoldás értelemszerűen magas készletet eredményez, ami ha a termék önköltsége nem túl magas, akkor nem okoz problémát. Természetesen a beépülő elemeket is le kell gyártani, ezért az ezekhez tartozó munkautasítást is el kell készíteni. Ez történhet a végszereléssel párhuzamosan vagy egy feltöltési gyártással is. Optimalizálásra ott van lehetőség, hogy a feltöltés illeszkedjen a megrendelésállományhoz pl. úgy, hogy elsősorban olyan kapacitás lekötő elemeket gyártsak, amire a következő három hónapban szükség lesz. 

• A következő lehetőség, hogy először optimális sorrendben legyártjuk az alkatrészeket, majd összeszereljük a terméket. Ez a módszer alacsony készletszintet eredményez, de magas a rendelés átfutási ideje. Az elemek gyártási sorrendje optimalizálható, de a tapasztalat azt mutatja, hogy nagyon kicsi a nyereség az optimalizálási idő viszont igen nagy. Ha a beépülő elemek önköltsége magas, akkor ez a jó megoldás. A tanulmányrendszer genetikus eljárással optimalizál.

• A vegyes módszernél a végszerelést készletről kezdjük le, közben folyik a beépülő elemek előállítás is, így nem kell az összes alkatrészt készletezni, ennek ellenére alacsonyabban lehet tartani az átfutást. Érdekes módon ehhez sem kell optimalizálni, ugyanis a műveleti sebességek alapján már a tervezési fázisban is megvannak az optimális indítási időpontok. Ezt az információt a tanulmányi rendszer úgy kezeli, hogy a technológiában megadható a termékek indítási eltolásának a mértéke.

• Ha a gyártási egységet több megrendelés alkotja, de a rendelések legyártásának sorrendjét továbbra is a szállítási határidő szabja meg és a rendelések fázistermékek a gyártás során nem keverednek, akkor sincs értelme az optimalizálásnak.

• Ha a gyártási egység több megrendelés, de az azonos elemek gyártását összevonjuk és a megrendelés elkészülésének sorrendjét nem a szállítási határidő szabja meg, hanem gyártási finom-programokat képezünk (pl. hetes, kéthetes bontásban), akkor lehet értelme az optimalizálásnak. A tapasztalat azonban azt mutatja, hogy ilyen nagyságú finom-programok esetén az optimalizálás nem gazdaságos. A tanulmányrendszer itt is genetikus optimalizációt alkalmaz. Az optimalizáció bármikor megszakítható, mindig legyártható program áll rendelkezésre.

Elvben maga a termelésirányítási rendszer el tudná dönteni, hogy milyen eljárást kell alkalmazni, de ezt a funkciót nem szokás implementálni. A tanulmányrendszer is csak egy választási lehetőséget tartalmaz, a döntés a termelésprogramozóé.

Ezeknél a stratégiáknál (mindegyik PULL stratégia) nincs értelme minimális sorozatnagyságról beszélni, de célszerű kialakítani minimális rendelési nagyságokat (ami azért lehet egy darab is). Ahol optimalizálás nem hoz komoly eredményt, az optimalizálásra fordított költség nem térül meg. Egy jobbnak nevezhető otimalizációs eljárás kb. annyiba kerül, mint maga az ERP rendszer. Véleményem szerint a termelésoptimalizálást meg kell hagyni a PUSH rendszereknek.

Az ütemezés sok gyártási paraméterre van hatással:

1. határidők tartására,
2. raktári készletszintekre,
3. műveletközi készletek szintjére,
4. átlagos folyamidőre,
5. kapacitáskihasználásra,
6. átállási időkre,
7. dolgozói létszámra,
8. egyéb gyártási költségekre.

Jól érzékelhető, az ütemezés célja nehezen fogalmazható meg, és minél bonyolultabb célt tűzünk ki, annál nehezebb (és drágább) a megoldás. A kulcskérdés az, hogyan lehet meghatározni azt a paramétert, amellyel jellemezni lehet az ütemezés sikerét. Olyan kell amit viszonylag könnyű számolni. Ilyen pl. az állásidő vagy a kapacitáskihasználás, de ezek nem jól jellemzik a termelést. Viszont jól kezelhető a költség, amely egyidejűleg alkalmas a gépi és a humánerőforrás kihasználtság minősítésére is. Erre az ad lehetőséget, hogy a rezsiórabérek és az állási órabérek bevezetésével számolható az önköltség és a bruttó nyereség. A bruttó nyereség maximalizálása egy jó mérőszám. A rezsiórabérek kiszámolása azonban kihívás elé állítja a könyvelést, a rendszernek pedig meg kell oldani a veszteségek felosztását és a félkész termékek értékének meghatározását.
A rezsiórabért nem kell feltétlen tényleges költségnek tekinteni, ez valójában egy mérőszám, amely egyes erőforrások fontosságát mutathatja. Elegendő lehet fokozatosan hozzáigazítani a tényleges költséghez. Azért  fontos, mert a KKV szektorban a pontos költségfelosztás ritkán áll azon a szinten, hogy a könyvelés rezsiórabért tudna számolni. Ez általában egy önálló projekt.
A Tanulmányrendszer tud  bruttó nyereséget számolni.

A KKV-k esetén a rugalmasság ritkán egyeztethető össze a kapacitáskihasználás maximalizálásával (legyen az termelőeszköz vagy munkaerő kapacitás) és a gyártási költségek minimalizálásával. Aztán vannak paraméterek, amelyeket az üzem adottságai korlátoznak, pl. a műveletközi készletek. Ezeket stratégiai szinten kell elfogadni és kezelni.
Jól ismert ütemezési modellek olyan követelményeket támasztanak, amit – pont a rugalmassága miatt életképes KKV-k esetében a legegyszerűbb gyártás sem tudja teljesíteni. Az irodalomban található jól ismert megoldások olyan iparágakra alkalmas, mint pl. az autógyártás, a nehézvegyipar, vasgyártás, stb.

A KKV környezetben a termelésirányításnak működnie kell fejlett ütemezés nélkül is. Ekkor ki kell állítani a kísérőlapokat vagy munkautasításokat, amit az üzemvezető oszt ki a személyes tapasztalata alapján. Ha ehhez tartozik egy jó minőségű elszámolás ez is vezethet jó eredményhez. Sőt egy egyszerű, de gyorsan változó, rugalmas termelés esetén egyszerűen ez a legjobb megoldás.

A tanulmányrendszer ennek három szintjét biztosítja, ami lehetőséget teremt a fokozatos bevezetésre.

1. Az első  szinten papíralapú dokumentumokat készítünk és a gyártási tényadatok rögzítése kézzel történik.
2. A második szinten még mindig papíralapon történik a munkautasítások kiadása, de az elszámolás már elszámolóterminálokon történik és maga a munka elvégzője számol el.
3. Harmadik szinten, már csak digitális munkautasítás van.

Az első két megoldás nem is igényel idő szerinti pontos ütemezést, a rendszer csak a gyártási sorrendet írja elő, a munka kezdésének és befejezésének az időpontját nem. Ez azért fontos, mert az időütemezés meglehetősen nehéz és felkészültséget igénylő munka.

Számítani kell arra, hogy gyakorlatilag minden cégnek és gyártási megoldásnak saját ütemezési eljárása lesz, ráadásul KKV szinten mindig biztosítani kell az újratervezést és a közvetlen kézi beavatkozást is. A Tanulmányrendszerben ez azt jelenti, hogy minden céghez készül egy ütemezési eljárás.

A digitális termelésirányítástól azt várjuk, hogy sok feladatot vegyen át az embertől.  Ahhoz, hogy ezt meg tudjuk oldani és a feladatokhoz el tudjuk készíteni a szoftvert bizonyos feltételek teljesülését elő kell írnunk. Ezek zöme magától értetődő, ezért nem fűzök hozzá magyarázatot. Ha valamelyik feltétel nem teljesíthető a gépek vagy a termékek tulajdonsága miatt, akkor egy új programot kell rá írni vagy egy meglévőt kell módosítani. Van olyan feltétel amely kihagyása nagy többletköltséget igényel.

1. a műveletek sorrendje előre meghatározott,
2. egy művelet csak egy gépen hajtható végre,
3. a művelet nem megszakítható,
4. műveletek nem maradhatnak ki (a kivitelezésnél),
5. a folyamat elején a műveletek rendelkezésre állnak,
6. lehet gépállítás,
7. a gyártási egység az egy késztermékre vonatkozó megrendelés,
8. lényegesen eltérő termékek gyártása követheti egymást,
9. egy munkatárs egy időben csak egy műveletet végez,
10. egy munkatárs több műveletben is kompetens lehet.

Tekintsük át azokat az ütemezési modelleket, amit tudni kell egy ERP rendszernek. Az ütemezésnek két szintjét különböztetjük meg. Amikor a program csak a műveletek sorrendjét adja meg és azt, amikor óra/perc pontossággal megadja a kezdés és befejezés időpontját is. A megrendelések és a műveletek sorrendjétől és ezek átfedésétől függően több lehetőség van.
Ezek a következők:

Tisztán soros rendelésre-gyártás
A modell jól és pontosan írja le azt a gyártási folyamatot, ahol egy munkatárs végzi az összes műveletet, gyakorlatilag korlátlan műveletközi tárolóhely van, a munkahelyek láncban vannak és az egyik művelet befejezése után a következő műveletet végzi a munkatárs. A művelet kezdőpontját kézzel adja meg a művezető és az egyik megrendelés elkészülte után indul a következő megrendelés legyártása, de az is egy önálló gyártási egység és nem automatikusan láncolódik az előző megrendeléshez.
A modellhez tartozó alapmegoldás:

A modell elsősorban a maximális átfutási idő meghatározására szolgál. A gyártás minimális humánerőforrás költséggel folyik, de a gépkapacitás kihasználtsága nagyon rossz. Ha gépre tesszük ezt a gyártást, akkor a batch kezdetét kézzel szokás megadni, de többi időpontot a rendszer számolja ki.
Van ilyen gyártás, de ezek nagyon kis kézműipari cégek, ahol sohasem térül meg a digitális termelésirányítás.
A tanulmányrendszer kezeli ezt a modellt.

A műveleteket eltérő munkatársak is végezhetik
A KK szektor elején találunk ilyen cégeket. A könnyűiparban a bonyolultabb kézműipari terméke esetén szokás használni. A gyártás vezérlésére jól használható a kísérőlap.
Óvatosan kell megítélni ezt a rendszert, mert ezeken a helyeken gyakran bonyolultabbak a termékek és a gyártási rendszerek, mint az autógyártásban.

Ez egy rendkívül gazdaságtalan megoldás miután a humánerőforrás és a gépkapacitás kihasználása is alacsony.

 

Ezt az ütemezést használjuk a bevezetési szakaszban, amikor a jelentősége csak a műveletek egymásutániságának kijelölésében van. de alkalmas arra is, hogy adjon egy biztonságos vállalási határidőt. Az ütemezéssel egy-időben elkészül a munkautasítás, ami már tartalmazza a műveletek sorrendjét. Az elszámolóterminálok feladata a művelet sorrendjének a betartatása. Az ábra azt a helyzetet mutatja, amikor egy művelet az előző művelet befejezésekor indulhat el.
A tanulmányrendszer kezeli ezt a modellt.

Részben átfedő munkavégzés.
Az operatív munka során az elszámolóterminál segítségével már a termelési tényadatokhoz igazodó ütemezés mellett párhuzamos műveletvégzés folyhat, amely a fenti ütemezési tervnél sokkal jobb eredményt biztosít. Technológiában ugyanis megadható, hogy egy művelet adott százalékos készültségénél már elindítható a következő művelet.

Mindig ezt a modellt kell használni a rendszer indításánál, mert nem szükséges hozzá jelentős szakmai ismeretet megkövetelő időütemezés. Ekkor a rendszer elkészíti a megfelelő sorrendet tartalmazó munkautasításokat, de nem rendel hozzá kezdési időket. A technológiában beállítható, hogy a következő műveletet mikor lehet elindítani. Az alapértelmezés az, hogy az előzővel együtt. Ilyenkor a műveletet elvégző munkatárs részéről feltételezzük azt a természetes intelligenciát, hogy a munkatárs képes eldönteni, indulhat-e a művelet.
A tanulmányrendszer kezeli ezt a modellt.

Gyártási szálak használata
A tanulmányrendszerben az egymástól független műveleti láncokat, a gyártási szálakat is tudjuk kezelni.

Az alapmodellben a gyártási szálak elejének időpontját kézzel adjuk meg. A gyártási láncokkal megjelentek a szervezett párhuzamos műveletek, amelyek már ütközéseket is eredményezhetnek amiatt a feltétel miatt, hogy egy munkatárs egy időben csak egy művelet végezhet. Ezek üzenetek generálnak.
A művelet megtervezésekor kialakítandó gyártási szálak használata nélkül nem beszélhetünk gazdaságos gyártásról.
A nagy-értékű eszközök gyártásánál jól használható modell.

Korlátozott műveletközi tárolóterület figyelembevétele
A modell annyiban változik, hogy a műveletek elvégzése után be kell iktatni egy logisztikai lépést, amikor a fázisterméket egy tárolóterületre szállítják. Ezt végezheti a művelet gazdája is. Ha logisztikai feladatot a művelet végző munkatárs látja el, akkor nem kell önálló lépésként felvenni, hanem lehet a művelet része is, amit a művelet „leállási” fázisába lehet beépíteni. Ugyanez igaz a műveletek elején is, ha a következő műveletet végző feladata a munkadarab munkahelyre szállítása, ekkor a ráállási fázis használható.

A logisztika növeli az átfutási időt, mert csak ennek végeztével kezdhető el a következő művelet. Ez az idő nem vehető figyelembe a darabidő meghatározásánál.

Gyakori verzió az, amikor a fázisterméket egy műveletközi tárolóterületre szállítják, ahol hosszabb rövidebb ideig áll. A fázisterméknek ilyenkor nincs cikkszáma és nem vezetjük a készletét sem. A szabályos raktári kezelés azért nem valósítható meg, mert nincs a fázisterméknek cikkszáma. Ennek ellenére elvárható vezetői igény, hogy a műhelyközi készletek is ismertek legyenek. Ez speciális raktárakkal megvalósítható. A következő művelethez erről a tárolóterületről szállítják a munkahelyre. A két művelet között jelentős idő is eltelhet.
A tanulmányrendszer kezeli a ráállási és leállási fázisokat.

Logisztikai riasztás
Ha egy művelet befejezése után a termékeket egy másik tárolóterületre kell szállítani és ehhez logisztikai munkatárs (pl. emelőtargonca) bevonása szükséges, akkor riasztás adható ki. Ilyenkor a logisztikai művelet nincs beépítve a technológiába. A riasztás azt jelzi, hogy a szállítási feladat lépett fel. A riasztás lehet mail, SMS, hangjelzés, fényjelzés vagy bármi más, aminek kezelése technikailag megoldható. A riasztás egy eszköz kezelését indítja el, amikor a művelet befejeződött (vagy megkezdődött). A riasztást nem az ütemezés váltja ki, hanem a termeléselszámolás, tehát mindig valós időben történik.
Riasztás előírása a művelethez tartozik, bármelyik művelet bármilyen fizikailag realizált riasztást kiadhat.
Az alább megoldás a folyamatos műveletvégzésnél késleltetheti a művelet végrehajtását, ezért inkább a késztermék vagy a gyártási szálak végén, az összevárási időszakban célszerű használni.

A jól megtervezett eljárásokban a logisztika nem késlelteti a többi műveletet.

Ehhez a megoldáshoz ki kell alakítani a gyártási szálakat

A logisztikai művelet kezelheti a raktárat, de ehhez az kell, hogy a raktári rendszerben létezzen a műveletközi raktár. Ilyenkor a végtermék azonosítója használható cikkszámként. Ennél ritkább megoldás, hogy a fázistermékeknek is van önálló cikkszáma. A raktárkezelés a művelet ráállási és leállási eseménye végzi.
A tanulmányrendszer kezeli ezt a modellt.

Átfedéses gyártási programok
A műveletek tervezési fázisában meg lehet határozni, hogy milyen átfedés esetén érhetjük el a legkisebb átfutási időt. Ennek egyik módja, hogy a csomag műveleteket hozunk létre, azaz az arányos műveletet adott nagyságú szakaszokra bontjuk. Csomagművelettel akkor jó dolgozni, ha a technológiában fizikailag is megjelenik a csomag. Ezt bizonyos műveletek esetén a művelet jellege is megköveteli, pl. egy vágási művelet esetén a gép képessége, az anyag jellege meghatározza, hogy hány tábla vágható fel egy fogással. Ugyanez igaz a kézi műveletnél is, ahol az anyag súlya jelent korlátot. Van olyan eset is, amikor a gazdaságossági szempont miatt kell meghatározni egy minimálisan legyártandó mennyiséget. Ezeket az egységeket nevezzük a továbbiakban gyártási csomagoknak. Ezt az adatot a művelethez rendeljük. A gyártási csomag nem azonos a Batch-el, mert ilyenkor a csomag nem kap önálló adagszámot, hanem csak technológia csoport keletkezik, miután a munkavégzés körülményei és a felhasznált anyagok forrásai nem változtak.Ha ilyen nincs fizikailag megjelenő csomagméret, akkor százalékos formában határozzuk meg a következő művelet elejét.

Tehát a műveletnek van egy ráállási és leállási része, és van egy arányos része, amit annyiszor végzünk el, ahány munkadarabot le kell gyártani. Ezt az arányos részt osztjuk fel csomagokra.

A műveletek megadásánál a csoporthatárok mentén is kérhetünk riasztást és a csoporthatárokhoz is illeszthetünk művelet kezdést.

Az is használható, hogy a riasztás csak a következő művelet elkezdését engedélyezi. Ekkor a gyártási terv tartalmazhat egy nagy megbízhatóságú teljesítési határidőt, ami az operatív fázisban radikálisan csökkenthető.

Riasztások kezelése
A csoporthatárokhoz rendelt riasztás a logisztikai folyamatokat is vezérelheti. Ehhez az szükséges, hogy a munkatárs gyakrabban adja meg a termelési adatokat, Pl. adott számú gyártási csomag elkészülte után a terminálon meg kell adni az elkészült és a selejtes mennyiségeket. Ilyenkor a terminál egyszerre engedélyezi a logisztikai és a következő művelet elkezdését, mert már összegyűlt akkora input anyag, ami biztosítja a folyamatos munkavégzést.

Ez a modell és a korábban bemutatott „Részben átfedő” munkavégzés között az az eltérés, hogy ez mér a tervezési fázisban megjelenik és tartozhat hozzá időütemezés, míg az előző csak a gyártási fázisban van jelen.
A tanulmányrendszerben nem realizáltam ezt a lehetőséget, de fel van rá készítve és szükség esetén bővíthető vele.

Érezhető, hogy ez a modell egy pontos technológiai tervet igényel, amelyhez képzett szakember szükséges. Miután ekkor már nélkülözhetetlenek a pontos, jól beállított műveleti idők, ezért ez általában egy későbbi fázisban indítható el.

Bérmunka kezelés
A bérmunka kezelése egy kritikus része a termelésnek. Leghelyesebb, ha a gyártási folyamatban egyáltalán nem építünk bérmunkára. Nem sorolom a bérmunkához azt az esetet, amikor a bérmunkás, a munkaeszközeivel együtt a műhelyen belül található.

A szerződéstől és a gyártás adottságaitól függően egy bérmunka vagy bármikor elkezdhető – pl. raktárra történő gyártáskor, vagy csak adott napokon történik a kiszállítás és adott napon a visszaszállítás (pl.: hétfő-péntek), ámbár lehet eseti is a folyamat, amikor akkor szállítjuk ki a félkész terméket, amikor a bérmunka-tevékenység előtti utolsó művelet elkészült. Ha bármikor kezdhető, akkor lehet arányos is a művelet, így ki tudjuk számolni az átfutási időt. Ez szerződés kérdése. Történhet a folyamat szerződés vezérelt módon, ilyenkor pontos ütemezési és költség adatokat az ajánlatban kapjuk meg. Ezeket értelemszerűen kézzel kell megadni az ütemezésnek, de nagy hátránya az is, hogy megnöveli az átfutási időt. A bérmunka vezérlése kiemelten fontos kérdés az egyedi igények alapján történő könnyűipari termékek gyártásánál.
A tanulmányrendszer kezeli a bérmunkát.

Összefoglalás
Ennek a modellnek az volt a lényege, hogy a szerződések teljesítése vagy nem fedték át egymást vagy átfedték ugyan, de mindvégig megmaradt a megrendelések teljesítési időpont szerinti sorrendje. A megrendelések teljesítését kézzel indíthatjuk el a kezdés időpontjának megadásával, de automatikusan egymáshoz is láncolódhatnak a műveletek.
Ez a helyzet a gyakorlatban úgy jelenik meg, hogy a vevői megrendeléseket egyenként vesszük gyártás alá és nem képezünk finom-programot. Ilyenkor természetesen az optimalizálásnak nincs meg a feltétele.

Ezek a modellek jól érzékeltetik, hogy milyen gondosan kell megtervezni egy termék gyártását. Láttuk azt is, hogy a logisztikai (és pl. a minőség-ellenőrzési) folyamatokat akár be is tervezhetnénk a technológiába, a riasztásos megoldás azonban sokkal életszerűbbé teszi a gyártás folyamatát.

Párhuzamosan futó megrendelések legyártása (finom-programok képzése)
A legyártandó megrendelések ebben a modellben is termékekre bontva érkeznek és a gyártási alapegység továbbra is egy termék adott mennyiségben történő legyártása. A gyártáshoz szükséges minden beépülőelemhez (alkatrész, részegység, fődarab, stb.) itt is önálló digitális (bár kinyomtatható) munkalapok készülnek. A megrendeléseknek van egy állapotjelzőjük (továbbiakban státusz), A munkalapok gyártásba adáskor „Nyers” állapotban vannak, ami azt jelenti, hogy a megrendelési fázis befejeződött a termék valamikor legyártható. Amikor gyártás alá vesszük a „Programozás modul” „Nyitott” állapotba helyezi a munkalapokat. A nyitott munkalapok alkotnak egy gyártási finom-programot. A finom-program minden késztermék tétele legyártásra kerül. Célszerű a finom-programot úgy kialakítani, hogy egy rögzített időtartam (pl. egy hét) kapacitását kitöltse (bár konkrétan nincs korlátozva a finom-program hossza). Célszerű lehet a nagy rendeléseket kisebb egységekre bontani (a szállítási egységekhez lehet igazítani).

Az operatív program (konkrétan mikor mit gyártunk) munkalaponként keletkezik, a munkalapok sorrendjét és a kezdési időt a rendszer kiszámítja. Az eljárás most is lehet olyan, hogy a teljes szükségletet legyártja, de lehet olyan is, hogy csak a szabad készlettel csökkentett mennyiségeket gyártja le. Az operatív program összeállítását követően az esetleges holtidőket fel lehet tölteni a „Nyers” állapotú tételekből, amit raktárra fog gyártani. Ha ezzel nem találja meg a gazdaságos összeállítást, akkor veszi a készletfeltöltési állományt és abból tölti fel a finom-programot hiányzó tartományait. Sajnos miután a legtöbb gyár azonos technológiai sablonon alapuló termékportfóliót alakít ki, ez ritkán hoz jó eredményt.

Minden művelethez tartozik egy alapértelmezett munkatárs, munkahely és gép. A munkahely, munkahely-csoportokhoz, a gép gépcsoportokhoz tartozik. Bár ezek homogén csoportok, ennek ellenére előírható a programozási sorrendjük. A programozás mindig az alapértelmezett munkatársat, munkahelyt és gépet próbálja betervezni. A munkatársaknak van egy művelet kompetencia sorrendje, meghatározva milyen műveleteket végezhet, de ez a sorrend jellemezhet hozzáértést is. A programozásnál a sorrendet szinten figyelembe vesszük, egy alacsonyabb kompetenciájú munkatársat csak akkor programozunk, ha ez nélkülözhetetlen.
A modell nem biztosít optimumot, de jól közelíti azt. A finom-program célfüggvénye lehet a legrövidebb teljesítés, fő teljesítménymutatója lehet a munkaidő kihasználás vagy a tervezett bruttó nyereség. Ha a munkaidő kihasználtság tartósan kedvezőtlen értéket mutat, akkor a cég termékportfóliója és erőforrás struktúrája nem illeszkedik egymáshoz.
A finom-programot a rendszer automatikusan állítja össze a kijelölt gyártási megrendelésekből.

Ha pl. a gyártásba adott megrendelések technológiája a következő:

Akkor az algoritmus ezt az ütemezést szerkeszti össze:

A piros időtartományok a kieső időket mutatja.
Ez tudja a tanulmányrendszer.

Jobb eredmény érhető el, ha engedélyezzük a műveletek bontását:

Ez a modell a bontást csak akkor engedélyezi, ha a műveletnél nincs önállóan elszámolt gépállítási tevékenység vagy biztosított az, hogy a gépállítás és megmunkálási művelet nem válik el egymástól. A bontás engedélyezése általában új adagszámot eredményez, mert a gyártási körülmények változhatnak a gyártási szakaszok között.
Ez a modell nincs implementálva a tanulmány rendszerben.

Munkahely-csoportok használata
Az eddigiek figyelembe vettek egy olyan előírást, hogy egy művelet csak egy munkahelyen folyik, de ez a feltétel sokszor nem teljesíthető vagy nagyon rossz eredményre vezet.

Ha a művelet sok termékben előfordul, akkor célszerű több munkahelyet létrehozni a művelet számára, ami kétféleképpen kezelhető.

• Ilyenkor a művelet eleve munkahely-csoportot tartalmaz és nem alapértelmezett munkahelyet és az ütemezés választja ki a munkahelyet és egy munkatársat. Ekkor a munkahelyeken ugyanaz a művelte folyik, de a műveletek más-más elem legyártásához tartozik. A további munkahely bevonása csak akkor történik meg, ha az alapértelmezett munkahely már foglalat. A munkahely kijelölésénél figyelembe lesz véve a munkahelyek preferenciája, amely a munkahely csoportokban van megadva.

• A másik lehetőség, hogy egy termék előállítása eleve párhuzamos műveletekre lettek tervezve. Ilyenkor meg a technológia többször tartalmazza ugyanazt a műveletet.
  Ez nincs implementálva.

PUSH mód használata
Valóban használható optimalizáció legfeljebb a raktárfeltöltésére indított gyártás esetén képzelhető el, amikor a gyártás összeállítása kizárólag a költséghatékonyságot célozza meg. Sajnos ez is nagy raktárkészletet eredményez és nem is igazán életszerű.
Ebben a modellben a raktárfeltöltés egy önálló, automatizált programozási modult tartalmaz.
A tanulmányrendszerben csak a feltöltés legyártása van implementálva, de ehhez az szükséges, hogy egy importtal át tudja venni a rendszer a raktárkészletet, tehát a tanulmányrendszert össze kell kapcsolni az ERP rendszer készlet moduljával.

Összefoglalás
Ha a finom-program több szerződés összevonásából jön létre, akkor kisebb veszteségű ütemezéseket lehet készíteni, de még így is magasabb árat eredményez ez a vállalkozási forma.

A fenti az ábrák csak egy – bár a legfontosabb – dimenziót szemléltetik. Miután a műveletekhez nyilvántartunk rezsórabért, állási költséget, a bérmunkához pedig beszerzési értéket ezért az operatív programhoz rögtön megkapjuk a költségeket és a kihasználtsági mutatókat is. A költségek növekedését a munkaerő kihasználás vesztesége, a gépek állási vesztesége okozza és ezekre is rendelkezésre áll adat.

Mindezt összefoglalva jelentősebb eredményt az automatikusan összeállított ütemezéstől, az ellenőrzéstől, a folyamatok jobb megismerésétől és kézben-tartásától várom, nem pedig az optimalizációtól.

 

___________________________________________________________________________________________
@Kupán Károly (2020)                                                                        v1.04                                                                  Kupan.Karoly@Kupan.hu