Kysymys on itse asiassa yllättävän vaikea, kuten tästä artikkelistakin ehkä ilmenee. Ja siihen on tottakai helppo ja nopea vastauskin: ota meihin Webbrosiin yhteyttä ja me autamme asiassa eteenpäin.
Yhden toimittajan ja tuotteen kelkkaan hyppääminen tuntuu varmasti arveluttavalta. Tyypillisempäähän on ensin kirjata omat vaatimuksensa listaksi, jonka pohjalta tehdään karsintaa ja sitten lähetetään tarjouspyyntöjä, kuten oppikirjat kehottavat tekemään. Sitten vain valitaan se ERP ja toimittaja, joka parhaiten ja kustannustehokkaimmin vastaa tarpeisiin. Simple!
Tässä tavassa on ideaa, mutta myös monia sudenkuoppia, joita yritän alla kuvata.
Ideoinnin kautta tulevaan
Toisinaan tarpeita kartoitetaan sarjalla työpajoja tai kokouksia, joissa joko omin voimin - tai fasilitoivan konsultin avustuksella - listataan tarpeita ja ajatuksia tulevasta toimintatavasta. Jonka mahdollistajaksi sitten se järjestelmä otetaan.
Lue tästä artikkelista, mitä kaikkia ongelmia tässä lähestymistavassa tulee eteen ja miksi lopputulos ei yleensä ole ihan täydellinen. Lopputuloksena ideoinnista saadaan siis vaatimuslista, jossa on mukana turhia, ristiriitaisia ja puolueellisia tarpeita, mutta silti siitä puuttuu oleellisia asioita.
Vauhtia prosesseista -malli
Toinen yleinen tapa on ottaa lähestymiskulmaksi liiketoimintaprosessi (tai prosessit, monikossa). Ei siis keksitä tarpeita tyhjältä pöydältä, vaan kuvataan yrityksen prosessit kaavioiksi, ja johdetaan tarpeet prosessien vaatimuksista.
Tässä tavassa on paljon hyvää! Turhat vaatimukset karsiutuvat pois, vaatimusmäärittelyt ovat yhdenmukaisia ja puuttuvat palaset huomataan helpommin, kun prosessinäkökulma sitoo asiat napakasti yhteen.
On vain yksi mutta! Prosessit ovat käytännössä tuotekohtaisia: eri ERP-tuotteet ovat kehitelleet tietyn asian hallinnoimiseksi kukin omanlaisensa tavan.
Prosessivariaatioiden ongelmia
Ensimmäinen ongelma tulee siinä, että tarjouksia voi olla vaikea tulkita. Niissä puhutaan eri termeillä ja eri prosesseista kuin tarjouspyynnössä. Näin voi käydä vaikka toimittaja olisi ymmärtänyt tarpeen aivan oikein ja ikäänkuin vain muuntanut vaatimukset oman tuotteensa käsitteistöön. Toki myös on voitu ymmärtää väärin, tai vastineen puuttuessa vaatimukseen on hämäysmielessä käännetty katse muualle. Vaikeaa päätellä!
Toinen ongelma on turhat (tai väärät) negatiiviset tulkinnat: toimittaja saattaa rehellisenä todeta että pyydetty vaatimus ei onnistu. Mutta kuitenkin tuotteessa olisi ollut tapa hallita haluttu asia toisenlaisella menettelytavalla. Jos vaatimus lukittiin tiukasti jo vaatimusmäärittelyvaiheessa, ihan vain että saatiin eheä määritys, samalla suljettiin (turhaan) osa vaihtoehdoista pois.
Kolmas ongelma on määrittelytyö valitun toimittajan kanssa. Tehdyt aiemmat kuvaukset määrittelyryhmän kanssa eivät luultavasti kelpaa totetustoimittajalle, koska prosessit ja termit eivät täsmää tuotteeseen. On siis alettava prosessien määrittelytyö uudestaan alusta. Hintalapun lisäksi varmasti harmittaa myös tuplamallinnustyön nielemä aika.
Alustavan tuotevalinnan tie
On mahdollista tehdä tuotevalinta myös karkeammin, ikäänkuin alustavana. Sitten tehdään prosessikuvaustyö tätä alustavaa tuotetta vasten, käyttäen referensinä sen prosesseja. Jos selvityksen lopputuloksena huomaa vaatimusten toteutuvan, määrittelyjä koordinoineen toimittajan olevan yhteistyökykyinen ja taidokas, ja jos vielä saadaan suoraan hyväksyttävissä olevan totetustyötarjouskin, on tarjolla ainakin yksi houkuttelevan helppo optio.
Jos jokin edelläolevista ei toteudu, niin ei silti ole sen huonommassa tilanteessa kuin geneerisessä määrittelyssä ja mahdollisesti yksi huono vaihtoehto on saatu listalta pois.
Tulevaisuus-aspekti
Riippumatta miten tarpeet on listattu, niiden rajoituksena on tyypillisesti staattisuus. Ne ovat parhaimmillaankin ikäänkuin pysäytyskuva yrityksen nykytarpeista. Jos kaikki menee kuin elokuvissa, ERP-projekti osaltaan saa yrityksen nosteeseen ja kasvuun. Jolloin edessä ovatkin jo uudet haasteet, tästä artikkelista voit lukea että esimerkiksi mitä.
Jos ERP valittiin tiukasti vastaamaan vain alkuperäisiä vaatimuksia, "ilman kasvunvaraa", eivät uudet tarpeet ehkä enää onnistu sen avulla. Jolloin ollaan taas lähtöruudussa. Tai kovassa hädässä ja kasvukiireen keskellä niille uusille tarpeille kullekin hommataan oma erillisjärjestelmänsä. Jotka tyypillisesti toimivat oikein hienosti itsessään, mutta päädytään integrointiongelmiin; yritys päätyy naputtelemaan samoja tuotteita, asiakkaita, keikkoja ja muita asioita kuhunkin niistä erikseen. Tai toteuttamaan työläitä koodauksia, jotta järjestelmät juttelisivat keskenään, mikä on on omanlaisensa ongelma. Tai sitten tiedot vain eivät ole ihan synkassa!
Jälkiviisaana voi kysyä, olisiko pitänyt valita alunperinkin ERP siten, että siinä olisi ollut optiot kasvuun?
Webbrosin toimintatapa
Webbros suosii käytännönläheisyyttä ja suoraviivaisuutta, ja meiltä saa melko nopeastikin arvion miten suuri työ ERP juuri teidän yrityksellenne olisi. Voit varata ajan tämmöiseen keskusteluun alta.
Varaa ilmainen keskusteluaika tästä
Tunnistamme toki, että aina ei ole mahdollista saada haluttua toimintaa standardijärjestelmällä aikaan. Siihenkin meiltä löytyy keinoja. Lue tästä artikkelista minkälaisia ja miksi juuri Odoo!
