![rpa-ohjelmistorobotiikka rpa-ohjelmistorobotiikka](https://digitalworkforce.com/wp-content/uploads/2016/08/rpa-ohjelmistorobotiikka.jpg)
Lyhyt opas RPA:n maailmaan: Automatisoitavien prosessien tunnistaminen työpaikalla
Miten lähestyä ohjelmistorobotiikkaa (RPA)?
Ohjelmistorobotiikka (Robotic Process Automation, RPA) 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.
Lue lisää ohjelmistorobotiikka (RPA)
Artikkeli Emma Luukka – RPA Solutions Consultant, Digital Workforce