MRP kehittyi  1960-luvulla IBM:n toimesta. Tietokoneet rupesivat yleistymään tuotantolaitoksissa ja niillä ruvettiin hoitamaan monia laskutehtäviä. Koska tuotannon suunnittelu oli melko monimutkaista, oli luonnollista yrittää saada se tietokoneen laskettavaksi.

Sen lähtökohdat on IBM:ssä, josta se rupesi yleistymään amerikkalaisiin tehtaisiin 1970 luvulla. Sittemmin MRP:tä jalostui ensin MRP II (manufacturing resources planning) kehittyen edelleen BRP (business resource planning), ERP (enterprise resources planning) ja SCM (supply chain management).

Huolimatta erilaisista nimistä, pohjautuu nykypäivän ERP ja SCM-ohjelmat vahvasti edelleen alkuperäiseen MRP-ideaan.

Rakaamateriaalin ohjaus

Ennen MRP-ohjelmien saapumista raakamateriaalien ohjaus pohjautui erilaisten tilauspisteiden hallintaan. Sittemmin huomattiin, että tämä ei välttämättä ole paras tapa hoitaa raakamateriaalien tilaamista. Koska kysyntä ohjaa tuotantoa, tiedämme materiaalitarpeen kysynnän mukaan lasketusta tuotannosta. MRP pohjautuukin vahvasti BOM:n (bill of material) eli tuotantorakenteesta laadittuun osalistaan.

Järjestelmään on syötetty kuinka paljon mitäkin osaa tarvitaan yhden lopputuotteen valmistamiseen. Puhutaan niin sanotusta riippuvasta kysynnästä, eli jonkin osan kysyntä riippuu toisen osan kysynnästä tai lopputuotteen myynnistä. Riippumaton kysyntä on järjestelmän ulkopuolista kysyntää, kuten lopputuotteiden ja varaosien myynti. Riippuva kysyntä on järjestelmän sisäistä kysyntää, jolloin osatarve seuraa ja on riippuvainen lopputuotteen kysynnästä. Huomaa että jotkin komponentit voivat sisältyä molempiin, mikäli ne ovat varaosia.

MRP:tä kutsutaankin työntöohjaavaksi systeemiksi, koska se laskee osatarpeet riippumattomasta kysynnästä takaperin ja sen jälkeen työntää osien aikataulutuksen läpi koko tuotannon, jossa valitsee riippuva kysyntä.

Järjestelmän tarkoituksena on laskea ja aikatauluttaa hankinnat ja työvaiheet. Se laskee tarpeet BOM:n mukaan myynnistä. Yleensä järjestelmä koostuu aikaikkunoista, jotka voivat olla päiviä tai viikkoja. Mitä enemmän laskentakapasiteettia, sitä lyhyempää aikaikkunaa voidaan käyttää. Aikaikkunan koko onkin jatkuvasti lyhentynyt.

Esimerkin vuoksi, jos järjestelmän aikaikkuna on 1 viikko, laskee järjestelmä koko viikon kysynnän yhteen ja aikatauluttaa tuotannon tapahtuvaksi maanantaihin mennessä.

Ongelmat

MRP järjestelmään liittyy monia samoja ongelmia, mitä aiemmin on kuvattu tilaamisesta. Minkä suuruisia eriä tilataan ja minkä suuruisia eriä tuotannossa tuotetaan. Järjestelmässä on varmuusvarastojen lisäksi tuotantoon liittyvä varmuusaika, joka tarkoittaa sitä, että tuotanto aikataulutetaan tapahtuvan riittävän ajoissa kysyntään nähden. Tuotannossa voi tapahtua monia virheitä, kuten konerikkoja, eikä kaikki tuotettu tuotanto välttämättä täytä laatustandardeja. Näiden erinäisten muuttujien johdosta joudutaan aikatauluttamaan pelivaraa.

MRP:n huonoja puolia on sen vaikeahko muuttaminen. Aikataulut luodaan etukäteen ja kysynnässä tapahtuvat muutokset on vaikea viedä läpi koko ketjuun. Ennalta määritellyt tilauserät voivat luoda muutostilanteissa todella omituisia aikataulutuksia. Tämän johdosta paras tilauserä olisikin 1 kpl, mikä ei monestikaan ole kovin taloudellista. Eri osille tulisi luoda erilaiset tilaustavat, osa materiaalista hankittaisiin tilausvälimenetelmällä, osa yksittäin ja osa tietyllä eräkoolla.

Lisäksi malli olettaa tuotannon tapahtuvan aina yhtä nopeasti oli tehdas täyteen kuormitettu tai tekemässä ainoastaan tätä tilausta. Malli tavallaan olettaa tuotannon kapasiteetin äärettömäksi.

Pitkät läpimenoajat kasvattavat varastoja. Läpimenoaikoihin sisäänleivotut turvamarginaalit vain voimistavat tätä efektiä.

MRP II

MRP kehittyi kakkosversioon, kun järjestelmää kehitettiin ratkomaan omia ongelmiaan. Tietomäärä kasvoi ja MRP II sisältää mm. kysynnän hallintaa, ennustuksia, kapasiteetin suunnittelua ja lähetystoimintaa. Ajan myötä tämä kehittyi niin pitkälle, että järjestelmää alettiin kutsumaan nimellä ERP. Osittain syynä oli MRP:n huono kaiku, osittain siksi, että yritys nimeltään SAP halusi suunnata ohjelmistonsa laajempaan kuin vain tuotannon käyttöön.

 

 

Mikäli aihe kiinnostaa enemmänkin, niin tämän pintapuolisen kuvauksen sijasta järjestelmän syvempi olemus, tarkempi BOM-rakenne ja erilaiset laskutehtävät esitellään hyvin seikkaperäisesti esimerkiksi Factory Physics -kirjassa (Wallace J. Hopp  & Mark L. Spearman). Siinä asiaa käsitellään 35 sivun verran.

Written by Jesse Uitto

CEO @ Novellus.fi

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *