3.3 Analyysi
3.4.6 Taloushallinnon automaatiohankkeiden organisointi
onko IT-infrastruktuuri organisaation omistuksessa vai esimerkiksi pilvipalvelussa, jol-loin kustannus muodostuu käyttöpohjaisesti. Lisäksi tulee harkita, toteutetaanko ohjel-mistorobotti virtuaalityöasemalla vai konkreettisesti jollakin organisaation tiloissa ole-valla työasemalla.
”Ehdottomasti vaatii jonkinlaisen tiimin, joka on tukena asioita tehtäessä. – – Hyvä että on monella taustalla tulevia ihmisiä, jotta tulee erilaiset näkemykset esiin. – – Tällaisella ryhmällä voidaan päästä budjettiesteiden yli.” (#8, Head of Robotics & Process Automation)
Haastateltavat kokivat, että uusien teknologioiden ydinosaaminen on tärkeää säilyttää or-ganisaatiossa. Ydinosaamisen lisäksi pidettiin tärkeänä, että organisaatiossa säilytetään hankintaosaaminen. Erityistä teknistä osaamista ei kuitenkaan voi luokitella ydinosaa-miseksi, koska se on ilman suurempia riskejä hankittavissa organisaation ulkopuolelta.
Ostaminen oman organisaation ulkopuolelta nostaa kehittämistyön hintaa, mutta siihen ei sisälly niin suuria riskejä kuin itse tekemiseen, koska se ei vaadi suuria alkuinvestointeja.
Ulkopuolelta on lisäksi mahdollista ostaa kapean osaamisalueen asiantuntemusta, mitä ei ole kannattavaa hankkia itselle.
Muutosjohtamisella nähdään olevan vaikutusta ohjelmistorobotiikkahankkeiden onnistu-miseen. Henkilöstön positiivisella osallistumisella muutoksen aikaansaamiseksi kutsu-taan termillä ”buy-in”, eli henkilöstö kokee muutoksen hyväksi asiaksi. Lisäksi koroste-taan yleisen automaatiotietouden merkitystä osana muutosprosessia.
”Isoin asia – – on mindsetin muutos henkilöstössä. Siinä on edistytty, mutta vielä paljon on tekemistä. Tulee vaatimaan jokaiselta paljon, että he ymmär-tävät, kuinka paljon toimenkuva tulee muuttumaan ja pysyy mukana muu-toksessa, he ovat arvokkaita jatkossakin. Kaikkien pitää ymmärtää perus-teet” (#4 Manager, Process Development)
” Financen puolella ei ostata tuoda asiaa oikein esiin, viestinnän kärki on siinä, mitä työtehtäviä voidaan poistaa.” (#7, Project Manager, RPA)
”Sit kun on yks projekti, jota voi markkinoida loppukäyttäjillä positiivisena muutoksena, niin se auttaa sitten kun tulee sitä pelottavaa muutosta. – – Buy-in saadaan, kun todetaan ettei tää ole mikään pääkonttoriprojekti.” (#7, Project Manager, RPA)
Taloushallinnon automaatioprojekti on liiketoimintaprosessien kehittämisprojekti. Esi-merkiksi yleisiä projektinjohtamisen malleja voidaan soveltaen hyödyntää myös auto-maatioprojekteihin. Martolan ja Santolan (1997) nelikentässä (Kuvio 3) automaatiopro-jektit ovat usein laajuudeltaan pieniä ja muutoksen syvällisyydeltään vähäisiä, sillä usein tarkoituksena ei ole uudistaa koko prosessia, vaan tehostaa nykyistä. Siksi
ohjelmistoro-botiikkaprojekteihin ei kannata soveltaa kovin raskasta projektimallia. Case-organisaa-tiossa ei ole olemassa yleistä hankemallia, mutta tiettyjä yhteneväisyyksiä on tunnistetta-vissa.
” – – pitää olla jokin idea tai pooli ideoita, mistä haarukoidaan, mitä lähetään toteuttaan. Tietysti siinä on joku businesscase aina – – sen [prosessin] pitää olla aikaa säästävä tai tosi riskialtis, että siihen kannattaa pari euroa laittaa”
(#1, Senior Manager, Financial Control)
Automaatioprojektin kulku noudattaa pääasiassa mallia. Se lähtee liikkeelle tarpeesta pa-rantaa prosessia. Ensin prosessi määritellään, jonka jälkeen asetetaan automatisoinnin ta-voitteet. Case-organisaatiossa on ollut kokemuksia projekteista, joissa suunnittelematto-muus tai epäselvät tavoitteet ovat johtaneet ongelmiin.
” – – missään nimessä ei kannata tehdä mitään ennen, kun oot käyny koko prosessin läpi. Se venyy ajallisesti ja budjetillisesti, kun tulee sellaisia ideoita kesken kehittämisen – – Mitä enemmän oli ihmisiä mukana, sitä enemmän alkoi tulemaan ideoita. Tärkeintä olisi projektin rajaaminen, et saadaan se jos-kus tuotantoon. (#7, Project Manager, RPA)
Projektijohtamisen kannalta pidetään tärkeänä, että projektilla on selkeät vastuualueet ja -henkilöt. Tätä näkemystä tukevat havainnot projektien toteutuksesta tutkimuksen aikana.
Epäselvät vastuuhenkilöt aiheuttavat viivästyksiä projektiin, jos kenelläkään ei ole sel-keää käsitystä siitä, miten toteutus etenee. Aluksi voidaan tehdä pilottiversio pienem-mässä mittakaavassa, jonka jälkeen se otetaan käyttöön laajemmin. Kehittämishankkeen aikana arvioidaan jatkuvasti prosessin teknistä soveltuvuutta, mutta sen ei pitäisi olla koko hanketta määrittelevä tekijä. Ilmiön ollessa henkilöstölle uusi, selkeän projektimal-lin puuttuminen voi nostaa kynnystä kehitysaloitteiden tekemiselle. Organisaatiossa tulisi myös viestiä, miten muut projektit ovat onnistuneet ja mitä niistä voitaisiin oppia.
”Pitää olla selkeä omistaja sillä projektilla kuka sitä vetää ja mitä tavoitellaan.
(#2 Expert, Business Analysis)
”Niistä [projekteista] on oltu hiljaa, jotka ei oo lähtenyt lentoon. Olis hyvä, että nämäkin tuotaisiin kaikkien tietoon, koska niistä voitaisiin sitten oppia, että tällaisissa on ehkä tavoiteltu liikaa tai prosessi ei ole ollut kypsä.” (#3, Director, Financial Control)
IT-organisaation tukea pidetään tärkeänä elementtinä hankkeiden onnistumiselle. Hank-keen tulee olla case-organisaation vetämä, mutta tekninen toteutus vaatii myös IT:n tukea.
IT:n tehtävänä on myös varmistaa tietoturvallisuus ja tarjota automatisoinnin työkalut.
”Sisältö tulee meiltä. IT tukee ja kertoo mitä RPA on. Puhutaan vahvasti jär-jestelmäasiasta. He ei voi ottaa kantaa siihen onko tää hyvä vai huono pro-sessi.” (#1, Senior Manager, Financial Control)
Case-organisaatiossa automatisoidaan ohjelmistorobotiikalla pääkirjanpitoprosessin kontrollia, joka on tehty aiemmin ulkoistettuna organisaation BPO -organisaatiossa. Pro-sessi lähti liikkeelle yksittäisen henkilön aloitteesta. Projektin alkuvaiheessa suunnitte-luun ja määrittelyn osallistui paljon henkilöitä, ja ohjelmistorobottiin liitettiin uusia toi-minnallisuuksia. Tämän prosessin automatisoinnin suunnittelu on onnistunut hyvin, koska se tehtiin yhteistyössä ydinorganisaation ja sen itse valitseman ohjelmistoyrityksen kanssa yhteistyössä. Kun prosessi on automatisoitu, prosessinomistajaksi vaihdetaan ydinorganisaatio BPO-organisaation tilalle eli prosessi siirretään ulkoistuskumppanilta ydinorganisaatioon. Automaation onnistuminen siis mahdollistaa prosessin siirtämisen BPO-organisaatiolta ydinorganisaatiolle. Automaatio myös vähentää prosessiin sitoutu-nutta työvoimaa, jolloin työvoimakustannusten merkitys vähenee ja työn fyysisellä sijain-nilla ei ole enää niin suurta merkitystä. On kuitenkin muistettava, että automatisoitu pro-sessin vaatii ihmistä edelleen valvomaan sekä kehittämään prosessia. Toisaalta automaa-tio mahdollistaa myös raportoinnin kehittämisen ja automatisoinnin yhteydessä paran-nettu raportointi parantaa taloushallinnon tuottamaa arvonlisää.
Taloushallinnon kehityshankkeiden toteuttaminen on tarkoituksenmukaista organisoida keskitettyyn alaorganisaatioon taloushallinnon ydinorganisaation alle (luku 2.5.2). Haas-tateltavien näkemykset osaamiskeskuksen kannattavuudesta vaihtelevat. Suuri osa kokee osaamiskeskuksen hyväksi malliksi, vaikka siinä nähdään myös riskejä. Osaamiskeskusta puolletaan kustannustehokkuudella ja sillä, että projektien toteutus saadaan omiin käsiin.
Osa haastateltavista perusteli organisaation kokonaisetua sillä, että ydinorganisaation kannattaa toteuttaa tai vähintäänkin osallistua vahvasti itse hankkeiden toteuttamiseen, koska he itse tuntevat omat prosessinsa parhaiten.
”Mä haluaisin, että meillä olis tällanen COE. – – pystyttäis nopeammin ja halvemmalla tekemään skriptejä. – – Siellä olis niitä tekijöitä” (#5, Senior Manager, Robotics & automation)
” – – sen [COE:n] puolesta oon koittanut lobata. – – [prosessinomistajilla]
on hyvä tuntemus siitä mitä pystyy ylipäänsä tekemään. Ne pystyy näke-mään mihin automaatiota voi käyttää ja se on se paras porukka myös spek-saamaan. – – COE olis kustannustehokkain ratkaisu automaatioon.” (#2, Ex-pert, Business Analysis)
”[COE:n etuja ovat] kaikki skaalauseduista lähtien. Ainut mikä on hankalaa, on se, et me eletään täällä omissa siiloissa. Keskustelu COE:n ja päättävän pään välillä on hankalaa, jos ei tehdä jotakin foorumia, jossa keskustellaan.”
(#7 Project Manager, RPA)
Osaamiskeskuksen riskejä on sen siiloutuminen siten, että viestintä funktioihin on heik-koa. Kun ydinorganisaatio ja prosessinomistajat pidetään kehityshankkeissa mukana, tu-lee prosessin kokonaistehokkuus huomioitua paremmin. Toisaalta on huomioitava, että myös osaamiskeskuksen on maksettava itsensä takaisin. Osan haastateltavista nosti esiin sen, että osaamiskeskus vaatii ensin paljon valmiita ideoita, ennen kuin se kannattaa pe-rustaa.
” On tiettyjä osa-alueita, joille COE kannattaa rakentaa. – – Siinä on yks iso riski et jätetäänkö liikaa asioita COE:n ratkaistavaksi, kun pitäis koko automaatioas-tetta nostaa. Ei liikaa haluttais sellaisia profiileja, että toiset ymmärtää työkalut ja toiset prosessit. Tarvittais niitä, jotka ymmärtää molemmat. COE on hyvä ajatus-malli, mutta se on nopeasti tukossa. – – Pitäisi päästä nopeampaan toimitusmal-liin, ja COE ei oo välttämättä siinä oikea tapa” (#3 Director, Financial Control)
”Iso tiimi kerryttää kustannuksia myös. Jos palkataan 5-10 devaajaa, niin pi-täis olla pitkä backlog aihoita, mitä sillä teetetään, ennen kun se maksaa edes itsensä pois.” (#8, Head of Robotics & Process Automation)
Monet ohjelmistorobotiikkaan investoineet yritykset ovat organisoineet hankkeiden to-teutuksen osaamiskeskuksiin. Kun kehityshankkeet ovat hajautettuina niin, että osa pro-jekteista toteutetaan BPO -kumppanin toimesta ja osa ydinorganisaation toimesta, kokonaiskuva muodostuu epäselväksi, eikä se palvele organisaation kokonaisetua. BPO -kumppanin toteuttaessaan omia automaatiohankkeita ydinorganisaation näkyvyys ulkois-tettuihin prosesseihin heikkenee. Osaamiskeskus mahdollistaisi uudenlaisen osaamisen kehittämisen palvelukeskuksessa. Esimerkkinä haastatteluissa mainittiin Process analyst -rooli, joka on keskeinen rooli osaamiskeskusmallissa (Kuvio 4 ja Taulukko 1).
”Pitäis mennä platform -ajattelun kautta, että tekninen kyvykkyys hankittais [case-yrityksen] tasolla ja mahdollisimman moni pääsee hyödyntää sitä. Ei niin et jokainen hommaa vähän jotain omaa robottia. (#5, Senior Manager, Robotics & automation)”
Organisaatiossa halutaan uusia kehityshankkeita liikkeelle nopeasti ja paljon. Nykyinen projektihankemalli ei kuitenkaan mahdollista joustavia ja nopeita kokeiluja. Prosessieks-perteillä ei ole mahdollisuuksia, eikä usein aikaakaan lähteä ideoimaan parannuksia omin päin. Hidasteeksi koetaan toisaalta myös suunnitteluprosessin kesto.
”Financessa haasteena on, et mennään ylisuunnittelun puolelle. Joitakin ai-hioita kannattaisi lähtee koittaa ja tekee ja oppia sitä kautta. – – Enemmän protoilua ja pilotointia suunnittelun ja pohtimisen sijaan.” (#8, Head of Ro-botics & Process Automation)
Prosessieksperttien hiljainen tieto tulisi hyödyntää tehokkaasti. Ratkaisua voisi olla auto-maatiokoulutus, jossa asiantuntijoille annetaan tietoa, mahdollisuudet ja työkalut proses-siensa kehittämisen ideoimiseen. Testiautomaatiotyökalut mahdollistaisivat joustavat ko-keilut, joilla ideoitansa voisi kokeilla ennen kuin ne viedään varsinaiseen toteutukseen.
Jotta kynnys kokeilemiseen pidetään matalana, voidaan testausta tehdä linjaorganisaa-tiossa tiimikohtaisesti ilman erillistä hyväksyntää. Haastateltavat olivat yksimielisiä siitä, että prosessinomistajien pitäisi osallistua prosessien automatisointiin. Prosessinomistajat tuntevat prosessinsa parhaiten, joten heidän osallistumisestansa on hyötyä.
”Joku voi tuntea hyvin templatet, dokumentit ja järjestelmäympäristöt, mut sit vaan ei ymmärrä tai osaa et täällä on järjestelmä, joka voi käyttää näitä samalla tavalla kuin ihminenkin.” (#6, Senior Process Manager)
Haastatteluissa nousi esiin myös työntekijöiden mahdollisuudet oman osaamisensa kehit-tämiseen sekä työtyytyväisyyden kohottamiseen. Lisäksi prosessin kehitkehit-tämiseen osallis-tuminen ylipäänsä on hyödyllistä prosessinomistajille, sillä se ikään kuin pakottaa työn-tekijät miettimään prosessinsa työtapojen tarkoituksenmukaisuutta sekä asettaa heidät haastamaan työtapojensa järkevyyttä, mikä voi jälleen nostaa uusia prosessin tehokkuutta parantavia ideoita. Enemmistö haastateltavista on yhtä mieltä siitä, että aloite ohjelmisto-robotiikan hyödyntämiseen jossakin tietyssä prosessissa tulisi tulla henkilöstöltä, mutta kaikki eivät nähneet sitä tärkeänä. Kuitenkin siitä oltiin täysin yksimielisiä, että prosessin omistajan tulee osallistua hankkeen suunnitteluun ja toteutukseen.
”Kärjistetysti sanottuna ainut oikea lähestymistapa on se, että aloite lähtee henkilöstöstä ja niiltä, jotka tuntevat sen tehtävän ja osaavat speksata sen, että tällainen säästömahdollisuus olisi.” (#2, Expert, Business Analysis)
”En koe et on tärkeää mistä päin aloite tulee. – – Voidaan lähteä alhaalta ylös tunnistamaan caseja ja ihmiset nostaa lippua et miks teen tällästä työtä.
Top down lähestymistapa on se et lähetään systemaattisesti perkaamaan pro-sessit ja workshoppien kautta kaivetaan info ulos. – – Osalle organisaatiosta voi antaa hyvän kuvan pelkästään siitä mitä ne meidän prosessit ylipäänsä olikaan” (#8, Head of Robotics & Process Automation)