Black box

"Fekete doboz", mondjuk néha olyan dolgokra, amelyeknek nem ismerjük a működését. Eltekintve attól, hogy a fekete doboz sohasem fekete (mert úgy nehéz lenne megtalálni), egy magyarázat szerint "absztrakt módon egy rendszert, amelyről modellt akarunk készíteni, fekete doboznak (black box, ang., fekete doboz) tekintünk, ami azt is jelenti, hogy a szerkezetét nem ismerjük. Hogy ezt megismerjük, véletlen vagy meghatározott jeleket, bemenőjeleket közlünk a dobozzal, és a hatást a kimenőjeleken figyeljük vagy mérjük meg. E jelek vizsgálatából matematikai módszerek segítségével meghatározható a kapcsolatukat leíró átmeneti függvény" (wikipedia).

Amikor egy folyamatot meg akarunk ismerni (pl. azért, mert javítani akarjuk a hatékonyságát), modellt készítünk róla (uszoda modell vagy értékáram térkép), meghatározzuk, milyen célt kell elérni az adott folyamatnak, majd ennek megfelelően átalakítjuk, elindítjuk és megfigyeljük, eléri-e a kívánt eredményt (amolyan trial and error módon). Ha nem, akkor tovább módosítjuk, újra teszteljük, és ezt a folyamatot ismételjük, amíg el nem érjük az célt.

Első próbálkozásra ritkán sikerülnek jól (100%-osra) a dolgok, nem is célszerű ilyen elvárásokkal a folyamatoptimalizálásnak nekikezdeni.

---

Ugyanaz vagy ugyanúgy?

Azt mondta egy sikeres (?) manager, hogy "ha valaki 10 évig ugyanazt csinálja az könnyen belefárad és ilyenkor egy váltás új lehetőséget biztosíthat a számára". És mindenki bólogat, taps, függöny le, manager balra el.

Érdekes elmélet, de nem teljesen igaz. Ha valaki pl. 10 évig minden nap számlákat könyvel, na abba bele lehet zakkanni. Ez tény. De lehet azon a könyvelésen VÁLTOZTATNI. MÁSHOGY CSINÁLNI. Problémákat feltárni, megszüntetni, egyszerűsíteni, stb. Ha valaki megpróbálja ezt komolyan venni, akkor

• vagy az lesz, hogy simán kibír 10 évet, mert nem csinálja mindig ugyanazt, ugyanúgy.
• vagy az lesz, hogy szépen lassan "racionalizálja" magát, miközben kitanul más szakmát/munkát, így talál magának más munkát a 10 éven belül, akár többször is, ha ahhoz van kedve.

Például.

---

Sorrend kellene

Néha úgy tűnik, hogy az ügyfelek elég ad-hoc módon választják ki "kaizenelendő" folyamataikat. Pedig nem ártana figyelembe venni, hogy a folyamatokat mindig kiváltja egy esemény. Ezen események egy része tulajdonképpen probléma. Ez a probléma egy másik folyamatban keletkezik amit szintén események indítanak, amelyek közül néhány esetleg probléma, ésígytovább. Ezt a "problémapiramist" azonban érdemes "visszabontani", mielőtt a problémamegoldással elkezdünk foglalkozni. Mert ilyenkor az történhet, hogy a piramis lábánal levő folyamatokat kezdjük el optimalizálni, miközben esetleg nincs is rájuk szükség, ha a kiváltó eseményeket (problémákat) megszüntetjük.

Talán a folyamatok esetében is érdemes lenne az eredetileg tudomásom szerint a tevékenyégekre kitalált ECRS-módszert akalmazni. Azaz először mindig kérdezzük meg magunktól: mi lenne ha ilyen folyamatunk nem is lenne? Mert az erre adott "de ez azért kell nekünk, mert..." kezdetű válaszokban ott van az összes érdekes probléma.

---

Cél, mérőszám és eredmény

