WMS speksaus – mitä se tarkoittaa?

Warehouse management system eli varastonhallintajärjestelmä, niin kuin kaikki muutkin tietojärjestelmät, pitää määritellä tarkkaan ennen hankintapäätöksen tekemistä. Koska monissa tarjolla olevissa järjestelmissä on paljon samoja ominaisuuksia, pitää omien prosessien tuntemus olla niin hyvällä tasolla, että osataan valita omaan toimintaan parhaiten sopiva järjestelmä.

Vaikka WMS-myyjä kertookin, että heidän tarjoamassaan järjestelmästään löytyy tuki äänikeruulle ja itseoptimoituva keruureitti ja mahdollisuus eränumeroseurantaan, niin jokainen hyvältä kuulostava ominaisuus pitäisi johtaa nyökyttelyn sijaan syventävään jatkokysymykseen.

Toimiiko äänikeruu vain tietyllä raudalla vai onnistuuko sen ohjaaminen olemassa olevalla laitteistolla? Miten keruureitti osaa optimoida itse itseään, jos varastoja on useammassa eri rakennuksessa? Toimiiko eränumeroseuranta samaan aikaan komponenttitasolla ja valmistuotetasolla?

Kaikella kunnioituksella WMS-myyjiä kohtaan. Teillä on hienot tuotteet, joiden hienouksien ymmärtäminen vaatii paljon vihkiytymistä. Ja samaan aikaan teillä on vaativat asiakkaat, jotka eivät aina oikein osaa kommunikoida omia tarpeitaan ymmärrettävästi.

Perusteellisesti tehty WMS määritystyö pitää aloittaa jo ennen ensimmäistä yhteydenottoa myyjään. Selvitetään mitä prosesseja WMS:n halutaan hallinnoivan. Yleensä näihin kuuluu ainakin saapuvan tavaran vastaanotto, hyllytys, keräily, lähtevän tavaran toimitus ja jonkinlainen inventointiratkaisu. Käydään osastokohtaisesti läpi, millainen toimintatapa tällä hetkellä on käytössä ja piirretään prosessikaavioita käytännön ja järjestelmän näkökulmasta. Selvitetään mihin muihin järjestelmiin WMS pitää linkittää. Tuleeko ostotilaukset ja tuotetiedot erillisestä järjestelmästä? Halutaanko raportointi tehdä ERP:n tai vaikkapa PowerBI:n kautta?

Kun omat prosessit on saatu kattavasti kartoitettua, ja luotetaan että käytännön toiminta noudattaa prosessikuvauksia, voidaan varovasti lähestyä WMS-toimittajia. Toimittajan pitää pystyä osoittamaan millä tavalla heidän järjestelmänsä selviytyy kuvatuista prosesseista. Usein vastauksena voi olla järjestelmän räätälöinti, tai ehdotus muuttaa olemassa olevaa prosessia.

Tämä ei automaattisesti ole huono vastaus. Vaikka samat prosessit sinänsä toistuvatkin eri yrityksissä, löytyy jokaisesta liiketoiminnasta omat erikoisuutensa, jotka aiheuttavat järjestelmätoimittajalle päänvaivaa. Tärkeintä on, että WMS-toimittaja pystyy uskottavasti osoittamaan, että heidän järjestelmänsä taipuu tukemaan varaston prosesseja.

Kun WMS-toimittaja (tai useampi) on valittu, on aika esitellä järjestelmää loppukäyttäjille. Tämänkin voi tehdä useammalla eri tavalla. Järjestelmä voidaan esitellä kaikille loppukäyttäjille, tai pelkästään pääkäyttäjälle, mutta yleensä jotain siltä väliltä. Hyväksi havaittu ratkaisu on koota loppukäyttäjistä työryhmä, joka osallistuu käyttöönottoprojektiin laajemmin. Tämä porukka toimii myös hyvänä tukena loppukäyttäjien koulutuksessa ja muutosvastarinnan voittamisessa.

Testaaminen on hyvä tapa varmistua järjestelmän toimivuudesta. Järjestelmätoimittaja pystyy usein rakentamaan testiympäristön, jossa oikealla tilausdatalla voidaan kokeilla kaikkien prosessien toimivuus. Testiympäristö on usein arvokas työkalu vielä järjestelmän käyttöönoton jälkeenkin. Siellä voi tutkia erilaisten ongelmatilanteiden syitä tai kokeilla uusien ominaisuuksien toimivuutta.

Sitten kun WMS on joskus saatu asennettua ja käyttöön, pitää vielä huolehtia järjestelmäkehityksestä. Vaikka määritysvaiheeseen käytettäisiin kuinka paljon aikaa, jotain voi aina jäädä huomioimatta, tai prosesseissa on voinut tulla muutoksia. Kiinteät suhteet järjestelmätoimittajaan helpottavat ongelmatilanteiden korjaamista ja kehitysehdotusten eteenpäin viemistä. Yhteisestä kielestä ja aikavyöhykkeestä on apua, mikäli järjestelmätoimittajan edustajan halutaan saapuvan paikanpäälle. Käyttöönottovaiheeseen on hyvä varata useampi kuukausi aikaa sekä tilaajan, että toimittajan puolelta.

Sivuhuomio: WMS-määrittelyyn käytetty ulkopuolisen yrityksen työ voidaan laskea investoinniksi ja vähentää poistoina järjestelmän suunnitellun budjetin mukaisesti.