Digityöntekijä – 0 – 100 km/h sadassa päivässä

Sanotaan, että digityöntekijän (ohjelmistorobotiikan) käyttöönotto on helppoa. Projektit ovat lyhyitä ja vaivattomia ilman byrokratiaa. Mikä tahansa organisaation rutiineista automatisoituu käden käänteessä vain muutamassa viikossa. Lopultakin voimme liiketoiminnan puolella unohtaa IT-budjetit ja pitkät toivomuslistat, joita tietohallinto ei kuitenkaan koskaan saa täysin toimitettua. Vai onko se sittenkään näin helppoa? No, tavallaan on, tavallaan ei.

Skaalautuvuutta ja toistettavuutta etsimässä

Digityöntekijöiden opettaminen (automaatioskriptien tekeminen) on periaatteessa helppoa ja nopeaa. Kunhan ensin on löydetty oikeat kohdeprosessit ja mietitty esimerkiksi, miten automaatio saattaa muuttaa prosessia tai miten prosessien poikkeamat käsitellään. Ja päätetty, kuinka ihmiskollegoiden rooli muuttuu tiimissä, kun digityöntekijä tekee puuduttavat rutiinit jättäen ihmisille aikaa ajatteluun ja luovaan työhön. Ennen kuin digityöntekijä on aidosti skaalautuva, tarvitaan myös tekninen alusta, josta voi tilata uusia digityöntekijöitä sormia napsauttamalla.

Todellinen ”hauskuus” alkaa siinä vaiheessa, kun perusjärjestelmiin tehdään versionpäivityksiä ja vasta toteutetut kymmenet prosessiautomaatiot lakkaavatkin toimimasta. Tässähän muistuu ihan mieleen IT:n alkuajat (tai ATK:ksi sitä kai silloin kutsuttiin). Silloin oltiin todella luovia ja kovat IT- kundit olivat varsinaisia sankareita. Kaikki tiesivät, että Jaskan lomaillessa kukaan muu ei osaa operoida järjestelmiä. Ei kuulosta oikein hyvältä tavalta automatisoida liiketoiminnalle kriittisiä prosesseja.

Jos et tiedä minne olet menossa, kaikki tiet johtavat sinne

Organisaatiot eivät palkkaa digityöntekijöitä vain huvin vuoksi (vaikka se on tosi mukavaa, usko pois!). Digityöntekijältä halutaan konkreettisia tuloksia: parempaa tehokkuutta, parempaa laatua tai vaikkapa suurempaa lisäarvon tuottoa asiakkaille. Mikä ikinä onkaan tavoite, voit olla varma, että se ei toteudu itsestään. Heti matkan aluksi on syytä miettiä, mitä tavoittelee ja rakentaa saman tien toimintamalli, joka toteuttaa tavoitteen.

Digityöntekijä on oikein käytettynä äärimmäisen tehokas ja joustava työkalu. Mutta myös kaikkein joustavimmatkin työkalut tarvitsevat käyttöohjeet, johtamista ja malleja. Jos työkalu on niin helppo, että kuka tahansa osaa sitä käyttää, voit olla varma, että ennen silmänräpäytystä organisaatioon on syntynyt satoja näppäriä automaatioita – joista valitettavasti moni lopettaa toimintansa seuraavassa ERP- päivityksessä kunnes ne on konfiguroitu uudelleen.

Digityöntekijää pitää johtaa, eihän ihmisiäkään saa jättää ilman tukea

Kuvitellaanpa hetki ihmisistä koostuvaa organisaatiota ilman sääntöjä tai tavoitteita. Jokainen saisi tehdä mitä haluaa ja miten haluaa sopimatta mitään kollegoidensa kanssa. Jotenkin epäilen, että tästä organisaatiokokeilusta ei tulisi kovin menestyksekästä tai pitkäikäistä. Nykyään puhutaan paljon itseohjautuvasta organisaatiosta ja tiimeistä sekä Teal organisation/Holakratia- tyyppisistä orgaanisista rakenteista. Kannattaa muistaa, että ne ovat varsin kaukana anarkiasta. Niissä organisaatiolle on asetettu selkeä tavoite ja pyhät perussäännöt, joiden mukaan pelataan. Samalla tavalla digityöntekijä kaipaa ympärilleen johtamista ja selkeitä tavoitteita. Digityöntekijät kun eivät valitettavasti osaa organisoitua itsekseen ilman ohjausta, eivät ainakaan vielä.

