Mitkä prosessit kannattaa automatisoida ja miten ne tunnistaa

Neljä kysymystä, joilla päivittäisen työnsä voi seuloa itse: onko se ketju, jolla on tulos, saako kone dataa vai kuvan, päättääkö vaihe jotakin ihmisestä, ja onko prosessilla jo ulkoinen määräaika.

Kysymys ”mitä meidän pitäisi automatisoida” esitetään yleensä liian myöhään, koska se olettaa, että vastaus on luettelo työkaluista. Käytännössä suurin osa epäonnistuneista automatisointihankkeista on alkanut oikeasta työkalusta, joka asetettiin väärin valitun työn päälle, ja juuri valinta, ei työkalu, ratkaisi tuloksen.

Tämä artikkeli ei yritä määritellä, mitä liiketoimintaprosessien automatisointi on, koska määritelmä ei ratkaise mitään; sen sijaan se antaa neljä kysymystä, joilla päivittäisen työnsä voi seuloa itse, ja kunkin kysymyksen jälkeen näyttää, miltä näyttää tapaus, joka sen läpäisee, ja tapaus, joka ei läpäise. Seulonta ei maksa mitään ja vie yhden iltapäivän, mutta säästää selvästi enemmän kuin mikään työkalujen vertailu, koska se vastaa ketjun varhaisimpaan kysymykseen.

Ensimmäinen kysymys: onko se ketju, jolla on tulos, vai klikkausten sarja

Tämä on se raja, joka ratkaisee eniten, ja se kannattaa vetää tarkasti: prosessi on toimintojen ketju, jolla on syöttötiedot, tulos ja omistaja: laskun laatiminen tilauksesta, uuden työntekijän palkkaaminen, asiakkaan pyynnön polku lomakkeesta vastaukseen. Menettely eli yksittäinen toimenpide on se, miten tietty vaihe tehdään: mistä klikataan, mitä kopioidaan, mihin kenttään numero laitetaan.

Molemmat voi automatisoida, mutta tuotto eroaa moninkertaisesti, ja siksi järjestys on tärkeä: jos automatisoit ketjun, muutat tulosta — asiakirja päätyy kirjanpitoon itsestään, eikä kukaan enää kopioi sitä. Jos automatisoit klikkausten sarjan, nopeutat yhtä vaihetta ketjussa, jonka muu osa pysyy ennallaan, ja hyöty on juuri sen yhden vaiheen osuuden kokoinen.

Käytännön tunnistamistapa on yksinkertaisesti kysyä, mitä tulokselle tapahtuu sen jälkeen, ja vastaus kertoo yleensä kaiken: jos se on ”sitten joku ottaa tämän tiedoston ja laittaa sen toiseen järjestelmään”, ketju jatkuu ja yhden vaiheen automatisointi merkitsee pullonkaulan siirtämistä, ei sen poistamista. Jos vastaus on ”sitten työ on valmis ja tulos on järjestelmässä”, sinulla on prosessi, jolla on selvä päätepiste, ja juuri sellaiset kannattaa ottaa ensimmäisinä.

Otetaan yksi tyypillinen ketju ja seurataan se loppuun, koska juuri seuraaminen näyttää, missä hyöty oikeasti piilee: asiakas täyttää lomakkeen sivustolla, pyyntö saapuu sähköpostiin, joku kopioi sen asiakasjärjestelmään, toinen laatii tarjouksen, ja hyväksynnän jälkeen vielä joku laatii laskun kirjanpito-ohjelmassa. Tässä on yksi prosessi, jolla on selvä tulos (pyynnöstä laskuun), ja siinä on vähintään kolme kohtaa, joissa samat tiedot kopioidaan uudelleen, joka kerta virheen mahdollisuudella.

Jos tästä ketjusta automatisoidaan vain pyynnön kopiointi asiakasjärjestelmään, hyöty on todellinen mutta pieni, koska kaksi muuta kopiointia jää. Jos automatisoidaan koko ketju, työn luonne itse muuttuu: ihminen ei enää kopioi, vaan tarkistaa ja tekee päätöksiä siellä, missä niitä todella tarvitaan. Juuri siksi ketjun rajat kannattaa piirtää ennen mitä tahansa työkalukeskustelua, koska ne määräävät, miten suuri mahdollinen hyöty on.

