RPA done right

RPA Done Right - ajatteletko ohjelmistorobotiikan oikein?

RPA eli ohjelmistorobotiikka on ollut viime vuosien trendisana it-myynnissä. Hypen varjolla yrityksille on myyty ohjelmistorobotiikkaa käyttötapauksiin, joihin muut ratkaisut sopisivat paremmin.

Nyt hype RPA:n eli ohjelmistorobotiikan ympärillä on ampunut yli. Asiakkaiden tulisi suhtautua siihen kriittisemmin.

Tämä saattaa tuntua omituiselta näkemykseltä tullakseen yrityksestä, joka myy ohjelmistorobotiikkaa osana tarjoamaansa. HiQ on Pohjoismaiden vanhin ja kokenein integraatiotalo, jossa ensimmäiset integraatiot tehtiin jo kolmekymmentä vuotta sitten IBM OS/2:n päälle toteutetulla FRENDS-integraatioalustan ensimmäisellä versiolla. Jo tuolloin työskentelimme prosessien orkestroinnin ja workflow-automaation eli liiketoimintaprosessien kokonaisautomaation ympärillä. Idea oli jo 80-luvulla siirtää ihmisiä rutiinien suorittamisesta tuottavampiin tehtäviin. Tämä tavoite ei ole vuosien kuluessa muuttunut mihinkään.

Prosessien automatisointia on siis tehty jo iät ja ajat ennen kuin RPA (Robotic Process Automation) “keksittiin”. Ohjelmistorobotiikassa automaatio perustuu yleensä ihmisten toiminnan simulointiin esimerkiksi nauhoittamalla tietojen syöttöä käyttöliittymän kautta. Ihmisten toiminnan simulointi on helppoa, mutta se on monissa tapauksissa väärä lähestymistapa. Miksi simuloida ihmistä käyttöliittymää käyttämässä jos voit simuloida itse prosessia suoraan rajapintojen päällä?

Miten RPA:ta tulisi käyttää?

Kun ohjelmistorobotiikka toteutetaan oikein, käytetään integraatioalustan prosessimoottoria ja ihmisen toiminnan simuloimista - esim. RPA-työkalun nauhoitusta - yhdessä.

RPA Done Right tarkoittaa, että käytetään oikeita välineitä integraatioon, orkestrointiin ja workflow-automaatioon. Silloin käytetään järjestelmien rajapintoja aina, kun se on mahdollista. Nauhoitusta käytetään silloin, kun tämä ei onnistu. Esimerkkejä tällaisista tapauksista on puuttuvat tai ikivanhat ja tehottomat rajapinnat tai käyttöliittymään upotettu logiikka.

Miksi rajapintoja pitäisi käyttää RPA-simuloinnin sijaan?

• Nopeus Simulointi ja nauhoittaminen on hidasta, koodin käyttäminen monta kertaa nopeampaa. Robotti simuloi ihmistä - kun oikea prosessiautomaatio simuloi suoraan prosessia. Se on tuhansia kertoja nopeampaa.

• Vikasietoinen integraatio Moni on varmasti nähnyt koneissa lappuja “robotti töissä, älä koske”. Nauhoituksissa prosessi katkeaa ja työt pysähtyvät, jos joku kesken ajon koskee vahingossa hiireen tai koneeseen tulee päivitys. Nykyisin yleisissä SaaS-palveluissa käyttöliittymät voivat muuttua yllättäen, kun palveluissa otetaan käyttöön uutta toiminnallisuutta. Käyttöliittymän muutokset sekoittavat robotin ajon. Rikkoontumisen ongelmaa korostaa syyn löytämisen työläys.

• Monikäyttöisyys Lähdeaineiston muodolla ei ole juurikaan väliä integraatioissa. Jopa Excel-taulukoita voidaan syöttää järjestelmiin sanomamuunnosten ja rajapintakutsujen avulla.

• Monitoroitavuus Prosessi-integraatioalustalla tehdyt ratkaisut tarjoavat visuaalisen näkymän jokaiseen prosessin suorituskertaan ja sen ajonaikaiseen sisältöön. Nauhoituksin tehdyt robotisaatiot ovat tähän verrattuna kuin mustia laatikoita, joista putkahtaa ulos vain lopputulos – joka voi olla haluttu tai väärä.

HiQ:n integraatiofilosofia tiivistyy FRENDS-integraatioalustaamme, joka on ohjelmistorobotiikkaa parhaimmillaan. Asiakas voi saada parhaat puolet molemmista maailmoista. Jos orkestrointi ja workflow-osuus on rakennettu FRENDS:in päälle, voi käyttöliittymänauhoituksia ajaa osana isompaa integraatioprosessia. Tällöin nauhoituksen ajoon riittää suoritusrobotti, eikä organisaation tarvitse hankkia esimerkiksi orkestrointimoduulia robottitoimittajalta. FRENDS:llä voi esimerkiksi ajaa UiPathin tai Blueprismin robotteja osana kokonaisintegraatiota.

HiQ tarjoaa kokonaisvaltaista prosessiautomaatiota, johon on sisällytetty robotiikka osaksi integraatioita ja API:en hallintaa.

Minkälaiset käyttötapaukset sopivat RPA:lle?

Alla on listattu joukko tapauksia, jotka erityisesti sopivat robotisoidun automaatiolle.

• Rajapintoja ei ole Iäkkäämmissä järjestelmissä ei ole tarvittuja rajapintoja, aina pelkkä tiedoston sisäänlukurajapinta ei riitä automaation loppuun asti viemiseksi.

• Automatisoitava operaatio on yhden käyttöliittymän sisällä Automatisoitava operaatio on esimerkiksi kahden kentän yhdistäminen yhden tai parin käyttöliittymän välillä - operaatio on hyvin yksinkertainen. Tässäkin on jo syytä varoa vikaherkkyyttä ja miettiä kuinka kriittisen asian laitat tällaisen perinteisen makronauhoituksen vaaraan?

• Liiketoimintalogiikka on upotettu käyttöliittymään Iäkkäämmät sovellukset ovat usein koodattu arkkitehtuurilla, missä logiikka ja käyttöliittymä ovat yhtä - liiketoimintatapahtuma on koodattu käytännössä vaikkapa napin painalluksen taakse käyttöliittymään. Nykyaikaisissa järjestelmissä näin ei ole, vaan käyttöliittymä on eristetty omaksi kerrokseksi ja se kutsuu uuden aikaisia rajapintoja (API), joissa myös logiikka suoritetaan. Näitä samoja rajapintoja (API) myös prosessiautomaatioon kykenevä integraatioalusta pystyy kutsumaan.

• Räikeästi hinnoiteltu rajapinta Osa perinteisten järjestelmien toimittajista tuntuu vieläkin ajattelevan rajapintoja ns. lisäominaisuutena, joista voi veloittaa suuria summia. Räikeästi lisähinnoitellun rajapinnan voi kiertää käyttämällä robottia jos suorituskykyvaateet eivät integraatiolle ole kovin suuret.

Webinaaritallenne

Lataa webinaaritallenne aiheesta: "RPA:sta hyperautomaatioon ja IPAan" (45min)

Lataa lyhyt oppimäärä: "RPA:sta hyperautomaatioon" (12min)