Egy nagyon „korszerű” rendszer

Példaként nézzünk meg egy igazán korszerű, felhőben futó, mesterséges intelligenciát tartalmazó megoldást. A freemium értékesítési taktikájú rendszer pont az általunk is jövendölt struktúrájú, azaz adott egy tetszőleges ERP rendszer és ehhez appok segítségével kapcsolódik a termelésprogramozás. Magát APS-nek (Advanced Planning and Scheduling – fejlett tervezés és ütemezés) nevező, sok üzleti feladatot ellátó, agresszív marketinggel rendelkező rendszerrel beszélünk.

A klasszikus termelésirányítási elveken szocializálódott szakember számára ezek a korszerű termelésirányítási rendszerek annyira meglepőek, mint a brüsszeli nyitott utcai WC-k. Az ember csak áll és leesett állal bámulja a Budi Buildinget.

Brüsszelben a sétálóutcákban találhatók olyan kissé meghajlított és szélein összehegesztett lemezből álló objektumok, amelyek rendeltetését nem volt egyszerű felismerni. Azonban kellő kitartással elérhető, hogy üzem közben is láthassa az ember. Ezek háromszemélyes WC-k, egy időben akár három ember is odaállhat és elvégezheti sürgős teendőjét.

Többféle dizájn is van

Nehéz minősíteni az ötletet. Nem is akarom. Persze van, aki számára egyszerűen elfogadhatatlan, bár azoknak, akik már ennek látványával nőnek fel, meglehet már teljesen természetes lesz. És van, akinél egyszerűen nem működik. Hiába állsz oda, nem megy. Ez a megoldás a társadalom egy jelentős részét azonban kirekeszti, pl. a nőket, akiknek egyébként sokkal nagyobb szükségük lenn rá, mint az egészséges férfiaknak.
Az érdekesség kedvéért megjegyzem, hogy a római korban teljesen természetes volt a sokszemélyes nyilvános WC.

 Ennek az elvnek az a lényege, hogy egy folyamat környezetét annyira leegyszerűsítjük amennyire csak lehet, cserébe lemondunk bizonyos felhasználókról.

Ezeknek a korszerű rendszereknek a szemlélet annyira más, mint az én (a szerző) klasszikus termelésirányítási szemléletem, hogy érdemes a két gondolkodásmódot összehasonlítani.

Először nézzük meg a rendszer stratégiáját és annak termelésirányítási reprezentálását. A rendszerben nincsenek igazi törzsadatok. Van anyag és van alkatrész és slussz. (Van továbbá szülő termék, ami egy teljesen új dolog.) Tehát a nyersanyag, alapanyag, göngyöleg, segédanyag ….. főalkatrész, részegység, félkésztermék stb. stb. eltűntek.
Érdekes a termék modellezése is.

A termékmodell (katt a képre)

A bal oldalon van a termék neve, az alkatrészek és az anyagok jegyzéke, jobb oldalon a műveletek. Azaz, az anyagok nem a művelethez vannak rendelve, hanem magához a termékhez.
Mit jelent mindez a gyártás szempontjából? A termék és alkatrész struktúra azért van, hogy az eltérő igényű elemeket a tulajdonságaiknak megfelelően lehessen kezelni, ez határozza meg honnan lehet beszerezni, hogy kell tárolni, milyen minőségi követelmények vannak velük szemben.
Az anyagokat és alkatrészeket azért a gyártási lépéshez (vagy a művelethez) rendeljük, hogy a logisztika pontosan tudhassa melyik anyagot melyik géphez kell kihelyezni.
Ez most mind elveszett.

Nézzük meg a gyártási megrendelést.

A bal oldalon van, hogy milyen terméket kérünk és mennyit, a jobb oldalon pedig, hogy milyen technológiával. A kis lépcsőre kattintva pedig azonnal ütemezi is.
Szupi.

Gondoljunk ennek utána kissé.
Ehhez az szükséges, hogy a vevői rendelés értelmezését és a gyártási megrendelés rögzítését egy olyan munkatársra bízzuk, aki képes értékelni a meglévő technológiát, ismeri a gyártási eljárásokat, az anyagokat, azok normafüggését, így képes sebtében belenyúlni a technológiába és rögtön ütemezni is.
Félő, hogy ilyen embert a föld nem hord a hátán.

