A gyártás digitalizálása sorrendi probléma, nem technológiai

A sorrend a nehéz rész, és ezt hagyja ki a szállítói anyag, mert az őszinte változat azt jelenti, hogy idén kevesebbet kell eladni az ügyfélnek. Ez az oldal erről a sorrendről szól.

Miért akadnak el a digitalizációs projektek a gyártásban

Négy ok adja a többségüket. Mind a négy programhiba, nem termékhiba, és pont ez a lényeg: ezek azok, amelyek fölött az üzemnek van hatalma. A szoftver a maga módján is tud bukni, és az a lista a beszerzésbe tartozik: a tranzakciók kialakítása, a teljesítmény nagy adatmennyiségen, egy olyan szállító, akinek az élesítéssel véget ér a jelenléte.

Az első a szponzor, aki alatt nincs gazda. A szponzor jóváhagy egy büdzsét és eljár a havi megbeszélésre; a gazda üzemi időt tölt a gyártásban, joga van folyamatot megváltoztatni, és személyes érdeke fűződik ahhoz, hogy az üzem egy év múlva másképp működjön. A második az üzleti indoklás, amely nem létező adatokat feltételez, így az állásidő-elemzés terve egy műszaklap szabadszöveges rovatába ütközik. A harmadik a pilot, amit soha nem arra terveztek, hogy ki lehessen terjeszteni. A negyedik az, hogy a platformot a kérdés ismerete előtt veszik meg, így az üzemnek lesz egy sokat tudó rendszere, amihez nincs első felhasználás.

Hogyan válassza ki az első digitalizációs projektet

Az első projektnek az üzem korlátjából kell jönnie, nem a modullistából. A legtöbb gyárban a veszteség hétköznapi: a szabványnál hosszabb átállások, megtalálhatatlan anyag, kétperces leállások, amiket senki nem jelent.

Három kérdés gyorsan megszűri a jelölteket. Megjelenik-e a veszteség már most is az üzem saját könyvelésében selejtként, túlóraként, expressz fuvarként vagy késedelmi kötbérként? Csinálna-e valaki bármit másképp még ugyanabban a műszakban, ha megkapná a választ? Egy termelési cikluson belül eldönthető-e, hogy működött-e? Ciklus, nem negyedév: három hónap tisztességes próba egy nagy termékválasztékú, ismétlődő gyártásban, és értelmetlen a repülőgépiparban vagy egy gyógyszeripari kampánynál, ahol az egység egy kampány vagy egy rendelés.

Néha a szoftver a rossz válasz: ha a korlát fizikai, semmilyen adat nem gyorsítja fel a gépet. A mérés arra jó, hogy megmutassa, hová megy a kapacitás, és ez jellemzően átirányítja a beruházási igényt, nem megerősíti. A kiszemelt gép saját futásideje rosszabbnak látszik, mint bárki hitte, ha a mikroleállásokat is számoljuk, ugyanakkor az elvesztett órák többsége nem is a sajátja volt: kiéheztette a megelőző művelet, blokkolta a követő, átállásban állt, vagy arra az operátorra várt, aki két gépet kezelt. A gép soha nem volt a szűk keresztmetszet, és a pénznek máshol a helye.

Mit mérjen az indulás előtt, hogy később bizonyítani tudja a változást

A csapda fogalmi. Élesítés előtt a rendelkezésre állás egy olyan műszaklapról jön, ahová a mikroleállásokat nem írják fel; utána a rendszer automatikusan érzékeli a leállásokat, így a mért OEE esik, mert a veszteségeket, amelyek mindig is ott voltak, végre megszámolják. Ha senki nem rögzítette a régi definíciót és a régi számot, a harmadik hónap visszalépésnek látszik, és a program a saját hitelességét költi el az önvédelemre.

Írja tehát le teljes egészében a mostani számot és a definícióját: milyen időalapon számol a százalék, honnan jön az ideális ciklusidő, hogyan osztályozzák az állásidőt, kiveszik-e a tervezett karbantartást, és mi történik az utómunkával. Az első kettő dönti el a többségét: a naptári, az ütemezett és a ténylegesen munkaerővel lefedett idő ugyanabból az adatból három különböző számot ad ugyanannak az üzemnek, az ideális ciklusidő pedig vagy géptábla szerinti, vagy a legjobb bizonyított, vagy egy technológiai útvonalon egyszer beállított és azóta soha nem nézett érték.