Ketjulla on myös omistaja, ja se on kysymys, joka usein jää kysymättä: jos kukaan tietty ihminen ei osaa sanoa, miten prosessi etenee alusta loppuun, automatisoinnista tulee oletusten sarja siitä, miten se luultavasti tapahtuu, ja ensimmäinen todellinen tapaus rikkoo nämä oletukset. Omistajan löytäminen vie yleensä yhden keskustelun mutta säästää useita viikkoja, siksi se on hankkeen halvin osa.

Toinen kysymys: saako kone dataa vai kuvan

Tämä on koko automatisoinnin tärkein tekninen ero, ja Suomessa sillä on nyt myös sääntelypuoli. Jos järjestelmä saa rakenteisia tietoja (XML, JSON, tietokantarivin), se voi käsitellä ne ilman arvailua. Jos se saa kuvan, eli PDF-tiedoston tai skannatun sivun, jonkun on ennen käsittelyä arvattava, mitä siinä lukee, ja juuri tämä arvailu synnyttää virheet, jotka joku myöhemmin korjaa käsin.

Laskuesimerkki näyttää sen parhaiten, koska siinä molemmat vaihtoehdot elävät rinnakkain ja niitä kutsutaan lähes samoin. Verkkolasku (EN 16931), arkikielessä pelkkä verkkolasku, on koneluettava asiakirja määrätyssä muodossa — Suomessa se vastaa standardia SFS-EN 16931-1:2017 ja Peppol BIS Billing 3.0 -profiilia. Vastaanottajan järjestelmä pystyy kirjaamaan sen ilman ihmisen osuutta, siksi juuri tämä muoto on se, jota säädösten määräajat koskevat.

PDF-lasku, jonka vastaanottaja on suostunut ottamaan sähköisesti, on myös pätevä asiakirja: arvonlisäverolain 209 d § sallii laskun antamisen sähköisessä muodossa, jos vastaanottaja antaa siihen suostumuksensa, mutta pätevä se on arvonlisäverolaskuna, ei verkkolaskuna, ja koneelle se on yhä kuva.

Tästä seuraa johtopäätös, joka säästää paljon rahaa: PDF-laskujen tunnistaminen optisella merkkientunnistuksella (OCR) ei ole verkkolaskun käyttöönottoa. Se on erillinen toimenpide, jonka ihmiset automatisoivat perustellusti, koska se vähentää kopiointia, mutta se ei synnytä rakenteista asiakirjaa eikä täytä velvollisuutta sellainen laatia. Yritys, joka pitää OCR:ää vastauksena säädösvaatimukseen, huomaa muutaman vuoden päästä automatisoineensa väärän pään, ja hanke on aloitettava uudelleen siitä järjestelmästä, joka laatii laskut, ei siitä, joka ne vastaanottaa.

Käytännön tarkistustapa on tässä yksinkertainen: kysy, missä muodossa järjestelmä pystyy tietoja luovuttamaan ja vastaanottamaan. Jos vastaus on ”voi viedä CSV:nä”, kyse on jo rakenteisista tiedoista, vain puutteellisesti automatisoiduista. Jos vastaus on ”voi tulostaa” tai ”voi tallentaa PDF:nä”, kuva on ainoa tuloste, ja jatko joko vaatii rajapinnan tai jää arvailuksi.

Kannattaa myös tietää, että vastaus on usein parempi kuin yrityksessä luullaan, koska monilla kirjanpito- ja varasto-ohjelmilla rajapinta on, sitä ei vain ole koskaan kysytty, koska arki sujuu viennillä. Yksi kysymys toimittajalle siitä, onko järjestelmässä ohjelmointirajapinta ja mitä sillä voi tehdä, ratkaisee usein, kannattaako hanketta ylipäätään aloittaa.

Kolmas kysymys: päättääkö vaihe jotakin ihmisestä