Amikor az élet úgy hozta, hogy egy csúcsminőségű, számítógép vezérelt, gyönyörű ufó dizájnú, futóbetűs üzeneteket megjelenítő, zenélő kávéfőzővel – természetesen távmenedzseléssel – magamnak kellett volna kávét főzni, akkor volt egy pont, amikor a szakszerű és határozott utasítás ellenére, néhány puha próbálkozás után azt mondtam, én ezt a kart nem nyomom le.
A vadi új kávéfőző egy hónap múlva tönkrement. Természetesen azonnal cserélték és azt írták, bocs, ezt elterveztük.
Az, aki ezt tervezte az nem volt mérnök, nem tanult sem anyagismeretet, sem statikát. És soha nem volt pajszer sem a kezében. A javítás vélhetőleg abból állt, hogy egy alkalmatlan műanyagból készített bizbaszt kicseréltek egy másik alkalmatlan műanyagra, pedig oda minimum titán kellene.
Gondolom belépett ebbe a rendszerbe és a műanyagot hirtelen elhatározással átírta egy másik műanyagra.

A termék tervezésének, az anyagok kiválasztásának, a technologizálásnak megvan a maga eljárása, amire ez rendszert emelt fővel fittyet hány.
Ez a program generálja a rossz megoldásokat.
Szóval így keletkezik az a mérhetetlen mennyiség szemét, amit már nem tudunk hova tenni.

Az biztos, hogy a klasszikus termelésirányításnak változnia kell. A gyártás természeti és társadalmi környezete olyan mértékben változik – felmelegedés, időjárás változás, a víz hiánya, egyéb erőforrások hiánya és ezek következtében elinduló népvándorlás – amire választ kell adni. Ezeknek a hatása az ellátási láncban összegződnek, mégpedig a munkaerőhiány, az anyaghiány és szállítási bizonytalanság formájában.
A termelésirányítási rendszerek előtt két út van.
A merev szabályok lebontása és az ellátási lánc menedzselése.
Jó lenne, ha a szabályok lebontása nem menne sem a hatékonyság sem a minőség rovására, ami csak úgy képzelhető el, ha a termék, a termelés és a termelésirányítás együtt alakul az új helyzethez.
A másik az SCM (Supply Chain Management), azaz az ellátási lánc kézbentartása. Az SCM már az ellátásra helyezi a hangsúlyt és le kell, hogy váltsa az ERP rendszert. Az alapelv az, hogy mindig előre látnunk kell, hogy mi fog bekövetkezni így mindig legyen elegendő idő a válasz kidolgozására. SCM egyelőre csak a GIGA rendszerek között van.

Most egy olyan rendszert nézünk meg, amely az első utat választotta, de remélhetően ez csak útkeresés. Az azonban biztos, hogy a magára valamit adó termelésirányítási rendszereknek el kell indulni az SCM irányába.

 

A fennkölt stratégiát követően nézzük meg picinykét részletesebben pl. az ütemezését.

Ennek a termelésprogramozási megoldásnak az az alapelve, hogy szétválasztja a programozási folyamatot és első lépésben a rendelések számától és tartalmától függetlenül elvégzünk egy vezénylést, melyben a gépekhez hozzárendelünk munkatársakat, majd ezt követően egy önálló folyamatban szétosztjuk a feladatokat a gépek között, miközben automatizálás vagy optimalizálás (ami nem mesterséges intelligencia) csak erre a folyamatra történik.

Az ismertetésre kerülő rendszer APS-nek, tehát fejlett programozási és ütemezési eljárásnak mondja magát, ennek ellenére kifejezetten az egyszerűségre törekszik.
A rendszerhez elérhető egy sor YouTube klip (ami helyes), az üzemi képernyőn majd minden mezőhöz kapunk támogató szövegeket és van nagyon segítőkész ügyfélszolgálata. Érdekes módon Help-ként videót is használ.
Gépkönyv viszont nincs hozzá.
És itt álljunk is meg.
A vevő által választható rendszerek kritériumát úgy határoztuk meg, hogy (legalább adott ideig) használhatjuk a rendszert és kapunk a teszteléshez részletes gépkönyvet is.
Ez most nincs, tehát ezt a rendszer nem fogjuk javasolni megvételre.
Egy termék vásárlásakor pontosan tudnunk kell, hogy mit fogunk kapni. Egy krumplinyomó esetén nem kritikus a kérdés, ha nem jó kidobjuk (bár erről is le kéne szoknunk, ha komolyan vesszük a fenntartható társadalmat), de olyankor, ha a termék nagyon drága vagy nagyon sok munkát kell beleölni a biztonságos döntéshez, akkor kell egy támpont, ami alapján dönteni tudunk és ami alapján érvényesíthetjük a garanciális jogainkat. Ezért a gépkönyv a vásárlási / bérlési szerződés része, így jogi szempontból sem nélkülözhető. Nagyon barátságtalan üzenet az, ha csak a vásárlást követően adják át a gépkönyvet.