Utána rögzítse azokat a tényeket, amelyeket nehezebb átdefiniálni, és amelyek a pénzügyhöz egyeztethetők: leszállított darabszám, kifizetett óra a ledolgozott órához mérve, késve teljesített rendelési sorok, jóváíró számlák és túlóra. A nehezebb nem lehetetlen, ezért mindegyikhez fagyassza be a definíciót és a forrásrendszert, az OEE-definíció mellé. A határidőre szállításnak saját leírt döntésre van szüksége, mert a dátumalap az az egy definíció, amin minden üzemben újra és újra vitatkoznak: eredeti vállalás vagy utoljára módosított dátum, rendelés vagy sor, kiszállítás vagy átvétel.

Mi jön előbb: összekötés, törzsadat, aztán analitika

Az összekötés és a törzsadat minden alatt ott ül, az analitika legfelül, és annyit ér, amennyit az alatta lévő rétegek, a törzsadat pedig az a függőség, amit következetesen alábecsülnek. Egy gyártásvégrehajtó rendszer nem tud kiadni olyan műveletet, ami hiányzik a technológiai útvonalról, egy ütemező pedig nem tud sorrendet képezni normaidők nélkül, amiket valaki ebben az évtizedben mért meg. Ezért mielőtt dátumot vállalna, számolja meg a technológiai útvonal nélküli cikkeket, a kerek számú normaidőket, a helyeket, amelyek a gyakorlatban léteznek, de rendszerben nem, és a duplikált darabjegyzékeket.

A másik varrat, amit a végén helyett az elején kell lehatárolni, az ERP-integráció, ahol a nehézség a megegyezés, nem a kód: mit jelent a visszajelentés mindkét oldalon, és az üzem könyveli-e, vagy retrográd elszámolás, hogyan érkezik a részmennyiség és a rendelésbontás, mi történik egy sztornóval, miután az anyag már elmozdult, hová könyvelődik a selejt a standard költséggel szemben. Minden válasz olyan osztályok közötti döntés, amelyeknek eddig soha nem kellett megegyezniük.

Két hosszú átfutású függőség ritkán kerül fel a technikai ütemtervre. Az a gyártási nyilvántartás, amely a kibocsátást, a leállásokat és a selejtet névvel azonosított operátorhoz köti, Németországban és Európa nagy részében egyéni teljesítmény megfigyelésére alkalmas rendszernek minősül, ezért élesítés előtt az üzemi tanáccsal tárgyalt üzemi megállapodás kell hozzá. A jóváhagyás hónapokig tart, ezért az első évben kell elindítani, a törzsadat mellett. A tartalma rövid: tárolják-e egyáltalán az operátor azonosítóját, ki látja, meddig, és tervezetten összesítve történik-e a riportolás.

A második a szabályozott gyártásra vonatkozik. A gyógyszeriparban, az orvostechnikában és az élelmiszeripar nagy részében az a rendszer, amely minőségi minősítést rögzít vagy kikényszerít, validálási hatókörbe tartozik: validálási terv, kvalifikáció, audit trail, aláírási kötelezettségek, utána lassabb változáskezelés. A riportolás, az állásidő-rögzítés és az ütemezés a vonalon kívül van; a tételzárolás, a minősítés és az a modellverzió, amit egy ellenőrző rendszer használ, belül. Még a modul megvásárlása előtt határolja le, mert a validálás gyakran a program leghosszabb egyetlen tétele.

Miért jön a MES az APS előtt, és a minőségi adat az MI-alapú minőségelőrejelzés előtt

Ha a fejlett termeléstervezés tegnapi feltételezést kap arról, hol tart a munka, a sorrendet a műszak kezdete előtt kézzel újrarendezik, a tervező hetek alatt visszakerül a táblázatba, és az ítélet az lesz, hogy rossz volt az ütemezőszoftver. Nem volt rossz, csak vak volt.

Az élő bemenettől az ütemterv megvalósítható lesz, nem futtatható, és ebben a résben lakik az APS-csalódások többsége. A tökéletes adatra épülő ütemtervet is figyelmen kívül hagyják, ha rossz célfüggvényt optimalizál, mondjuk az átállást minimalizálja, miközben az üzemet határidőn mérik; ha hiányoznak a másodlagos korlátok, hiszen a valódi sorrendet a szerszám, a képzettségi mátrix és a megosztott munkaerő dönti el; vagy ha semmi nincs befagyasztva, hiszen a folyamatosan újraszámoló optimalizáló minden ránézéskor új tervet ad a művezetőnek. Állapodjanak meg egy fagyasztott időszakban, és az optimalizálás azon kívül forogjon.