Suurin osa automatisoinnista on lukujen siirtämistä järjestelmien välillä, eikä siinä ole erityisiä oikeudellisia kysymyksiä. On kuitenkin yksi vaiheiden ryhmä, joka on tunnistettava erikseen: ne vaiheet, jotka päättävät jotakin tietystä ihmisestä — otetaanko hänet töihin, myönnetäänkö luotto, irtisanotaanko, myönnetäänkö etuus.

Yleisen tietosuoja-asetuksen 22 artikla säätää, että rekisteröidyllä on oikeus olla joutumatta sellaisen päätöksen kohteeksi, joka perustuu pelkästään automaattiseen käsittelyyn ja jolla on häntä koskevia oikeusvaikutuksia tai joka vaikuttaa häneen vastaavalla tavalla merkittävästi. Poikkeuksia on (sopimuksen välttämättömyys, laki suojatoimineen, nimenomainen suostumus), mutta silloinkin jää oikeus ihmisen osallistumiseen, oman kannan esittämiseen ja päätöksen riitauttamiseen. Valvontaviranomaisten ohjeet lisäävät tärkeän vivahteen: ihmisen osallistumisen on oltava merkityksellistä, eikä muodollinen hyväksyntänappi, jota joku painaa sisältöön katsomatta, poista prosessia 22 artiklan piiristä.

Tämä ei ole kielto automatisoida, vaan ohje siitä, mitä juuri tällaisessa prosessissa saa automatisoida: automatisoida voi valmistelun (tietojen keräämisen, tarkistuksen, ehdotuksen laatimisen), mutta itse päätös jää ihmiselle, joka sen todella tekee. Käytännössä se muuttaa hankkeen laajuutta, siksi se kannattaa huomata ennen kehitystä, ei sen jälkeen.

Sivussa kannattaa tietää yksi määräaika, joka ei ole vielä koittanut mutta vaikuttaa pitkän aikavälin suunnitelmiin: tekoälyasetuksen vaatimukset suuren riskin järjestelmille työllisyyden alalla, eli rekrytoinnissa ja henkilöstöpäätöksissä, alkavat tulla sovellettaviksi 2. joulukuuta 2027. Se merkitsee, että tänään valinta on vapaampi, mutta järjestelmälle, jota rakennetaan pitkäksi aikaa, tämä päivämäärä on laitettava suunnitelmaan.

Neljäs kysymys: onko prosessilla jo ulkoinen määräaika

Osalla prosesseista määräajan asettaa yrityksen prioriteettien sijaan ulkoinen velvollisuus, ja ne nousevat automaattisesti listan kärkeen, koska niistä ei enää päätetä, tehdäänkö, vaan vain milloin ja miten. Suomessa selkein esimerkki on taas laskut, ja siinä on kolme eri päivämäärää, jotka sekoitetaan.

Ensinnäkin hankintayksikön on otettava vastaan ja käsiteltävä rakenteinen sähköinen lasku valtion keskushallinnossa jo 1. huhtikuuta 2019 lähtien; toiseksi 1. huhtikuuta 2020 alkaen vastaanottovelvollisuus koskee myös muita hankintayksiköitä, ja samasta päivästä hankintayksiköllä ja elinkeinonharjoittajalla on oikeus saada pyynnöstä verkkolasku toiselta yritykseltä; kolmanneksi valtio on Valtiokonttorin linjauksen mukaan huhtikuusta 2021 vastaanottanut vain Eurooppa-normin mukaisia verkkolaskuja.

Juuri tämä kolmas rajaus on julkisessa keskustelussa useimmin väärin, ja syy on yksinkertainen: verkkolasku ja Eurooppa-normin mukainen verkkolasku sekoitetaan, alkuperäinen velvollisuus valtiolle alkoi 2019 ja tiukkeni myöhemmin, ja osa toisen käden artikkeleista ei ole seurannut rajauksia — osa esittää lisäksi yleistä B2B-pakkoa, jota laissa ei ole. Yritykselle, joka suunnittelee budjettia, ero on suuri, siksi päivämäärä kannattaa tarkistaa ensisijaisesta lähteestä, ei uudelleenkerronnasta.