A videoklipeket csak hasznos kiegészítőnek tekintjük, de csak akkor, ha valóban van komoly információtartalma. A videók csak egy-egy konkrét esetre mérvadóak, de elvárjuk, hogy egy rész csak egy verzióban legyen elérhető és az illeszkedjen az aktuális szoftververzióhoz. A videóktól elvárjuk a kiváló felbontást. Ha a videó csak a képernyőablakban nyílik, akkor már dobhatjuk is ki, ha kicsik a betűk és olvashatatlan, homályos a kép, akkor is kukát neki. Ha nem tudjuk kitenni egy második nagy képerőre már be is kell fejezni az ismerkedést.
Jelen esetben is igen hasznos a videók bazi nagy betűkkel történt feliratozása, mert így kiküszöbölhetők a kiejtésbéli eltérések.

A videó azonban kevés.
Könnyen lehet, hogy egy korrekt videó elkészítése sokkal nagyobb munka, mint egy leírásé, amit természetesen nem olvasunk, hanem egy felolvasóprogrammal olvastatjuk. A videók itt is hiányosak, inkább csak marketingtermékek. Lássunk erre egy példát. A programban a gépeknek meg lehet adni műszakját. Így:

(klikk a képre)

És kinagyítva az eleje:

és a vége

(rettenetesen bosszantanak ezek a rövidítések mikor a sor fele üres)

Ez helyes, mert nem mindig engedhetjük meg, hogy minden gép minden műszakban dolgozzon és fordítva. A műszak egy tulajdonságokkal rendelkező objektum, aminek azonban nincs olyan tulajdonsága, hogy munkatárs vagy munkatárs csoport, ezért érthetetlen, hogy mit keres itt a Jóska. Ha a műszak a megadott munkatárshoz vagy csoporthoz tartozik, akkor meg nem itt van a helye, hanem a munkatársnál.
Ez a videóból nem derül ki, az olvasót pedig feleslegesen terheli. Persze help sincs a mezőhöz.

A másik rendszerszintű kihívás, hogy a termelésirányítás mindig testre szabott, így csak akkor képzelhető el gépkönyvet pótolni képes videó, ha előállításának hatékonysága nagyobb a gépkönyvírásnál.

Kétségtelen, hogy a rendszer nulláról 20 percen belül elindult, ami a korszerű felhőtechnológia érdeme és 5 óra múltán pedig már gyártottunk vele. Ez meg annak köszönhető, hogy sehol sem tároltak napi átlagos hőmérsékletet pl. a cikkszám helyén, így egy hozzáértőnek Black-box technikával kiismerhető.