Kuinka päästä piloteista aidosti tuottavaan toimintaan?

Monet organisaatiot ovat kokeneet huikeaa euforiaa onnistuneista piloteista. Tunnelma vaan on tupannut pahasti lässähtämään, kun tosielämän tulokset ovatkin osoittautuneet lopulta aika vaatimattomiksi, eivätkä liiketoiminnalliset tavoitteet ole toteutuneet. Usein tämä johtuu siitä, että digityöntekijän käyttöönottoa ei ole tavoitteellistettu riittävästi. Eikä olla muistettu rakentaa aidosti skaalautuvia teknisiä alustoja eikä toimivia johtamis- ja organisoitumismalleja.

Me Digital Workforcessa olemme nähneet liian monen asiakkaan kärsivän liian hitaasta digityöntekijän tuottavuuskäyrän käynnistymisestä. Kun mietitään heti alusta alkaen mitä tavoitellaan, loppu oikeastaan hoituukin aika helposti: asetetaan visio ja tavoitteet, ja niistä johdetaan tarvittavat toimenpiteet. Tarvitaan toimiva ja skaalautuva alusta. Tarvitaan toimivat priorisointi- ja päätöksentekomallit. Tämä ei ole varsinaisesti rakettitiedettä, mutta silti jokaisen organisaation täytyy miettiä asia läpi omaan toimintaansa sopivaksi. Ja liian monelta tuo mietintä on jäänyt tekemättä. Jos kuulostaa tutulta ja tuntuu, että saippuapala välillä karkaa käsistä, istutaan alas ja jutellaan hetki.

Siirry suoraan kiihdytyskaistalle

Digital Workforce on jo tehnyt tämän matkan usean organisaation kanssa. Yhdessä asiakkaiden kanssa on koettu tuskaa ja hienoja oivalluksia. Näistä kokemuksista olemme kiteyttäneet opit, miten digityöntekijää pitää johtaa pohjoismaisessa kulttuuri- ja IT-ympäristössä. Olemme tuotteistaneet 100 päivän digityöntekijän käynnistysohjelman, jonka avulla siirryt satunnaisten pilottien ja kokeilujen kierteestä aitoon tuottavuuteen ja organisoituun itsensä rahoittavaan robotiikan kehitysohjelman pariin sadassa päivässä. Haluatko lisätietoja? Ota meihin yhteyttä!

Jari Annala: jari.annala@digitalworkforce.fi / p. +358(0) 400 33 85 85

 

Kohtaa tulevaisuuden haasteet digityöntekijä rinnallasi! Ota meihin yhteyttä ja selvitä automaation potentiaali omassa organisaatiossasi jo tänään. 

Artikkeli: Jari Annala –Digital (R)evolutionist, Digital Workforce
Kuva KeWynn Lee lisenssillä CC BY 2.0

Lyhyt opas RPA:n maailmaan: Automatisoitavien prosessien tunnistaminen työpaikalla

Miten lähestyä ohjelmistorobotiikkaa?

Ohjelmistorobotiikka on suhteellisen tuore ilmiö, joka yleistyy hyvää vauhtia. Nimi on hieman harhaanjohtava – ohjelmistorobotiikka ei tarkoita sitä, että toimistoon tulee liuta robotteja korvaamaan ihmistyöntekijöitä. Paino on nimenomaan sanalla ohjelmisto: tietokoneohjelma, joka mallintaa ihmisen toimintaa. Mutta juuri robotti-sanan luoma, ehkä jopa hieman uhkaava ja futuristinen mielikuva saattaa herättää vastarintaa – kuten muutos yleensä.

Seuraavia vaiheita noudattamalla pystytään selvittämään, olisiko ohjelmistorobotiikasta hyötyä omalle organisaatiolle. Selvityksen voi tehdä yksin tai yhdessä tiimin kanssa. Joka tapauksessa, mukaan ei välttämättä tarvita konsultteja, vaan selvitys voidaan tehdä itsenäisesti ilman sitoutumispaineita.

Joten miksei tutkia asiaa? Vaikka lopputulos olisikin se, ettei ohjelmistorobotiikkaan kannata lähteä, on prosesseihin tutustuminen aina hyödyllistä, kuten kohta huomataan.

Potentiaalisesti automatisoitavien prosessien valitseminen

Selvitys alkaa pienistä ja yksinkertaisista prosesseista.

Jos ei ole koskaan määritellyt prosesseja, niiden määrittelyn hankaluuden aliarvioi helposti. Vaikka prosessi olisi miten pieni, sen tarkka määrittely kaikkine yksityiskohtineen ja poikkeuksineen on yllättävän iso urakka.

Jos prosessien määrittely on tuttua puuhaa, prosessien automatisointi silti hyvä aloittaa pienestä. Mitä loogisempi ja yksinkertaisempi prosessi on, sitä nopeampi se on toteuttaa ja sitä vikasietoisempi se on.

Valittavien prosessien tulee olla sellaisia, että niiden automatisoinnista on jotain hyötyä. Ärsyttävät, usein toistuvat prosessit ovat hyviä ehdokkaita. Prosessit, joita kukaan ei halua tehdä, mutta jotka nyt vain on pakko hoitaa päivittäin tai vähintään viikoittain. Jos tällaiset prosessit lopulta automatisoidaan, harva tulee valittamaan asiasta.

Huomaa sanan ”jos” käyttö. Kaikkia prosesseja ei kannata automatisoida, vaikka ne aluksi vaikuttaisivatkin tähän sopivilta. Joissain prosesseissa tarvitaan jatkuvasti ihmistä tekemään päätöksiä jatkotoimenpiteissä. Toisissa tapauksissa prosessi itsessään paljastuu liian monimutkaiseksi ja raskaaksi määritellä suhteessa ajojen toistuvuuteen. Tällöin  investointi automatisointiin ei ole perusteltu. Näin käy erityisesti, jos prosessia saadaan yksinkertaistettua muilla keinoin. Syitä voi olla monia. Alkuvaiheessa onkin suositeltavaa tarkastella useampaa prosessia samaan aikaan.

Prosessien määrittely

Kun potentiaaliset prosessit on valittu, tulee ne määritellä. Määrittelemätöntä prosessia on mahdotonta automatisoida.

Aluksi prosessin kanssa tekemisissä olevat henkilöt, eli alansa asiantuntijat, kerätään yhteen huoneeseen ja määritellään prosessi yhdessä.

Ensimmäiseksi määritellään prosessin alku- ja loppupiste. Esimerkiksi rekrytointiprosessi voidaan katsoa alkaneeksi, kun huomataan tarve uudelle työntekijälle, kun työpaikkaa on mainostettu, tai kun ensimmäinen työhaastattelu alkaa. Vastaavasti sen voidaan katsoa päättyneen, kun viimeinen työhaastattelu loppuu, työntekijä hyväksyy työtarjouksen, tai työntekijä aloittaa ensimmäisen työpäivänsä. Alku- ja loppupisteen määrittäminen varhaisessa vaiheessa auttaa osapuolia keskittymään prosessin olennaisiin osiin.

Sanotaan, että yllämainitussa esimerkissä alkupisteeksi määritetään ensimmäisen haastattelun alku ja loppupisteeksi viimeisen haastattelun loppu. Tässä tapauksessa koko rekrytointiprosessista jää paljon tarkastelun ulkopuolelle. Tämä saattaa kuulostaa haaskaukselta, mutta tiiviimmän osan tarkasteluun menee huomattavasti vähemmän aikaa ja siihen keskitytään kokonaisvaltaisemmin.

Määrittelyvaiheen lopussa pitäisi syntyä yksityiskohtainen prosessikuvausdokumentti, jonka pohjalta voidaan tehdä jatkokehitystä.

Prosessien seuraaminen käytännössä

Kun prosessi on määritelty, kannattaa varmistaa määrittelyn paikkansapitävyys Jos määrittelyn ja käytännön välillä on eroja, määrittelyä tulee päivittää vastaamaan käytäntöä. Usein ihmiset kertovat toimivansa tietyllä tavalla, mutta toimivatkin käytännössä eri tavalla. Prosessin määrittelystä ei ole mitään hyötyä, jos se ei vastaa todellisuutta.

Prosessien parantelu