Ulkoisia määräaikoja on muuallakin: työajan seurannan on oltava objektiivista ja saatavilla, kirjanpitoaineistolla on säilytysajat, ja sopimuksissa on usein raportointipäiviä. Yhteistä on se, että näistä määräajoista ei neuvotella, ja prosessi, jolla sellainen on, antaa työlle selvän perusteen — toisin kuin prosessi, joka automatisoidaan siksi, että se tuntuu nykyaikaiselta.

Miltä näyttää prosessi, joka kannattaa ottaa ensimmäisenä

Jos neljä kysymystä yhdistää, syntyy melko konkreettinen muotokuva, jonka voi liittää mihin tahansa listaan: arvokkain ensimmäinen ehdokas on ketju, jolla on selvä tulos, jossa tiedot ovat jo rakenteisessa muodossa tai voivat tulla sellaisiksi, jossa yksikään vaihe ei päätä mitään ihmisestä, ja jolla on ulkoinen määräaika tai ainakin mitattava volyymi.

Käytännössä se näyttää yleensä tältä: tilaus kaupasta päätyy kirjanpitojärjestelmään ilman kopiointia; hyväksyntäketju, jossa pyyntö menee oikealle ihmiselle ja palaa merkinnän kanssa; tietojen synkronointi varaston ja sivuston välillä, jossa ihminen vie nyt tiedoston kahdesti päivässä. Kaikissa kolmessa on yksi yhteinen piirre — kahden järjestelmän välillä kulkee tänään ihminen tiedosto kädessä.

Juuri tämä piirre on helpoin huomata ja vaikein unohtaa, siksi kartoitus kannattaa aloittaa siitä. Kirjoita, missä yrityksessäsi joku vie, kopioi tai kirjoittaa uudelleen, kuinka usein ja kuinka kauan. Tämä lista on yleensä lyhyempi kuin odotetaan, ja siinä on lähes aina yksi rivi, joka erottuu.

Toinen piirre, joka nostaa ehdokkaan esiin, on virheen hinta, ja se jää laskelmista yleensä pois: jos kopiointivirhe tässä ketjussa merkitsee väärää laskua asiakkaalle, väärää varastosaldoa tai myöhästynyttä määräaikaa, automatisoinnin hyöty ei ole vain säästetyt tunnit vaan myös estetyt virheet, ja se on yleensä näistä kahdesta luvusta suurempi. Prosessi, jossa virhe on huomaamaton ja harmiton, on tässä mielessä heikompi ehdokas, vaikka se veisi yhtä paljon aikaa.

Kolmas piirre on se, miten volyymi muuttuu yrityksen mukana, ja se on kolmesta tärkein: työ, joka kasvaa yrityksen mukana, koska enemmän tilauksia merkitsee enemmän kopiointia, kallistuu ajan myötä, ja juuri siinä automatisointi maksaa itsensä kahdesti: se vapauttaa aikaa tänään ja poistaa kulun, joka muuten kasvaisi, kun taas työ, jonka volyymi ei riipu liikevaihdosta, ei anna tätä toista hyötyä.

Muotokuvaan kannattaa liittää vielä yksi asia järjestyksestä, koska siinä yritykset erehtyvät useammin kuin työkalun valinnassa: ensimmäistä automatisoitavaa prosessia ei pidä valita sen mukaan, mikä on suurin tai kipein, vaan sen mukaan, mikä on parhaiten ymmärretty ja nopeimmin valmis, koska ensimmäinen hanke opettaa yritykselle, miten tällaiset hankkeet ylipäätään etenevät — miten poikkeukset kuvataan, miten testataan ja miten virheisiin tartutaan. Tämä oppi on paljon halvempi saada yksinkertaisesta työstä kuin työstä, josta kassavirta riippuu.

Miltä näyttää prosessi, jota ei kannata ottaa ensimmäisenä

Yhtä hyödyllistä kuin tunnistaa hyvä ehdokas on tunnistaa se, mikä näyttää houkuttelevalta mutta maksaa itsensä huonosti, ja tällaisia tapauksia on neljä. Ensimmäinen on työ, joka tapahtuu harvoin (kerran neljännesvuodessa tai kerran vuodessa), koska kehityskustannus pysyy samana, mutta säästö jaetaan neljällä tai yhdellä.

