Case-organisaation nykytilanne ja ohjelmistorobotiikkahankkeiden taustaa 45

Case-organisaatiossa on tunnistettavissa taloushallinnon pääprosessien jaottelu luvussa 2.1.1 esitetyllä tavalla. Organisaation pääasiallinen peruste ohjelmistorobotiikan käyttöön on kehittää pääprosesseja ja edistää strategista tavoitetta automatisoida taloushallinnon prosesseja. Tavoitteena on myös vähentää ylitöiden tekemistä ja parantaa työn laatua sekä läpinäkyvyyttä. Organisaatio on automatisoinut parin viime vuoden aikana muutamia prosesseja ohjelmistorobotiikalla ja tietämys siitä on kasvanut viimeisten vuosien aikana huomattavasti. Case-organisaatiossa automatisointi on pääasiassa liiketoimintalähtöistä ta ja business casen tarpeellisuudesta ollaan lähes yhtä mieltä, vaikka poikkeaviakin mie-lipiteitä sen tarpeellisuudesta on.

”– – [automaatiota] on jo paljon, varsinkin järjestelmien sisäistä. – – Pystyt-täis automatisoida paljon enemmänkin, mut se ei tarkota sitä et se aina kan-nattaa automatisoida. Jos ei ole business casea niin onks järkee?” (#5, Senior Manager, Robotics & automation)

”Kvantitatiiviset asiat ja konkreettiset esimerkit on liian suuressa arvossa – – Business casea lähetään helposti muodostamaan sitä kautta, että tää tuo paljon säästöjä, kuin että tää tuo tällasta muutosta tänne. Business case on valitetta-vasti lähtökohtana, talon koko määrittelee.” (#7, Manager, Project Manager) Organisaatiossa tiedostetaan automaation potentiaali taloushallinnon standardiproses-seissa, mutta sille on vaikeaa löytää konkreettisia hyödyntämiskohteita. Vaikka business casen olemassaoloa pidetään lähtökohtana, kriteerit täyttävien prosessien löytäminen on vaikeaa. Se voi johtua osittain siitä, ettei automaatiota ole ylipäänsä tehty vielä paljon.

Tällä hetkellä organisaatio tunnistaa itsensä ”yritys ja erehdys” -vaiheesta, missä ensim-mäisiä projekteja tehdään osin oppimisen vuoksi ja niistä edetään laajamittaisempiin pro-jekteihin.

”– – meillä on aika paljon sellasia pieniä taskeja, mitään isoja business caseja on vaikee muodostaa.” (#2, Expert, Business Analysis)

”Nyt on oppimiskausi menossa, tunnistetaan potentiaalit ja mitä tehtäviä kan-nattaa automatisoida.” (#9, Expert BPO & ICR)

Sopivien automatisoitavien prosessien löytäminen on helpointa osto- ja myyntilaskupro-sesseista. Niissä voidaan tunnistaa tehtäviä, joissa on suuri volyymi ja jotka ovat riittävän yksinkertaisia automatisoitaviksi. Näissä prosesseissa toteutetut automatisointihankkeet ovat sujuneet haastateltavien mukaan paremmin kuin pääkirjanpitoprosessissa. Pääkirjan-pitoprosessia kuvaillaan sekavaksi ja monimutkaiseksi, minkä seurauksena sieltä ei ole helppo tunnistaa yhtäläisiä prosesseja, joita olisi kannattavaa automatisoida. Pääkirjanpi-toprosessi kokoaa muiden osaprosessien tietoa yhteen ja se sisältää paljon erilaisten ad hoc -raporttien tekemistä. Tämän seurauksena sieltä ei ole helppoa löytää prosesseja, jotka ovat riittävän yksinkertaisia ja joissa on automatisoinnin vaatimaa volyymi ja toisto.

Organisaation yhtenä tavoitteena on toteuttaa kuitenkin yhdestä kahteen automatisoitavaa prosessia pääkirjanpitoprosessista. Vaikeuksista huolimatta organisaatio on ryhtynyt to-teuttamaan ohjelmistorobotiikkahankkeita vaihtelevalla menestyksellä, koska tarve auto-matisoinnille on suuri. Automatisointia on kohdennettu niihin aikoihin, kun henkilöstö tekee paljon ylitöitä ja niihin prosesseihin, joissa henkilöstö ei pysty nykyisillä järjestel-millä enää suoriutumaan tehtävistä.

”On pyritty vähentämään pullonkauloja niiltä päiviltä, kun tehdään ylitöitä, että saadaan sitä aikasäästöä. Toinen on se, että alkaa olla sellaisia exceleitä, jotka alkavat kaatumaan, että virhealttius ja laatu tulee sieltä. Ja läpinäky-vyys ylipäätään.” (#3 Director, Financial Control)

Organisaatiossa ilmenee vähäisessä määrin myös teknologista lähestymistapaa ohjelmis-torobotiikkaan. Tällaista ajattelua voi esiintyä silloin, kun markkinoille ilmaantuu uusia teknologioita. Teknologiapainotteisen ajattelutavan riskinä on se, että organisaatio ei käytä liiketoimintaprosessien kehittämiseen parhaita mahdollisia työkaluja, vaan ”tekno-logiahypen” kohteena olevia uusia vaihtoehtoja, vaikka ne eivät olisi parhaita vaihtoeh-toja lopputuloksen kannalta. Tällainen lähestymistapa saattaa johtaa siihen, että käytetään ohjelmistorobotiikkaa sellaisiinkin ongelmiin, joissa se ei ole paras ratkaisu.

Organisaatiossa on laajassa mittakaavassa jonkintasoinen ymmärrys siitä, mitä taloushal-linnon automaatio ja ohjelmistorobotiikka tarkoittaa ja mikä sen potentiaali on. Sopivien prosessien löytämiseksi henkilöstö tulee kouluttaa prosessien tunnistamiseen ja ensim-mäisiä koulutuksia onkin jo aloitettu. Tavoitteena kuitenkin on, että henkilöstöltä tulisi enemmän aloitteita. Case-organisaatiossa tiedostetaan, että henkilöstön aloitteet ovat yksi keskeinen tapa nostaa automaatioastetta.

Kun suuri osa taloushallinnon suurivolyymisista prosesseista on siirretty ulkoistuskump-panille, case-organisaatioon on jäänyt ainoastaan vaikeammin automatisoitavat tehtävät.

Konsernin taloushallinto on keskittynyttä siltä osin, kun sitä ei ole ulkoistettu BPO-kumppanille. Toisaalta organisaation suuri koko ja ulkoistus aiheuttaa ongelmia kehittä-mistyölle ja haasteet myös tunnistetaan.

”Mä on nähny monenlaisia malleja, mutta niissä ei koskaan ulkoistettu sitä robotiikan scopea, niinku me ollaan. Miten voi draivaa robotiikkaa, kun se ulkoistettu ja vielä jaat niitä hyötyjä sen ulkoistuskumppanin kanssa. Me ol-laan ulkoistettu se tehtävä sinne ja toivotaan että he automatisoivat sitä teke-mistä. Se malli on hankala jo siinä” (#3, Director, Financial Control)

Hajautettu toteutus ydinorganisaation ja BPO-kumppanin välillä on hidastanut ohjelmis-torobotiikkahankkeita, mihin ollaan tyytymättömiä. Organisaatio on toteuttanut projek-teja ulkoistuskumppanin kanssa sen omasta aloitteesta. BPO-organisaatiossa ollaan auto-maatiossa pidemmällä, osittain siksi, että sinne on siirretty standardiprosesseja, mutta osittain myös siksi, että siellä on käynnistetty järjestelmällinen kehitystyö aikaisemmin.

BPO-organisaatiossa realisoituneet säästöt hyödyttävät osaltaan myös case-organisaa-tiota. BPO-organisaatiossa tehtyjen projektien tietoisuus on levinnyt myös laajemmalle, koska RTR -organisaation prosessiasiantuntijat ovat olleet mukana kehittämässä kump-panin automaatiohankkeita. Organisaatio on tästä näkökulmasta hankalassa välitilassa – BPO-kumppani ei ota automaatiota käyttöön siinä määrin, kun olisi potentiaalia, mutta case-organisaatio ei voi itsekään automatisoida ulkoistamiaan prosesseja. Toisaalta hi-dasteena nostetaan esiin johdon tahtotilan ja toteutuksen välinen kuilu – eli johto haluaa tuloksia, mutta organisaatiolla ei ole keinoja päästä tavoitteisiin.

”Yksi hidaste on se, että ylätasolla on Finance managementilla tahtotila ja that’s it. Toisaalta [BPO-kumppani] on tuottanut ideoita, on tehty ruohonjuu-ritasolla työtä. Tavallaan keskitaso on puuttunut.” (#1 Senior Manager, Fi-nancial Control)

Matriisiorganisaatiorakenne on vaikeuttanut projektien koordinointia. Ohjelmistorobo-tiikkaprojektit on toteutettu linjaorganisaatiossa, minkä vuoksi projektilta puuttuvat si-toutuneet tekijät ja vetäjät. Projekteilla ei aina ole dokumentoitua työohjelmaa ja aikatau-lua, mikä aiheuttaa projektitiimissä epätietoisuutta siitä, mistä kukakin on vastuussa. Jos projektin vetäjä on linjaorganisaatiosta, projekti ei välttämättä ole projektin vetäjän tär-keysjärjestyksessä kovin korkealla. Lopulta tehokas projektitiimi on melko pieni, mikä poikkeaa nykytilanteesta, jossa on ajoittain hyvin paljon sidosryhmiä ja osallistujia.

”Kehittämiseen osallistuisi aloitteen tekijä, riippumatta tehtävästä, alueen ekspertti, itse koodaaja/kehittäjä.” (#1 Senior Manager, Financial Control)

Organisaatiolla on visio siitä, millä tasolla prosessien halutaan tulevaisuudessa olevan.

Valmisteilla on malli ohjelmistorobotiikkahankkeiden toteuttamiseen päätöspuineen. Au-tomatisoitujen prosessien kuvaukseen käytetään vuokaaviota. Sen sijaan tulevaisuuden rooleja ei ole määritetty eikä muutoksista organisaatiorakenteeseen ole sovittu. Nykyiset hankkeet on toteutettu siten, että toteutuksesta vastaavat henkilöt ovat osallistuneet pro-jekteihin varsinaisten tehtäviensä ohessa. Henkilöstöä ei ole juurikaan koulutettu ohjel-mistorobotiikan hyödyntämiseen, eli suurin osa automaation potentiaalista on vielä hyö-dyntämättä. Lisäksi organisaatio ei ole jakanut onnistuneista hankkeista tulevia hyötyjä, vaikka sitä muuten tehdään monessa organisaation kehityshankkeessa. Esimerkkejä on-nistuneista ohjelmistorobotiikkahankkeista ei ole levitetty henkilöstön tietoisuuteen.

Hallinnan puute on tunnistettu keskeiseksi ongelmankohdaksi. Sen seurauksia ovat haja-nainen projektimalli ja projektien toteutus. Kaikissa projekteissa ei välttämättä ole pro-jektiaikataulua, jota säännöllisesti seurattaisiin. Välillä projektit viivästyvät, koska orga-nisaatiossa pohditaan, mikä olisi oikea tapa edetä. IT -organisaatiolla on käytössään eri-laisia malleja automaatiohankkeiden toteuttamiseen, mutta taloushallinnossa niitä ei pi-detä käyttökelpoisena, koska siellä automatisoinnin lähtökohdat eroavat jonkin verran IT:stä, eikä malleja voi sellaisenaan käyttää. Hankkeiden raportointi on hajanaista ja ko-konaisnäkemys projektien onnistumisesta on epäselvä. Case-yrityksessä on linjattu, että projektijohto kuuluu osaksi ostettua palvelua, mikä on johtanut siihen, että case-organi-saatio ei voi kontrolloida projektien käytännön toteutusta, mikä on johtanut tyytymättö-myyteen.

”Yksittäisten tehtävien läpivienti on vienyt paljon aikaa, projektirakenne ei selkeä ja käytännön asioissa huolettomuutta. – – seurauksena tulee yllätyksiä ja viivästyksiä, kun asioita joudutaan korjaamaan. [case-yrityksessä] ohjat-tiin, että project management on osa [BPO-kumppanilta] ostettua palvelua.

Sellainen tunne, että oikeat stepit viivästyivät entisestään. – – 10 henkilöä saattaa tehdä robotiikkaa, ja kukin raportoi omasta pienestä palasestaan. Dy-naaminen, kokoava voima puuttuu.” (#9, Expert BPO & ICR)

Case-organisaatiolla on automaatiotyöryhmä, joka voisi toimia hankkeiden sponsorina ja resurssien tarjoajana. Minkäänlaista robotiikkaan keskittynyttä projektiorganisaatiota ei ole olemassa, vaan periaatteessa henkilöt kootaan mukaan tarpeen mukaan. Käytännössä hankkeiden toteutus on kuitenkin hiljalleen siirtynyt tiettyjen henkilöiden vastuulle. Pro-jekteissa tulisi olla alusta asti nimetyt vastuuhenkilöt ja he tarvitsevat riittävät resurssit, jotta projektin tavoitteet saavutetaan. Valmistelua leimaa suunnittelemattomuus ja tehtä-vät jaetaan ad hoc -tyyppisesti. Erityisesti process analyst -rooli olisi keskeinen, sillä pro-sessiosaamista ei voi ostaa ulkopuolelta. Linjaorganisaatiosta ei kuitenkaan voida irrottaa resursseja projekteihin, vaikka siellä olisi paras prosessiosaaminen. Jo olemassa olevaa osaamista voidaan jatkokouluttaa automatisoitavien prosessien tunnistamiseen ja järjes-tää henkilöstölle mahdollisuudet osallistua projekteihin.

Organisaatioon ollaan toteuttamassa toiminnanohjausjärjestelmän uudistusta lähitulevai-suudessa, joten raskasta automaatiota ei nähdä kannattavana ennen sitä, koska lähes kaikki taloushallinnon prosessit kulkevat jossain määrin toiminnanohjausjärjestelmän

kautta. Vaikka ohjelmistorobotiikan takaisinmaksuaika on lyhyt, ei automaatio ole vält-tämättä kovin kustannustehokasta, koska toiminnanohjausjärjestelmän päivittämisen jäl-keen ohjelmistorobotteihinkin jouduttaisiin tekemään mittavat päivitykset. Muutenkin toiminnanohjausjärjestelmän uudistuksen mittaluokka on merkittävästi suurempi kuin yksittäisten automaatioprojektien.

Ohjelmistorobotti ei ole lähtökohtaisesti hidas, mutta sen hitaus syntyy käyttöliittymistä, sillä se käyttää ohjelmistoja kuten ihminen. Esimerkiksi toiminnanohjausjärjestelmien käyttöliittymien hitaus hidastaa myös ohjelmistorobotin toimintaa. Uuden ERP -järjestel-män käyttöönoton odottaminen voi hidastaa ohjelmistorobotiikan käyttöönottoa, sillä en-sin halutaan katsoa, mitä prosesseja sillä saadaan suoraan tehostettua. Havainto on risti-riidassa robotiikan lyhyen takaisinmaksuajan kanssa. Tilanteeseen on voinut johtaa esi-merkiksi resurssien puute, jolloin organisaatio ei kykene toteuttamaan useampaa uudis-tushanketta samanaikaisesti.

3.4.2 Ohjelmistorobotiikan potentiaali

Ohjelmistorobotiikassa nähdään yleisesti ottaen paljon potentiaalia, mutta sillä on myös paljon reunaehtoja. Ohjelmistorobotiikan hyödyntämisen edellytyksiä on kuvattu luvussa 2.1.3. Yleisesti ottaen haastateltavat olivat samaa mieltä ohjelmistorobotiikan hyödyntä-misen edellytyksistä. Neljä tärkeintä vaatimusta hyödyntämiselle, jotka on kuvattu kuvi-ossa 3, tulivat esille lähes jokaisessa haastattelussa. Haastateltavat muistivat myös mai-nita, ettei ohjelmistorobotiikka korjaa prosessissa itsessään olevia ongelmakohtia. Ohjel-mistorobotiikan tärkein reunaehto on digitaalinen ja rakenteinen data. Haittana nähtiin, ettei ohjelmistorobotti kykene lukemaan kuvatiedostoja tai vapaamuotoisia sähköposteja.

”Vahvuuksia on – – rutiinitehtävien nopeuttaminen ja outputin standardi-sointi, että se on aina tasalaatuista, on se sitten määritelty hyväksi tai huo-noksi. Se nopeuttaa ja poistaa sen manuaalisen tekemisen niin aikaa vapautuu muuhun tekemiseen.” (#1 Senior Manager, Financial Control)

Ohjelmistorobotiikan vahvuudet ovat rutiinitehtävien poistamisessa, työn lopputuleman standardisoinnissa ja työntekijöiden työajan vapauttamisessa muuhun toimintaan. Auto-maatiolla saatavia kustannussäästöjä korostettiin haastatteluissa. Sen hyviä puolia ovat

lisäksi työtyytyväisyyden parantaminen, kun ihmiset voidaan vapauttaa luovempaan työ-hön irti rutiineista. Toisaalta automaatio kasvattaa tuottavuutta vain, jos ihmiset voidaan siirtää tuottavampien tehtävien hoitamiseen.

Ohjelmistorobotiikan vahvuudeksi nähdään kehitystyön helppous verrattuna perinteiseen järjestelmäkehittämiseen. Prosessien määrittely ei vaadi erityistä teknologista osaamista, joten nykyinen henkilöstö kykenee siihen lisäkoulutuksen jälkeen. Prosessi pitää vain määritellä riittävän yksityiskohtaisesti ja loogisesti, jotta se on mahdollista siirtää ohjel-mistorobotin hoidettavaksi. Mitä enemmän prosesseja automatisoidaan, sitä helpom-maksi tulevien prosessien automatisointi ohjelmistorobotiikalla muuttuu. Suurtuotannon etuja kehittämistyöstä saadaan, mikäli organisaatio omistaa ohjelmistorobotiikkaskriptit, eli ohjelmistorobotin koodatut työvaiheet. Kun skripti on kerran luotu ja yrityksen omis-tuksessa, se voidaan kopioida nopeasti uusiin prosesseihin. Samaten alkuvaiheessa koh-datut ongelmat voidaan helposti välttää tulevissa projekteissa.

Ohjelmistorobotille hyvin soveltuvia tehtäviä ovat esimerkiksi reskontratyö ja siihen liit-tyvät täsmäytykset. Robottien eduksi todettiin ohjeistetun työn virheettömyys ja transak-tioiden nopeus verrattuna ihmisen tekemään työhön. Toisaalta ohjelmistorobotiikan eduksi luettiin myös integraatio legacy -järjestelmien välillä. Ohjelmistorobotiikka näh-tiin hyväksi vaihtoehdoksi nostaa liiketoimintaprosessien automaatioastetta järjestelmien elinkaaren loppuvaiheessa. Automaation avulla voidaan kasvattaa kontrollien lukumää-rää, koska kerran automatisoitu kontrolliprosessi voidaan monistaa lukemattomasti. Edel-leen ohjelmistorobotiikalla voidaan vähentää väärinkäytösten riskiä vähentämällä vaaral-listen työyhdistelmien määrää automatisoimalla riskisimmät osat prosesseista.

Taloushallinnon tehtävät tunnistetaan sopivaksi kohteeksi automatisoinnille, koska siellä on paljon standardiprosesseja. Ostolaskuprosessissa nähdään laskujen käsittelyn automa-tisoinnissa paljon potentiaalia, mutta se asettaa paljon vaatimuksia myös kolmansille osa-puolille, kuten tavarantoimittajille, joiden täytyy lähettää lasku sellaisessa muodossa, että se voidaan käsitellä automaattisesti. Laskun käsittelyn automatisointi nähdään järkevänä aloittaa muutamasta suuresta tavarantoimittajasta, joilta tulee paljon laskuja. Näin toimi-malla ostolaskuprosessissa voidaan vielä kohtuullisella työmäärällä hallita yhteistyön vaatimaa kommunikaatiota.

Taloushallinnon prosessien automatisointi nähdään myös hyvänä tapana kehittää henki-löstön osaamista. Taloushallinnon asiantuntijoiden osallistuminen ohjelmistorobotiikka-hankkeisiin auttaa ymmärtämään suurempia kokonaisuuksia ja kehittämään kokonaisnä-kemystä end-to-end -prosessiin. Kehittämistyöhön osallistuminen ikään kuin pakottaa miettimään oman prosessin tehokkuutta suhteessa muihin, mikä palvelee organisaation kokonaisetua.

Tulevaisuuden mahdollisuudeksi nostettiin esimerkiksi todennäköisyyksiin perustuvien kirjausten tekeminen. Se ei sinänsä ole uutta, sillä aiemminkin monet päätökset ovat pe-rustuneet ihmisen tekemään arvioon. Jatkossa vain algoritmi tekee arvion, ei ihminen.

Hieman samasta asiasta on kyse nykyisin raja-arvoihin (engl. threshold) perustuvissa kir-jauksissa, mutta käytännössä nykyiset raja-arvot ovat lähinnä pyöristyseroja. Tulevaisuu-dessa voidaan nähdä automaattisia kirjauksia, joiden raja-arvot ohjelmistorobotti tai ko-neoppiminen osaa itse päätellä, jolloin jokaista raja-arvoa ei tarvitse määritellä jokaiselle kirjaustyypille erikseen.