Kun prosessi on varmasti määritelty tarkasti ja osuvasti, on aika tarkastella sitä kriittisesti. Onko prosessia mahdollista parantaa? Löytyykö siitä pullonkauloja tai muita ongelmakohtia? Voiko sitä tehostaa? Onko esimerkiksi mahdollista nopeuttaa joitain vaiheita tai suorittaa joitain vaiheita samanaikaisesti, kun ne on aiemmin suoritettu peräjälkeen?

Aikamääreet vaikkapa vastauksia ja reaktioita odotettaessa on syytä arvioida tarkasti. Esimerkiksi myyjät voivat joskus olla epätietoisia siitä, miten kauan odottaa vastausta ja milloin soittaa tarjouksen perään. Myös se, milloin vastuu siirretään päätäntävallassa korkeammalle henkilölle, esimerkiksi asiakaspalvelutapauksissa, on hyvä määrittää tarkasti.

Paranteluvaiheessa selvitetään, mitkä prosessin osat, jos mitkään, voidaan automatisoida.

Prosessin jatkoparantelu asiantuntijoiden kanssa

Analysoitu ja paranneltu prosessi, käydään läpi yhdessä asiantuntijoiden kanssa, jotka osallistuivat alkumäärittelyyn. Heiltä saadaan palautetta, jonka perusteella prosessia parannellaan entisestään.

Tämän vaiheen päätteeksi nämä asiantuntijat laativat lopullisen version dokumentista, joka määrittelee uuden vakiotoimintamenettelyn. Syntyneen dokumentin avulla voidaan mm. perehdyttää uusia työntekijöitä tulevaisuudessa.

Jos joku prosessin osa päätetään automatisoida, aloitetaan automatisointi.

Vaikka määritelty prosessi ei soveltuisi automatisoitavaksi se on silti määritelty paremmin ja ehkäpä muokattu paremmaksi kuin ennen. Näin ollen se on tehokkaampi ja mukavampi niille, jotka sitä suorittavat. Lisäksi, on opittu huomattavasti prosessien määrittelystä ja siitä, millaiset prosessit sopivat automatisoitavaksi.

Artikkeli Emma Luukka – RPA Solutions Consultant, Digital Workforce
Kuva WOCinTech Chat lisenssillä CC BY 2.0

”Ohjelmistorobotti sairaalassa on terve ratkaisu!”, Birminghamin yliopistollisen sairaalan IT-johtaja Stephen Chilton

Digital Workforce osallistui Terveydenhuollon Teknologiapäiville 24.-25.5. Lahdessa sekä organisoi tapahtuman yhteyteen oman kutsuvierastilaisuutensa. Tiistai-illan cocktail-tunnille saapui valikoitu joukko kuulemaan Tekesin rahoittaman tuoreen tutkimuksen tuloksia sekä korkeasti arvostetun vieraspuhujan ajatuksia RPAsta. Birminghamin yliopistollisen sairaalan IT-johtaja, Stephen Chilton jakoi kokemuksensa lähes kymmenen vuoden matkalta ohjelmistorobotiikan parissa.

Cocktail-tilaisuuden avasi Heikki Länsisyrjä, jonka puheenvuoron päätteeksi Mika Vainio-Mattila esitteli vasta julkaistun tutkimuksen löydökset. Tutkimuksen mukaan yli 70% terveydenhuollon ammattilaisista kokee päätteellä tehtävän tietyön vievän aikaa pois varsinaisesta potilastyöstä. Vastanneista lääkäreistä 30% kertoi käyttävänsä yli 6h/ vuoro tietojärjestelmien parissa. Kerättyjen vastausten pohjalta oli nähtävissä tietotyön määrän entisestään lisääntyneen viimevuosien aikana.

Järjestelmien välisen integraation puutteen vuoksi, vastaajat kertoivat kirjaavansa samaa tietoa moneen paikkaan. Päällekkäisten kirjausten laskettiin aiheuttavan suorina palkkakustannuksina vuosittain noin 54 MEUR menon tutkimukseen osallistuneissa yhdeksässä sairaanhoitopiirissä. DWN arvioi että 2-10% kaikesta terveydenhuollon tietotyöstä voitaisiin automatisoida. Tämän tason automaatio synnyttäisi Suomessa noin 300-600 MEUR säästöt sekä mahdollistaisi korkeasti koulutettujen ammattilaisten keskittymisen työn keskeisimpiin alueisiin.