A minőségelőrejelzés ugyanilyen alakú: a selejtet előrejelző modellhez a selejtet ott kell rögzíteni, ahol keletkezett, a művelet szintjén, okkal és folyamati kontextussal együtt, a géptől és a szerszámtól az anyagtételig.

A karbantartásnál van egy különbségtétel, amit az értékesítés átugrik. A rezgésen vagy áramjelen futó anomáliadetektálás meghibásodási előzmény nélkül is működik, ami nem ugyanaz, mint hogy adat nélkül működne: hetekre való egészséges állapotú adat kell hozzá, ami lefedi a teljes üzemi tartományt, különben minden átállásra riaszt, nem a károsodásra, és olyan szenzorok, amelyeket a minket érdeklő hibamódokra szereltek fel és mintavételeznek. Még akkor is csak annyit mond, hogy valami szokatlan, és ahhoz, hogy tudjuk, mely anomáliák számítottak, hibamódokkal ellátott munkalap-előzmény kell.

Az a kamera sem változtatott az üzemen, amelyik a képernyőn megfelelt vagy nem megfelelt eredményt mutat: az ítéletnek egy munkalaphoz, egy tételhez és egy modellverzióhoz kell kapcsolódnia a gyártási és minőségi nyilvántartáson belül, ami a vizsgálatot késői képességgé teszi, nem belépési ponttá. Külön útmutatók foglalkoznak a véges kapacitású ütemezéssel, azzal, hogy mit kell teljesítenie egy APS-ütemtervnek, és azzal, hol ér véget a CMMS és hol kezdődik a prediktív karbantartás.

Ki viszi a programot, és miért ellenkeznek az operátorok az üzemi adatrögzítéssel

Az IT partner, nem gazda: ha az IT birtokolja a programot, az integrációra és a biztonságra optimalizál, ezeket jól is csinálja, aztán megreked az elfogadásnál, mert abban a vonalban senki nem felel azért, hogy az operátor használja-e a képernyőt. A gazda alatt ülnek a kulcsfelhasználók, területenként egy, névvel, kiosztott órákkal: ők döntik el, mit kérdez a képernyő és milyen sorrendben, és az üzem rájuk hallgat.

Az elfogadás akadályaként szinte mindig az embereket nevezik meg; a valódi akadály általában a tranzakció kialakítása. Nézzen meg egy visszajelentést átállás közben, kesztyűben, a következő rendeléssel a nyakukon. Ha a leállási ok bevitele semmi láthatót nem változtat, a rögzítés adó a műszakon, amit a lehető legkésőbb fizetnek meg, jellemzően a végén, egy csokorban, kitalált adatokkal. Ha viszont értesíti a karbantartást, frissíti a műszaktáblát, vagy átrendezi a következő rendelést, a munka részévé válik.

A jó adatrögzítési kialakítás konkrét: terminál a gépnél, egykezes, kesztyűs kezelés, a rendelésből húzott alapértelmezések, és géptípusonként rövid oklista olyan taxonómia helyett, amelyből csak néhány kódot használnak valaha. Ha a tranzakció illeszkedik a munkához, a betanítás elég rövid ahhoz, hogy a gépnél, műszak közben elvégezhető legyen. Ha nem illeszkedik, semennyi tantermi óra nem javítja meg, és a több képzés iránti kérés gyakran kialakítási probléma, embereknek tulajdonítva.

A legtöbb képzési tervből két dolog hiányzik. Az első a helyesbítés: a jó mennyiség visszajelentését könnyű megtanítani, de a rossz visszavonása, vagy egy nem a megfelelő rendelésre könyvelt visszajelentés kibogozása az, ahol a betanítatlan felhasználó valódi kárt okoz. A második az, hogy a képzés nem esemény, mert a művezetőknek többre van szükségük, mint az operátoroknak, és az új belépők, a kölcsönzött munkaerő és a többnyelvű üzem folyamatosan érkezik.

Pilot kiterjesztése a teljes üzemre: mitől másolható egy pilot

