Tuotteen elinkaari ERP:ssä – myynnistä toimitukseen ja takuupalautukseen

Tämä opas kuvaa yhden konkreettisen prosessin alusta loppuun. Se on tarkoituksella yksityiskohtainen, koska ERP-keskustelu jää muuten helposti abstraktille tasolle: puhutaan tehokkuudesta ja läpinäkyvyydestä, mutta ei siitä, mitä varastossa oikeasti tehdään maanantaiaamuna. Datastorm Oy on suomalainen ohjelmistoyritys, joka rakentaa räätälöityjä toiminnanohjausjärjestelmiä pk-yrityksille, ja tämä esimerkki on koottu siitä työstä.

Esimerkkiyritys on tavallinen suomalainen pk-yritys, joka myy ja toimittaa fyysisiä tuotteita. Tuote saapuu toimittajalta, se otetaan vastaan, avataan, tarkastetaan, tarroitetaan, pakataan ja toimitetaan loppuasiakkaalle. Osa tuotteista palautuu takuun perusteella, ja tilalle toimitetaan uusi. Prosessi ei ole monimutkainen, mutta siinä on kymmenkunta kohtaa, joissa joku hyväksyy, tarkistaa tai merkitsee jotain – ja juuri niissä kohdissa tieto katoaa.

Miltä tuotteen elinkaari näyttää tänään ilman järjestelmää?

Ilman toiminnanohjausjärjestelmää prosessi kulkee sähköpostien, Excel-taulukoiden, paperisten lähetteiden ja ihmisten muistin varassa. Se toimii yllättävän pitkälle, koska kokeneet työntekijät tietävät, mitä tehdään. Ongelmat alkavat silloin, kun joku on lomalla, kun volyymi kasvaa tai kun asiakas kysyy jotain, mikä tapahtui kolme kuukautta sitten.

Mitä vaiheita matkalla on?

Tyypillinen ketju menee näin. Tuote päätetään ottaa myyntiin, ja joku perustaa sille nimikkeen – yleensä Exceliin ja verkkokauppaan erikseen. Asiakas tekee tilauksen. Myynti tarkistaa hinnan ja katteen ja hyväksyy tilauksen. Tavara tilataan toimittajalta tai varataan hyllystä. Saapuva lähetys otetaan vastaan ja kuitataan rahtikirjaan. Paketti avataan ja tuote tarkastetaan silmämääräisesti. Tuotteeseen liimataan tarra, jossa on sarjanumero tai yrityksen oma tunniste. Tuote pakataan, rahtikirja tulostetaan kuljetusliikkeen portaalista ja lähetys luovutetaan kuljettajalle. Lopulta asiakas ottaa tuotteen käyttöön.

Jokainen vaihe on itsessään yksinkertainen. Yhdessäkään niistä ei kuitenkaan synny pysyvää merkintää siitä, kuka teki ja milloin. Rahtikirja arkistoituu mappiin, tarranumero kirjoitetaan lappuun ja tarkastuksen tulos jää tarkastajan muistiin.

Miksi kollegoilta joutuu jatkuvasti kysymään, mistä paketti on tullut?

Kysymyksiä joudutaan esittämään siksi, että tieto on syntynyt jonkun ihmisen päässä eikä järjestelmässä. Kun vastaanotto kuitataan paperille, avaaja ei kirjaa itseään mihinkään ja tarranumero kirjoitetaan käsin lappuun, ainoa paikka jossa tapahtumaketju on tallessa on työntekijän muisti. Silloin jokainen selvitys vaatii kahden ihmisen työajan, ja vastaus on sitä epävarmempi mitä kauemmin tapahtumasta on aikaa.

Käytännössä tämä näkyy neljänä toistuvana kysymyksenä: mistä tämä paketti on tullut, kuka sen on avannut, kenelle se on toimitettu ja millä tarralla se on merkitty. Tällaiset selvitykset voivat keskeyttää useamman henkilön työn. Keskeytys voi aiheuttaa myös työn uudelleen aloittamiseen liittyvää tehottomuutta.

Mikä nykyisessä prosessissa oikeasti rikkoutuu?

Ensimmäinen rikkoutuva asia on jäljitettävyys. Kun sarjanumeroa ei ole kytketty toimitukseen, takuutapauksessa ei tiedetä, milloin juuri tämä kappale on lähtenyt ja kenen tarkastamana. Silloin takuupäätös tehdään arvion perusteella, ja arvio menee vuorotellen yrityksen ja asiakkaan vahingoksi.