Hallottam pár érdekes célt mostanában, van velük egy kis problémám. Az egyiket már egyszer említettem, mivel az anyagkészletek csökkentése egy termelő vállalatnál nem lehet cél, ez ui. a lean átalakulás egyik eredménye. Mivel azonban könnyen meghatározható és mérhető, valamint nem ütközik komoly politikai ellenállásba, ez lesz célnak meghatározva. Pedig cél helyett alkalmazható lenne mérőszámnak, ami ugye azért nem ugyanaz. Ez az egész kinézhetne pl. így is:

1. CÉL: adott termék gyártási költségeinek csökkentése 20%-al [HUF]
2. MÉRŐSZÁMOK [mértékegység]:
• gyártási költség, [HUF]
• anyagkészletek, [HUF]
• emberi ráfordítások, [munkaóra]
• elfoglalt felület, [m²]
• karbantartási költségek, [HUF]
• ...
3. MÓDSZER: pl. termelés kiegyenlítése (heijunka), JIT-filozófiájú átszervezése
   

A másik érdekes cél, amibe nemrég futottam bele, az a beszállítói szám csökkentése. Miért nem lehetne ezt pl. így:

1. CÉL: beszerzési költségek csökkentése [HUF]
2. MÉRŐSZÁMOK [mértékegység]:
• beszerzési költség, [HUF]
• beszerzői létszám, [fő]
• beszállítók darabszáma, [db]
• beszerzési átfutási idő, [óra, munkanap]
• ...
3. MÓDSZER: beszerzési folyamat értékáram elemzése, veszteségek kiküszöbölése, ok-okozati elemzések elvégzése

Mi derülhet ki egy ilyen esetben? Pl. hogy azért tart sokáig egy beszerzési folyamat, mert sok a beszállító és sok ajánlatot kell kérni, mert beszerzési előírás, hogy minden igényre "n" darab ajánlatot kell bekérni. Pl. hogy azért kell sok beszerző, mert minden "n." évben újra ki kell írni (értsd: meg kell pályáztatni) az anyagot, szolgáltatást, mert ez az előírás, annak érdekében, hogy még olcsóbban tudjunk beszerezni. Pl. hogy az olcsón beszerzett anyagokkal, szolgáltatásokkal sok a probléma, ezért magas a beszerző nem értékteremtő (értsd: reklamációkezelő) ráfordítása, amiért aztán sok beszerzőre van szükség.  Vagy pl. az, hogy a beszerzés nem azt tartja értéknek, hogy biztonságosan (értsd: JIT, megfelelő minőség, elfogadható ár/érték arány) kiszolgálja az értékteremtő folyamatokat, hanem azt, hogy olcsón szerezzen be...

Már ezért megéri ezzel foglalkozni...

---

Megint szoftverek...

A szoftverek fontosak. Mai életünk azonban (sajnos) tele van szoftverekkel, sokuk nélkül már életünk megszervezése is nehéz, de pl. blogot sem lehetne írni, ha nem lenne internet, blogmotor, egyebek..

Viszont többségük kiválóan alkalmas arra, hogy meggondolatlan alkalmazásukkal ott is hibákat vétsünk, ahol azelőtt nem. Vegyük pl. a logisztikát. Ismerek olyan szoftvert, ami olyan sok felhasználót támogat szerte a világon, hogy nem előre beállított, hanem paraméterezhető folyamatokat tartalmaz. Így pl. beállíthatunk olyan folyamatot, amely negatív raktárkészlethez vezet, azaz tisztán informatikailag pl. a még be sem érkezett anyagot már el is használhatjuk. Aztán pl. megtörténhet, hogy a beérkezett anyagot beérkezéskor (amikor még fizikailag a teherautón van) rögtön a végleges helyére tárolunk be magában a szoftverben, miközben fizikailag csak órák múlva kerül oda.

Ami igazából érdekessé teszi a problémát az az, hogy bár az esetek, problémák egy részéért valóban a szoftver a felelős de a többségéért a folyamat vagy maguk a folyamatokban dolgozó emberek. Mégis mindig a szoftver a hibás... és persze fejlesztésre szorul. Aminek azonban csak a szoftverfejlesztők örülhetnek.

---

Robotok

