Az optimalizálónak igaza volt, a műszak mégis rosszul sült el

Van egy sajátos kudarcforma, amely azután következik be, hogy egy cég ütemezőszoftvert vásárol, és gyakoribb, mint azt a szakmámban bárki szívesen elismerné.

Megszületik a terv. Érvényes. Minden korlát, amelyet megadtak a rendszernek, teljesül, a költségszám alacsonyabb a kézi megoldásnál, és a projektet vezető embernek van róla egy diája.

Aztán lefut a műszak, és káosz lesz. Délelőtt tízre a művezető papíron újraépítette a felét.

Senki nem hazudott. A megoldó azt tette, amit kértek tőle. A rés a matematikailag helyes válasz és a valódi reggelt túlélő műszak között van, és négy helyről ered. Kettő az Ön problémája. Kettő a szállítóé, és ezeket érdemes rajta számon kérni.

1. A korlátok, amelyeket senki nem írt le

Ez a legnagyobb, és szinte soha nincs benne a projekttervben.

Minden működés szabályok olyan halmazán fut, amely le van írva, és egy jóval nagyobb halmazon, amely nincs. A leírtak az első héten bekerülnek a modellbe. A leíratlanok a következő hat hónapban bukkannak elő, egyesével, esetről esetre.

Így hangzanak. Ezt a kettőt nem tesszük egy csapatba. A 4-es kapu mindig Péteré, mert Péter tudja, hogy az érzékelő rossz. Ha esik, kell egy plusz ember arra az állóhelyre, és ez semmilyen dokumentumban nincs benne. Az 05:40-es eligazítás minden hétfőn túlfut. Az az ügyfél reklamálni fog, ha új belépőt küldünk, függetlenül a képesítéstől.

Ezek egyike sem irracionális. A legtöbb valami olyat kódol, ami egyszer rosszul sült el. És az a beosztás, amely figyelmen kívül hagyja őket, technikailag megvalósítható és gyakorlatilag használhatatlan, mert a működés tényleges, nem pedig dokumentált korlátait sérti.

A hiba az, ha ezt egyszeri adatgyűjtésnek tekintik. Nem az. A hallgatólagos korlátok kinyerése azoktól, akik birtokolják őket, bármely ütemezési projekt valódi munkájának nagy része, hónapokig tart, és ez az a rész, amelyből megtartásra érdemes rendszer születik. Tervezzen rá keretet kifejezetten. Ha egy szállító bevezetési tervében nincs jelentős tétel arra, hogy diszpécserekkel és művezetőkkel üljön le, akkor nem csinálta még ezt.

Egy gyakorlati út befelé: futtassa az optimalizáló tervét az emberi terv mellett néhány hétig anélkül, hogy cselekedne alapján, és kérje meg a művezetőt, hogy magyarázzon el minden eltérést. Minden magyarázat vagy egy hiányzó korlát, vagy egy elhagyásra érdemes szokás. Mindkettőt érdemes tudni, és három ilyen hétből többet tanul, mint három hónap workshopból.

2. Az időtartamai két különböző dolog átlagai

Minden ütemezési modellnek tudnia kell, mennyi ideig tartanak a feladatok. Szinte mindegyik vagy normaidő-táblázatból, vagy múltbeli átlagból veszi ezt, és mindkettő ugyanúgy, csendben téves.

Vegyen egy feladatot húszperces normaidővel. Nézze meg, mi történik valójában, és általában azt találja, hogy ez nem húsz körüli eloszlás. Hanem két eloszlás. Tizennégy perc a tapasztalt csapattal, ismerős géptípuson, és harminckettő, ha új belépő van, vagy az eszköz a távoli állóhelyen áll, vagy fagypont alatt vagyunk.

Az átlag huszonhárom, és a huszonhárom olyan szám, amely egyetlen tényleges eseményt sem ír le.

Tervezzen az átlaggal, és egész nap mindkét irányban téved. A nehéz eseteket alultervezi, a könnyűeket túl, és a hibák nem oltják ki egymást — egyenetlenül csapódnak le, és pontosan ez az, ami egy feszes beosztást megtör.

Ennek javításához nem kell ügyes modellezés. Ahhoz kell, hogy a modell tudja, mitől függ ténylegesen a feladat: melyik típus, melyik állóhely, milyen tapasztalati szint, milyen az időjárás. Ez nem gépi tanulási projekt. Ugyanaz a korlátmodellezési beszélgetés, mint fent, időtartamokra alkalmazva — és az alátámasztó adat általában már létezik valahol, ahová senki nem nézett.