A pilotok olyan okok miatt nem terjeszthetők ki, amelyeket eleve beléjük terveztek: a legjobb gyártósor, a régi gépek kikerülése, naponta helyszínen lévő szállító, kézzel összerakott törzsadat. A kiterjesztésre tervezett pilot reprezentatív gyártósoron fut, legalább egy nehezen kezelhető, problémás gépet is tartalmaz, és rögzíti a gyártósoronkénti óraráfordítást, mert ez a fajlagos költség az egyetlen őszinte bemenet a bevezetési tervhez.

A kilépési kritériumokat és a bevezetési döntés dátumát a pilot indulása előtt egyeztetik, a záró szakasz pedig a szállító nélkül fut. Ennek a szakasznak nem a hossza számít, hanem a lefedettsége, mert a pilotok ritkán buknak el a hétköznapi futás közben. Az első időszakzárásnál buknak el, amikor a számoknak egyezniük kell az ERP-vel, és valaki megtalálja a kétszer könyvelt selejtet, és az első, leállás utáni újraindulásnál, amikor a gatewayek visszajönnek, a pufferelt darabszámok viszont nem. Írja tehát elő a lefedettséget: egy időszakzárás az egyeztetésével együtt, a gyártósor teljes termékválasztéka, és egy tervezett leállás és újraindulás. A legtöbb üzemben ez egy hónap vagy egy teljes ciklus, nem két hét.

Mit fed le egy digitalizációs büdzsé, és mennyi az utána maradó üzemeltetési költség

A licenc az a tétel, amit a legkeményebben alkudnak le, az eredményt eldöntő tételek pedig máshol vannak: ERP- és gépintegráció; hardver, a gatewayektől és paneleken át az utólagos szenzorokig; törzsadat-tisztítás; képzés és az általa elvitt termelési idő; valamint a belső ráfordítás. A belső ráfordítás az a tétel, amit a leggyakrabban kihagynak: kulcsfelhasználók, a gazda, az IT, a gatewayeket felszerelő technikusok, az átállásnál kieső termelés. Ha ezeket az órákat senki nem árazta be, a büdzsé hibás, akármilyen jól alkudták le a licencet.

A fizikai munka két kategóriára bomlik, amelyek másképp ütemezhetők. A kábelezés, a switchportok és az irányítási és üzleti hálózat közötti szegmentálás hosszú átfutású, hétköznapi mérnöki munka, és a termelés mellett elvégezhető. Ami a gépszekrényen belül van, az nem: az elkülönített munka, kizárást és megjelölést (LOTO), valamint tervezett leállást igényel, és a legtöbb üzemben állandó tilalom él a feszültség alatti szekrény felnyitására. Az összekötés ütemezésének valódi korlátja tehát az, hány leállási ablak maradt még idén, és ezekből mennyit foglalt le a karbantartás. Az összekötést a karbantartási naptárhoz tervezik, nem a szoftvertervhez.

Aztán ott az üzemeltetési költség, amit egyetlen projektbüdzsé sem tartalmaz, és amit a pénzügyi vezető kérdez meg elsőként: mennyibe kerül a negyedik évben. Az előfizetés vagy az éves támogatás fut tovább, az ipari panelek és gatewayek pedig gyorsabban kopnak el, mint az irodai hardver. Mindenekelőtt pedig valaki belülről üzemelteti a rendszert, miután a szállító elment: törzsadat-karbantartás, okkód- és technológiaiútvonal-változások, felhasználókezelés, az egyes kiadások átvétele. Az élesítés utáni tizenkét hónap változtatásaira külön tervezzen büdzsét, mert a finanszírozásra érdemes igények csak akkor érkeznek meg, amikor az üzem elhiszi, amit a rendszer mond neki.

Hogyan ütemezzen egy hároméves okosgyár-ütemtervet

A naptár hozzáad valamit, amit a függőségi sorrend nem tud: ki dönt az egyes határokon, és hogyan ütemeződik a pénz és az óra. Az első év azokat a döntéseket rendezi le, amelyeket drága újranyitni, és ezeket a gazda a pénzüggyel, az IT-vel és az üzemi tanáccsal rendezi le, nem a projektcsapattal: KPI-definíciók, törzsadat-szerkezet, az ERP-varrat, az operátorazonosítás és szabályozott üzemben a validálási hatókör. A belső ráfordítás itt tetőzik a licencköltéshez képest, így az a büdzsé, amelyik egy hagyományos IT-projekt alakját veszi fel, már eleve hibás. Egy tétel az első évbe tartozik, amit az üzemek halogatni szoktak: a legnagyobb villamos fogyasztók mérése, hogy legyen kiindulási alap — ez műszerezés, nem modellezés, és egy energiaszabvány vagy audit alatt gyakran nem mérlegelés kérdése.