Egy cikkben olvastam, hogy már nálunk is műtöttek robottal. A robot által végzett műtétek előnye a hatékonyság és a magasfokú betegorientáltság (kevesebb vérveszteség, kevesebb fájdalom, rövidebb műtét utáni gyógyulási idő). Azaz nagyon leannek tűnik. De.

A robotok és az életmentés egyéb, egyre fejlődő technikái fontosak és nélkülözhetetlenek, a fejlődés itt is elkerülhetetlen. Ez a fejlődés viszont nem lehet kizárólag technikaorientált. Ezzel párhuzamosan a kórházak alapvető működési rendjének is meg kell változnia. Amihez viszont elsősorban a fejekben kell változásnak bekövetkezni. Gondolok itt a páciensek előtérbe heylezésére, a tevékenységek megszabadítására mindenféle veszteségtől (épp azért, hogy a betegekkel lehessen többet foglalkozni), miközben továbbra is fontos a gazdaságos és átlátható működés, hiszen olyan emberek pénzét költi el az egészségügy (ha minden így marad), akik lehet, hogy sohasem kerülnek kórházba, tehát elég kritikusan figyelik, mire is megy el a pénz. Ha viszont a dolgok "fizetőssé" válnak és megjelenik egyszercsak az öntudatos fogyasztó, akkor ő öntudatos beteg is lesz, akinek fontosak a fent említett paraméterek.

Nem beszélve arről az abszolut el nem hanyagolható kérédsről, milyen ütemben tart mindezzel lépést a személyzet és az orvosok oktatása (gondolok elsősorban a felsőoktatásra). Nem mindegy ui, hogy a Kovács doktor úrnak asszisztál az ember vagy MZ/X-nek, még ha elsőre viccesnek is hangzik a dolog. Emellett számos, eddig fel nem merülő kockázattal és rizikóval kell megbírkózni, mert bár a robot homlokát nem kell megtötölgetni, de mi van, ha meghibásodik?

---

Egyszerű

Mindig kutatjuk a kaizen lehetőségeit (ugye kutatjuk?) és sokszor gondolunk Nagyon Bonyolult Dolgokra. Pedig nem kellene. Íme egy példa:

Nálunk a különböző irodákban és tárgyalókban egészen intelligens világítás van, egészen bonyolult kapcsolókkal. A kapcsolókra rejtélyes dolgok vannak felvésve, hogy a jövő régészeinek is legyen mivel elütniük az időt. Egy ilyen kapcsolókomplexum, ha pechünk van (márpedig van), állhat pl. 6 különböző kapcsolóból, mindenféle eligazodást jelentő piktogram nélkül vagy ami még rosszabb, megtévesztő feliratokkal, egy nyelven (emlékeznek a T. Olvasók, én multinacionalista vállalatnál dolgozom). Megfigyeléseim szerint a nagyon profi kapcsolgatók kivételével mindenki csak próbálkozik. Ez főleg a tárgyalók esetében tettenérhető, mert azokhoz nem szokik hozzá az ember (mert keveset megbeszél, ugye:). Kaizen lenne, ha mondjuk a kapcsolókon lenne vmi kis felirat, hogy mit kapcsolnak. Magyarul és külföldiül, vagy piktogrammal, mert az univerzális.
Ennyi.

---

Programozott pazarlás

Nemrég töröltem -magyarul uninstalláltam- egy programot a gépről. Az utolsó szükséges klikk után kis ideig nem történt semmi, majd egy kis ablakban megjelent üzenet szerint a program az uninstalláláshoz szükséges adatok gyűjtésébe fogott. Innentől kezdve a gépen semmit sem lehetett csinálni (hozzátenném, hogy jó középkategóriás hardware-ről van szó) úgy kb 10 percig, amíg ez a gyűjtögetés, majd a törlés folyt. Akármit próbáltam, minden komoly késéssel hajtódott végre.

Tudom, hogy az informatikusok szerint alapvetően mindenért a windows a felelős, de én ezt vitatnám. Véleményem szerint ui. a szoftvergyártók elenyésző része gondolja úgy, hogy meg kellene keresnie a középutat a jól működő szoftver és a gépigény között. A Microsoft sem célozta meg ezt fejlesztéseivel. A szoftverek nagy része szépen lassan fejleszteti a felhasználóval a gépet, mások egyszerűen már a piacra kerüléskor kinevetik a nem high-end hardware-rel felszerelkezett felhasználókat... 

