Varastonhallinnan kehittämistä on pitkään leimannut järjestelmien pohjalta tehtävä kehitystyö. Tilanne järjestelmäkentässä on lähivuosina muuttunut ja nykyaikaiset ERP-järjestelmät sisältävät yhä enemmän varastotoiminnallisuuksia. ERP:n tueksi ovat tulleet mobiilipäätteet ja joustavat keräysjärjestelmät, jotka tukevat yhä laajemmin kaikkea operatiivista työtä. Mitä tämä tarkoittaa varastonhallinnan sovellusarkkitehtuurin näkökulmasta ja miksi varaston omat prosessit olisi syytä nostaa kehittämisen lähtökohdaksi?
Varastojen sovellusarkkitehtuurin kehittäminen on perinteisesti ollut varsin järjestelmälähtöistä. Vähänkin mittavammissa varastoissa on käytännössä hankittu WMS, jonka ympärille omat prosessit on rakennettu. Tämä logiikka toimi aikakaudella, jolloin varastotoimintojen digitalisointi oli uutta ja järjestelmät pitkälti määrittelivät, mitä varastossa tehtiin.
Nykytilanne on toinen. Yritykset kohtaavat hyvin erilaisia tarpeita sekä lyhyellä että pitkällä aikavälillä ja varaston omat prosessit on nostettava vahvemmin kehittämisen lähtökohdaksi. Arkkitehtuurin tulisi joustaa ja mukautua liiketoiminnan tarpeisiin sen sijaan, että prosessit taivutettaisiin järjestelmän logiikan mukaisiksi. Tämä tahtotila vaatii yrityksiltä osaamista, selkeää visiota sekä riittäviä resursseja kehityshankkeiden läpivientiin.
Järjestelmälähtöisen kehittämisen haasteet
Miksi järjestelmälähtöinen kehittäminen voi johtaa ongelmiin:
- Prosessien jäykistyminen:
- Varaston työnkulkuja muokataan järjestelmän rajoitteiden mukaan, vaikka ne eivät tukisi optimaalista toimintaa.
- Kustannusten kasvu:
- Muutostarpeet johtavat kalliisiin räätälöinteihin ja integraatioihin.
- Hitaampi reagointi:
- Kun liiketoiminnan tarpeet muuttuvat, järjestelmälähtöinen arkkitehtuuri ei taivu riittävän nopeasti.
Tämä asetelma korostaa prosessilähtöisen ajattelun merkitystä. Varaston kehittäminen alkaa kysymyksestä: mitä meidän on saavutettava nyt ja mitä pitkällä aikavälillä? Vasta sen jälkeen valitaan ja rakennetaan järjestelmät tukemaan tätä tavoitetta.
Perinteinen asetelma: aina tarvitaan WMS
itkään ajateltiin, että moderni varasto tarvitsee ehdottomasti oman WMS:n. Se tarjosi kehittyneitä varastotoiminnallisuuksia, joita ERP-järjestelmät eivät pystyneet kattamaan. WMS ohjasi vastaanottoa, hyllytystä, keräilyä ja lähetyksiä – ja oli siten varaston digitaalinen selkäranka.
Malli toi mukanaan tarpeen monimutkaisille integraatioille ERP:n ja WMS:n välille. Projektien laajuus teki kehittämisestä hidasta ja usein kallista. WMS-projekteista tulikin usein kustannuksiltaan ja kestoltaan ERP-hankkeiden veroisia. Lisäksi kaiken kattavissa WMS ratkaisuissa on usean yrityksen näkökulmasta turhaa toiminnallisuutta, josta hankkeissa kuitenkin maksetaan.
Nykytila: ERP ja keräysjärjestelmät (WES)
Tilanne on muuttunut, sillä nykyään monissa ERP-järjestelmissä on yhä enemmän sisäänrakennettuja varastotoiminnallisuuksia. Operatiiviset tehtävät voidaankin ohjata suoraan erilliseen keräysjärjestelmään. Tämä kehitys on muuttanut sovellusarkkitehtuurin logiikkaa:
- ERP voi toimia varaston toiminnallisuuksien perustana. Tyypillisesti nykyaikainen ERP sisältää esimerkiksi vastaanoton, perustason hyllytyksen, varastosiirrot, saldojen hallinnan, inventoinnin ja usein myös yksinkertaiset keräily- ja lähetysprosessit.
- WMS ei ole enää aina välttämätön ensiaskel, vaan sitä tarvitaan lähinnä useamman varaston ympäristössä, kun prosessit ovat laajoja ja erityisen monimutkaisia sekä automaatio on mukana kokonaisuudessa.
- Kevyemmät, usein ”keräysratkaisuiksi” kutsutut WES-ratkaisut (Warehouse Execution Systems) tuovat tehokkuutta ja joustavuutta ilman raskasta integraatiokerrosta.
Mitä muutos on tuonut varaston sovellusarkkitehtuurin kehittämiseen?
- Arkkitehtuurin ja järjestelmien tehtävänjaon muutos on avannut uusia vaihtoehtoja varastonhallinnan kehittämiseen, joilla voidaan saavuttaa:
- Joustavuutta:
- Yritys voi valita modulaarisesti, mitä toiminnallisuuksia se tarvitsee ja milloin.
- Nopeutta:
- Muutoksia voidaan tehdä ketterämmin ilman raskasta WMS-hanketta.
- Kustannustehokkuutta:
- Ratkaisujen laajuus voidaan mitoittaa tarkasti kehittämisen prioriteettien ja prosessien mukaan, jolloin vältetään yli-investointeja. Operatiivinen fokus ulosmittaa hyödyt nopeasti ja takaisinmaksuajat lyhenevät olennaisesti.
- Prosessilähtöisyyttä:
- Kehittäminen lähtee varaston tarpeista, ei järjestelmän raajoista ja reunaehdoista. Näin hankkeet tukevat paremmin liiketoimintaa ja sen tavoitteita.
Prosessilähtöisen kehittämisen esimerkki: Medifon Oy
Medifon Oy on erinomainen esimerkki siitä, miten varaston prosessilähtöinen kehittäminen mahdollistaa merkittävän kasvun. Yli 100 miljoonan euron liikevaihtoa pyörittävän yrityksen perusta luotiin jo varhaisessa vaiheessa, kun liikevaihtoa oli vasta muutamia miljoonia euroja. Tuolloin WMS oli käytännössä pakollinen, sillä ERP:t eivät vielä tarjonneet varastonhallinnan kannalta riittäviä ominaisuuksia. Oma kehitystyö oli, ja on edelleen, keskeisessä roolissa. Sen avulla on saavutettu tilanne, jossa järjestelmät eivät sanele reunaehtoja, vaan tukevat joustavasti kasvua ja uusia tarpeita.
Jyrki Ristinen, Medifon Oy:
”Järjestelmien kehitys on ja pitää olla aina prosessilähtöistä. Sama pätee liiketoimintaan yleensä. Ensin on selvitettävä mitä halutaan tehdä, sen jälkeen miten tehdään ja vasta sen jälkeen aloitetaan miettimään miten järjestelmät voi tätä tukea ja mielellään tuoda lisäarvoa haluttuun lopputulokseen.
Tämä on aina ollut meidän lähtökohtamme järjestelmien valintaan ja kehitykseen ja olisi suotavaa, että kaikilla yrityksillä olisi näin. Toki useimmiten kyse on myös resursseista. Kaiken voi räätälöidä halutessaan lähes loppuun asti, jolla toki on oma kustannuksensa. Toisaalta on aina laskettava missä kannattaa tehdä kompromisseja halun ja tarpeen välillä.”
Katso videohaastattelu, jossa Jyrki Ristinen kertoo näkemyksistään.
Joustavampi ja kustannustehokkaampi tulevaisuus
Varaston sovellusarkkitehtuurin kehittäminen ei ole enää kiinni siitä, mitä järjestelmä pystyy tarjoamaan. Liikkeelle voidaan lähteä suoraan varaston tarpeista. Kun kehittäminen perustuu omiin tavoitetilan prosesseihin ja liiketoiminnan tavoitteisiin, arkkitehtuuri voi olla kevyempi, joustavampi ja kustannustehokkaampi. Perinteinen ”aina WMS” -ajattelu onkin selkeästi väistymässä. Tilalle on tullut malli, jossa ERP:n varastotoiminnallisuudet ja niitä tukevat operatiivisen työn suorittamisen sekä johtamisen ratkaisut rakentavat arkkitehtuurin juuri yrityksen tarpeisiin. WMS:llä on edelleen paikkansa, mutta sen tarve tulisi arvioida harkiten ja faktoihin perustuen, aina omien prosessien, prioriteettien ja taloudellisten seikkojen pohjalta.