Toinen rikkoutuva asia on työjärjestys. Kun mikään ei estä vaiheiden ohittamista, joskus ohitetaan. Tuote pakataan ennen tarkastusta, koska kuljettaja odottaa ovella. Lasku lähtee ennen toimitusta, koska laskutuspäivä on kuun viimeinen. Kumpikaan ei ole kenenkään vika, mutta molemmat maksavat.

Kolmas rikkoutuva asia on perehdytys. Kun prosessi on ihmisten muistissa, uuden työntekijän tuottavaksi saaminen kestää viikkoja ja kuormittaa samalla kokenutta työntekijää. Neljäs on skaalautuminen: prosessi, joka toimii kolmellakymmenellä lähetyksellä viikossa, voi kuormittua sadalla. Valmisratkaisu voi toimia hyvin standardiprosessissa, mutta yrityskohtaisessa prosessissa se voi vaatia kompromisseja – vertailu löytyy oppaasta räätälöity ERP vs valmis ERP.

Miten sama prosessi mallinnetaan räätälöidyssä ERP:ssä?

Räätälöidyssä toiminnanohjausjärjestelmässä prosessi mallinnetaan tilakoneena. Se tarkoittaa, että tuotteella on kerrallaan täsmälleen yksi tila ja että tilasta toiseen pääsee vain sallittuja reittejä pitkin. Jokaisesta siirtymästä kirjataan tekijä, aikaleima ja mahdollinen lisätieto, kuten tarkastuksen tulos tai tarranumero.

Mitä tilakone tarkoittaa liiketoiminnan kielellä?

Tilakone tarkoittaa sitä, että tuotteella on kerrallaan täsmälleen yksi tila ja että tilasta toiseen pääsee vain sallittuja reittejä pitkin. Käytännössä tämä estää mahdottomat tilanteet: tuotetta ei voi lähettää ennen kuin se on tarkastettu, eikä laskua muodostu ennen kuin toimitus on kuitattu. Tilakone on siis kirjattu versio siitä työjärjestyksestä, jonka kokenut työntekijä muistaa ulkoa, ja sen ansiosta myös uusi työntekijä tekee vaiheet oikeassa järjestyksessä.

Tärkeä yksityiskohta on, että tilakone ei saa olla tiukempi kuin todellisuus. Aina tulee tilanteita, joissa vaihe on pakko ohittaa. Ratkaisu ei ole kieltää sitä vaan vaatia ohitukselle syy ja hyväksyjä. Silloin poikkeukset ovat sallittuja mutta näkyviä, ja kuukauden päästä nähdään, mitkä poikkeukset toistuvat niin usein, että prosessia kannattaa muuttaa.

Mitä audit trail tarkoittaa ja miksi se on tärkeä?

Audit trail eli muutosloki tarkoittaa, että järjestelmä tallentaa jokaisesta vaiheesta kuka teki, mitä teki ja milloin. Se ei ole valvontaa vaan muistia: kun asiakas kysyy puolen vuoden päästä, missä kunnossa laite lähti, vastaus löytyy sekunneissa eikä sitä tarvitse arvailla. Takuutapauksissa muutosloki on usein myös se todiste, jolla ratkaistaan, kuuluuko vika takuun piiriin vai onko vaurio syntynyt kuljetuksessa.

Miltä elinkaari näyttää vaihe vaiheelta?

Alla oleva taulukko kuvaa saman prosessin mallinnettuna. Vasemmalla on vaihe, sitten sen omistaja, sitten se mitä järjestelmä kirjaa automaattisesti, ja oikealla se manuaalinen työ, joka poistuu.

Miten takuupalautus toimii, kun se on mallinnettu kunnolla?

Takuupalautus avataan järjestelmässä alkuperäisen toimitusrivin päälle, jolloin se tietää heti sarjanumeron, toimituspäivän, takuuajan ja sen, kuka tuotteen on aikanaan tarkastanut ja tarroittanut. Palautus etenee omana ketjunaan: palautuslupa, saapuminen, vikatarkastus, päätös takuusta, korvaavan kappaleen varaus ja toimitus sekä viallisen kappaleen käsittely tai reklamaatio toimittajalle. Koska korvaava toimitus on kytketty alkuperäiseen riviin, järjestelmä osaa myös olla laskuttamatta asiakasta uudelleen ja pitää takuuajan laskennan oikein.

