Ohjelmistorobotiikka
Markus Miettinen
Pro gradu -tutkielma
Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede
Heinäkuu 2017
i ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Kuopio Tietojenkäsittelytieteen laitos
Tietojenkäsittelytiede
Opiskelija, Markus Miettinen: Ohjelmistorobotiikka Pro gradu -tutkielma, 50 s.
Pro gradu -tutkielman ohjaajat: FT Virpi Hotti Heinäkuu 2017
Prosessien kehittäminen ja virtaviivaistaminen ohjelmistorobotiikan avulla edellyttää organisaatioilta ja niiden työtekijöiltä kyvykkyyttä konfiguroida ohjelmistorobotteja tai ainakin ymmärrystä siitä, mitä ohjelmistorobottien konfigurointi tarkoittaa. Tässä tutkielmassa konstruoitiin malleja (esimerkkitoteutus sekä toteutusprosessikonstruktio ja hyödyntämisarviokonstruktio), joiden avulla pyritään lisäämään ymmärrystä siitä, mitä ohjelmistorobottien konfiguroinnilla tarkoitetaan. Konstruktiot kytketään aikai- sempaan kirjallisuuteen ohjelmistoroboteista, joten tutkielmassa tarkastellaan, mitä ohjelmistorobotiikasta on kirjoitettu ei-tieteellisesti tai tieteellisesti.
Yhteenvetona voidaan todeta, että ohjelmistorobotiikassa on potentiaalia nousta mer- kittäväksi teknologiaksi osaksi jokapäiväistä arkea, ja sitä se jo joissain organisaa- tioissa tänäkin päivänä. Ohjelmistorobotiikan hyödyntämiseen löytyy lähes jokaisesta organisaatiosta jokin prosessi. Lisäksi todettiin, että yksinkertaisen ohjelmistorobotin teko on helppoa ja jopa yksinkertaista robottia voi hyödyntää oikeissa sovelluksissa sekä ohjelmistorobotin käyttöön siirtymisestä saavutetaan suuria etuja organisaatioon hyväksi. Lopuksi pohdittiin, että uusien teknologioiden käyttöönotossa on omat ris- kinsä, mutta jos organisaatio on valmis ottamaan riskit ja projekti onnistuu, voi siitä saatavat hyödyt olla todella merkittävät sekä taloudellisesti että toiminnallisesti.
Avainsanat: Ohjelmistorobotti, koneoppiminen, automatisointi, automatisointikriteeri, UiPath
ACM-luokat (ACM Computing Classification System, 2012 version): Surveys and overviews, Cognitive robotics, Robotic planning, Robotics
ii UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Kuopio School of Computing
Computer Science
Student, Markus Miettinen: Robotic Process Automation Master’s Thesis, 50 pages
Supervisors of the Master’s Thesis: PhD Virpi Hotti July 2017
Process development and simplification with software robotics requires ability to con- figure, or at least understanding how software robotics logic works. In this research, we constructed models for software robotics implementation and utilization, of which are used to increase understanding what configuring software robotics is. Construc- tions are bound to scientific and non-scientific literature about software robotics.
In conclusion software robotics has potential to be a remarkable technology in daily tasks in many organization, in some organizations software robotics already is a part of daily work. Nearly every organization has a process where software robotics can be used. In addition, we can say that simple software robot is easy to configure and even a simple software robot can be used in real applications, also even a simple software robot can create huge value to organization. Finally, discussed, if organization is ready to take a risk with a new technology and project success, its benefits can be huge to the organization compared to risks organization have to take in order to try out the new technology, both economically and functionally.
Keywords: Robotic process automation, machine learning, automation, automation criteria, UiPath.
CR Categories (ACM Computing Classification System, 2012 version): Surveys and overviews, Cognitive robotics, Robotic planning, Robotics
iii
Esipuhe
Tämä tutkielma on tehty Itä-Suomen yliopiston Tietojenkäsittelytieteen laitokselle ke- väällä 2017.
Iso kiitos Virpi Hotille, joka on jaksanut kannustaa tutkielman tekemiseen venyneestä aikataulusta huolimatta.
iv
Sisällysluettelo
1 Johdanto ... 5
2 Ohjelmistorobotiikan asemointi ... 7
2.1 Ohjelmistorobotiikan sovelluskohteet ... 8
2.2 Ohjelmistorobotiikan maturiteetti ... 12
3 Ohjelmistorobotiikan soveltuvuuden arviointi... 14
3.1 Prosessien automatisointikriteerit ... 14
3.2 Suosituksia ohjelmistorobotiikan hyödyntämiseksi ... 18
3.3 Ohjemistorobotiikan tuottavuus ... 20
4 Ohjelmistorobotin luonti sekä toteutusprosessikonstruktio ja hyödyntämisarviokonstruktio ... 22
4.1 Robotin luonti... 23
4.2 Robotin ”ajaminen” tai ”tuotantoon vienti” ... 28
4.3 Toteutusprosessikonstruktio ... 30
4.4 Hyödyntämisarviokonstruktio ... 33
5 Teknologisten trendien, kuten ohjelmistorobotiikka, pohdintaa ... 39
5.1 Organisaatioiden suhtautuminen trendeihin ... 40
5.2 Trendien lähestyminen ... 42
5.3 Trendien vaikutus organisaatioon ... 44
6 Yhteenveto ... 46
Lähteet ... 48
5
1 Johdanto
Prosessien kehittämisen uusin tulokas on ohjelmistorobotiikka, joka tarjoaa organisaa- tioille virtuaalista työvoimaa ja joka ”muodostuu ohjelmistoista, jotka suorittavat mää- ritettyä prosessia aivan kuin ihmiset käyttäen prosessia tukevia järjestelmiä aivan kuin ihmiset” (Haikonen, 2016). Ohjelmistorobotiikka (robotic process automation, RPA) voidaan määritellä toteutusteknisemmin tarkoittamaan ”ohjelmistoa, joka matkii ihmi- sen tekemää työtä toistuvissa prosesseissa käyttäen samaa käyttöliittymää ja samoja ohjelmistosovelluksia kuin ihminen” (Eera, 2016). Vaikka ilmaisun ohjelmistorobotii- kan mielleyhtymä on fyysinen robotti, joka vaeltelee ympäri toimistoa suorittamassa ihmisten tehtäviä, niin termillä tarkoitetaan ihmisten suorittamien (palvelu)tehtävien automatisointia (Lacity et al., 2015a) - jopa työntekijät itse voivat konfiguroida robotin esimerkiksi transaktioiden prosessointiin, datan manipulointiin tai kommunikointiin.
Prosessien kehittäminen ja virtaviivaistaminen ohjelmistorobotiikan avulla edellyttää organisaatioilta ja niiden työtekijöiltä kyvykkyyttä konfiguroida ohjelmistorobotteja tai ainakin ymmärrystä siitä, mitä ohjelmistorobottien konfigurointi tarkoittaa. Tässä tutkielmassa konstruoidaan malleja, joiden avulla pyritään lisäämään ymmärrystä siitä, mitä ohjelmistorobottien konfiguroinnilla tarkoitetaan. Oleellisena osana tieteel- listä konstruktiivista tutkimusta on, että konstruktiot kytketään aikaisempaan kirjalli- suuteen ohjelmistoroboteista ja sen vuoksi tässä tutkielmassa tarkastellaan, mitä ohjel- mistorobotiikasta on kirjoitettu ei-tieteellisesti tai tieteellisesti. Kun tehdään koehakuja Googlesta ja Google Scholarista sekä Scopus-tietokannasta (hakupäivä 20.12.2016), niin havaitaan, että Googlessa ja Google Scholarissa otsikkohaulla intitle:”robotic process automation” Google antaa hakutuloksia 8860 ja Google Scholar yhdeksän.
Scopuksessa otsikkohaulla TITLE(”robotic process automation”) hakutuloksia on yksi.
Tässä tutkielmassa päädyttiin tarkastelemaan ensisijaisesti Google Scholarin hakutu- loksia ja niissä esiintyviä muita lähteitä. Kun Google Scholarin artikkeleita käy läpi hakulausekkeella ”robotic process automation”, niin professorit Lacity ja Willcocks ovat tehneet useita julkaisuja RPA:sta ja heidän tuotantonsa muodostaa pohjan tälle
6 tutkielmalle. Tutkielmassa käsitellään ainoastaan ohjelmistorobotiikkaan liittyviä ha- kutuloksia, joissa ilmenee ”robotic process automation” eli tutkielmassa ei käsitellä esimerkiksi ”software robotics” tai ”smart process automation” asioita, vaikka niiden- kin suomennokset ovat ohjelmistorobotiikka.
Luvussa 2 tarkastellaan, miten ohjelmistorobotiikka asemoituu ja missä sitä on käy- tetty erilaisten esimerkkien kautta. Lukuun 3 on koottu ohjelmistorobotiikan soveltu- vuuden arviointiin liittyviä kriteereitä sekä suosituksia ohjelmistorobotiikan hyödyn- tämiseksi. Jotta ymmärretään, mitä ohjelmistorobotti käytännössä tarkoittaa, niin tut- kielmassa tehdään ohjelmistorobottiesimerkki ja toteutusprosessikonstruktio sekä ar- vioidaan hyödyntämiskonstruktiota (Luku 4). Ohjelmistorobotin tekemisessä käyte- tään UiPath-nimistä ohjelmistoa (UiPath, 2017), joka on yksi johtavista ohjelmistoro- bottien konfigurointiohjelmistoista ja siitä on saatavissa kokeiluversio. Luvussa 5 ar- vioidaan nykyisiä teknologisia trendejä ja niiden vaikutusta projekti tekemiseen sekä organisaatiotasolla. Yhteenveto-luvussa kiteytetään tutkielmassa käsitellyt asiat ja teh- dyt konstruktiot sekä esitetään mahdollisia jatkotutkimusaiheita.
7
2 Ohjelmistorobotiikan asemointi
Ohjelmistorobotiikka kuuluu kognitiiviseen laskentaan ja sen avulla pyritään automa- tisoimaan tai korvaamaan pääasiassa ihmisen ja koneen vuorovaikutuksessa tapahtu- vat rutiininomaiset työtehtävät. ”Tietotyön automatisointia pidetään eräänä lähivuo- sien merkittävimmistä murroksista ja ohjelmistorobotiikan avulla sitä voidaan edistää ja nopeuttaa. Eeran tutkimuksen mukaan automaation avulla voitaisiin korvata jopa 36
% suomalaisten työpanoksesta, jolloin ihmiset voisivat rutiinien sijaan keskittyä mie- lekkäämpiin työtehtäviin" (Eera, 2015a-b).
Automaation, kuten ohjelmistorobotiikan käyttöönotto, voi kuulostaa siltä, että se joh- taa ihmisten irtisanomisiin ja työpaikkojen vähenemiseen, mutta tutkimuksissa (Lacity et al., 2015a-d) on osoitettu, että näin ei ole. Ohjelmistorobotiikkaa tarvitaan hoita- maan tämän päivän haasteet suurien datamassojen käsittelyssä, joita ihminen ei vält- tämättä järkevässä ajassa pysty käsittelemään(Lacity et al., 2015b).
Yleensä ohjelmistorobotiikkaa kokeilevat IT-saralla valveutuneet yritykset ovat koke- neet, että ohjelmistorobotiikan avulla samassa ajassa tehtyjen transaktioiden määrä on merkittävästi suurempi verrattuna ihmistyövoimaan, joka johtaa kustannussäästöihin, laadun parantumiseen ja seurattavuuteen.
Ohjelmistorobotti on helppo konfiguroida ja ei tarvitse ohjelmointitaitoja (Dunlap &
Lacity, 2017). Helppouden takia ohjelmistorobotiikan potentiaali on suuri ja siksi tut- kielman laatija uskoo, että muutaman vuoden kuluttua ohjelmistorobotiikka on paljon isompi juttu kuin se on tänä päivänä.
Ohjelmistorobotiikkaa myydään jo usean yrityksen toimesta, kuten CGI (2017), Af- fecto (2017), KnowIT (2017) ja OpusCapita (2017). He kertovat hyvin vähän omista tuotteistaan verkkosivuilla ja mitä palvelut ne pitävät sisällään. Ohjelmistorobotiikka- ohjelmistoja on myös jonkin verran saatavilla kuten BluePrism (2017) ja UIPath (2017). Suurin osa näistä on maksullisia, varsinkin, jos niitä haluaa hyödyntää johon- kin. Luvussa 4 tehty ohjelmistorobottiesimerkki on tehty UIPath Community Editi-
8 onilla, joka on ilmaisversio kyseisestä ohjelmistosta. Community Edition ei pidä sisäl- lään kaikkia toiminnallisuuksia ja laajennoksia, jotta sitä voisi välttämättä käyttää te- hokkaasti.
Luvussa 2 avataan ohjelmistorobotiikan käyttökohteita (Luku 2.1) ja luvussa 2.2 jat- ketaan ohjelmistorobotiikan maturiteetin arvioinnilla.
2.1 Ohjelmistorobotiikan sovelluskohteet
Kun ohjelmistorobotiikan esimerkkejä haetaan Googlesta (intitle:ohjelmistorobotti), niin löydetään esimerkiksi seuraavia toteutettuja käyttötapauksia:
− Birminghamin yliopistollinen sairaala valitsi ohjelmistorobotiikan korvaa- maan kuormittavan ja kalliin manuaalisen työn, jossa lähetteitä, testituloksia ja sairaskertomuksia siirretään kansallisen- ja sairaalan järjestelmän välillä. (Di- gital Workforce, 2016)
− HSI (Helsingin Seudun Isännöitsijät) on ottanut ohjelmistorobotit käyttöön esi- merkiksi isännöitsijäntodistusten lähettämiseen. Asiakaspalvelu keräsi aiem- min tiedot järjestelmistä käsin ja toimitti isännöitsijäntodistuksen kirjanpitä- jälle ja isännöitsijälle tarkastettavaksi. Jos kaikki oli kunnossa, todistus toimi- tettiin asiakkaalle laskun kanssa. Asiakaspalvelu toimii enää laadunvalvojana.
Se tarkistaa ennen laskuttamista ja todistuksen lähettämistä, että kaikki on kun- nossa. (Kolehmainen, 2016)
− Ohjelmistorobotit auttavat toimiston työntekijöitä Postin henkilöstön palkko- jen laskennassa. Ohjelmistorobotit hoitavat öisin rutiinitöitä, joita palkanlaski- jat laskivat ennen käsin. (Vasama, 2016)
− Valtion talous- ja henkilöstöhallinnon palvelukeskus (Palkeet) automatisoi teh- täviä ostolaskujen käsittelyssä sekä palvelussuhteen tietojen tarkastamisessa ja tallennuksessa. (Palkeet, 2016)
− Monetrassa ohjelmistorobotit tekevät rutiininomaisia tarkastuksia. Kun ne huomaavat virheen, työ siirtyy taloushallinnon ammattilaisen hoidettavaksi.
(Moliis, 2016)
9 Lacityn tutkimuksissa on havaittu, että työelämä muuntautuu yhä enemmän siihen suuntaan, jossa ihmisistä sekä roboteista koostuvat tiimit toimivat yhdessä saavuttaak- seen asetetut tavoitteet. Ohjelmistorobotiikan lisäksi on olemassa kognitiivisuutta ko- rostavat työkalut kuten IMB Watson. Yhdistämällä näitä teknologioita ihmiset voivat hyödyntää robotteja tekemään avustavia tehtäviä, jotta voivat itse keskittyä tekemään tehtäviä, joihin robotit eivät kykene hyödyntäen robottien tuottamaa tietoa (Lacity &
Willcocks, 2016). Ohjelmistorobotiikka voi olla johdolle lähetetystä automatisoidusta sähköpostin lähetyksestä aina yksinkertaisiin salasanan resetointiin tai käyttäjätilien aukaisemiseen liittyvää automatisointia (Fung, 2014). Lisäksi ohjelmistorobotiikan konkreettisia esimerkkejä ovat ”raporttien muodostaminen eri tietolähteistä, käyttöliit- tymien toiminnallisuustestaus lokalisoinnin jälkeen ja tilausten käsittely” (Haikonen, 2016).
Jos tarkastellaan robotiikkaa tutkimuksessa (Manyika et al., 2017), on mielenkiintoista nähdä kuinka suuret potentiaalit automatisointi pitää sisällään (Kuva 1). Tutkimuksen mukaan jopa 5 % ammateista voisi olla automatisoitavissa. Tutkimuksessa koroste- taan, että 60 % ammateista sisältää 30 % automatisoitavaa työtä. Tuo on todella mer- kittävä osuus, jos sitä verrataan esimerkiksi keskimääräisen suomalaisen normaaliin viikkotuntimäärään (37,5 t/vk), joka tekee noin 11 viikkotuntia.
10
Kuva 1. Ammattien tekninen automatisointipotentiaali (mukaillen Manyika et al., 2017).
Ohjelmistorobotiikka kuitenkin on selkeästi mukana mullistamassa nykyihmisen ar- kea yhdessä robotiikan kanssa. Tutkimuksessa (Manyika et al., 2017) on käyty läpi automatisoinnin vaikutuksia eri ammattiryhmiin (Taulukko 1) sekä kyseisen ammatti- ryhmän automatisointipotentiaali. Suurin osa automatisointipotentiaalista on robotii- kalla toteutettavissa ja osittain ohjelmistorobotiikalla. Esimerkiksi finanssi- ja palve- luala hyödyntävät ohjelmistorobotiikkaa.
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
Tekninen automatisointi potentiaali
Ammatit
11
Taulukko 1. Eri ammattiryhmien automatisointi potentiaali USA:ssa (mukaillen Manyika et al., 2017).
Ammattiryhmä Automatisointi
potentiaali
Majoitus- ja ravitsemuspalvelut 73 %
Valmistus 60 %
Maanviljely 58 %
Kuljetus ja varastointi 57 %
Vähittäiskauppa 53 %
Kaivosteollisuus 51 %
Muut palvelut 49 %
Rakennusala 47 %
Palveluala 44 %
Tukkukauppa 44 %
Finanssi- ja vakuutusala 43 %
Taide ja viihde 41 %
Kiinteistönvälitys 40 %
Hallinto 39 %
Sosiaali- ja terveyspalvelut 36 %
Informaatio 36 %
Ammattilaiset 35 %
Johto 35 %
Koulutus 27 %
12
2.2 Ohjelmistorobotiikan maturiteetti
Tutkielman laatija havaitsi tutkielmaa tehdessä, että ohjelmistorobotiikka elää vielä vaiheessa, jossa sen mahdollisuudet ovat vielä osittain pimennossa. Ohjelmistorobo- tiikkaa on tutkittu todella vähän, jos vertaa esimerkiksi robotiikkaan. Toisaalta robot- teihin viitattiin kirjallisuudessa ensimmäisen kerran jo 1920-luvulla (Manyika et al., 2017), jolloin puhuttiin tehdas-androideista. Ohjelmistorobotiikka on ollut olemassa makrojen muodossa jo pitkään, mutta ne eivät ole olleet niin pitkälle vietyjä kuin tä- män päivän ohjelmistorobotit. Vastaava ideologia nykyisillä ohjelmistoroboteilla kui- tenkin on, mutta ne kykenevät paljon suurempaan määrään erilaisia operaatioita.
Ohjelmistorobotiikan osalta ei ole vielä tehty yleisiä arkkitehtuurimalleja kuten Aa- kash & Muhammad (2016) tutkimuksessa, jossa tutkitaan robotiikan arkkitehtuurimal- leja. Robotiikan osalta vastaavia tutkimuksia löytyy paljon, mutta ohjelmistorobotii- kasta ei tutkielmaa tehdessä ollut vielä vastaavia.
Dunlap & Lacity (2017) arvioivat, että ohjelmistorobotiikka osuu Gartnerin hype- käyrällä (Kuva 2) teknologinen alku (Technology Trigger) vaiheessa (tuolloin ei pu- huttu vielä ohjelmistorobotiikasta vaan Claim Automated Engine), jossa teknologia on vielä nousemassa ja saa osakseen vielä suurta kiinnostusta, mutta siitä ei vielä uskota välttämättä tulevan pysyvä teknologia. Muut hypekäyrän vaiheet ovat seuraavat (Gart- ner, 2017):
− Paisutetun odotuksen huippu (Peak of Inflated Expectations), jolle on omi- naista julkisuuden ja raportoinnin kiihko, mikä kehittää epärealistisia odotuk- sia muutamia tuotteita tämän vaiheen aikana
− Pettymyksen kuoppa (Trough of Disillusionment). Kiinnostus laskee ja toteu- tuksien toimitus epäonnistuu. Sijoitukset jatkuvat vain, jos tarjoajat kehittävät ja panostavat tuotteeseen.
− Valistuksen mäki (Slope of Enlightenment), jossa jotkut organisaatiot jatkavat investoimista teknologiaan, lopulta ymmärtäen etuja ja luoden käytännöllisen ja hyödyllisen tuotteen.
− Tuottavuuden tasanne (Plateau of Productivity). Toteutukset alkavat onnistua ja suuressa linjassa saadaan hyviä lopputuloksia.
13
Kuva 2. Gartnerin hypekäyrä (mukaillen Dunlap & Lacity, 2017).
Tutkielman laatijan mukaan ohjelmistorobotiikan maturiteetti on tällä hetkellä jo vai- heessa ”Tuottavuuden tasanne”, koska ohjelmistorobotiikkaa myydään jo kaupallisesti eri toimijoiden toimesta. Lisäksi ohjelmistorobotiikka-ohjelmistojen saralla on jo kil- pailua valmistajien kesken. Uutisointi antaa välillä ymmärtää, että olisimme ”Paisute- tun odotuksen huippu” -vaiheessa, mutta ohjelmistorobotiikkaa tarjoavien ohjelmisto- jen maturiteetti on jo korkeampi.
14
3 Ohjelmistorobotiikan soveltuvuuden arviointi
Kun organisaatio miettii prosessien automatisointia, niin prosesseja voidaan tarkastella esimerkiksi automatisointikriteerien avulla (Luku 3.1). Lisäksi voidaan antaa suosi- tuksia ohjelmistorobottien hyödyntämiseen (Luku 3.2), tarkastella liiketoiminnan hyö- tyjä esimerkiksi pääoman tuottoprosentilla (Luku 3.3) ja arvioida ohjelmistorobotiikan merkitystä ammattiryhmittäin.
3.1 Prosessien automatisointikriteerit
Kun arvioidaan sitä, milloin prosessi kannattaa automatisoida, niin voidaan tarkastella työn määrää suhteessa työn vaikeusasteeseen (Kuva 3). Yksinkertainen prosessi on määritelty niin, että ihminen pystyy suorittamaan sen muutamassa minuutissa. Moni- mutkaisen prosessin määritelmän mukaan suorittaminen kestää enemmän kuin 30 mi- nuuttia. Esimerkiksi Telefonica O2 on pääsääntöisesti automatisoinut yksinkertaisia prosesseja, jotka sisältävät noin 1000 transaktiota, niin he sanovat, että myös moni- mutkaisia prosesseja voidaan automatisoida, jos siitä koituvat kustannussäästöt ovat riittävän isot. (Lacity et al., 2015a)
15
Ty ön m ää rä
Työn vaikeusaste
Korkea
Korkea
Matala
Matala
Kuva 3. Telefonica O2: sen arvio prosessin automatisoitavuuden soveltuvuudesta (mukaillen La- city et al., 2015a)
Fungin (2014) tutkimuksessa on tunnistettu joukko automatisoitavia prosessiesimerk- kejä ja työnkulkuominaisuuksia ITPA:lle. ITPA (Information Technology Process Au- tomation) on Fungin (2014) mukaan ohjelmistorobotiikan synonyymi. Fungin (2014) tutkimuksessa on tunnistettu kirjallisuudesta ja haastatteluja tekemällä yhdeksän eri- laista työnkulkuominaisuutta, jolloin IT-prosessiautomatisointi (Information Techno- logy Process Automation, ITPA) eli ohjelmistorobotiikan hyödyntäminen kannattaa:
− Suuri määrä transaktioita (High volume of transactions)
− Suurta arvoa tuottavat transaktiot (High value of transactions)
− Usein toistuva pääsy useaan järjestelmään (Frequent access to multiple sys- tems)
− Vakaa ympäristö (Stable environment)
− Vähäinen inhimillinen interventio/väliintulo (Limited human intervention)
− Vähän poikkeustilanteiden käsittelyä (Limited exception handling)
− Virhealttiit manuaaliset IT-prosessit (Manual IT processes prone to errors or re-works)
− Helposti jaettavat IT-prosessit (Ease of decomposition into clear IT processes)
16
− Selkeä käsitys nykyisistä manuaalisista kustannuksista (Clear understanding of current manual costs)
Seuraavaksi esitellään Fungin (2014) esittämät työnkulkuominaisuudet. Jollei lause tai virketasolla ole merkitty muuta lähdettä, niin esittelyt perustuvat Fungin (2014) artik- keliin.
Suuri määrä transaktioita. IT-prosessityönkulut tai niiden transaktiot, joita on run- saasti, ovat hyviä kriteereitä ITPA:lle. Suurimääräiset transaktiot ovat yleensä rutiineja ja toistettavia sekä helposti perusteltavissa, etenkin jos ne ovat yksiselitteisiä ja hel- posti automatisoitavissa (Slaby, 2012).
Suurta arvoa tuottavat transaktiot. IP-prosessityönkulut, joiden transaktioiden määrä ei ole suuri, mutta ne tuottavat arvoa, sopivat ITPA:lle. Esimerkiksi automatisointi vä- hentää kustannuksia 24/7-palveluissa, joissa automatisoinnin puute aiheuttaa merkit- täviä henkilökustannuksia etenkin loma-aikoina ja viikonloppuina (Sutherland, 2013).
Usein toistuva pääsy useaan järjestelmään. Prosessit, jotka vaativat usein pääsyä use- aan järjestelmään, ovat hyviä kohteita automatisoinnille. ITPA voi pienentää kirjautu- misista aiheutuneita virheitä ja parantaa suorituskykyä, koska ohjelmistorobotti ei tee virheitä kirjautumisien yhteydessä (Sutherland, 2013).
Vakaa ympäristö. Jos IT-prosessi toimii vakaassa ympäristössä, se sopii ITPA:lle. Jos IT-prosessi pysyy muuttumattomana 12-18 kuukautta, silloin IT-prosessi on sopiva ITPA:lle (Slaby, 2012).
Vähäinen inhimillinen interventio/väliintulo. IT-prosessit, jotka eivät vaadi inhimil- listä interventiota, voivat olla hyviä kandidaatteja automatisoinnille (Slaby, 2012).
Myös ne IT-prosessit, jotka vaativat inhimillistä interventiota, voivat sopia ITPA:lle, jos esimerkiksi tekoäly mahdollistaa ITPA:lle inhimillisen ajattelun ja subjektiivisuu- den (Sutherland 2013).
Vähän poikkeustilanteiden käsittelyä. Automatisoitavassa IT-prosessissa pitää olla mahdollisimman vähän poikkeustapauksia, jotka automaation täytyy käsitellä (Slaby,
17 2012). Tähän liittyen on myös toinen koulukunta, jonka mukaan myös poikkeusta- paukset tulee antaa ITPA:lle (Sutherland 2013).
Virhealttiit manuaaliset IT-prosessit. ITPA:lla voidaan korvata manuaaliset IT-pro- sessit, koska ne ovat virhealttiita. Esimerkiksi ihmisen tekemät skriptatut eräajot ovat virhealttiita, etenkin, jos suoritettavien skriptien parametrit muuttuvat tai ne otetaan jostain toisesta järjestelmästä (Sutherland, 2013).
Helposti jaettavat IT-prosessit. Jos IT-prosessi on helposti jaettavissa aliprosesseihin, niin ITPA on helpompi saavuttaa, koska tällöin saadaan yksiselitteisempiä prosessiku- vauksia (Slaby, 2012). Selkeästi määritellyt aliprosessit, jotka muuntavat panokset tu- loksiksi loogisine virtoineen ja yksiselitteisine päätöksineen, helpottavat ITPA:n hyö- dyntämistä (Sutherland, 2013).
Selkeä käsitys nykyisistä manuaalisista kustannuksista. Johdon ja muiden sidosryh- mien edustajien, jotka eivät tunne yksityiskohtia, on helpompi tehdä päätöksiä ITPA:sta, jos he tietävät manuaaliset käsittelykustannukset sekä ROI:n (Sutherland, 2013).
Fungin (2014) esittämä prosessien automatisointikriteeristö on verrattavissa Lacity et al. (2015a) esittämiin prosessiattribuutteihin, joita ovat transaktioiden paljous (Vo- lume of transactions), prosessin standardointi (Degree of process standardization), pro- sessin kypsyys (Degree of process maturity), prosessin säännönmukaisuus (Degree to which process is rules-based), yhteentoimivuus (Degree of interoperability), prosessin monimutkaisuus (Degree of process complexity), prosessin riippuvuus (Degree of pro- cess interdependence), komplianssiriski (Degree of compliance risk) ja liiketominta- arvo (Degree of business value) Kustannustehokkuus ei välttämättä ole ainut kriteeri, vaan kustannustehokkuuden täytyy kuitenkin olla linjassa muiden suorituskykyyn vai- kuttavien tekijöiden kanssa (Taulukko 2).
18
Taulukko 2. Prosessiattribuuttien sopivuus jaetuille palveluille, ulkoistamiselle ja ohjelmistoro- botiikalle (mukaillen Lacity et. al., 2015a); n/a tarkoittaa not applicable, not available, tai no
answer.
Prosessiattribuutti Arvo, jolloin suositel- laan jaettuja palveluja ja ulkoistamista
Arvo, jolloin suositel- laan ohjelmistorobotiik- kaa
Transaktioiden paljous Korkea Korkea
Prosessin standardointi Korkea Korkea
Prosessin kypsyys Korkea Korkea
Prosessin säännönmukai- suus
Korkea Korkea
Yhteentoimivuus Korkea n/a
Prosessin monimutkai- suus
Matala n/a
Prosessin riippuvuus Matala n/a
Komplianssiriski Matala n/a
Liiketoiminta-arvo Matala n/a
3.2 Suosituksia ohjelmistorobotiikan hyödyntämiseksi
Fung (2014) kiteyttää ITPA:n hyödyntämisen seuraavien kolmen tekijän avulla:
- Perustele liiketoiminnan esimerkillä (Justify with a business case) - Aloita pienesti, ajattele suuresti (Start small think big)
- Käytä oikeita henkilöitä (Use the right human resources)
Seuraavaksi esitellään Fungin (2014) esittämät hyödyntämistekijät. Jollei lause tai vir- ketasolla ole merkitty muuta lähdettä, niin esittelyt perustuvat Fungin (2014) artikke- liin.
19 Perustele liiketoiminnan esimerkillä. Prosessien automatisointi on helpompi perustella johdolle ja sidosryhmille, jos heille tarjotaan jotain konkreettista. Siksi prosessin au- tomatisointi on helpompi perustella näyttämällä jokin liiketoiminnan esimerkki, jossa myös mitatut tunnusluvut tuovat lisäarvoa liiketoimintaesimerkille. Ennen esimerkin suunnittelua on syytä miettiä tunnusluvut, joita esimerkissä mitataan ja joilla perustel- laan automatisoitavan prosessin kannattavuus. Tällaisia tunnuslukuja voi olla esimer- kiksi automatisoinnista koituvien säästettyjen työtuntien lukumäärä tai asiakaspalve- lun tikettien nopeutunut hoitaminen. Lisäksi ohjelmistorobotiikkaa voidaan suositella esimerkiksi silloin, kun tehtävän suorittamiseen menee ihmiseltä aikaa yli 30 minuuttia ja päivätasolla tehtävien määrä on yli 30 (Lacity et al., 2015a). Liiketoiminnan esi- merkkiä tukemaan kannattaa tehdä konseptin tai ratkaisun todennus (Proof Of Con- cept, POC), joka voi olla esimerkkitoteutus ja joka simuloi automatisointia.
Aloita pienesti, ajattele suuresti. Prosessien automatisointi on järkevää aloittaa sellai- sista prosesseista, jotka ovat yksinkertaisia ja niiden riskit sekä automatisoinnin kus- tannukset ovat matalat. Näin organisaatio pystyy opettelemaan prosessien automati- sointia ja saavuttamaan nopeita voittoja. Kun organisaatio aloittaa yksinkertaisella prosessin automatisoinnilla, tällöin IT-henkilöstö oppii ohjelmistorobotiikan toimintaa sekä ohjelmistorobotin vaatimuksien mukauttamista organisaation vaatimuksiin. Kun- nes saavutetaan tietty osaamisen taso ohjelmistorobotiikan käytössä, voi organisaatio harkita ohjelmistorobotin käyttöönottoa muilla osastoilla, liiketoimintayksiköissä tai tytäryhtiöissä.
Käytä oikeita henkilöitä. Onnistunut ohjelmistorobotin käyttöönottoprojekti vaatii myös oikeat ihmiset. Ennen ohjelmistorobotin käyttöönottoprojektin alkua täytyy ar- vioida tiedot ja taidot, mitä IT-henkilöstöltä vaaditaan. Mikäli organisaation sisältä ei löydy tietotaitoa, täytyy palkata ulkopuolinen henkilö avustamaan, varsinkin projektin alkuvaiheessa. Ennen kaikkea ulkopuolisen konsultin palkkaaminen kehittää oman IT- henkilöstön osaamista, josta on hyötyä tulevaisuuden ohjelmistorobotiikan käyttöön- ottoprojekteissa. Käyttöönottoprojektissa täytyy olla mukana kaikki avainhenkilöt au- tomatisoitavan prosessin ympäriltä, jotta prosessi saadaan mallinnettua oikein, ja hei- dät täytyy sitouttaa käyttöönottoprojektiin.
20 Ohjelmistorobotiikkaa voidaan verrata liiketoimintaprosessien hallintajärjestelmiin.
Vertailuattribuutteina (Taulukko 3) ovat liiketoiminnan päämäärä (Business Goal), tekninen lopputulos (Technical Outcome), integrointimenetelmä (Integration Met- hod), kehittäjät (Developers) ja testausvaatimukset (Testing Requirements).
Taulukko 3. Attribuutit, joilla verrataan liiketoimintaprosessien hallintajärjestelmiä (Business Process Management System, BPMS) ja ohjelmistorobotiikkaa (mukaillen Lacity et al., 2015a)
Attribuutti Liiketoimintaprosessien hal- lintajärjestelmä
Ohjelmistorobotiikka
Liiketoiminnan pää- määrä
Uudelleen suunnittele prosessit Automatisoi olemassa olevat prosessit
Tekninen lopputulos Luo uusi sovellus Käytä olemassa olevia sovelluksia
Integrointimenetelmä Pääsy liiketoimintalogiikkaker- rokseen
Pääsy olemassa olevien sovellusten esitysker- rokseen
Kehittäjät Ohjelmistokehittäjät Liiketoiminnot Testausvaatimukset Järjestelmätestaus Tuotoksen todennus
3.3 Ohjemistorobotiikan tuottavuus
Tutkimuksessa (Lacity et al., 2015d) havaittiin, että Iso-Britannian puhelinpalveluita tarjoava Telefonica O2 otti käyttöön yli 160 ohjelmistorobottia, jotka suorittavat 400 000–500 000 transaktiota joka kuukausi. Ohjelmistorobottien käyttöönotto toi yri- tykselle sijoituksen tuottoa (Return of investment - ROI) yli 650 % ja huimat säästöt saavutettiin kouluttamalla vain neljä ihmistä. Vastaavasti toisessa tutkimuksessa otet- tiin käyttöön yli 300 ohjelmistorobottia, jotka suorittivat yli kolme miljoonaa transak- tiota kvartaalissa. Nämä robotit toivat yritykselle 200 % ROI:n. Tässä tapauksessa kaksi ihmistä hallitsee 300 robottia, jotka suorittavat 600 ihmisen työt.
Lacityn tutkimuksessa (Taulukko 4) käytiin läpi hänen aikaisempien tutkimuksien pro- sessien automatisointiesimerkkejä, jossa olivat mukana Telefonica O2, Utility ja
21 Xchanging. Kaikki kolme organisaatiota ovat ohjelmistorobotiikan edelläkävijöitä ja ovat omissa käyttöönotoissaan kokeneet myös haasteita. Siitäkin huolimatta kaikki or- ganisaatiot ovat automatisoineet suuren määrän prosesseja ja ohjelmistorobotit tekevät todella suuren määrän transaktioita kuukaudessa. Kaikkien havaitsemat liiketoiminnan hyödyt ovat hyvin samankaltaisia. Liiketoiminnan näkökulmasta saavutetut hyödyt ovat todella tärkeitä ja varsinkin sijoitetun pääoman tuotto (ROI) on tärkeä tunnusluku, joka on jokaisessa tapauksessa hyvällä tasolla (Lacity et al., 2015d).
Taulukko 4. Esimerkkejä automatisoinnin tunnusluvuista (Lacity et al., 2015d)
Automatisoitu- jen prosessien määrä
Ohjelmistorobot- tien transaktioiden lukumäärä kuu- kaudessa
Liiketoiminta hyödyt
ROI
Telefonica O2
35 % tukitoi- minnoista (15 ydinprosessia)
400 000 – 500 000 - Nopeampi toi- mitus
- Parempi palve- lunlaatu
- Korkeampi oi- keellisuus
- Strateginen mahdollistaminen - Resurssien vält- täminen
- Resurssien uu- delleensijoitus - Resurssisäästöt
650 % - 800 %, 3 vuo- dessa Utility 35 % tukitoi-
minnoista
1 000 000 200 %
vuo- dessa Xchanging 14 ydinproses-
sia
120 000 30 %
per pro- sessi
22
4 Ohjelmistorobotin luonti sekä toteutusprosessikonstruk- tio ja hyödyntämisarviokonstruktio
Tässä luvussa tehdään ohjelmistorobottiesimerkki, jotta syntyy ymmärrys siitä, mitä tarkoittaa robotin konfigurointi. Samalla syntyi kolmivaiheinen toteutusprosessi (Kuva 4), kuuluvat automatisoitavan prosessin määrittely, ohjelmistorobotin konfigu- rointi ja ohjelmistorobotin tuotantoon vienti.
Kuva 4. Alkukonstruktio ohjelmistorobotin toteutusprosessista
Ohjelmistorobotin tuotantoprosessikonstruktiossa esiintyviä vaiheita tarkennetaan, kun tehdään Excel-robotti eli demossa on tarkoitus luoda Excel-tiedosto, jonne kirjoi- tetaan kahteen soluun dataa. Tämän jälkeen data luetaan ja katenoidaan yhdeksi stringiksi ja kirjoitetaan kolmanteen soluun, josta se tallennetaan tekstitiedostoon. Ex- cel-robotin tekemisessä oli seuraavat vaiheet: robotin luonti UiPath-tutorialien avus- tuksella mukaan (Luku 4.1) sekä aja robotti (Luku 4.2). Toteutusprosessia tarkennet- tiin luvussa 4.3. Lisäksi ohjelmistorobottien hyödyntämistä haluttiin tarkastella kyp- syystasotarkastelulla, jota varten laaditaan hyödyntämisarviokontruktio (Luku 4.4).
Vie ohjelmistorobotti tuotantoon
Konfiguroi ohjelmistorobotti
Määrittele automatisoitava prosessi
23
4.1 Robotin luonti
UiPath-ohjelmisto asennetaan työasemalle. Excel-robotti vaatii UiPath-paketin laajen- noksen nimeltä UiPath.Excel.Activities.
Robotille täytyy antaa Excel Application Scope (Kuva 5), jossa Exceliin liit- tyvät toiminnot suoritetaan ja tälle täytyy määritellä polku, jonne Excel luodaan.
Kuva 5. Excel Application Scope
Tämän jälkeen valitaan Write Value -komponentti (Kuva 6), joiden avulla kirjoi- tetaan arvo määriteltyyn soluun. ”Sheet1” märittelee Excelin välilehden ja ”A1”
määrittelee solun, johon kyseinen arvo kirjoitetaan.
24
Kuva 6. Excel Write Value komponentit
Tämän jälkeen luodaan kaksi muuttujaa, joihin arvot A1 ja A2 voidaan lukea (Kuva 7). Variables-vähilehdellä voi luoda taulukkoon muuttujia ja määritellä niiden tie- totyypin, tässä tapauksessa valitaan String.
Kuva 7. Variables-välilehti
Luetaan arvot edellä määriteltyihin muuttujiin (Kuva 8).
25
Kuva 8. Luetaan arvot soluista muuttujiin
Luodaan uusi muuttuja (Kuva 9), johon aiemmin luetut muuttujat voidaan sijoittaa käyttäen Assign-komponenttia, jonka avulla voidaan katenoida kaksi String-tyyp- pistä muuttujaa. Assign-komponentti pystyy käyttämään Visual Basic -komentoja.
Kuva 9. Katenoidaan muuttujien arvot
Kun nimet on saatu katenoitua, voidaan kirjoittaa arvo soluun ja sen jälkeen lukea arvo solusta (Kuva 10).
Kuva 10. Kirjoitetaan ja luetaan saatu arvo
26 Lopuksi kirjoitetaan muodostettu arvo tekstitiedostoon (Kuva 11).
Kuva 11. Kirjoitetaan muuttujan arvo tekstitiedostoon
Valmis robotti (Kuva 12) näyttää työnkulun ja robotin tehtävien suoritusjärjestyksen.
Valmista robottia voidaan käyttää toisen robotin osatehtävänä. Kyseinen esimerkki ei välttämättä sovellu toisen robotin osaksi, koska se ei ota mitään syötettä eli inputtia eikä tarjoa mitään tuotosta eli outputtia.
27
Kuva 12. Valmis robotti
Kuva 13 on mallinnettu aiemmin laaditun Excel-robotin työnkulku. Yksinkertainen työnkulkukaavio on helppo ymmärtää ja vastaava työnkulkukaavio on hyvä laatia kai- kista roboteista, jotta prosessi on mallinnettu myös muualla kuin automatisointiohjel- mistossa.
28
Kuva 13. Excel-robotin työnkulku
4.2 Robotin ”ajaminen” tai ”tuotantoon vienti”
UiPath 8 tarjoaa helpon tavan ajaa robotteja suoraan sovelluksen Run-painikkeesta.
Robotin voi myös julkaista, jolloin robotista muodostuu .nupkg-paketti, jonka voi lähettää haluttuun robotin käyttökohteeseen.
Paketin ajamiseen tarvitaan UiRobot Agent, joka sisältyy UiPath-asennuspakettiin.
UiRobot Agent listaa robotit (Kuva 14), joita se voi ajaa. Jos listaan halutaan tuoda jokin robotti, se täytyy viedä UiPathin asennuskohteesta riippuen listattuihin pakettei- hin. Tässä testissä polku on C:\ProgramData\UiPath\Packages.
Tee Excel Application
Scope
Kirjoita arvot soluun
Lue arvot muuttujiin
Katenoi arvot Kirjoita arvo
soluun Lue arvo solusta
Kirjoita arvo tekstitiedostoon
29
Kuva 14. UiRobot Agent
Kun ohjelmistorobotti on ajettu, voidaan tarkistaa aiemmin (Luku 4.1) määriteltyjen tiedostojen sisältö ja varmistua, että ohjelmistorobotti toimii halutulla tavalla. Avataan Excel-tiedosto polusta C:\uipathtext\ExcelRobot ja tarkastetaan, onko tulos oikea. Ex- cel-taulukon solut A1 ja A2 (Kuva 15) on katenoitu ja soluun A3 on kirjoitettu niiden tulos, joka vastaa aiemmin (Luku 4.1) asetettuja arvoja.
Kuva 15. Excel-taulukko
Lopuksi avataan aiemmin määritellystä (Luku 4.1) polusta tekstitiedosto ja tarkaste- taan, että solusta A3 luettu arvo on kirjoitettu oikein tekstitiedostoon (Kuva 16).
Kuva 16. Tekstitiedosto
30
4.3 Toteutusprosessikonstruktio
Kun organisaatio tunnistaa prosesseja, joiden osia voidaan automatisoida ohjelmisto- robottien avulla, niin automatisoitavien prosessien määrittelyä, ohjelmistorobotin kon- figurointia ja tuotantoon ottoa, voidaan tarkentaa (Kuva 17).
Kuva 17. Konstruktio ohjelmistorobotin toteuttamiseksi
Ohjelmistorobotin määrittelyprosessissa on mietittävä, onko prosessia syytä jakaa ali- prosesseihin, jotta automatisoitavat prosessit olisivat mahdollisimman yksinkertaisia ja yksiselitteisiä, varsinkin, jos automatisoitava prosessi on monimutkainen ja raskas.
Kullekin aliprosessille tulee mallintaa päätöksentekologiikka ja säännöstö, jotta tiede- tään mitä robotin täytyy tehdä missäkin tilanteessa.
Ohjelmistorobotin konfigurointi perustuu määrittelyvaiheessa tuotettuun logiikkaan ja säännöstöihin. Ohjelmistorobotin tekninen toteutus täytyy suunnitella ja tämän jälkeen automatisoitavan prosessin kukin komponentti täytyy luoda sekä mallintaa looginen
Vie ohjelmistorobotti tuotantoon
ylläpito jatkuva kehittäminen prosessin päivittäminen laatupoikkemat
Konfiguroi ohjelmistorobotti
luo robotille komponentit säännöstön pohjalta
suunnittele tekninen
toteutus testaa verifioi toimintalogiikka
Määrittele automatisoitava prosessi
määrittele prosessin aliprosessit mallinna robotin päätöksenteko
logiikka laadi selkeät ja yksiselitteiset säännöt
31 päätöksenteko määrittelyvaiheen säännöstön pohjalta. Kun komponentit on saatu teh- tyä, robotti täytyy testata ja verifioida looginen päätöksenteko.
Kun ohjelmistorobotti on viety tuotantoon, sitä täytyy ylläpitää ja seurata ohjelmisto- robotin palvelutasoa. Ohjelmistorobotti vaatii jatkuvaa kehittämistä sekä havaittujen virheiden eli bugien tai toiminnallisten puutteiden että prosessin päivityksestä johtu- vien muutosten vuoksi. Prosessin päivittäminen voi johtua liiketoiminnan päätöksen- teon seurauksesta tai ohjelmistorobotin toiminnallisten tarpeiden seurauksesta. Ohjel- mistorobotti raportoi jatkuvasti laatupoikkeamista ja virhetilanteista, joita ylläpito seu- raa ja raportoi liiketoiminnasta vastaaville henkilöille. Tämän perusteella tehdään pää- töksiä esimerkiksi ohjelmistorobotin kehityksestä ja käyttöönoton laajentamisesta.
Esimerkiksi Xchangingin toteutusprosessikonstruktio sisältää kahdeksan vaihetta (Kuva 18). Xchanging aloitti ohjelmistorobotiikan hyödyntämisen 2013 loppuvuo- desta ja vuonna 2014 Q3 he saivat ensimmäiset neljä prosessia automatisoitua. Tämän jälkeen he ovat jatkaneet ohjelmistorobotiikan laajempaa käyttöönottoa ja kehittä- mistä.
32
Kuva 18. Xchangingin toteutusprosessikonstruktio (mukaillen Lacity et al., 2015b)
Lacityn tutkimuksessa (2015c), joka on edelläkävijä ohjelmistorobotiikan saralla, ha- vaittiin useita monissa muissakin case-tapauksissa toistuvia seikkoja:
- Anna liiketoiminnan ohjata ohjelmistorobotiikkaa - Lähetä oikeanlainen viesti henkilökunnalle
- Anna ohjelmistorobotiikan tiimeille aikaa hitsautua yhteen - Tunnista prosessit ja aliprosessit, jotka sopivat automatisoitaviksi
Tunnista automatisoitava prosessi (Identifying
processes for automation)
Tuo prosessi esille IT johtoryhmässä (Bringing
IT on board)
Kasaa ohjelmistorobotiikka tiimi (Assembling the RPA
Team) Rakenna
ohjelmistorobotin operatiivinen malli (Building the Robotic
Operating Model)
Kouluta henkilöstö ja ohjelmistorobotit (Training the staff and
the robots)
Tee automatisoitu esimerkki (Automating
Example)
Toivota robotit tervetulleeksi (Welcoming the robots to
the team) Opitut asiat (Lessons
learned)
33 - Tee prototyyppejä, kun ohjelmistorobotiikkaa laajennetaan uusiin liiketoi-
minta alueisiin
- Uudelleenkäytä komponentteja, jotta käyttöönotto on nopeampaa sekä edulli- sempaa
- Tuo automatisoitava prosessi IT-johtoryhmälle ajoissa - Rakenna kestävä infrastruktuuri
- Ajattele ohjelmistorobotiikkaa liiketoiminta järjestelmien täydentäjänä
4.4 Hyödyntämisarviokonstruktio
Jotta organisaatio voi hyödyntää ohjelmistorobotiikkaa, sillä täytyy olla taitoja ja ky- vykkyyksiä. Kypsyystasomallissa (Taulukko 5) ohjelmistorobotiikkaa voidaan tarkas- tella aloittelevan, teollistuvan ja vakiintuneen toiminnan kypsyystasoilla. Ohjelmisto- robotiikan hyödyntämistä aloitteleva organisaatio hankkii itselleen kyvykkyyksiä ja teollistuvassa vaiheessa oleva vakiinnuttaa hyviä käytäntöjä kokemuksiensa pohjalta.
Sekä kustannustehokkuuteen että erikoistumiseen päästään siinä vaiheessa, kun ohjel- mistorobotiikan hyödyntämiskyvykkyys on osa suorituksen johtamista. Esimerkiksi Xchanging saavutti vakiintuneen toiminnan vaiheen todella nopeasti eli he pystyivät nopeasti kasvattamaan robottien lukumäärää halutessaan useisiin satoihin, koska heillä oli liiketoiminta ja teknologinen arkkitehtuuri kunnossa (Lacity et al., 2015b).
34
Taulukko 5. Yrityksen RPA-kypsyysmalli (mukaillen Lacity et al., 2015b).
Aloitteleva Teollistuva Vakiintunut Organisaatio Määrittele auto-
matisoinnin ta- voitteet
Virtuaalinen työvoima tarjoaa toisen keinon toi- mittaa palveluita
Jaa töitä ihmisten ja virtuaalisen työ- voiman kesken kustannustehok- kaasti
Määrittele roolit ja muut muutok- set, jotka tukevat ohjelmistorobo- tiikkaa
Ohjelmistorobotiikka on keskeinen komponentti teknologiapinossa
Ihmiset ja ohjel- mistorobotit työs- kentelevät yhdessä tehokkaasti
Perusta hallinto- ryhmä, vaatimus- putki ja tukimalli
Tulevat päätökset perus- tuvat ohjelmistorobotii- kan käytön maksimoin- tiin
Koulutus Julkaise standar- doitu lähestymis- tapa ja prosessit, jotka määrittele- vät laajuuden ja edut automaation mahdollisuuksille
Esittele automaatiosta koituneita hyötyjä laa- jemmalle yleisölle orga- nisaatiossa
Sisällytä ohjelmis- torobotiikan mitat- tuja hyötyjä ohjel- mistorobotiikan suunnitelmaan
Määrittele kriitti- set menestysteki- jät (CSFs)
Kannusta henkilöstöä tunnistamaan ja ehdotta- maan automatisoitavia mahdollisuuksia
Vedä kampanjoita ja aloitteita, jotka tukevat liiketoi- minnan ajureita Määrittele keskei-
set suorituskyky- mittarit (KPIs) au- tomatisoinnin ar- viointiin
Käytä saavutettuja hyö- tyjä uusien asioiden aja- miseen
Kyvykkyys Kouluta ohjelmis- torobotiikan ydin- tiimi
Käytä ydintiimiä uusien jäsenien kouluttamiseen ja ohjaamiseen
Syvä osaaminen ja tieto koko tiimillä Perusta ympä-
ristö, arkkiteh- tuuri ja toimitus- malli
Perusta ohjelmistorobo- tiikkakoodin parhaat käytännöt
Sisällytä ketterä kulttuuri ohjelmis- torobotiikan kehit- tämiseen
Toimita automaa- tioesimerkkejä to- distaaksesi hyö- tyjä
Vaihda täysin virtuali- soituun arkkitehtuuriin
35 Telefonica O2:lle osoitettiin Lacityn (2015a) mukaan kolme kysymystä, joiden poh- jalta arvioitiin ohjelmistorobotiikan käyttöönottoa korvaamaan nykyinen liiketoimin- taprosessien hallintajärjestelmä:
- Integroituuko ohjelmistorobotti nykyisiin tiedonhallintajärjestelmiin rikko- matta niitä?
- Tarjoaako teknologia laadukasta palvelua?
- Onko teknologian ROI riittävä?
Liiketoiminnan esimerkki osoitti, että nykyinen liiketoimintaprosessien hallintajärjes- telmä kykeni suoriutumaan automatisoinnista, mutta ROI sen sijaan jäi huomattavasti ohjelmistorobotiikan toteutuksesta. Ohjelmistorobotiikan keinoin automatisointi mak- soi itsensä takaisin 10 kuukaudessa, mutta toiminnanohjausjärjestelmällä vastaava saa- vutettiin kolmessa vuodessa.
Telefonica O2 nosti viisi seikkaa, joita muiden automatisointia harkitsevien yritysten kannattaa ottaa huomioon (Lacity et al., 2015a):
− Ohjelmistorobotiikka on yksi työkalu muiden prosessityökalujen joukossa (“RPA is one tool along with process elimination, process improvement, and other business process tools”)
− Robotit tarvitsevat eksplisiittisemmät ohjeet kuin ihmiset (“Robots need more explicit instructions than humans”)
− Pidä huoli, että sisäinen infrastruktuuri pysyy automatisoinnin vaatimusten mukana (“Make sure your own internal infrastructure grows in pace with au- tomation”)
− Mieti tarkkaan paras ulkoistusmalli (“Consider carefully the best sourcing op- tion”)
− Jos haluat olla ohjelmistorobotiikan edelläkävijä, niin sinun täytyy ottaa myös riskejä (“To be an RPA pioneer, you will need to take some risks”)
Ohjelmistorobotiikka on yksi työkalu muiden prosessityökalujen joukossa. Vaikka Te- lefonica O2 on ohjelmistorobotiikan kannattaja, niin se pitää silti ohjelmistorobotiik- kaa työkaluna muiden työkalujen tavoin. He eivät aio korvata liiketoimintaprosessien
36 hallintajärjestelmää ohjelmistorobotiikalla, vaan he aikovat jatkossa käyttää molempia työkaluja rinnakkain.
Robotit tarvitsevat eksplisiittisemmät ohjeet kuin ihmiset. Ihmiset tekevät päätökset perustuen järkeilyyn, jota robotti ei osaa tehdä. Siksi robotille pitää yksiselitteisesti sanoa, mitä tehdä missäkin tilanteessa.
Pidä huoli, että sisäinen infrastruktuuri pysyy automatisoinnin vaatimusten mukana.
Telefonica O2:sen infrastruktuuri koki suuria haasteita ohjelmistorobottien käyttöön- otossa, jonka vuoksi he joutuivat päivittämään koko infrastruktuurin vastaamaan oh- jelmistorobotiikan vaatimuksia.
Mieti tarkkaan paras ulkoistusmalli. Telefonica O2 lähestyi omaa palveluntarjoajaa selvittääkseen minkälaisia automatisointi mahdollisuuksia heillä oli, mutta päätyivät kuitenkin Blue Prism:iin.
Jos haluat olla ohjelmistorobotiikan edelläkävijä, niin sinun täytyy ottaa myös riskejä.
Telefonica O2 koki myös ongelmia ohjelmistorobotiikan käyttöönotossa, josta he op- pivat ja pystyivät kehittämään omia prosessejaan.
37 Moni organisaatio voi olla kiinnostunut ja halukas automatisoimaan omia prosessejaan kuultuaan kustannusten pienentymisestä. Kustannussäästöt voivat olla hyvinkin mer- kittäviä, mutta organisaation täytyy olla kypsä sekä teknisesti että prosessin puolesta ottamaan ohjelmistorobotti käyttöön.
Organisaatiot voivat arvioida omaa kypsyyttään yksinkertaisilla kysymyksillä, joita tutkielman tekijä on laatinut perustuen Lacityn kypsyysmalliin (Taulukko 6).
Taulukko 6. Ensimmäisen tason kysymykset perustuen Lacityn kypsyysmalliin.
Taso 1
Onko prosessien automatisoinnin tavoitteet määritelty?
Onko organisaatiolle perustettu ohjelmistorobotiikan hallintoryhmä?
Onko automatisoitavat prosessit määritelty?
Onko organisaatiolle koulutettu ohjelmistorobotiikan ydintiimi?
Onko automatisoinnille määritelty keskeiset suorituskykymittarit (key performance indicators, KPIs)?
Mikäli organisaatio pystyy vastaamaan kaikkiin edelliseen ”Kyllä”, niin organisaatio on erityisen valveutunut ja ottanut itse selvää mitä ohjelmistorobotiikan käyttöönotto vaatii. Tämän jälkeen voidaan esittää lisäkysymyksiä (Taulukko 7), joiden avulla kar- toitetaan mahdollisia kehityskohteita organisaation ohjelmistorobotiikan käytössä.
38
Taulukko 7. Toisen tason kysymykset perustuen Lacityn kypsyysmalliin.
Taso 2
Onko ohjelmistorobotiikka keskeinen komponentti käytettävissä tek- nologioissa?
Perustuvatko päätökset ohjelmistorobotiikan käytön hyödyntämi- seen?
Onko henkilöstölle kannustimia automatisoitavien prosessien tunnis- tamiseksi tai ehdottamiseksi?
Hyödynnetäänkö ohjelmistorobotiikan ydintiimiä ohjelmistorobotii- kan kouluttamiseksi?
Onko ohjelmistorobotiikan parhaat käytännöt määritelty?
Mikäli organisaatio kykenee vastaamaan tason 2 kysymyksiin ”Kyllä”, tällöin organi- saatio on jo omaksunut ohjelmistorobotiikan organisaation sisällä ja kykenee itse ke- hittämään omaa prosessiaan haluamaansa suuntaan. Lacityn mallin mukaan tason 2 kysymyksiin vastattuaan organisaatio on teollistuvalla kypsyystasolla, mutta ei välttä- mättä vielä vakiintunut. Tason 1 ja 2 kysymykset ovat tarkoitettu kartoittamaan orga- nisaation nykyistä tilannetta ohjelmistorobotiikan hyödyntämiset suhteen, mutta ei ar- vioimaan organisaation kypsyyttä. Kysymyksillä ei ole tarkoitettu arvioida tai kehittää jo pitkään ohjelmistorobotiikkaa hyödyntäneiden organisaatioiden tasoa, vaan auttaa ohjelmistorobotiikkaa aloittelevien organisaatioiden hahmottamaan nykytilannetta or- ganisaatiossa.
39
5 Teknologisten trendien, kuten ohjelmistorobotiikka, poh- dintaa
Monilla toimialoilla tulee ja menee trendejä, mutta IT-ala on yksi ala, joilla noita tren- dejä tulee ja menee enemmän kuin monella muulla toimialalla. Osa trendeistä tulee jäädäkseen ja osa poistuu yhtä nopeasti käytöstä ja tietoisuudesta kuin se oli tullutkin.
Viime vuosina on noussut todella mielenkiintoisia ja merkittäviä trendejä kuten ohjel- mistorobotiikka, robotiikka ja virtuaalitodellisuus:
• Ohjelmistorobotiikasta uutisoitiin muutama vuosi sitten tulevan rutiinitehtä- vien poistajaksi, mutta aivan siihen se ei ole yltänyt. Ohjelmistorobotiikalla voidaan automatisoida manuaalisia usein toistettavia yksiselitteisiä tehtäviä, jotta ihmisille jää enemmän aikaa tehdä loogista päättelykykyä vaativia tehtä- viä (Lacity et al., 2015a).
• Robotiikka on noussut isoksi asiaksi hoitoalalla - esimerkiksi vanhustenhoi- toon on suunniteltu ja kehitetty erilaisia robotteja. Robotit hoitavat yksinker- taisia tehtäviä ja ovat erityisesti seuraksi vanhuksille. Varsinkin suomessa suurten ikäluokkien siirryttyä eläkkeelle ja vanhainkoteihin, ei riitä hoitohen- kilökuntaa hoitamaan, joten robotit ovat erittäin tervetulleita lisäyksiä. Vielä hoivarobotit eivät ole alaa vallannut, mutta ne tulevat varmasti olemaan suuri mullistus, kun teknologia ja ohjelmistot saadaan tiettyyn pisteeseen.
• Virtuaalitodellisuus on noussut näistä viimeisimpänä otsikoihin ja on saanut myös todella paljon huomiota. Virtuaalitodellisuuden ympärille suunnitellaan jatkuvasti uutta ja sitä voidaan jo hyödyntää toimivissa sovelluksissa. Esimer- kiksi rakennusalalla virtuaalitodellisuus on osoittautunut äärimmäisen hyväksi lisäykseksi. Virtuaalitodellisuuden avulla voidaan mallintaa valmiita raken- nuksia ja ”viedä” kyseiset rakennukset niille suunniteltuun fyysiseen paikkaan virtuaalisena, jolloin voidaan havaita mahdollisia virheitä jo suunnitteluvai- heessa. Tämä mahdollistaa myös asiakkaille vierailla tulevassa talossaan ennen kuin talo on valmistunut ja havaita mahdollisia muutoksia tai kehityskohteita.
40 Tässä luvussa pohditaan teknologisia trendejä kuten ohjelmistorobotiikkaa. Luvussa 5.1 pohditaan organisaatioiden suhtautumista teknologisiin trendeihin ja niistä lähtö- kohdista luvussa 5.2 pohditaan trendien lähestymistä. Lopuksi luvussa 5.3 pohditaan trendien vaikutusta organisaatioon.
5.1 Organisaatioiden suhtautuminen trendeihin
Organisaatioiden näkökulmasta teknologisten trendien tuleminen ja meneminen ai- heuttavat haasteita useastakin syystä:
- Osaajia voi olla vaikea löytää
- Teknologian käyttöönotto voi olla kallista ja vaikeaa
- Uuden teknologian myyminen asiakkaalle voi olla pitkä prosessi - Teknologia voi osoittautua jälkeenpäin vääräksi valinnaksi - Teknologian/tuotteen ylläpito lopetetaan kannattamattomana
- Teknologia on todella kallista ja asiakkaat eivät ole valmiita maksamaan - Kyseiselle teknologialle ei löydy sovelluksia/käyttöä
Osaajia voi olla vaikea löytää. Osaajia uudella teknologialla on yleensä todella vähän, erityisesti jos teknologia on luonut kokonaan uuden toimialan, niin osaajien löytämi- nen on vielä vaikeampaa. Tästä esimerkkinä virtuaalitodellisuus, siinä on samoja oh- jelmointikieliä ja työkaluja kuin vanhemmissakin teknologioissa, mutta ideologiana virtuaalitodellisuus on hieman erilainen ja vaatii erilaista osaamista.
Teknologian käyttöönotto voi olla kallista ja vaikeaa. Uuden teknologian kanssa kom- pastuskiviä on yleensä enemmän ja kaikkiin ongelmiin ei osata varautua. Tämä voi johtaa siihen, että käyttöönottoprojektista tulee kallis ja vaikea, siksi joissain tapauk- sissa koko toimitusprojekti epäonnistuu.
Uuden teknologian myyminen asiakkaalle voi olla pitkä prosessi. Uuden ajattelumallin ja teknologian myynti on haastavaa, koska sen mukana tulee myös muutoksia, ei vält- tämättä suuria, mutta sellaisia, joita joku vastustaa. Muutosten lisäksi uusi teknologia tuo mukanaan uuden oppimista, joka yleensä myös täytyy perustella hyvin, jotta asia- kas haluaa maksaa siitä.
41 Teknologia voi osoittautua jälkeenpäin vääräksi valinnaksi. Kaikessa uudessa on aina riskinsä, etenkin teknologioissa. Voi olla, että teknologian sopimattomuus suunnitel- tuun käyttökohteeseen havaitaan käyttöönottovaiheessa, jolloin joudutaan aloittamaan alusta tai kuoppaamaan koko hanke. Tämän havaitseminen etukäteen voi olla vaikeaa varsinkin, jos kyseistä teknologiasta ei ole toimittajalla tai asiakkaalla.
Teknologian/tuotteen ylläpito lopetetaan kannattamattomana. Voi olla mahdollista, että teknologian tai tuotteen kehitys lopetetaan, koska sitä kehittävä organisaatio näkee sen järkeväksi. Syyt voivat olla taloudelliset, vähäinen käyttäjämäärä tai toteutuskel- voton idea. Esimerkiksi virtuaalitodellisuus sai alussa kritiikkiä, koska se on niin kal- lista sekä kehittää että käyttää kuluttajana. Lisäksi vähäinen sovellusten määrä on uu- den teknologian alkutaipaleella ongelma, koska kuluttajilla ei ole sisältöä mitä käyttää.
Teknologia on todella kallista ja asiakkaat eivät ole valmiita maksamaan. Varsinkin uusi teknologia johon sisältyy laitteita, on yleensä hyvin kallista. Ei pelkästään kehittää vaan myös fyysiset laitteet maksavat paljon. Uusi teknologia voi olla vaikea lähtökoh- taisesti vaikea myydä asiakkaalle, koska hintalappu on yleensä iso ja referenssejä ei välttämättä löydy ollenkaan. Organisaatioiden päättäjiä on vaikea vakuuttaa pelkäs- tään sanoilla ja myyntipuheella, koska ei ole tarjota mitään lukuja väitteiden tueksi.
Kyseiselle teknologialle ei löydy sovelluksia/käyttöä. Kuten kaikessa uudessa, niin myös teknologiassa, sille ei alussa välttämättä löydy käyttökohteita. Etenkin tuotteissa, jotka vaativat kehittäjien tekemiä ohjelmistoja, ohjelmistojen vähäisyys on ongelma kuluttajille.
Kaikki edellä mainitut ongelmat voidaan yleisesti ottaen välttää tekemällä uudelle tek- nologialle Proof-Of-Concept (POC) tyyppinen toteutus, jossa toteutetaan pienem- mässä mittakaavassa haluttu tuote. Tällöin ei lähdetä heti rakentamaan isoa infrastruk- tuuria tietämättä mitä se vaatii. Vaikka POC:ssa ei välttämättä törmää kaikkiin ongel- miin, mitä isompi toimitusprojekti tuo tullessaan, niin ainakin perustietotaito saadaan POC-projektin aikana.
42 POC-projektin elinkaari on vastaava kuin normaalin isomman mittakaavan projekti.
Aluksi tehdään määrittely ja kartoitetaan asiakkaan tarpeet. Tämän jälkeen suunnitel- laan mitä ja miten toteutetaan sekä pohditaan uuden teknologian tuomat haasteet ky- seiselle projektille.
Kehitysvaiheessa voidaan käyttää ketteriä menetelmiä ja tehdä useita iteraatioita, jol- loin asiakas pysyy kehityksessä koko ajan mukana ja voi heti korjata, jos kokee, että tehdään vääriä asioita. Kun asiakas hyväksyy tuotteen, niin tuote voidaan toimittaa asiakkaalle käytettäväksi. Tämän jälkeen siirrytään ylläpitoon, jossa asiakas voi halu- tessaan ostaa ylläpitopalvelut toimittajalta, jolloin yhteistyö jatkuu.
5.2 Trendien lähestyminen
Teknologisia trendejä voi olla organisaation näkökulmasta vaikea lähestyä, koska sii- hen monesti tarvitaan jokin ammattilainen kertomaan ja avaamaan kyseistä trendiä.
Tähän tarvitaan yleensä konsultointia, mutta konsultointikaan ei välttämättä riitä saa- maan selkeää kuvaa tai käsitystä teknologian mahdollisuuksista.
Organisaatio, joka haluaa hyödyntää uutta teknologiaa, tarvitsee osaajia kyseisen tek- nologian ympäriltä, kuten aiemmin mainittu, konsultteja tai omia tekijöitä. Omien te- kijöiden palkkaaminen lisää riksiä, koska jos teknologia ei kannata, niin työntekijöistä pitää päästä jotenkin eroon, jos heitä ei voi hyödyntää muualla. Siksi konsulttien käyttö voi olla uuden teknologian kohdalla järkevää.
Organisaation on hyvä perustaa johtoryhmä uuden teknologianympärille, jotta voidaan tehdä päätöksiä ja seurata taloudellista kannattavuutta kyseisen teknologian ympärillä.
Organisaatio yleensä haluaa, että jonkun uuden asian käyttöönotosta seuraa myös hyö- tyjä ja yleensä se hyöty on rahallinen. Siitä syystä pelkästään teknologian osaavat am- mattilaiset eivät riitä, vaan tarvitaan myös taloudellista osaamista ja päätöksentekoky- kyä, jotta teknologiaan ei panosteta enempää rahaa kuin on tarve. Päätöksentekijät, kuten johtoryhmä, voi koostua jo organisaatiossa olemassa olevista henkilöistä, mutta heidän tai ainakin jonkun heistä on syytä olla myös hieman perillä kyseistä teknologiaa hyödyntävien henkilöiden ajankäytöstä ja ammattitaidosta. Yleensä johtoryhmään
43 kuuluu joku tuoteomistaja, joka tekee töitä uuden teknologian parissa ja mahdollisesti myös johtaa kehitysporukkaa.
Työnkulku (Kuva 19) mallintaa organisaation uuden teknologian fiksun lähestymista- van; tehdään POC-toteutus, tulkitaan lopputulos ja hyödyt, pohditaan sovelluskohteita ja jatkokäyttöä.
Kuva 19. Uuden teknologian hyödyntämisen työnkulku organisaation näkökulmasta.
Kuten aiemmin jo mainittu POC:n avulla organisaatio saa jo hyvissä ajoin selville uu- den teknologian kompastuskivet ja mahdolliset ongelmat. Lisäksi kehittäjät ja projek- titiimi saa kokemusta kyseisen teknologian käytöstä ja näin ollen uusien toteutuksien tekeminen helpottuu merkittävästi. POC-toteutuksen jälkeen on syytä pysähtyä miet-
Jatkokäyttö
Pohditaan mihin uutta teknologiaa voidaan laajentaa käytettävän tulevaisuudessa
Sovelluskohteet
Pohditaan mihin organisaatio voi hyödyntää uutta teknlogiaa
Tulkitse lopputulos; hyödyt ja haitat
Tulkitaan mitä hyötyjä ja haittoja teknologialla on
POC
POC:lla saadaan selville teknologian hyödyt ja haitat
44 timään mikä meni POC:ssa hyvin ja mikä huonosti (lessons learned), jolloin projekti- tiimi voi jakaa tuntemuksiaan uuden teknologian kehittämisesti ja implementoinnista asiakkaiden tai pelkästään toimittajan kesken.
Seuraavaksi organisaation kannattaa pohtia uuden teknologian hyötyjä ja haittoja, joita havaittiin esimerkiksi POC toteutuksen aikana. Tässä vaiheessa organisaatio voi tehdä päätöksen, että kyseinen teknologia hylätään ja sitä ei oteta käyttöön laajemmin tai vastavuoroisesti tehdä päätöksen teknologian käyttöönotosta laajemmassa mittakaa- vassa. Mikäli teknologia päätetään hylätä, niin POC-toteutukseen käytetyt rahat ovat menneet hukkaan, mutta toisaalta organisaatio säästi paljon rahaa, että ei lähtenyt käyt- tämään uutta teknologiaa täyden mittakaavan projektissa ja tehnyt sen jälkeen päätök- sen, että teknologiaa ei ole järkevä käyttää.
Teknologian pohdinnan jälkeen organisaatiossa kannattaa miettiä sovelluskohteita eli missä kaikkialla teknologiaa kannattaa hyödyntää. POC-toteutus ei välttämättä ole ai- noa, missä uutta teknologiaa kannattaa hyödyntää, mikäli se nähdään järkevänä ja sen käyttöä jatketaan. Tässä vaiheessa on ainakin hyvä miettiä voisiko uusi teknologia so- pia muille organisaation osa-alueille ja mahdollisesti tehdä POC-toteutuksia myös or- ganisaation muissa liiketoimintayksiköissä.
Lopuksi on hyvä pohtia tulevaisuutta ja sitä mitä mahdollisuuksia uusi teknologia avaa. Voisiko uusi teknologia avata kenties uusia markkinoita tai kokonaan uuden asiakassegmentin kyseiselle organisaatiolle? Yleensä kaikki kysymykset ovat avoinna uuden teknologian osalta, jolloin vain testaamalla ja ideoimalla saadaan selville mihin kaikkeen kyseinen teknologia sopii ja missä sitä on järkevä hyödyntää.
5.3 Trendien vaikutus organisaatioon
Trendien vaikutus organisaatioon on voi olla merkittävä etenkin silloin, kun kyseinen teknologia jää organisaation käyttöön. Tästä hyvänä esimerkkinä ohjelmistorobo- tiikka, jossa organisaation pitää pystyä muuntautumaan ohjelmistorobotiikan vaati- muksiin.
45 Jos organisaatio ei lähde mukaan teknologiseen trendiin, niin se ei voi kilpailla uutta teknologiaa hyödyntävillä markkinoilla. Toimiala (Tilastokeskus, 2008) vaikuttaa tek- nologian käyttöönottoon. Esimerkiksi teollisuudessa (TOL 2008, pääluokka C), jossa muunnetaan tuotannontekijöitä (kuten komponentit ja raaka-aineet) tuotteiksi, voidaan kokeilla uusia teknologioita, mutta niiden tuotannollinen käyttöönotto voi olla hitaam- paa kuin rutiiniluonteisissa ja useimmiten lyhytkestoisissa tukipalveluissa (TOL 2008, pääluokka N). It-alan (TOL 2008, pääluokka J) yritysten kilpailuvalttina on organisaa- tion mukautuminen ja uusien trendien sekä teknologioiden tarjoaminen asiakkaille, jo- ten heidän on ehdottomasti oltava ensimmäisenä tarjoamassa ja käyttämässä uusia trendejä.
Ohjelmistorobotiikka on yksi viime vuosien kuumimmista puheenaiheista automati- soinnissa. Ohjelmistorobotiikan avulla organisaatio säästää merkittävästi kustannuk- sissa ja voi automatisoida yksiselitteisiä toistettavia tehtäviä ja näin ollen vähentää re- sursseja näistä tehtävistä. Esimerkiksi ohjelmistorobotiikan vaikutukset organisaa- tioon ovat onnistuessaan positiiviset - tuovat organisaatiolle säästöjä ja vapauttaa re- sursseja muihin tehtäviin. Joissain tapauksissa resurssien vapautuminen johtaa myös irtisanomisiin.
Ohjelmistorobotiikan kanssa tietysti robotiikka on myös kiinnostava aihe organisaati- oille, etenkin terveydenhuollossa. Organisaatioiden, etenkin työntekijöiden, pitää ope- tella ja tottua siihen, että työkaverina ei välttämättä enää ole ihmisiä vaan fyysinen robotti. Robotit tulevat organisaatioihin tekemään yksinkertaisia tehtäviä ja jopa kor- vaamaan joitakin ammattiryhmiä kuten sihteerit, siivoojat ja vastaanottovirkailijat.
Robotteihin tottuminen ei välttämättä ole organisaatiotason asia, vaan ihmisten. Ihmis- ten pitää tottua siihen, että työkaverina saattaa olla peltipurkki ihmisen sijaan.
Koko organisaation ei välttämättä tarvitse pystyä muuntautumaan uusien trendien mu- kaan, mutta kuten aiemmin mainittu, organisaation on syytä tutkia mahdollisuuksia uusien trendien ympärillä. Organisaatiot voivat kokeilla uusia teknologioita, joko omilla resursseilla tai vaihtoehtoisesti konsultteja hyödyntäen.
46
6 Yhteenveto
Luvussa 2 käsiteltiin, miten ohjelmistorobotiikka asemoituu ja mitkä sen mahdolliset käyttökohteet ovat. Yhteenvetona voidaan todeta, että ohjelmistorobotiikassa on po- tentiaalia nousta merkittäväksi teknologiaksi osaksi jokapäiväistä arkea, ja sitä se jo joissain organisaatioissa tänäkin päivänä.
Luvussa 3 käsiteltiin ohjelmistorobotiikan soveltuvuuden arviointia. Yhteenvetona voidaan todeta, että ohjelmistorobotiikan hyödyntämiseen löytyy lähes jokaisesta or- ganisaatiosta jokin prosessi, jossa sitä voi hyödyntää. Luvussa esitettiin tutkimuksia, joissa saavutettiin merkittävä sijoitetun pääoman tuotto eli ROI (Return of Invest- ment).
Luvussa 4 luotiin esimerkinomaisesti ohjelmistorobotti sekä toteutusprosessikonstruk- tio ja hyödyntämisarviokonstruktio. Yksinkertaisen Excel-robotin avulla saatiin ym- märrys mitä ohjelmistorobotin luominen ja toteuttaminen vaatii. Lisäksi arvioitiin to- teutetun ohjelmistorobotin toteutusprosessia ja hyödyntämistä. Yhteenvetona voidaan todeta, että yksinkertaisen ohjelmistorobotin teko on helppoa ja jopa yksinkertaista robottia voi hyödyntää sovelluksissa.
Luvussa 5 pohdittiin teknologisia trendejä kuten ohjelmistorobotiikkaa. Yhteenvetona voidaan todeta, että uusien teknologioiden käyttöönotossa on omat riskinsä, mutta jos organisaatio on valmis ottamaan riskit ja projekti onnistuu, voi siitä saatavat hyödyt olla todella merkittävät sekä taloudellisesti että tuotannollisesti.
Ohjelmistorobotiikka on ollut viime aikoina paljon esillä ja siitä oletettiin olevan jopa runsaasti sekä tieteellisiä että ei-tieteellisiä lähteitä. Tämä osoittautui kuitenkin vää- räksi oletukseksi tutkielman edetessä ja tutkielman tekijällä oli vaikeuksia löytää tie- teellisiä lähteitä tutkielman tueksi. Ohjelmistorobotiikan saralla professori Mary La- city Missourin yliopistossa on tutkinut paljon ohjelmistorobotiikkaa ja hänen tutki- muksiinsa myös tässä tutkielmassa paljon viitataan.