Toinen on prosessi, jonka järjestys vielä muuttuu, ja se on tapaus, jossa kiire maksaa kalleimmin: jos järjestystä on viimeisen puolen vuoden aikana muutettu kolme kertaa, automatisointi lukitsee sen version, joka muuttuu joka tapauksessa pian, ja ylläpito syö hyödyn. Tässä oikea järjestys on sopia ensin menettelystä ja automatisoida vasta sitten, vaikka käytännössä käy usein toisinpäin.

Kolmas on työ, jossa jokainen tapaus on poikkeus, ja siinä raja on itse tehtävän luonteessa, koska automatisointi pärjää hyvin toistuvan ja ennakoitavan kanssa mutta huonosti tilanteessa, jossa kymmenellä tapauksella on kymmenen eri polkua; siellä ihmisen harkinta on itse työ, ja sen korvaaminen sääntöpuulla synnyttää yleensä enemmän poikkeuksia kuin estää.

Näitä kolmea tapausta yhdistää yksi piirre: niissä automatisointi lukitsee jotakin, mikä ei ole vielä valmis lukittavaksi. Harvinainen työ ei ole riittävän hioutunut, jotta se kannattaisi ikuistaa; muuttuva prosessi etsii vielä muotoaan; poikkeustyö on luonteeltaan harkintaa, ja kaikissa kolmessa oikea teko on odottaa tai järjestää ensin, ei automatisoida nopeammin.

Neljäs on tapaus, jossa näytön toimia toistetaan siksi, ettei järjestelmässä ole rajapintaa: se on joskus ainoa mahdollinen tie, mutta se on myös haurain, sillä riittää muutos näytössä ja työ pysähtyy. Jos järjestelmässä on rajapinta tai sen voi vaatia, se on lähes aina edullisempi valinta kuin näytön toimien toistaminen.

Mitä tapahtuu ihmisille, joiden työ automatisoidaan

Tämä kysymys kierretään automatisointitarjouksissa yleensä, vaikka yrityksessä se esitetään jo ensimmäisenä päivänä, ja vastaamattomana siitä tulee hiljainen vastarinta, joka voi pysäyttää hankkeen varmemmin kuin mikään tekninen ongelma. Rehellinen vastaus useimmissa pienissä ja keskisuurissa yrityksissä on, että automatisointi vapauttaa aikaa, ei ihmistä: kopiointi on se työn osa, jota kukaan ei halua, ja sen katoaminen merkitsee yleensä, että sama ihminen ehtii vihdoin tehdä sen, mihin ennen ei riittänyt aikaa.

Tästä seuraa käytännön suositus, joka kuulostaa pehmeältä mutta on puhdas projektinhallintakysymys: ihminen, joka työn tänään tekee, on otettava hankkeeseen tietävimpänä lähteenä, ei tiedotettavana tuloksesta. Hän tuntee poikkeukset, joita kukaan ei ole kirjoittanut ylös, ja juuri poikkeukset rikkovat automatisoinnin. Hanke, jossa tämä keskustelu käydään alussa, maksaa vähemmän kuin sellainen, jossa se käydään ensimmäisen virheen jälkeen.

On myös rehellistä sanoa toinen puoli, koska päinvastainen olisi teeskentelyä: jos yrityksessä jonkun työ koostuu kokonaan tiedon siirtämisestä kahden järjestelmän välillä, automatisointi todella korvaa tämän työn, ja se on keskustelu roolin muutoksesta, jota johtaa yrityksen johto, ei toimittaja. Tarjous, joka ei tätä kysymystä esitä lainkaan, ei ole hienotunteinen — se on yksinkertaisesti kesken ajateltu.

Miten lasket oman lukusi