Käytännön ero on suurin siinä hetkessä, kun asiakas soittaa. Ilman järjestelmää asiakaspalvelija pyytää sarjanumeron, lupaa palata asiaan, kysyy varastosta kuka tuotteen lähetti, etsii sähköposteista toimituspäivän ja soittaa takaisin seuraavana päivänä. Järjestelmän kanssa sarjanumero syötetään hakukenttään, koko historia avautuu ruudulle ja palautuslupa lähtee asiakkaalle saman puhelun aikana.

Takuuketjun mallintaminen tuottaa myös tietoa, jota ei aiemmin ollut olemassa. Kun jokainen palautus on kirjattu vikakoodilla ja kytketty toimittajaan, erästä ja tarkastajaan, puolen vuoden jälkeen nähdään, mikä tuote-erä palautuu muita useammin. Se on tieto, jolla neuvotellaan toimittajan kanssa – ja sen saa vain siten, että kirjaukset syntyvät työn ohessa eivätkä erillisenä raportointina.

Mitä prosessista katoaa, kun se on ERP:ssä?

Suurin yksittäinen poistuva työ on selvittely eli kollegoilta kyseleminen siitä, mistä paketti tuli, kuka sen avasi, kenelle se toimitettiin ja millä tarralla se merkittiin. Sen lisäksi poistuvat saman tiedon kirjaaminen useaan paikkaan, osoitetietojen näppäily kuljetusliikkeen portaaliin, tarratietojen kirjoittaminen käsin, hyväksyntöjen kysely sähköpostilla ja takuupäätösten etsiminen vanhoista lähetteistä. Jäljelle jää se työ, joka on oikeasti fyysistä: tuotteen avaaminen, tarkastaminen, tarroittaminen ja pakkaaminen.

Tämä on räätälöinnin varsinainen hyöty. Kun järjestelmä tehdään juuri sitä prosessia varten, jokainen turha manuaalinen työvaihe voidaan hioa pois, ja lopputulos on yksinkertainen sovellus, jota on helppo käyttää. Valmisratkaisussa käy usein päinvastoin: koska ohjelmisto on tehty tuhannelle erilaiselle yritykselle, jokainen näkymä sisältää kymmeniä kenttiä, joita teillä ei tarvita, ja käyttäminen alkaa itsessään olla työlästä.

Hyvä mittari onnistumiselle on ruutujen määrä. Jos varastotyöntekijä hoitaa vastaanoton, tarkastuksen, tarroituksen ja pakkauksen neljällä napinpainalluksella samalla näytöllä, järjestelmä on onnistunut. Jos hän joutuu vaihtamaan välilehteä joka vaiheessa, ei ole.

Paljonko tämä on tunteina ja euroina?

Alla olevat esimerkit on laskettu 70 €/h + ALV -perusteella. ERP-hanke hinnoitellaan projektina. Lähityössä lisäksi 1 €/km + ALV Mäntsälästä. Ennen töiden aloitusta saat arvion tunteina ja euroina, eikä mitään laskuteta ennen kuin arvio on hyväksytty. Alla on tyypillinen työmäärä tämän oppaan kuvaamalle kokonaisuudelle.

Vastapainoksi kannattaa laskea, mitä nykyinen selvittely maksaa. Laskuesimerkki, jonka luvut sinun kannattaa korvata omillasi: jos kuusi henkilöä käyttää keskimäärin 20 minuuttia päivässä kyselemiseen ja tiedon etsimiseen, se on 2 tuntia päivässä eli noin 460 tuntia vuodessa. Sisäisellä 40 €/h kustannuksella se on 18 400 € vuodessa – eli enemmän kuin koko yllä kuvattu kehitystyö kalleimmallaan.

Laskelma ei ole lupaus vaan tapa muuttaa epämääräinen tunne mitattavaksi. Mittaa oma lukusi viikon ajan ennen kuin päätät mitään: merkitse ylös jokainen kerta, kun joudut kysymään kollegalta jotain, minkä järjestelmä voisi kertoa. Viikon jälkeen tiedät, kannattaako projekti. Hinnoista ja aikataulusta kerromme tarkemmin oppaassa ERP-projektin hinta ja aikataulu.