Ahhoz, hogy összehasonlíthassuk a klasszikus és az új szemléletet, nézzük meg, hogy egy gyártás milyen követelményeket támaszthat a vezényléssel szemben.

  • Saját munkahely. A munkahelyet egyrészt értelmezzük cégszinten (melyik cégnél dolgozom) és értelmezzük cégen belül, ahol ez egy területrész, ahol rendszeresen dolgozunk, gép vagy eszköz. Azaz a munkavégzési hely. A saját munkahely létezése rendkívül fontos a vezethetőség, a kezelhetőség, a lojalitás, az egészséges légkör (és a kiégés) szempontjából.
    Ha egy termelésirányítási rendszer a munkatársadatok között nem tartalmazza a munkahelyet, akkor nyugodtan kimondhatjuk, hogy a szervezője lehet, hogy vezetett már váltóáramot, de céget biztos nem.

    Egy munkatársat csak akkor vezénylünk más munkahelyre, ha ehhez nagyon komoly előny tartozik.
  • A gépeken műveleteket végzünk, viszont szó sincs arról, hogy bárki bármilyen műveletet végezhet. Mindig van egy kompetencialista, amely azt mutatja meg, hogy ki melyik gépen dolgozhat (mihez van vizsgája), ill. milyen művelet végezhet (mit tanult meg) és milyen hatékonysággal végzi ezt a műveletet.
    Ha a rendszer nem kezel kompetenciát, akkor igen sok iparág kiesik.
  • A gépekhez sok esetben tartozik helyettesítő gép, ill. ezek csoportja. A helyettesítő gépek egy inhomogén csoportok alkotnak, ahol még a gépek besorolás sem feltétlen azonos. Ez az az eset, amikor fúrógéppel kalapálunk vagy a csavarhúzóval vésünk. Ekkor a kihívást az okozza, hogy a helyettesítő gép kapacitása akár jelentősen is eltérhet a helyettesített gépétől, amit a programozásnál figyelembe kell venni. A valóságban azonban a kapacitásszorzó a gyártási lépéshez tartozik nem pedig a géphez, de a gyakorlatban általában elegendő a művelet-gép egységhez rendelni. Általában elvárjuk, hogy a helyettesítő gépet ne lehessen programozni, ha rendelkezésre áll az előírt gép. Ennek engedélyezése ill. tiltása rendszerparaméterrel történhet.
  • Mindenképpen kezelni kell a homogén gépcsoportokat. Akkor homogén egy gépcsoport, ha a névleges kapacitásuk minden műveletre azonos. A gépcsoport kapacitása műveletenként eltérő. A homogén gépcsoportnak van neve és egy műhelyen belül több homogén gépcsoport is lehet, ahol a gépcsoport elemei önálló gépek.
    Homogén gépcsoportra többféleképpen lehet programozni.
    • Gépcsoport tagjait lehet párhuzamosan működteti, ekkor az átfutási idő a gépek számával fordítottan arányos lesz.
    • A gépcsoport egyik része más terméken dolgozhat, mint a másik.
    • Előírhatjuk egy adott művelet melyik konkrét gépen fusson.
    • A gép kiválasztása lehet véletlenszerű.
    • A gép kiválasztása egy előírt sorrenddel vezérelhető mert a gyakorlatban a homogén gépcsoport sohasem homogén.
    • Megtehetjük, hogy nem gépre írjuk ki a munkát, hanem gépcsoportra, ekkor a vezényelt munkatárs választhat a saját szempontjai alapján.
  • Dolgozhatunk inhomogén csoporttal. A csoport akkor inhomogén, ha minden tagja alkalmas ugyan egy művelet elvégzésére, de nem ugyanazzal a hatékonysággal. Kezelése megegyezik a homogén csoporttal, de figyelembe kell venni a hatékonysági szorzót, amit elegendő lehet gépenként a műveletre vetíteni.
  • Érdekes csoport az ikermunkahely. Az ikermunkahelyen ketten dolgoznak és két önálló művelet egyidejűleg végeznek. Az egyik elvégzi az egyik műveletet (pl. egy ragasztó szórást), a párja a másik művelet (az összeillesztést és a rögzítést). Sok ilyen művelet van, történhet vegyi átalakulás a részműveletek között, elvesztheti tisztaságát, de leginkább kihűl a kritikus munkadarab. Attól iker, hogy a technológiában meghatároztuk, hogy a két művelet között mennyi idő telhet el, ezért a munkahelyeket (gépeket) egymás mellé telepítjük. Ez a felállás működhet azonban egy munkatárssal is csak akkor sokkal nagyobb lesz az átfutási idő (ráadásul nem a két norma összege lesz).
  • Van továbbá dedikált gép, amelyen csak statikus vagy dedikált munkatárscsoport dolgozhat. Ezek a gépek nem is indulhatnak el, ha a teljes munkatárs csoport nem áll rendelkezésre.