Laskelma, jota päätös tarvitsee, mahtuu yhdelle sivulle eikä vaadi konsulttia eikä tutkimusta, ja tarvitaan neljä lukua: kuinka monta kertaa viikossa tämä työ tapahtuu, kuinka monta minuuttia se vie joka kerta, mitä maksaa tunti sille ihmiselle, joka sen tekee, ja kuinka usein siinä syntyy virhe, jonka joku sen jälkeen korjaa.

Ensimmäiset kolme antavat suoran aikakustannuksen vuodessa, ja tämä luku on yleensä pienempi kuin odotetaan — juuri siksi pelkästään sillä hanketta perustellaan usein turhaan. Neljäs luku on se, joka enimmäkseen ratkaisee, koska virheen hinta on harvoin vain sen korjaamisen aika: väärä lasku merkitsee kirjeenvaihtoa asiakkaan kanssa, väärä saldo merkitsee joko myymättä jäävää tuotetta tai tilausta tuotteelle, jota varastossa ei enää ole, ja myöhästynyt määräaika merkitsee joskus sakkoa.

Näitä lukuja vasten pannaan kehityskustannus ja ylläpito, ja juuri ylläpito on se, joka unohdetaan. Automatisointi, joka yhdistää kaksi järjestelmää, elää vain niin kauan kuin molemmat rajapinnat elävät, siksi suunnitelmassa on oltava tilaa muutoksille, joita joku muu vaatii. Jos laskelma kannattaa vain silloin, kun ylläpitokustannusta ei oteta mukaan, se ei itse asiassa kannata lainkaan.

Vielä yksi asia, joka kannattaa selvittää ennen keskustelua, on se, kuinka usein järjestelmät muuttuvat. Pilvipalvelu, joka päivittyy itsestään, voi vaihtaa rajapintaa ilman varoitusta, kun taas omalle palvelimelle asennettu ohjelma pysyy ennallaan vuosia, mutta sen päivittäminen vaatii joskus kaiken tarkistamisen uudelleen. Kumpikaan vaihtoehto ei ole huonompi, mutta ne vaativat erilaisen ylläpitosuunnitelman, ja tarjous, joka tätä ei näytä, on liian halpa juuri siinä kohdassa, johon myöhemmin syntyy kuluja.

Miksi tutkimusten prosentteihin ei pidä luottaa

Automatisointitarjouksissa näkyy lähes aina luku: että työstä voi automatisoida puolet, että hankkeet kaatuvat kolmanneksessa tapauksista, että joku säästi kymmeniä tuhansia tunteja. Nämä luvut ovat olemassa ja ne voi siteerata, mutta ne eivät lähes koskaan kuvaa sitä yritystä, jolle niitä näytetään, ja juuri se tekee niistä huonon perustan päätökselle.

Laajasti siteerattu tunnus siitä, että suuri osa toiminnoista on automatisoitavissa, on laskelma toiminnoista palkkasummassa tietyssä maassa ja tiettynä vuonna, sen vuoden teknologioilla, ja sen julkaisi konsulttiyritys, joka myy tätä samaa palvelua. Tunnus hankkeiden epäonnistumisista tulee konsultin kokemuksesta asiakkaista, jotka kutsuivat hänet jälkeen ensimmäisten epäonnistumisten, siksi otos on vääristynyt jo määritelmän mukaan. Luku säästetyistä tunneista kuvaa tiettyä neljänkymmenen hengen kirjanpito-osastoa toisessa maassa useita vuosia sitten.

Tästä ei seuraa, että automatisointi ei kannata, vaan se, että oikea luku on omasi: kuinka monta kertaa viikossa tämä työ tapahtuu, kuinka kauan se vie ja mitä maksaa tunti. Tämän laskelman voi tehdä yhdelle sivulle, se kuvaa juuri sinun yritystäsi, ja se on ainoa, jonka varaan päätös kannattaa tehdä.

Mitä järjestelmistä on tiedettävä ennen kuin pyydät tarjousta

Kun ehdokas on valittu, seuraava askel ei ole tarjouksen pyytäminen vaan viiden minuutin selvitys itse järjestelmistä, koska juuri se ratkaisee, onko keskustelu toteuttajan kanssa ratkaisusta vai mahdollisuudesta. Selvitä, onko jokaisella mukana olevalla järjestelmällä ohjelmointirajapinta, onko se käytettävissä lisenssitasollasi ja veloittaako toimittaja siitä erikseen, koska kaikki kolme vastausta voivat poiketa toisistaan.

