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 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.
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.
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 á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.
Úgy tűnik az APS (fejlett programozás és ütemezés) megoldás simán összeegyeztethető azzal, hogy
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.