Yrityksillä on vaihtelevia intressejä ja pidäkkeitä joko aktiivisesti ajaa toiminnanohjausta sisään yrityksiinsä, tai sitten pysytellä siitä kaukana mahdollisimman pitkään. Asian tiimoilta löytyy kauhukertomuksia vaikeuksista, työmääristä, toiminnan sekoamisista ja hinnoista - ja valitettavasti myös tilastot kertovat karua kieltä epäonnistumisista. Yli puolet projekteista ylittää railakkaasti budjetin tai epäonnistuu joiltain kriittisiltä osin - tai molempia!
On toki lisääntyvässä määrin myös positiivisia kokemuksia onnistumisista. Voitaneen todeta, että suurin osa yrityksistä suhtautuu toiminnanohjaukseen sinänsä positiivisesti, mutta näkee käyttöönoton projektina liian hankalaksi tai kalliiksi ja riskipitoiseksi, ja siksi lykkää päätöksen mahdollisimman myöhäiseksi. Ehkä turhaankin, koska kehitystä on tapahtunut paitsi itse ERP:eissä kohti parempia ja käyttäjäystävällisempiä järjestelmiä, niin myös käyttöönottometodeissa kohti suurempaa konkretiaa ja käytännönläheisyyttä.
Lisäksi on helpompaa ja halvempaa "hypätä ERP:in kyytiin" kun toiminta on vielä suhteellisen yksinkertaista ja sitten kasvattaa yritystä yhdessä ERP:in kanssa kohti tulevaa, kuin ensin kasvattaa yritystä antaen toimintapojen rönsyillä hyvin erilaisiksi ja polveileviksi, ja sitten lopuksi yrittää yhdenmukaistaa tämä niin, että sen saa napakasti siirrettyä ERP:in puitteisiin. Toki niinkin päin se onnistuu, mutta mukauttamista on sitten vain enemmän - joko järjestelmän tai oman toiminnan.
Mitään tarkkaa kriteeriä sille milloin ERP olisi fiksuin ottaa käyttöön ei voi varmaankaan yksiselitteisesti antaa, mutta asiaa kannattaa ainakin harkita, kun
1) liikevaihto menee yli miljoonan,
2) ihmisiä on enemmän kuin "toimistollinen" eli esimiehiä on useampia tai porukkaa on eri sijainneissa,
3) tilauksia alkaa tulla kolminumeroinen määrä päivittäin.
Jos toiminta on mutkikasta, kuten maantieteellisesti levittäytynyttä, mukana on ulkomaantoimintoja, alihankintaverkostoja, tuotteiden valimistusta tai alihankintaa tms niin rajat ylittyvät luultavasti jo aiemmin - ehkä jo lähdössä.
Alla on kuvitteellinen case, jossa pienestä liikkeelle lähtevä nettikauppa pikkuhiljaa törmää asioihin, joissa toiminnanohjaus olisi voinut olla avuksi. Lopussa on lista asiosta, jotka toiminnanohjauksella helposti laitetaan kuntoon.
Kauppa aloittaa nettikauppa-platformilla yhdistettynä erilliseen pilvi-kirjanpitoon. Ne eivät toimi integroituna yhteen, koska suomalaista yhdistävää valmista integraatiota ei löydy! Mutta löyhästi ne toimivat kimppaan siten, että netin varastosaldot otetaan kuukausittain ulos ja siirretään könttänä talouteen. Ostolaskut menevät kirjanpitoon suoraan ja myynnit saadaan sinne maksupalveluntarjoajan tilityksistä. Pieni kauneusvirhe tulee siitä, että nettikaupan raportoima myynti ei ihan vastaa tilityksiä, koska maksupalvelu vähentää komissionsa välistä. Kirjanpidosta ei saa tuotekohtaista kannattavuutta ulos, koska sinne menee vain könttäkirjaukset tilityksittäin. Nettikaupan raporteista saa, mutta sieltä puuttuvat komissiot. Ja epäsuorat ostokulut, kuten rahdit ja tullit, jos niitä on ja laskuttaja on eri kuin tavarantoimittaja. Ja kaikki muut kuin hankintakulut, eli se näyttää vain myyntikatteen. Mutta tuo pieni epätarkkuus / vaillinaisuus ei vielä ylitä kynnystä, että lisätukea otettaisiin erpistä.
Varastonarvon raportointi on sinänsä selkää, nettikaupassa on kullekin tuotteelle sitä varten kaksi kenttää: ostohinta ja saldo. Varastonarvo saadaan niistä ja vastaavasti myyntikate myyntihinnan ja ostohinnan erosta. Yrittäjälle tulee kuitenkin ongelma, koska tietyt tuotteet hän saa halvemmalla laivarahtina, mutta toisinaan kiiretilanteissa ne otetaan kalliimmalla lentorahtina. Ostohinnaksi pitäisi kirjanpitäjän mukaan laittaa liukuva keskihankintahinta, joten se pitää laskimella laskea joka tuotteelle jokaisen oston vastaanoton yhteydessä vanhasta arvosta ja ostoarvosta. Mikä on järjettömän työlästä! Asia helpottuu kun hän löytää pluginin, jolla ostotilaukset voi syöttää etukäteen hintoineen sisään, ja se osaa laskea varastoarvot oikein kun tavara merkataan saapuneeksi. Se samalla parantaa kaupan käytettävyyttä, kun nollasaldo-tilanteessa asiakkaat nyt näkevät, milloin seuraava erä saapuu. Nyt vain sitten kaikki ostot pitää 1) ensin oikeasti tilata toimittajalta, sitten 2) syöttää sama tieto netin ostoksi ja 3) kun lasku tulee niin sama tieto vielä laskun muodossa sisään. Kun valitettavasti ulkomaisilta toimittajilta ei saa eLaskuja.
Sitten myynti yhtäkkiä alkaakin vetämään, ja eräässä kohdemaassa ylittyy verovelvollisuuskynnys (raja menee noin kymmpitonnissa). Joten ko. maan myynti pitää veroraportointia varten eriyttää. Sitä ei voi tehdä maksunpalvelijan raporteista, koska he eivät tiedä toimitusosoitetta eivätkä verovelvollisuutta, vaan vain luottokortin osoitteen. Joten myyntiluvut verokannoittain pitää kaivaa nettikaupan myyntiraporteista ja yhdistää (exceleillä) tilitysraportteihin, että sekä verot että komissiot menisivät oikein. Minkä kirjanpitäjä tekeekin, mutta siitä tulee vähän lisätyötä ja kustannuksia ja hitautta hallinnointiin. Taas käy mielessä, että eikö tähän olisi jotain parempaakin tapaa, mutta nopeasti ei mitään tule mieleen.
Seuraava hankaluus tulee, kun eräille vähän teknisemmille laitteille päätetään antaa takuu. Kun niitten myynti sitten alkaa vetämään, tulee myös tietty määrä ongelmia tai palautuksia, ja jokaisen keikan kohdalla pitää kaivella ja etsiä onko takuu vielä voimassa vai ei. Takuutapaukset voi vyöryttää osin valmistajalle, mutta toiset tapaukset ratkeavat nopeimmin ja järkevimmin vaihtamalla tietty varaosa toiseen ihan omin voimin, omissa tiloissa. Nämä korjauksen varaosat ovat kuitenkin samalla netissä myytävissä olevia nimikkeitä, joten käyttö pitää saada verkkiksen saldoista pois. Mikä on pieni ongelma, koska nettikauppa ymmärtää vain myyntitapahtumia, ja tämä korjauskäyttö ei ole myyntiä. Joten ne hoidetaan suorilla saldopäivityksillä, mutta seuraavaksi tulee sapiskaa kirjanpitäjältä, että inventaarikorjaus on eri asia kuin huoltokäyttö. Joten sille viritellään oma seuranta-excel. Se tosin ei ihan aina pysy ajantasalla ja synkassa netin saldojen kanssa, välillä unohtuu päivittää toinen, joten näitä varaosasaldoja pitää alkaa inventoimaan vähän useammin, ettei vahingossa myydä asiakkaille ei-oota. Kun takuukorjausten lisäksi asiakkaat alkavat kyselemään korjauksia ihan rahaakin vastaan, ja tästä tulee pieni mukava sivubisnes, yllämainittu korjaustoiminta alkaa hiertää aikaisempaa enemmän, kun sen hallinnointi on niin työlästä, vaikka itse korjaus olisi melko nopeaakin.
Jossain kohtaa huomataan, että monet asiakkaat haluaisivat hypistellä ja kokeilla tavaroita ennen ostoa. Tilaaminen ja palauttaminen on yksi vaihtoehto, mutta se työllistää molempia osapuolia ärsyttävän paljon ja syö katteita. Joten päätetään avata pieni myymälä suoraan varaston yhteyteen, edes muutamaksi illaksi viikossa, jonne houkutellaan kiinnostuneita paikalle. Mutta näiltä ihmisiltä pitäisi pystyä myös rahastamaan tuotteet. Kassatapahtumat voi kyllä syöttää ikäänkuin nettitilauksina, kun lisäilee vähän maksu- ja toimitustapoja, ja irrallinen kassapäätekin onnistuu kohtuuhelpolla. Mutta tämä vaatii aika paljon näpyttelyä per tilaus. Varsinaisen erillisen kassajärjestelmän hankinta tämmöistä pienimuotoista lisätoimintaa varten ei tunnu houkuttelevalta, joten maksusumma pitää aina naputella erikseen maksupäätteeseen. Sen kanssa pärjätään, eikä näppäilyvirheitäkään kovin usein tule. Ja toki tämä myynti pitää sitten taas viedä kirjanpitoon vähän eri tavalla, ja täsmäyttää kassa myyntiin, mutta tarkalla työllä nekin onnistuvat.
Sitten hyvin alkanut vienti innostaa avaamaan ko markkinoita varten oman verkkokaupan. Sinne ei pelkästään haluta sisältöä eri kielellä, vaan koko tuotevalikoima ja hinnoittelu halutaan paikallisella tyylillä, sekä myös kaupan kaikki muu sisältö. Ainoa hankala asia on saldot, joita on miltei mahdoton pitää synkassa molemmissa nettikaupoissa samaan aikaan - mikä on erityisen hankalaa kun saldoilla on tiettyä tuotetta enää yksi kappale jäljellä. Se ratkeaa kun otetaan varastointi- ja lähetyspalvelut käyttöön ko maassa, sisältäen fyysisesti ihan eri varaston. Mutta tietyt spesiaalituotteet halutaan pitää saldoilla vain kertaalleen, joten niiden kohdalla ongelma pysyy. Niille otetaan käyttöön drop-shipping toiminto ulkomailla siten, että tämä dropshippaaja on itse asiassa se oma kotimainen keskusvarasto. Mutta ne pitää sitten manusti lyödä erikseen myyntinä alkuperäiseen verkkokauppaan, ja sitten vielä kirjanpitäjän pitää eliminoida tämä tuplakauppa pois kirjanpidosta. Joten kynnystä pidetään korkealla, ettei ihan kaikkea tehdä noin raskaasti, vaan vain parhaan katteen tuotteet. Jälleen kerran mielessä raksuttaa, että kannattaako tämä lisäkauppa ollenkaan tai voisiko sitä mitenkään hoitaa jotenkin automaattisemin...
No, se siitä kuvitteellisesta tarinasta, mutta tuosta ehkä saa pientä esimakua mitä kaikkea yritys voi löytää edestään jos/kun se alkaa kasvamaan ja minkälaisia erilaisia kiertoteitä ja virityksiä systeemin ympärille helposti muodostuu. Kun tietty mahdollisuus avautuu, vaikka nyt sitten uuden markkinan valtaus, voi tuntua hankalalta, että juuri samalla hetkellä pitäisi alkaa ottamaan käyttöön uusia järjestelmiä, kun itse bisnes-keissiäkin pitäisi edistää. Mieleen voi juolahtaa, että kannattaisikohan hyvissä ajoin laittaa toimintansa siihen malliin, että perusvalmius hyvin erilaisillekin laajentumisille on koko ajan olemassa. Ja kun tilaisuus aukeaa, niin nämä optiot saadaan todella nopeasti käyttöön! Tämä alkaa kuulostamaan jo aika tavalla siltä, että toiminnanohjaus kannattaisi ottaa käyttöön jo vähän ennen tämmöistä laajentumisvaihetta.
Odoossa on, vain muutamia ominaisuuksia mainitakseni:
- varastonhallinta varastoarvoineen, mm liukuvalla keskihinnalla. Myös eränumero- tai sarjanumerotasoinen seuranta halutuille tuotteille
- integrointimahdollisuus verkkokauppoihin, kuten WooCommerce, Shopify tai vaikka Amazon marketplace. Niitä voi olla useita rinnakkain käytössä, myös useita samaa tyyppiä (siis vaikka kaksi Shopify-tiliä). Kytkettynä yhteen tai useaan varastoon.
- integrointimahdollisuus kirjanpitojärjestelmiin kuten ProCountor ja Netvisor, jos haluaa jatkaa niiden käyttöä ja tuttua kirjanpitotoimistoa, joskin siinä itsessäänkin on kirjanpitomoduli
- takuukäsittelymahdollisuus (warranty) ja takuuaikojen seuranta vaikka sarjanumeroittain, jotka viivakoodilla luetaan jokaisen toimituksen yhteydessä
- korjaukset (repair moduli), sekä takuu- että erillistä korjausta tukien, integroituna varastohallintaan ja laskutukseen
- ostotilausten hallinta, integroituna varastohallintaan ja myös taloushallintaan, tukien mm sähköpostipohjaista tiedonvaihtoa toimittajien kanssa. Siis sitä että tilaus tehdään vain kerran
- ostotilauksia voi automatisoida varastotilanteeseen ja hälytysrajoihin perustuen, niin että koko putki asiakasmyynnistä täydennyksiin omilta toimittajilta pyörii lähes automaattisesti
- mahdollisuus moniin varastoihin, moniin yrityksiin, monissa eri maissa, siirtoihin varastojen välillä, konsernin sisäiseen kauppaan
- vähittäismyynti (eli POS) -moduli, jolla voi tehdä myyntiä kuten kauppojen kassapäätteillä, tulostella kuitteja, integroida ne maksupäätteisiin, kytkeä kanta-asiakasohjelmiin jne. Ja se pitää kirjaa käteiskassasta.
- ja yli 1000 erilaista toimintoa / modulia joita voi ottaa sitä mukaa käyttöön, kun tarve ilmenee. Ne kaikki on valmiiksi integroitu toisiinsa sopiviksi - siis ei tarvitse kahlata pluginien versioviidakossa miettimässä milloin uskaltaa päivittää minkin niistä ilman että joku toinen alkaa piiputtaa.
- jne....