Miten tällainen projekti etenee käytännössä?

AI-avusteinen kehitys on lyhentänyt Datastormin nykyisten ERP-toteutusten työmäärää. Ensimmäisiä rajattuja tuotantoversioita pystymme nykyisellä toteutustavalla rakentamaan ilman raskasta projektiorganisaatiota. Datastormin nykyisissä hankkeissa ensimmäisen tuotantoversion tavoiteaikataulu on yleensä 2–4 kuukautta.

Yhdessä toteutuneessa projektissa asiakas pyysi tarjousta maaliskuun puolivälissä, ilmoitti huhtikuun alussa haluavansa ostaa ja järjestelmä otettiin käyttöön koko yrityksessä 25. toukokuuta. Nyt se on tärkeä osa heidän liiketoimintaansa. Päätöksestä tuotantoon meni siis noin kymmenen viikkoa. Vaiheittainen eteneminen on kuvattu oppaassa ERP-järjestelmän käyttöönotto vaiheittain, ja integraatioiden osuus oppaassa ERP-integraatiot: varasto, laskutus ja verkkokauppa.

Usein kysytyt kysymykset tuotteen elinkaaresta ERP:ssä

Mitä tuotteen elinkaari tarkoittaa ERP-järjestelmässä?

Tuotteen elinkaari tarkoittaa ERP-järjestelmässä kaikkia niitä vaiheita, jotka yksittäinen kappale käy läpi siitä hetkestä, kun se otetaan myyntiin, siihen hetkeen, kun loppuasiakas ottaa sen käyttöön – ja tarvittaessa vielä takuupalautukseen ja korvaavaan toimitukseen asti. Räätälöidyssä ERP:ssä jokainen vaihe on oma tilansa, jolla on omistaja, aikaleima ja kirjattu lopputulos. Kun elinkaari on mallinnettu, järjestelmästä näkee milloin tahansa, missä vaiheessa mikäkin kappale on ja kuka sitä on viimeksi käsitellyt.

Miksi kollegoilta joutuu jatkuvasti kysymään, mistä paketti on tullut?

Kysymyksiä joudutaan esittämään siksi, että tieto on syntynyt jonkun ihmisen päässä eikä järjestelmässä. Kun vastaanotto kuitataan paperille, avaaja ei kirjaa itseään mihinkään ja tarranumero kirjoitetaan käsin lappuun, ainoa paikka jossa tapahtumaketju on tallessa on työntekijän muisti. Silloin jokainen selvitys vaatii kahden ihmisen työajan, ja vastaus on sitä epävarmempi mitä kauemmin tapahtumasta on aikaa.

Mitä tilakone tarkoittaa liiketoiminnan kielellä?

Tilakone tarkoittaa sitä, että tuotteella on kerrallaan täsmälleen yksi tila ja että tilasta toiseen pääsee vain sallittuja reittejä pitkin. Käytännössä tämä estää mahdottomat tilanteet: tuotetta ei voi lähettää ennen kuin se on tarkastettu, eikä laskua muodostu ennen kuin toimitus on kuitattu. Tilakone on siis kirjattu versio siitä työjärjestyksestä, jonka kokenut työntekijä muistaa ulkoa, ja sen ansiosta myös uusi työntekijä tekee vaiheet oikeassa järjestyksessä.

Mitä audit trail tarkoittaa ja miksi se on tärkeä?

Audit trail eli muutosloki tarkoittaa, että järjestelmä tallentaa jokaisesta vaiheesta kuka teki, mitä teki ja milloin. Se ei ole valvontaa vaan muistia: kun asiakas kysyy puolen vuoden päästä, missä kunnossa laite lähti, vastaus löytyy sekunneissa eikä sitä tarvitse arvailla. Takuutapauksissa muutosloki on usein myös se todiste, jolla ratkaistaan, kuuluuko vika takuun piiriin vai onko vaurio syntynyt kuljetuksessa.

Miten takuupalautus toimii räätälöidyssä ERP-järjestelmässä?