A probléma nemcsak az "optimalizált" kóddal van, hanem a szoftverekbe épített, sokszor felesleges tudással is. Pl. a word lassan mindenre jó lesz, de én egyre kevésbé tudok vele szöveget szerkeszteni. Az egyik piacvezető cd/dvd-író szoftver installálásakor kipróbáltam a custom módot, ami ugye tapasztalt felhasználóknak (advanced user, vagy mi) ajánlott, nos ebben a módban nemcsak az installálás helsét, de a kívánt komponenseket is meghatározhattam. Hiába beszélt magyarul, sok komponensről máig nem tudom, mire való. Ezeket egyszerűen kikapcsoltam, így kb. a felére csökkent az elfoglalt hely a merevlemezen. Mi van a typical user-ekkel? Ők jobb, ha megveszik a legnagyobb merevlemezt, amit a boltban árulnak...

---

Megint eü

Hallottam, igazságtartalmát nem ellenőriztem, de a forrást megbízhatónak tartom:

Kórház szülészetén hosszú évek óta dolgozó munkatárs szülés után nem tudott visszamenni eredeti helyére, ezért áthelyezték az intenzívre (!). Rögtön első héten kapott is egy beteget, akiért így felelősséget is vállal. Betanítása nem volt, most tanulgatja, a gépeken melyik gomb, kapcsoló, kijelző mit jelent.

Most nem szeretnék hosszas fejtegetésbe bonyolódni, mit gondolok a nővérhiánynak nevezett management hibáról (ha a nővérek munkájából kivennénk az összes veszteséget, lenne rögtön elegendő kapacitás, abban biztos vagyok), inkább az egészségügybe ill. a működésbe beleépített kockázatokról beszélnék.

Bár az elv jól hangzik, nem nagyon láttam még olyan munkahelyet, ahova nem kell betanulni, legyen az bármilyen egyszerű vagy legyenek a tevékenységek bármennyire egyszerűsítettek. Még az utcasöprés sem ilyen (ha csak úgy nekiállunk, hamar elfáradunk, tessék csak kipróbálni...). Az egészségügy ráadásul szinte minden más munkahelynél nagyobb kockázatokat tartalmaz, ha nem tartunk be alapvető biztonsági előírásokat ill. nem rendelkezünk megfelelő tudással a munka ellátásához. Az intenzívre érkező munkatársnak alapos betanítást kellett volna kapnia (munkarend, kórtermek, gyógyszerek készletének helye, mi van zárva és kinél vannak a kulcsok, melyik gépnek mi a funkciója, melyik kijelző mit mutat, melyik hangjelzés mit jelent, stb.) és meghatározott ideig nem szabadna egyedül dolgoznia. Megkockáztatom, hogy az intenzív pont az a hely, ahol még vizsgát is kellene tennie.

Ja, hogy erre sincs kapacitás? Hogy nincs, aki betanítsa? Hoppá. Molnár úr gondolt esetleg arra, hogy meg lehetne emelni a fizetéseket (hogy az elégedettség meglegyen), hogy a kórház működését át kellene szervezni, hogy a veszteségeket ki kellene venni a folyamatokból, hogy a személyzetet oktatni kellene lean témakörben, hogy teret kell kapniuk, hogy ötleteiket elmondhassák, azokat, amikkel saját munkájukat és munkakörülményeiket javíthatják (hogy motiváltak legyenek). És ne mondják, hogy nincs pénz a fizetésemelésekre. Van, csak ma elszórják a gazdaságtalan működésre...

Ez talán jobban bejönne, ágyszámcsökentés helyett. Próbálják ki, figyeljék meg, hogy a végén kevesebb ágy is elég lesz, ki lehet tolni a többit a kórteremből. Sőt, nem lepődnék meg, ha egyszer csak maguk a nővérek és az orvosok tolnák ki.

---

Átfutási idő

---