Kalev Kaarna küsib oma teises tootmisjuhtimise alases artiklis, kas Excel saab olla närviline või on asi hoopis kasutajas. Kui hakkad kasutama mõnda ressursside planeerimise süsteemi, siis tekib oht ka närviliseks tarkvaraks ja närviliseks või ülitundlikuks tarneahelaks.
Loe ka eelmist artiklit Mis kujuga on sinu ettevõtte tootmisjuhtimise keerukus?
Kui närviline on sinu ettevõtte tarkvara?
Kas Excel saab olla närviline? Või saab närviline olla ainult Exceli kasutaja? Niikaua kui kasutad oma tootmise juhtimiseks paberit ja pliiatsit ning lihtsamaid Exceli tabeleid, siis tarkvara närvilisus sind tõenäoliselt ei kimbuta.
Kui aga hakkad kasutama mõnda ressursside planeerimise süsteemi (ERP – enterprise resource planning või MRP – material requirements planning), siis tekib oht ka närviliseks tarkvaraks ja närviliseks või ülitundlikuks tarneahelaks.
Iseenesest on toomiskeskkond üks keerukamaid töökohti, kus on palju sõltuvusi ja määramatust. Kui laos on sadu materjale, tehases kümneid töötajaid ning tehasest väljaspool kümneid tarnijaid ja edasimüüjaid, siis on päris keerukas kõike koordineerida ja tagada, et kõik tööd saaksid tehtud vastavalt nõutud kvaliteedile ja seatud tarnetähtajaks. Arvutipõhised planeerimise süsteemid nagu ERP-d ja ka kitsama fookusega lao ning tootmise juhtimise tarkvarad on loodud, et seda keerukat ülesannet kergemini ära teha.
Kahjuks ei ole tarkvara olnud ainult probleemide lahendaja vaid ka probleemide tekitaja
Üheks selliseks probleemiks on närvilisus tootmises ja tarneahelas. Mida rohkem kasutavad tootjad ja tarnijad ühes tarneahelas keerukaid ERP või MRP tarkvarasid, seda närvilisem on tarneahel.
Tarneahelate juhtimise sertifikaate väljastava APICSi sõnaraamatu järgi mõistetakse tarkvarast tuleneva närvilisuse all järgmist: närvilisus on materjalide planeerimise tarkvarade süsteemide (MRP) omadus, mille tõttu väikesed muudatused materjali spetsifikatsiooni kõrgemal tasemel (nt. 0 või 1) või peatootmisplaanis (MSP) toovad kaasa olulisi ajalisi ja koguselisi muudatusi materjali spetsifikatsiooni madalamatel tasemete (nt. 3) plaanides ja tellimustes.
Joonis 1. Toote kolmetasemeline materjalide spetsifikatsioon. Allikas:Tootearendus. Tartu Teaduspark 2006.
Iseenesest ei ole midagi halba plaanide muutmises
Võib juhtuda, et tootmises toimuvad muutused kiiresti ja kui me tarkvaras plaane ei uuenda, siis on toimiv tootmisplaan ainult tootmisjuhi peas. Hommikul tarkvaras tehtudplaan kehtib võib-olla ainult paar tundi kuni selgub, et mingi tellimus on ikkagi kriitilisem kui algul arvati või mõne tellimusega alustamiseks pole ikkagi kogu materjali olemas. Selles võtmes oleks ju hea, kui iga olulisema uue info korral tootmisplaan ümber tehakse, et see peegeldaks reaalsust, mitte soovunelmat.
Probleemid tekivad kui juhid ja töötajad tahavad olla liiga agarad ning iga uue infokillu järel teha muudatusi plaanidesse. Tootmisettevõttes tähendaks see piltlikult seda, et ühe kapi lisandumisel nõuab MRP tarkvara, et kogu naelte ja kruvide hanke plaan tuleb ümber teha. Selline iga tunni tagant plaanide ümbertegemine ei ole aga realistlik.
Tarneahela puhul tähendab tarkvarast tulenev närvilisus, et väike muutus nõudluses toob kaasa suuri muutusi poes, hulgifirmade vaheladudes ja tootjate juures. Ilmekaks näiteks tarneahelas tekkivale ülereageerimisele on Peter Senge raamatus “Viies distsipliin” toodud õlletootmise näide. Kui tarneaeg on 4 nädalat ja info liigub tarneahelas vaid tarkvara vahendusel edastatud tellimustena, siis muutub ühe konkreetse õllebrändi nõudluse tõus 4 kastilt nädalas 8 kastini tõeliseks õudusunenäoks. Kui 16nda nädalani on õlut pidevalt puudu ja täitmata tellimuste kogused muudkui kuhjuvad, siis 23ndaks nädalaks on tootjal ja hulgilaol tellimuste kuhjumise tõttu kokku üle 300 kasti õlut laos ja pood ei telli midagi. Samas turu nõudlus on olnud kogu aeg stabiilne (8 kasti nädalas) ja kõik kolm osapoolt on püüdnud kasumit maksimeerida. Peter Senge toob õlletootmise näite järeldustena välja, et probleemid tekivad siis kui tarneahel või tootmine ei suhtle erinevate osapooltega sisuliselt, tootmine ei suuda muutustele piisavalt kiiresti reageerida ja tarneahelas ei arvestata oma käitumise mõjuga järgnevatele üksustele. Siia võib lisada, et kiire aga ühekülgne info liikumine tänu IT-süsteemile võib kasu asemel hoopis kahju tekitada.
Ükskõik kas vaatame ettevõtte või tarneahela reageerimise närvilisust on võtmeküsimus, et kui tihti peaks uue info valguses ümber arvutama tellimuste tööplaane ja tähtaegu.
Oluline on eristada kahte aspekti:
– süsteemi informeerimise kiirus (minutitega),
– kui sageli võetakse uue info põhjal vastu otsuseid.
Otsustamise eelduseks on info olemasolu. Teadlikult otsustamisega venitamine on igal juhul parem olukord kui info puudusest tulenev tegutsemata jätmine.
Kui info on olemas, siis ühelt poolt võib väita, et närvilisus planeerimises on hea, aga pidev ümberotsustamine halb. See tähendab, et juhina tahan, et mul oleks võimalik uue infokillu puhul ümber hinnata, kuidas muutus materjali mitte saabumises tootmise tähtaegu mõjutab. Samas ei tähenda iga muutus laoseisus vajadust kohesealt reageerida ja kõigile töötajatele uued töökäsud kätte jagada.
Vähendamaks juhil vajadust iga muutuse peale reageerida peavad ettevõttes olema paigas materjalide ja ressursside puhvrid.
TSENTRI järgmistes postitustes käsitleme teemasid, kuidas määrata puhvrite asukohta ja suurust DD-MRP meetodil või taastamispõhise tarne meetodil.
Vaatamata puhvritele on siiski muutlikumas tootmiskeskkonnas vajadus ressursside planeerijal mitu korda päevas otsustada. Kui osad muutused tasakaalustavad teinetest ära ning ei nõua sekkumist, siis mõistlik oleks sisse seada otsustamise tsüklid.
Enamik otsuseid saab kokku koguda ning teha neid üks kord päevas (nt. materjali tellimine tarnijatelt, tellimuste täitmise töökäskude väljastamine). Samas tööde valmimise tähtajad võidakse vaadata üle korra vahetuse jooksul tagamaks tööde järjekorra õigsust. Osa info puhul piisab kui see vaadatakse üle korra nädalas (nt. enneaegselt saabunud tarne). Kindlasti on olemas aga ka otsuseid, mis nõuavad kohest langetamist ja kus viivitamine võib tuua kaasa kulukaid tagajärgi. Näiteks võib täitmisel olev materjali tellimine muutuda ebaoluliseks, sest klient tühistas oma tellimuse või muutis spetsifikatsioone. Kohest sekkumist vajavad ka normist oluliselt suuremad kvaliteediprobleemid.
Praktilisest seisukohast lähtudes tuleb jälgida, et sel ajal kui peatootmisplaani (MPS – master schedule plan) viiakse sisse muudatusi ning koostatakse uut plaani, ei tohi keegi saada süsteemist võtta töökäske. Ümberplaneerimise ajal võib MPS muutuda mitu korda ning poolikust uuest plaanist saadud info võib tekitada märkimisväärset segadust.
Kokkuvõttes kuigi ERP ja MRP tarkvara võimaldab arvutada plaane ümber kasvõi iga tunni tagant, siis enamasti muudaks nii sage peatootmisplaani muutmine süsteemi väga närviliseks ja üle reageerivaks.
Kui ettevõte soovib tagada kiiret reageerimist, aga vältida tarkvara närvilisust, siis:
– tuleks paika panna puhvrid,
– otsustada ära, milline on erineva info peale reageerimise sagedus (kohene, kord vahetuse jooksul, kord päevas, kord nädalas jne),
– arvestada ümberotsustamise mõjuga eelmistele või järgmistele üksustele tarneahelas.
Kasutatud materjalid:
· APICS Dictionary 2007 · Beer Distribution Game https://en.wikipedia.org/wiki/Beer_distribution_game
· Martin, J. R. The Beer Game. Management And Accounting Web http://maaw.info/TheBeerGame.htm
· P. M. Senge, A. Kleiner, C. Roberts, R. B. Ross, B. J. Smith. (2013) Viie distsipliini käsiraamat. Fontes, 523 lk.
· Ptak, C., Smith, C. (2011) Orlicky’s Material Requirments Planning. 3rd Edition. 526 lk.
· Srikanth, M. DBR, Buffer Management, and VATI Flow Classification (2011). Chapter 8. James F. Cox III. “Theory of Constraints Handbook.” 1216 lk. · Tootearendus. Tartu Teaduspark 2006. 172 lk.
Artikli autorid: Kalev Kaarna ja Tanel Velga