Ebből következik a kényelmetlen előfeltétel. Ha nem rögzíti, mi történt ténylegesen — feladat elkezdve, feladat befejezve, ki által —, ebből semmit nem tud megcsinálni, és az időtartamai örökre becslések maradnak. A végrehajtás rögzítése nem az optimalizálás után jövő kellemes extra. Ez az, amitől az optimalizálás nem romlik el.

3. Az optimális definíció szerint tartalék nélküli

Ez a szállító hibája, és ritkán magyarázzák el a vevőknek.

Ha azt kéri egy megoldótól, hogy minimalizálja a költséget vagy a létszámot, meg fogja tenni. Megtalálja azt az elrendezést, ahol mindenki dolgozik és minden rés bezárul, mert bármely meghagyott tartalék olyan költség lett volna, amelyet el tudott volna távolítani.

A tartalék nélküli beosztás olyan beosztás, ahol az első fennakadás továbbgyűrűzik. A késő beérkező nem csak azt a fordulót érinti; a következőt is, mert az az ember, aki azt csinálta volna, még mindig az elsőn van, és köztük szerkezetileg nem volt ütköző.

Így egy papíron öt százalékkal olcsóbb terv a gyakorlatban lényegesen drágább lehet, ha beleszámoljuk a túlórát, a helyreállítást és a szolgáltatásiszint-sértést. És ezt sosem fogja látni az összehasonlításban, mert az összehasonlítás a terven futott.

A megoldás az, hogy a tartalékot tudatosan vásárolja meg, ne pedig véletlenül távolítsák el. Védje azokat a fordulókat, ahol a késés a legmesszebbre gyűrűzik. Tartson egy szabad embert a csúcsban ahelyett, hogy beosztaná. Döntse el, hova kerülnek az ütközők, és tegye be őket a modellbe korlátként, hogy az optimalizáló körülöttük dolgozzon, ne pedig felélje őket.

Kérdezze meg minden szállítótól, hogyan kezeli ezt a rendszerük. Ha a válasz az, hogy a terv optimális, az rossz válasz.

4. A terv hipotézis volt, és senki nem frissítette

Az utolsó szerkezeti. Az 05:00-kor készült terv helyes volt azzal, amit 05:00-kor tudtak. 07:00-ra több minden megváltozott, és a terv egy olyan reggel leírása, amely nem történik meg.

Sok ütemezőszoftver itt megáll. Tervez, nyomtat, és vár a holnapra. Az újratervezést egy művezető végzi rádióval és filctollal — vagyis pontosan az, aminek a kiváltására a szoftvert vették.

A lényeges mérőszám a késleltetés a valóság változása és a terv változása között. Nevezzük újratervezési késleltetésnek. Ha egyik napról a másikra tart, tervezőeszközt vásárolt. Ha percekben mérhető, operatív rendszert. Jogos kérdés minden szállítóhoz, és a válaszok óriási szórást mutatnak.

Ahhoz, hogy percekre csökkenjen, három dolog kell, és mindhárom nehezebb magánál a megoldásnál: tudni, mi történik éppen most; elég gyorsan újraszámolni ahhoz, hogy műszak közben hasznos legyen; és úgy csinálni, hogy a művezető el tudja indítani és meg tudja érteni anélkül, hogy konfigurációs képernyőt nyitna. Ez az utolsó az, ahol a legtöbb ilyen rendszer elvérzik. Az az újratervezés, amelyben a művezető nem bízik, az az újratervezés, amelyet figyelmen kívül hagy.

Ki miért felel

Osszuk szét őszintén, mert ez a felosztás dönti el, működik-e a projekt:

Az elsőt senki nem tudja Ön helyett kinyerni — lehet segíteni, de a tudás az Ön embereiben él, és az adat az Ön működéséből jön. Ha nem szán rá valódi művezetői időt, ezt egyetlen szállító sem tudja pótolni. A másodikat pedig, ha egy szállító nem tudja konkrétan megbeszélni, akkor tervezőt ad el Önnek.

A jó hír, hogy mindkét fél halmozódik. A korlátmodell minden hónapban pontosabb lesz, ahogy valaki javítja. Az időtartambecslések minden héten jobbak lesznek, ahogy rögzíti, mi történt. Az az ütemezőrendszer, amely a második évben nem mérhetően jobb, mint az első napon, nem tanul semmit — és érdemes megkérdezni, miért.

Az Optimum Intelligence optimalizációs rendszereket épít olyan működésekhez, ahol a terv és a valóság ebédidő előtt elválik egymástól — földi kiszolgáláshoz, elosztáshoz és létesítménygazdálkodáshoz. Ha a művezetői délelőtt tízkor még mindig kézzel építik újra a tervet, szívesen beszélünk.