A vezénylés másik elengedhetetlen eleme a munkatárs vagy munkatárscsoport.
Ez a csoport is lehet dinamikus, statikus vagy dedikált. Ezek annyira hasonlítanak egymásra, mint a dinnye a teherautóra.

  • Dinamikusnak (vagy arányosnak) nevezzük a csoportot, ha gyártási körülmények lehetővé teszik, hogy a csoport létszáma változhasson. A művelet átfutási ideje fordítottan arányos a csoport létszámával. A csoportnak mindig van neve és vezetője, aki ellenőrzi a tagok jelenlétét és munkájuk minőségét.
    Az elszámolás történhet átalányban, amikor nem vizsgáljuk az egyes munkatársak teljesítményét, az elszámolást pedig a csoportvezető végzi és személyenkénti, amikor mindenki munkáját egyénileg rögzítjük.

    A csoportnak van egy névleges létszáma, amelyikkel a programozás történik (hiszen a programozáskor még nem tudjuk, hogy ténylegesen hányan fognak dolgozni. A csoporthoz tartoznak alapértelmezett munkatársak is.
    Ez egy gyakori eleme a gyártásoknak, még egészen fejlett gyártás esetén is, amikor pl. egy lézeres vágógép kivág vagy 100 elemet egy 8 mm-es vastáblából, akkor az elemek tizedmilliméteres fülekkel továbbra is táblában maradnak. Ezt kézzel szokás kipattintani. Na, ez egy tipikus dinamikus csoport.
    Általánosságban is kimondhatjuk, hogy ha egy csoportnak nincs kinevezett vezetője, akkor az nem csoport, hanem csürhe. Egészen elképesztő hiba, ha egy rendszerben olyan csoport objektumok vannak aminek nincs vezetője, ez a rendszer ugyanis nem alkalmas magas minőségű termék létrehozására és hatékony munkaszervezésre.
  • Van előírt (vagy statikus) csoport, amikor a csoport létszáma kötött, de nem követeljük meg, hogy mindig ugyanazok legyenek a csoporttagok. Viszont a csoport létszáma sem több sem kevesebb nem lehet. Ennek a csoportnak is van neve és vezetője, de mindig nyilvántartott adat a létszám is. A csoportnak van alapértelmezett feltöltése. Miután csak teljes létszámmal folyhat munka, ezért a munkatársak teljesítményadatai azonosak (a bér nem feltétlen).
    Korszerű és kézi gyártások esetén is találkozunk ezzel a szervezéssel. Ha van egy félutcányi gépünk, aminek egyik végén bemegy egy alumínium korong, a másik végén kijön egy gyönyörűen festett flakon és a gép egyes pontjaihoz személyzetet kell rendelni, akkor ők pont ilyen csoportot alkotnak. Ahol kézzel szegeznek raklapot, ott ezt csak két ember végezheti, mert a lapot egyszer meg kell fordítani, ott is ilyen csoport van. Egy munkatárs ehhez egyszerűen kevés, de dolgozhat itt bárki, ha az alapértelmezetten vezényelt személy hiányzik.
  • A dedikált csoport egy olyan statikus csoport, ahol a tagok cseréje általában nem megengedett, de ha igen akkor a cseréjénél azonos kompetencia szükséges. Minden CNC berendezés egy vagy többszemélyes dedikált csoport.

Az ERP választásnál ellenőrizni kell, hogy ha a cég dolgozik ilyen szervezési objektumokkal, akkor a szoftverben rendelkezésre állnak-e azoknak megfelelői ill. ki van-e dolgozva a folyamat.
Sok esetben a szoftver fejlesztői megelégszenek egy nem minősített csoporttal. Mondván, semmi baj, hozzá adunk két embert és máris dinamikus csoportunk van vagy kicserélünk egyet és nyomban statikus lesz. Na, ez nem igaz csak akkor, ha az ebet sem érdekli a minőség és a hatékonyság. A csoport tagjai között ugyanis kölcsönhatás van, és valójában a kölcsönhatás alapján keletkeztek maguk a csoportok is.
Azért érdekes, ha egy szervező ezt nem érti, mert még az iskolaudvaron is pontosan így szerveződtek a csoportos játékok.

Amit alább bemutattunk egy kellően pontos modellje egy valós működésnek. A klasszikus termelésirányítási szemléletben elvárjuk, hogy ezek az objektumok legyenek kialakítva, a rendszer minden automatizálható feladatot automatizáljon és ha lehet mindenhol optimalizáljon. (Továbbá elvárjuk, hogy a képernyőkép harmonikus legyen, legyen korrekt színegyensúlya, a betűk kellően nagyok legyenek és a szavak jól olvashatók, nincs felesleges billentyűlenyomás, felhasználóbarát és alacsony a felhasználói terhelés. Sajnos ezek a ménkű korszerű rendszerek ezt meg sem közelítik.)

A vezénylésnek az adja a bonyolultságát, hogy egy személy több csoportnak is tagja lehet és a kompetencia miatt sok az ütközés. Emiatt a vezénylést is optimalizálni szokás.

A rendszert az alábbi kifejezetten bonyolult termelési elrendezésen teszteljük.

Az 1. csarnok gépelrendezésében 

  • az R1, R2 ikermunkahely,
  • a D egy homogén gép/munkacsoport,
  • a B munkahely létrehoz előirányzott alkatrészt, társterméket, hulladékot, maradékot és selejtet,
  • van gyűjtő elosztópont,
  • van input/output terület és van gép melletti (L2) tároló.

Az általános minősítés esetén azt lehet vizsgálni, hogy a fenti igényeket egy-egy rendszer milyen mértékben elégíti ki. A szoftverek esetében, ha valamelyik alap felhasználó igény nem teljesíthető vagy a közelítő megoldás nem kielégítő, akkor meg kell állapítani, hogy mely iparágak esnek ki a potenciális felhasználók közül.
Természetesen szó sincs arról, hogy mindig ilyen bonyolult modellt kell tervezni, sőt nagyon fontos, hogy mindig legyen pont olyan modell, ami az ügyfélnek kell. Pláne úgy, hogy a bonyolultság mindig drága.

Jelen megoldás annyira meglepő, hogy ezzel kicsit részletebben is foglalkozunk. Nem állítom, hogy a bemutatott megoldás rossz. Ez olyan, amilyen, de tény, hogy a klasszikus szemléletnek nagyon furcsa.

A vezénylési műveletben a gép/munkanapok mátrix elemeihez hozzárendeljük a munkatársakat, ami egy klasszikus összerendelési feladat.

Készítettem egy vezénylést:

Felhívom a figyelmet arra, hogy az ábra a képernyő felét sem tölti ki, ugyanakkor nem tudom elolvasni a rosszul színezet, túlzottan apró betűket. Megnyugtatom ifjú szoftvermérnökeinket, hogy az Ő szemük is el fog romlani, ha ennyit ülnek monitor előtt.

Bal oldalon vannak a gépek/munkahelyek, a jobb oldalon pedig a napok, a napokhoz rendelt munkatársak és az időbeosztásuk. Az egyszerű kézi összerendelés során sem automatizmus, sem optimalizálás nincs. Az automatizálást elvártam volna, mert fontos, hogy minden munkatársnak legyen saját munkahelye és ha lehet ott is dolgozzon (mert növeli a kötődést és a hatékonyságot), továbbá a munkahelynél meg is adunk egy nevet, tehát az adat is rendelkezésre áll.
A rendszer nem bonyolódik bele abba kérdésbe, hogy mi a munkahely és mi a gép, ill. melyik az elsődleges. Mindenhol a „Workstation” kifejezést használja, de ettől függetlenül bevezeti pl. a gépcsoport fogalmat (Group machines) is. Viszont nincs munkahelycsoportja. Ez egy szemléletbeli kérdés, ami akkor jött volna igazán elő, ha felmerül a munkaszerződés, a munkaköri leírás kérdése, amelynek szabályoznia kellene, hogy mi minden tartozik egy munkahelyhez.

A vezénylés két fontos alapeleme a műszak és a munkaidő naptár.
Jelen esetben az alapadatok között megadtuk, hogy milyen alapértelmezett műszakok léteznek, ezek mikor kezdődnek és mikor záródnak. Megadható a műszak színjelzése is, ami az ütemezés áttekinthetőségét növeli.
Mindenekelőtt van egy műszak alapértelmezés.

Van egy személyi műszak tábla is:

Ez valójában ez egy napló (súlyos szoftverhibával), aminek az lenne a feladata, hogy a vezénylés változásait naplózza. Ha egy műszakon belül át kell helyeznünk egy munkatársat, akkor csak a megfelelő helyen átírhatjuk a vezénylés-táblát, ami itt naplózva lesz. Fontos észrevenni, hogy ez nem a munkavégzést naplózza, hanem a vezénylést (ami egyébként tökéletesen érthetetlen számomra).
Van továbbá minden gépnek/munkahelynek is műszakja.


Nem világos, hogy miért van a műszaknak munkatársa

Nézzük meg hogyan történik a vezénylés.
Ráállva az adott munkahelyre és napra a + jel megnyomásával vihetjük be az új vezénylést. A megnyíló ablakban kiválasztjuk, hogy munkatársat vagy munkatárs csoportot akarunk-e vezényelni, majd kiválasztjuk a munkatársat, megadjuk a műszakot és ha szükséges módosíthatjuk a kezdő és záró időpontot, ill. írhatunk egy megjegyzést is.

Aminek ez az eredménye:

Úgy tűnik az APS (fejlett programozás és ütemezés) megoldás simán összeegyeztethető azzal, hogy

  • kedden Holics Gyuri 16 órát dolgozik,
  • szerdán a délelőtti műszakban Holics két példányban fog termelni,
  • ugyancsak szerdán 6-tól 8-ig az egyszemélyes gép mellett ketten állnak,
  • Bogár Imre olyan műszakban dolgozik, ami nincs,
  • természetesen a sorrend sem számít, a 6 óra után vezényelhetek 4-re.

Meg kell jegyeznem, hogy az, hogy bármilyen marhaságot bárhova beírhatunk az a klasszikus informatikai kultúrájú emberek számára nehezen elfogadható és semmi esetre sem tartozik a rugalmasság fogalmába. Egy klasszikus rendszerben ezek mindegyikére hibaüzenetet kaptunk volna.
El sem tudom képzelni, hogy mi az ideológia a mögött, hogy ennyire szabadjára engedjük a végfelhasználót és még csak egy jelzést sem adunk a hibáról. Nem tudok másra gondolni, mint a „ha ennyire hülye vagy, akkor magadra vess” (caveat emptor) elv használatára.

Azért az utolsó tranzakció naplózása is figyelemre méltó:

A 3 – 7-ig kifejezés sehol sincs leírva. Most kissé értetlenül állok, mi oka lehetett, hogy mindenhonnan levont egy órát. (Csak nem napközben, pont abban a milliomod másodpercben volt óraátállítás?)

Azért van itt más probléma is:

Előszőr tisztázzuk a műszak jelentését.
A műszak egy jogi fogalom, a műszakbeosztás pedig a munkaidő kérdésében a munkaadó és munkavállaló együttes akaratát tükrözi. Mindig szerződés szabályozza, hogy egy dolgozó milyen munkarendben fog dolgozni és milyen feltétek esetén módosítható a műszakbeosztása. A munkaügyi törvény pedig meghatározza, hogy kit, milyen műszakba lehet beosztani. Szó sincs tehát arról, hogy a szoftvermérnök azt csinál, amit akar, a termelésprogramozó pedig azt ír be, amit akar.
A dolgozóadatok között nem találtam olyant, hogy műszakbeosztás! Van három másik műszakadat, de a legfontosabb, az bizony hiányzik. Ez azért kulcskérdés, mert a munkavállaló műszakjától eltérő vezénylésének túlóradíj, pótlék, ill. szabadság vetülete lehet. Ráadásul ebből a túlórát a munkaügyi törvény szabályozza. A vezénylő munkatárs azért van nagy bajban, mert ha a rendszer nem tartja nyilván, hogy ki, milyen műszakban dolgozik, akkor még dönteni sem tud. (Csak nem a húsz éves gyakorlat vagy egy Excel lenne a megoldás?)

A munkaidő naptár azt határozza meg, hogy melyek a munkaszüneti és az ünnepnapok. Ez értelemszerűen alapvető a programozásnál. Bonyolultságát az okozza, hogy bizonyos műszakok felülírják a naptárat, így több naptár is létezhet.  A naptár kezeli a hétvégéket, de semmi támpontot nem találtam arra, hogy mint csinál az ünnepnapokkal, mely napok ünnepnapok, hogy lehet munkanapcserét csinálni és kezel-e Bank Holiday-t.
Ilyent nem találtam, ezt is kézzel kell megoldani.

A vezénylés kezelhet munkatárscsoportokat. Ez jó.

Hát, ez elég egyszerű.
Most meg a csoportról csak annyit tart nyilván, hogy kik a tagjai, így valójában a komoly cégek ezrei esnek ki a potenciális felhasználok sorából.

Egy gyárban bizonyos művelethez rendszeresen vettek fel alkalmi munkásokat, akik együtt ugyanazt a műveletet végezték. Egy nap, egy munkás a műszak végén azzal állt elő, hogy Ő egész nap itt dolgozott és nem akarják kifizetni. A műszakkezdéskor valahogy bejött, nem szolt senkinek és még az is lehet, hogy tényleg dolgozott.
Ebben a gyárban pont ilyen volt a munkaszervezés és ütemezés, ahogy ez a rendszer mutatja. Ennél a cégnél valójában egy dinamikus csoport volt, de szervezetileg nem volt kialakítva. Az ilyen csoporthoz kötelezően tartozik egy csoportvezető, aki menedzseli a munkát. Neki kellett volna felismerni, hogy ez a csellengő ember nincs benne az alapértelmezett tagok között és nincs az esetileg vezényeltek között sem. Neki a feladata ellenőrizni, hogy folyik-e munka és az előírás szerű-e.
A megoldás az volt, hogy létre kellett hozni a szabályos dinamikus csoportot.
Amit ebben a rendszerben nem lehet.

Nézzük a gépcsoportokat. A rendszerben háromféle gépcsoportot találtam.
A vezérgép csoport (Collection workstation). Ez a csoport a munkahelyek kategóriában adható meg.

Van pl. négy gépünk, a példába mind a négy kárpitozó gép.  Kijelölünk egy vezérgépet és ennél megadjuk, hogy mely gépek tartoznak hozzá. Ennek a csoportnak tehát nincs saját neve, hanem mindenhol a vezérgép nevét fogja használni (ez végül is nem rossz). A probléma az, hogy nem kezelik a gép tulajdonságait, így ez csak homogén csoport lehet. Ezt erősíti meg, hogy a „Munkahelyi szabályok” között jelzik is az átfedés engedélyezését. Mint láttuk egy homogén gépcsoportot (Kárpitozás-1) sokféleképpen lehet programozni, de így biztosan nem.

Itt ugyanis csak egy nappali műszak van
(Megjegyezném, hogy a P2/1-es ütem eleje is el van számolva.)

Nos, itt elsőre mellényúltam.
A gépgyűjtemény fogalommal eddig nem találkoztam, Help pedig nem tisztázza a fogalmat és hogy mire használható. Ez egy tipikus digitális lópopó (a múlt maradványa) lehet. Ilyenkor kell megkérdezni: mire használjátok?
A gyűjtemény arra szolgál, hogy ide tehessük azokat a gépeket, amiket ritkán használnak (kisebb legyen a gépek száma), de időnként persze használni kell. Ilyenkor – kikerülve „a mesterséges intelligenciát) kézzel lehet ütemezni.
Kifejezett hibás gondolat, valós tartalom nélküli objektumokat nem lenne szabad létrehozni és tisztán IT érdekek miatt terhelni a termelést.

