Miten valita kuumilta markkinoilta juuri se omalle organisaatiolle sopiva ohjelmistorobotiikan (Robotic Process Automation, RPA) teknologia? Olisiko isojen kaupallisten toimijoiden lisäksi kenties vaihtoehtona vielä joku muu – vaikkapa avoimeen lähdekoodiin perustuva ratkaisu? Tässä kirjoituksessa vertailemme kaupallisen ja avoimen RPA-teknologian eroja, jotta valinta olisi sinulle helpompi.
RPA-ekosysteemien kilpailu: helppous vs. kyvykkyys
Enterprise Grade on kaupallisten RPA-teknologiatarjoajien suuri lupaus. UiPath, BluePrism, Automation Anywhere, Workfusion ja Pegasystems ovat varmasti jokaiselle ohjelmistorobotiikan kanssa toimivalle tuttuja nimiä, mutta mitä nämä eri teknologiat käytännössä loppukäyttäjälle tarjoavat? Avainsana tässä yhteydessä on nimenomaan teknologia, joka ei itsessään tuo lisäarvoa yrityksen toimintaan.
Kaupallisten teknologioiden tarkoituksena on yleensä luoda kumppaneiden voimalla oma, varsin suljettu platform-ekosysteemi, jonka päälle kaikki toiminnallisuus rakennetaan. Kokonaisuudet ovat eri toimijoilla vielä hyvin samankaltaisia sekä kyvykkyyksien että hinnoittelunkin suhteen. Ekosysteemi tarjoaa käyttäjälle helposti yhdestä paikasta niin työkalut, tuen kuin koulutuksen. Rajoitteena näissä usein on kuitenkin se, että mikäli haluttua toiminnallisuutta ei valmiista ratkaisusta löydy, voi sen mukaan tuominen olla hankalaa tai jopa käytännössä mahdotonta.
Avoimen ekosysteemin voima taas perustuu käyttäjiin: kenellä tahansa on mahdollisuus tuottaa arvoa kokonaisuuteen. Esimerkiksi Python- ja Robot Framework -ekosysteemeistä löytyy valtava määrä avoimen lähdekoodin vaihtoehtoja erilaisten toiminnallisuuksien luomiseen. Tämä kokonaisuus ylittää minkä tahansa kaupallisen ekosysteemin kyvykkyydet, jos vain tietää, miten ja mistä etsiä.
Python on tällä hetkellä suosittu ja puhuttu ohjelmistokehityksen kieli, joka tarjoaa mahdollisuuksia ja valmiita kirjastoja keinoälyn ja koneoppimisen puolella. Suosituimmat koneoppimisen kirjastot ovatkin avoimen lähdekoodin Python-pohjaisia ratkaisuja, jotka integroituvat saumattomasti Python-pohjaiseen RPA-ratkaisuun. Tänä päivänä uskottavan RPA-ratkaisun ja -toimittajan tulee pystyä laajentamaan toiminnallisuutta koneoppimisella, mikä on yksi ajankohtainen esimerkki Enterprise Grade -integroitavuudesta.
Teknologian arvo mitataan sillä, miten se vastaa liiketoiminnan tarpeisiin ja mitä se RPA-kentällä mahdollistaa mm. integraatiokyvykkyyksien ja tehokkuuden suhteen. Tällä ei tarkoiteta pelkästään RPA-teknologian integroitavuutta, vaan koko ekosysteemin integroitavuutta yrityksen toimintamalliin, kokonaisarkkitehtuuriin ja muihin teknologioihin.
Ohjelmistorobotin käsite – keinotekoisesti luotu rajoite?
Kaupallisten toimijoiden lisenssipohjaiset mallit ovat määritelleet omanlaisensa käsitteen siitä, mikä ohjelmistorobotti on. Näiden mallien mukaan ohjelmistorobotti toimii kuin ihminen, jolloin robotti (samoin kuin robottilisenssi) voi maksimissaan työskennellä 24 tuntia vuorokaudessa, 7 päivää viikossa. Käsite on täysin keinotekoinen ja hullunkurinen, kun loppupeleissä on kuitenkin kyse tietokonesovelluksesta.
Avoimen lähdekoodin ohjelmistorobotiikka skaalautuvasta pilvi-infrastruktuurista toimitettuna kääntää tämän mallin päälaelleen: kapasiteetti voidaan määrittää täysin prosessin tarpeiden mukaisesti sekä suorittavien ohjelmistorobottien määrän että suoritusajan suhteen. Se, mikä voisi viedä useita tunteja tai jopa päiviä yhdeltä pitkää päivää painavalta lisenssipohjaiselta robotilta, voidaan työstää minuuteissa kymmenillä tarpeen mukaan käynnistettävillä avoimen lähdekoodin roboteilla.
Tehokkuuden lisäksi lopputulos on myös edullisempi, koska lisenssikustannuksia tai robottien käyttöastetta ei tarvitse huomioida. Ohjelmistorobotin oikean käsitteen tulisikin olla ennen kaikkea automaation mahdollistava sovellus, joka tukee liiketoimintaa ja mahdollistaa, että ohjelmistorobotiikan hanke fokusoi ajatukset nimenomaan liiketoiminnan tarpeisiin, ei kustannuksiin tai käyttöasteiden optimointiin. Olemme huomanneet, että myös yritykset ovat koko ajan enemmän ymmärtämässä tämän määritelmän päälle. Tämä on osaltaan myös ajanut kaupalliset toimijat ja kumppanit mahdollistamaan uusia joustavampia palvelun hinnoittelumalleja.
Visuaalinen kehitystyökalu – markkinointia vai tehokkuutta?
Kaupallisten ratkaisujen iso markkinointivaltti on robottien kehitystyökalujen graafinen käyttöliittymä, jota periaatteessa kuka tahansa tietokonetta käyttävä pystyy pikaisen koulutuksen jälkeen jotenkin ymmärtämään ja käyttämään. On totta, että graafinen ulkoasu ja visualisointi tuo tehokkuutta ja läpinäkyvyyttä ohjelmistorobotiikkahankkeeseen, mutta ei niinkään kehittäjien kannalta. Visuaalisuus tehostaa hankkeen prosessien ja tehtävien määrittelyä, analysointia ja priorisointia.
Myös isompien projektien toteuttaminen hallitusti, skaalautuvasti ja ylläpidettävästi vaatii paljon syvempää ohjelmistokehityksen tuntemusta, kuin mitä kaupallisten ratkaisujen koulutukset tarjoavat. Devaajille koodien ja skriptien kirjoittaminen graafisuuden sijaan on usein paljon ilmaisuvoimaisempi ja tehokkaampi tapa tuottaa toimiva ratkaisu ja saumaton kokonaisuus. Ja vaikka kaupalliset työkalut ovatkin perusteiltaan graafisia ja visuaalisia, vaatii tehokas robottien kehitys myös niiden kanssa aina skriptien ja koodinpätkien kirjoittamista.
Ohjelmistokehityksen parhaat käytännöt mukaan ohjelmistorobotiikkaan
RPA-projekti on kuin mikä tahansa muu moderni ohjelmistokehityksen hanke, jossa kannattaa edetä ketterästi ja läheisesti asiakkaan ja toimittajan välillä projektipalasia iteroiden. Oli sitten kyse kaupallisesta teknologiasta tai avoimesta lähdekoodista, samat lainalaisuudet ja käytännöt pätevät. Tämä tarkoittaa mm. yksittäisten prosessien palastelua järkeviin osakokonaisuuksiin niin, että liiketoimintasäännöt ja -logiikka on selkeästi eroteltu palasista, joiden kautta esimerkiksi integroidutaan kohdesovelluksiin.
Kokonaisuuteen pitää siis sisällyttää hallittavuus ja uudelleenkäytettävyys. Suurimmalla osalla kaupallisista toimittajista on oma “komponenttipankki”, josta voi ladata valmiita omiin tarpeisiin konfiguroitavia prosessimallipohjia ja -palasia. Yksi lähtökohta skaalautuvalle ja ylläpidettävälle ohjelmistorobotiikan kokonaisuudelle onkin pyrkiä rakentamaan jokainen prosessi samaan malliin. Tällä osaltaan varmistetaan mm. hallittavuus ja tiedonsiirto eri tiimiläisten välillä. Avoimella lähdekoodilla taas koko ekosysteemi ja sen useat tuhannet käyttäjät ovat yksi valtava pankki, jossa vaadittu toiminnallisuus on usein jo jonkun toteuttama ja ladattavissa avoimesti muiden käyttöön.
DevOps, eli testiautomaation ja julkaisun putkittaminen jatkuvaan integraatioon sovelluskehityksen rinnalle, on osa modernia tehokasta ohjelmistokehitystä ja toimii yhtä lailla myös RPA-projektissa. Kehityksen tehokkuudesta ei juurikaan puhuta ohjelmistorobotiikan yhteydessä, vaan keskitytään enemmän uusiin automaatio- ja AI-ominaisuuksiin ja oikeanlaisen Center of Excellencen pystyttämiseen. Avoimen lähdekoodin Jenkins-työkalu on yksi alan käytetyimpiä DevOps-työkaluja ja se sopii loistavasti myös avoimen lähdekoodin ohjelmistorobottien orkestrointiin ja hallintaan. Kun julkaisu, testiautomaatio ja robottien orkestrointi saadaan kätevästi saman työkalun alle, eivät kaupalliset työkalut pysty tarjoamaan – ainakaan vielä – samanlaista integroitavuutta ja kehityshankkeen kokonaisuuden hallinnointia.
Ohjelmistorobotiikan skaalautuminen on tunnistettu haaste
Ohjelmistoja ja kehityshankkeita halutaan ostaa yhä enemmän palveluna, jossa toimittaja vastaa sekä hankkeen leveydestä (teknologia, arkkitehtuuri, infrastruktuuri ja näiden osaaminen) että syvyydestä (hankkeen elinkaari käynnistämisestä ylläpitoon ja jatkuviin palveluihin). Asiakas maksaa palvelusta yleensä kuukausittaista palvelumaksua. Lisenssejä ja infraa ei haluta enää hallita itse, ja varsinkin sitoutuminen useiksi vuosiksi yhteen lisenssiin tai toimittajaan ei ole enää nykypäivää digitaalisissa palveluissa tai teknologioissa. Riskit mahdollisista vendor-lukoista tai yllättävistä lisenssiehtojen tai -hintojen muutoksista halutaan minimoida. Projektia halutaan vielä eteenpäin dynaamisesti ja ketterästi ja halutaan myös varmistaa hankkeen hyödyt mahdollisimman varhaisessa vaiheessa.
Dynaamisesti ja ketterästi eteneminen ei tarkoita lyhytnäköisyyttä. Jo alkuvaiheessa kannattaa ottaa huomioon myöhempi skaalautuminen ja rakentaa arkkitehtuuri sekä valita teknologia tätä tukemaan. Kaupalliset toimittajat tarjoavat erilaisia lisensointivaihtoehtoja, joiden kanssa voi alkuun lähteä liikkeelle huokealla lisenssimallilla ja laajentaa tarpeiden kasvaessa. Tämä on periaatteessa hyvä asia, mutta käytäntö on osoittanut, että erilaiset lisenssivaihtoehdot ja -rajoitteet aiheuttavat hämmennystä ja myös pettymystä tuettujen ominaisuuksien suhteen. Avoin lähdekoodi tarkoittaa lisenssivapautta ja mahdollisuutta käyttää ratkaisua rajattomasti ja haluttaessa vaikka loputtomasti skaalaten.
Jälleen kerran palataan siihen, mikä on oleellista: teknologian tulee tukea tavoitteita ja auttaa fokusoimaan liiketoimintahyötyihin ja toiminnan tehostamiseen. Lisenssivapaa avoimen lähdekoodin teknologia poistaa nämä rajoitteet. Olemme eri asiakkaiden kanssa nähneet, että panostaminen skaalautuvaan teknologiaan ja arkkitehtuuriin heti hankkeen alkuvaiheessa on tuonut nopeimmin parhaat hyödyt. Myöhemmin automaatiota on saatu laajennettua tehokkaasti eri liiketoimintayksiköihin ja toimintoihin.
Ohjelmistorobotiikan hankkeeseen liittyy myös paljon teknologiasta erillään olevia riskejä – tai sanotaanko ennemmin haasteita. Nämä liittyvät etenkin organisaation muutoshallintaan, oikeiden roolien ja Center of Excellencen muodostamiseen ja ylipäänsä ihmisten valmiuksiin ottaa automaatio mukaan päivittäiseen työhön ja päätöksentekoon. Näistä kerromme tarkemmin myöhemmin toisessa kirjoituksessa.
Kaupallinen vai avoin RPA-ratkaisu? Kaikille on paikkansa.
Huomasit varmaan, että toistaiseksi tässä blogissa on ollut vahva avoimen lähdekoodin bias. Blogin tarkoituksena ei kuitenkaan ole arvostella kaupallisia toimijoita tai teknologioita. Kaikille on paikkansa ja valmiin “RPA-paketin” lisäksi kaupallisen tuotteen oppiminen ja omaksuminen voi ei-ohjelmointitaustaiselle henkilölle olla helpompaa kuin esimerkiksi Robot Frameworkin ja Python-pohjaisen järjestelmän haltuunotto.
Kaupalliset toimijat näyttävät usein myös suuntaa, johon ohjelmistorobotiikka on menossa ja mitä se voi mahdollistaa asiakkaille liiketoiminta-alueesta tai -sektorista riippumatta. Joskus voi myös olla perusteltua rakentaa avoimen lähdekoodin ja kaupallisen teknologian hybridi, jossa hyödytään parhaiten molemmista vaihtoehdoista.
Teknologialla ei kuitenkaan ole asiakkaalle loppupeleissä niin suurta merkitystä silloin, kun ohjelmistorobotiikka ostetaan palveluna. Merkitys ja arvo syntyy, kun teknologialla tuotetaan haluttu lopputulos aikataulussa ja kun pysytään budjetissa. Suomessa on ohjelmistorobotiikan markkinoilla nykyisin useita eri toimittajia, jotka tarjoavat RaaS-palvelua (Robotics-as-a-Service) joko kaupallisella tai avoimella lähdekoodilla toteutettuna. Teknologian lisäksi eri toimittajat hinnoittelevat palveluitaan eri tavoilla. Näin ollen jokainen asiakas voikin itse pohtia sopivinta mallia ja kumppania omaan toimintaansa nähden. Avoimen lähdekoodin ohjelmistorobotiikkaan tuo uusia mahdollisuuksia esimerkiksi Robocorp Technologies ja heidän Robocloud-alustansa, joka keskittää avoimen lähdekoodin ohjelmistorobotiikan hallinnan, orkestroinnin ja analytiikan yhden pisteen alle.
Mitä tästä kaikesta pitäisi etenkin ohjelmistorobotiikkaa harkitsevien pohtia päätöksenteossa? Ehkäpä oleellisin asia on se, että sekä teknologiaa että toimittajaa valittaessa on hyvä keskittyä isoon kuvaan, eikä mennä eteenpäin pelkän RPA-teknologian ja -osaamisen vimmassa. Kuten sanottu, Enterprise Grade ei ole teknologia, vaan erilaisten systeemien, kokonaisarkkitehtuurien, pilvi-infrastruktuurin ja teknologioiden ymmärtämistä ja yhteensovittamista – juuri sitä, mitä ohjelmistorobotiikkahanke myös todellisuudessa on.
Avoin lähdekoodi on tullut ohjelmistorobotiikkaan jäädäkseen.
Kirjoittaneet
Erno Pirinen ja Timo Kostamo