Takuupalautus avataan järjestelmässä alkuperäisen toimitusrivin päälle, jolloin se tietää heti sarjanumeron, toimituspäivän, takuuajan ja sen, kuka tuotteen on aikanaan tarkastanut ja tarroittanut. Palautus etenee omana ketjunaan: palautuslupa, saapuminen, vikatarkastus, päätös takuusta, korvaavan kappaleen varaus ja toimitus sekä viallisen kappaleen käsittely tai reklamaatio toimittajalle. Koska korvaava toimitus on kytketty alkuperäiseen riviin, järjestelmä osaa myös olla laskuttamatta asiakasta uudelleen ja pitää takuuajan laskennan oikein.

Mitä manuaalista työtä ERP poistaa tästä prosessista?

Suurin yksittäinen poistuva työ on selvittely eli kollegoilta kyseleminen siitä, mistä paketti tuli, kuka sen avasi, kenelle se toimitettiin ja millä tarralla se merkittiin. Sen lisäksi poistuvat saman tiedon kirjaaminen useaan paikkaan, osoitetietojen näppäily kuljetusliikkeen portaaliin, tarratietojen kirjoittaminen käsin, hyväksyntöjen kysely sähköpostilla ja takuupäätösten etsiminen vanhoista lähetteistä. Jäljelle jää se työ, joka on oikeasti fyysistä: tuotteen avaaminen, tarkastaminen, tarroittaminen ja pakkaaminen.

Paljonko tällaisen prosessin mallintaminen ERP:iin maksaa?

Elinkaaren ja takuupalautusten mallintaminen on tyypillisesti 125–240 tuntia eli noin 8 750–16 800 euroa lisättynä arvonlisäverolla hinnalla 70 euroa tunnilta. Ensimmäinen tuotantoversio, joka sisältää ytimen ja yhdestä kahteen integraatiota, on noin 170 tuntia. Tarkka kustannus riippuu laajuudesta, laajempi kokonaisuus on suuntaa antavasti noin 30 000 eurosta 80 000 euroon lisättynä arvonlisäverolla ja liiketoimintakriittinen hanke noin 80 000 eurosta 150 000 euroon ja tarvittaessa enemmän. Lopullinen hinta riippuu vaiheiden määrästä, integraatioista ja käyttäjämääristä, ja tarkka arvio annetaan kartoituksen jälkeen.

Kuinka nopeasti tällainen järjestelmä saadaan käyttöön?

Päätöksestä ensimmäiseen tuotantoversioon menee tyypillisesti kahdesta neljään kuukautta ja laajemmassa kokonaisuudessa useilla integraatioilla neljästä kahdeksaan kuukautta. Yhdessä toteutuneessa projektissa asiakas pyysi tarjousta maaliskuun puolivälissä, ilmoitti huhtikuun alussa haluavansa ostaa ja järjestelmä otettiin käyttöön koko yrityksessä 25. toukokuuta eli noin kymmenen viikkoa päätöksestä. Aikataulu riippuu eniten siitä, kuinka nopeasti asiakkaan puolelta saadaan päätökset, testidata ja aikaa testaukseen.

Yhteenveto

Tuotteen elinkaari on hyvä ensimmäinen kohde räätälöidylle toiminnanohjausjärjestelmälle, koska se on samaan aikaan konkreettinen ja mitattava. Vaiheet ovat selvät, niiden omistajat tiedetään ja hyöty näkyy heti ensimmäisenä käyttöpäivänä siinä, ettei kenenkään tarvitse kysyä, kuka tämän avasi.

Jos tunnistat oman yrityksesi tästä kuvauksesta, seuraava askel on kevyt kartoitus, jossa piirretään teidän oikea prosessinne vaihe vaiheelta ja lasketaan, mitkä vaiheet voidaan poistaa kokonaan. Kartoitus on 10–20 tuntia eli 700–1 400 € + ALV, ja sen jälkeen tiedät tarkasti, mitä oma järjestelmä maksaisi. Tarjouksen voi pyytää myös silloin, kun hankkeesta ei ole vielä tehty päätöstä.

Lue myös

• Räätälöity ERP vs valmis ERP – kumpi kannattaa?
• Milloin oma ERP-järjestelmä kannattaa?
• ERP-projektin hinta ja aikataulu
• ERP-integraatiot: varasto, laskutus ja verkkokauppa
• ERP-järjestelmän käyttöönotto vaiheittain
• Räätälöity ERP kilpailuetuna
• Räätälöity toiminnanohjausjärjestelmä palveluna →
• Ohjelmistokehitys palveluna →