Helyettesítő csoport (Process steps csoport). A másik csoport a folyamatlépésnél adható meg.  Az ütemezésnél valamelyik gép kiesése esetén az automatizmus ezek közül választ a művelethez gépet.

A választás véletlenszerű. Ez azért nem szerencsés, mert ez nem homogén gépcsoport, tehát a teljesítményük nem feltétlen azonos.

 Vezénylési csoport. A harmadik csoport a vezénylésnél adható meg.
Alább „Szerelés” néven a négy szerelő munkahelyből hoztunk létre egy csoportot.
Ezek egyfajta nyilvántartási csoportot jelentenek. Ha pl. az ütemezésnél szűrünk erre a csoportra, akkor csak ezek jelennek meg, ami akkor különösen hasznos, ha sok álló gép van.

Persze a vezénylési csoportok helyettesíthetőek közelítésekkel, úgy hogy az átfutási idő megfelelő részét átterheljük egy másik csoporttagra. Járható megoldás, de a ilyenkor a „mesterséges intelligencia” háta mögött kis kezünkkel és egy kalkulátorral végezzük a programozást. Nem túl elegáns. 

A grafikus megoldása azért lenyűgöző (katt a képre)

Bár jól látszik, hogy ez nem egy szerencsés ütemezés (pontosabban hibás), de mi kértük így ezért nem szólhatjuk meg. Ez azért van mert nem kezel csoportokat. A rendszer alapelve, hogy a „mesterséges intelligencia” kifejezetten az utasításunk szerint működjön.