A második évbe való átlépés ítélet, nem dátum, és akkor lépik át, amikor az üzem vitatkozni kezd a rendszer számával ahelyett, hogy figyelmen kívül hagyná. Egy hurok bezárása azt jelenti, hogy egy művezető vagy minőségvezető átad egy döntést egy szabálynak, ezért ezt a hatókört azokkal az emberekkel kell megtárgyalni, akiknek a jogköre mozdul, a költés pedig a belső órák felől a licenc és az integráció felé tolódik. A harmadik év két év nyilvántartásán érdemli ki a modellalapú réteget, a határfeltétele pedig a gazdai felelősség: minden képességhez kell egy névvel azonosított ember, aki birtokolja a küszöböt és az újratanítási ütemtervet. A darabra vetített energia ide tartozik, mert a hozzárendeléshez az a gyártási nyilvántartás kell, amit az első két év felépített.

Két leállási feltétel tartozik a jóváhagyásba. Ha az üzem nem bízik az első év adataiban, a második év nem indul el. Ha pedig azért hozzák előre a harmadik évet, mert az igazgatóság MI-kezdeményezést kért, az eredmény pontosan az az elakadt projekt lesz, amit az oldal elején leírtunk.

Hogyan döntse el, folytassa-e: kapukritériumok szakaszonként

Minden szakaszhoz kell egy kapu, olyan bizonyítékkal, amit egy szkeptikusnak is meg lehet mutatni. Az összekötés után: egyezik-e a rögzített termelés a kézi számlálással egy teljes műszakon át, a teszt előtt egyeztetett tűrésen belül. Az első jelentett szám után: karbantartják-e még mellette a régi táblázatot; amikor csendben abbamarad a frissítése, a számot elfogadták.

Egy kapu az első gyártásvégrehajtási élesítéshez tartozik, és szinte mindig kimarad: mit csinál a gyártósor, ha a rendszer nincs ott. Amint az operátorok a gépnél jelentenek vissza, és a minőség szabály alapján zárol tételeket, egy meghibásodott switch vagy interfész megállítja a termelést: az üzem egy papírtömböt cserélt le egyetlen meghibásodási pontra. Előbb tehát definiálja és tesztelje a degradált üzemmódot: mit pufferel a terminál helyben és meddig, mi a papíralapú tartalék, ki engedélyezheti a rendszer nélküli futást, és hogyan pótolják be az elmaradást kettős könyvelés nélkül. Úgy tesztelje, hogy futó műszak közben húzza ki a kapcsolatot, mert a tesztelés nélküli átállás a megszokott oka annak, hogy egy élesítésből termelési incidens lesz.

A gyártási nyilvántartás után: rekonstruálható-e egy rendelés a leállásokkal, a selejttel és azzal együtt, hogy ki futtatta, az egyeztetett azonosítási szinten, anélkül hogy embert kellene megkérdezni. Tervezés előtt: pontos-e a befejezetlen termelés a műszak kezdetén. Egy trend többet számít bármelyik egyedi kapunál: ha minden új gyártósor annyiba kerül, mint az előző, a program egyedi telepítéseket épített, nem módszert.

Hol illeszkedik ebbe a Meta Smart Factory

A Meta Smart Factory a fenti rétegeket külön modulokként fedi le, a MES-től, az MRP-től és az APS-től a minőségen, karbantartáson, raktáron és gépi látáson át az ERP-integrációig. A modularitás megvásárolhatóvá teszi ezt a sorrendet, de az első vásárlás nem csak egy modul. Egy modul egy megnevezett korlátra, egy területen, plusz az alatta lévő alap: összekötés, törzsadat-tisztítás, az ERP-varrat és a megegyezett definíciók. Ez az alap adja az első év ráfordításának nagy részét, és egyetlen árlistán sem szerepel, ezért saját tételként tartozik a jóváhagyásba, nem egy licencbe beleértve.

A nehéz részek bármelyik platformválasztást túlélik. Annak a lerendezése, hogy mit jelentenek a számok, a törzsadat tisztítása, olyan tranzakciók tervezése, amelyeket az operátorok hajkurászás nélkül végigvisznek, és annak eldöntése, mit hagyjanak abba — ezek közös munkák. Ha itt tart, egy beszélgetés arról, milyen sorrend illik az Ön korlátjához, többet ér egy termékbemutatónál.