Stephen Chilton avasi robotiikan tarjoamaa potentiaalia entisestään viitaten omiin kokemuksiinsa edustamassaan organisaatiossa. Birminghamin yliopistollinen sairaala palvelee vuosittain noin 900 000 potilasta ja tämä luku on jatkuvassa nousussa. Chilton kertoi RPAn vapauttaneen resursseja sairaalan asiakkaiden käyttöön. Potilaslukujen vuosittain kasvaessa, ei digitaalisen työvoiman määrää ole tarvinnut lisätä vastaavassa suhteessa.

Birminghamin Yliopistollisen Sairaalan etsiessä kustannustehokasta ratkaisua It:n hallintaan vuonna 2007, terveydenhuoltoalan tulokasyritys, Blue Prism esitti vaihtoehdoksi ohjelmistorobotiikkaa. Tästä ajasta lähtien RPA on osoittanut arvonsa kattaen yhä kasvavan määrän prosesseja ja toimintoja sekä kehittäen kyvykkyyksiään omavaraisesti.

Chilton kertoi kuinka 2010 valmistuneen uuden sairaalan vastaanottotilan suunnittelussa ei oltu huomioitu päivittäisen potilasliikenteen määrää. Tilaan oli rakennettu kaksi vastaanottotiskiä, joiden tehtäväksi tuli kirjata päivittäin 2000-25000 henkilön virta. Mahdoton tehtävä tuli ratkaista jollakin tavalla. Pohdintojen tuloksena toteutettiin automatisoitu kioski-pohjainen check-in malli, johon Blue Prism toimitti ohjelmistot. Menestyksekkäästä ratkaisusta tuli oma kaupallinen innovaationsa, jonka myynnistä Birminghamin yliopistollinen sairaala kerää rojaltin.

Toisessa tapauksessa Chilton kertoi, kuinka sairaalan toimintaa seurataan keskitetysti NHS Englannin sekä sosiaali-ja terveysministeriön toimesta. Dataa kerätään seurantatarkoituksessa sisäisesti, jonka jälkeen koottu tieto siirretään vastaanottajan järjestelmään. Vastaanottajan järjestelmä oli kuitenkin suljettu, minkä vuoksi raporttia ei voitu lähettää järjestelmästä toiseen vaan kerätty tieto tuli uudelleen kirjattavaksi sairaalahenkilökunnan toimesta. Ohjelmistorobotiikka valittiin korvaamaan kuormittava ja kallis manuaalinen työ. Myöhemmin, RPA:ta sovellettiin myös lähetteiden, testitulosten ja sairaskertomusten siirtoon kansallisen- ja sairaalan järjestelmän välillä. Automaation avulla saavutettiin säästöjä palkkakustannuksissa, eliminoitiin kalliit virheet ja tehostettiin muuta toimintaa.

Chilton huomautti, että sujuvan toiminnan takaamiseksi eri järjestelmien välinen informaation kulku on ensiarvoisen tärkeää. Kuitenkin, integraation toteuttamisen hinta on usein kohtuuttoman korkea. Esimerkiksi, Birminghamin yliopistollisessa sairaalassa lääkkeiden saatavuutta tarkkaillaan seurantajärjestelmän kautta. Fyysisesti lääkkeet ovat kuitenkin varastossa, jossa käytössä on erillinen varaston seurantajärjestelmä. Järjestelmät ovat keskenään yhteensopimattomat, joten tiedonsiirrossa nojattiin manuaaliseen työhön. Sairaala lähestyi molempia ohjelmistotoimittajia integraation rakentamiseksi ja sai tarjouksen, jossa hinnaksi esitettiin 20000 GBP/ toimittaja sisältäen 6kk kehitysvaiheen. Torjuttuaan tarjouksen, sairaala päätyi käyttämään ohjelmistorobotiikkaa järjestelmien väliseen tiedonsiirtoon. Toteutuksen hinta oli tarjouksessa esitetystä murto-osa ja käyttöönotto tapahtui 7-8 päivässä. Tänä kalenterivuonna Chilton arvioi ohjelmistorobotiikan käytön säästävän organisaatiolle 175000 GBP suorissa palkkakustannuksissa joka tunti ja 1,7-2,2 MGBP muissa vältetyissä kuluissa.