Végezetül meg kell jegyeznünk, hogy az APS megoldásoknak pont az a lényege, hogy a magát a vezénylést együtt optimalizálja a termelés többi paraméterével.
Úgyhogy ez esetben nem megalapozott az APS besorolás.

Kétségtelen, hogy van olyan ipari szegmens, ahol ez rendszer valóban megfelelő, de ez meglehetősen kicsi lehet. Miután deklaráltan nemzetközi forgalmazás folyik, így a piac ennek ellenére elegendően nagy.

Miután az anyagok nem a művelethez vannak rendelve, hanem magához a termékhez, így az anyagok nem helyezhetők ki a gépekhez csak akkor, ha a logisztikus munkatársaktól elvárjuk a teljes termék, anyag és alkatrészismeretet vagy egy gyártási megrendelés csak egy gépre szól. Ugyanakkor a gépek előtt nem lehet hosszú, eltérő termékeket tartalmazó gyártási sor sem mert a batchek jelzésének hiányában biztosan keveredés lenne. Kell az is, hogy ne legyen szükség homogén vagy inhomogén gép és munkatárs csoportokra sem. Kell továbbá, hogy a termékek rendelési tételnagysága legalább egy napnyi gyártást igényeljen.
Ez tipikusan az alkatrész gyártás-szerelés esete.
Minden más esetben sok kézi munkára, kézi tervezésre, termékismeretre és személyes menedzselésre lesz szükséges.


A rendszer az egyszerű alkatrészgyártásra ideális

A fenti Daisy Chan vagy ilyen elemeket tartalmazó gyártásra pedig tökéletesen alkalmatlan.

Ami igazán zavaró ezekben a korszerű rendszerekben, hogy egy ennyire fejlett szoftverhez, miért tartozik ilyen bántóan gyenge gyártási modell. Vélhetőleg az vezetett ide, hogy a termelésirányítás teljesen átcsúszott a szoftvermérnökök kezébe, bár az is lehet, hogy ez pont így jó és tényleg ez a jövő, csak a klasszikus ipari műveltségű emberek számára ez szokatlan még.