Toinen kysymys on, kuka tietoja säilyttää ja kuka saa niitä muuttaa: jos kaksi järjestelmää sisältää saman tiedon, esimerkiksi asiakkaan tiedot tai tuotteen varastosaldon, ennen yhdistämistä on päätettävä, kumpi niistä on pääjärjestelmä, koska muuten automatisointi alkaa kirjoittaa molempia ristiin ja tulos on huonompi kuin ennen. Tämä ratkaisu on ilmainen, jos se tehdään alussa, ja kallis, jos se paljastuu testauksen aikana.

Kolmas on kysymys siitä, mitä tapahtuu, kun jokin ei onnistu, sillä jokaisessa automatisoinnissa on tapauksia, jotka eivät mene läpi (kenttä puuttuu, järjestelmä ei vastaa, tiedot ovat ristiriitaisia), ja niille tarvitaan paikka, johon ne päätyvät, ja ihminen, joka ne katsoo. Automatisointi ilman virheiden käsittelyä toimii niin kauan kuin kaikki on kunnossa, eikä se ole koskaan kauan.

Kannattaa myös etukäteen päättää, millä arvioit, onnistuiko, koska ilman sitä hanke ei koskaan pääty, vaan se vain katkeaa. Mittari voi olla aivan yksinkertainen: kuinka monta kertaa kuukaudessa joku vielä kopioi tietoja käsin, kuinka monta virhettä korjattiin viime kuussa ja kuinka kauan pyyntö kulkee lomakkeesta vastaukseen. Tämä luku kannattaa mitata kerran ennen työn alkua, jotta myöhemmin on mihin verrata. Yritykset, jotka tätä mittausta eivät tee, riitelevät puolen vuoden päästä siitä, muuttuiko ylipäätään mikään.

Lopuksi kannattaa muistaa, että automatisointi ei ole kertatyö vaan jotakin, mikä jää yritykseen ja vaatii omistajan kuten mikä tahansa muu järjestelmä. Kun prosessi on yhdistetty, jonkun on tiedettävä, mistä katsoa, jos se pysähtyy, ja jollakulla on oltava oikeus pysäyttää se, jos tulos näyttää väärältä. Yrityksissä, joissa tätä roolia ei ole nimetty, automatisointi lakkaa hiljaa toimimasta, ja sen huomaa vasta kuukauden päästä, kun joku etsii kadonnutta asiakirjaa.

Mistä aloittaa käytännössä

Alku ei ole työkalun valinta eikä tarjouksen pyytäminen, vaan yksi viikko, jolloin kirjataan, mitä tapahtuu: mikä työ toistuu, kuinka usein, kuinka kauan ja missä ihminen siirtää tietoja järjestelmien välillä. Sen jälkeen esitä jokaiselle riville tämän artikkelin neljä kysymystä, ja suurin osa listasta putoaa jo kahden ensimmäisen jälkeen.

Tulokseksi jää yleensä yksi tai kaksi ehdokasta, ja se on hyvä, koska juuri sen verran kannattaa aloittaa yhtä aikaa: kaksi valmista työtä antaa enemmän kuin kuusi aloitettua. Kun ehdokas on valittu, seuraava askel on selvittää, onko mukana olevilla järjestelmillä rajapintoja, koska se ratkaisee sekä hinnan että ratkaisun kestävyyden.

Jos tässä vaiheessa on selvää, mikä prosessi on sinun, mutta ei ole selvää, miten se yhdistetään, siitä voi keskustella kanssamme: liiketoimintaprosessien automatisointi meidän toteutuksenamme on integraatioita ja työnkulkuja järjestelmien välillä, jotka sinulla jo on. Jos haluat ensin ymmärtää, miten eri lähestymistavat ja työkaluryhmät eroavat, kirjoita meille tai lähetä listasi — usein vastaus on, että yksi yhteys riittää, ei alusta.