Andreas Mällinen 

Asiakastiedottamisen automatisointi 

 

 

 

 

 

 

 
  

Vaasa 2021 

Tekniikan ja innovaatiojohtamisen yksikkö 
 

Tietojärjestelmätieteen Pro gradu -tutkielma 



2 

 
 
 

VAASAN YLIOPISTO 
Tekniikan ja innovaatiojohtamisen yksikkö 
Tekijä:    Andreas Mällinen 
Tutkielman nimi:  Asiakastiedottamisen automatisointi 
Tutkinto:    Kauppatieteiden maisteri 
Oppiaine:   Tietojärjestelmätiede 
Työn ohjaaja:   Teemu Mäenpää 
Valmistumisvuosi:  2021  Sivumäärä:  78 
 

TIIVISTELMÄ: 
 
Asiakaspalvelu vaikuttaa merkittävästi yrityksen menestymiseen, sillä toimiva asiakaspalvelu voi 
tuoda yritykselle merkittävää kilpailuetua. Toimivan asiakaspalvelun kannalta yksi aikaa vievim-
mistä ja tärkeimmistä tehtävistä on toimiva asiakastiedottaminen. Asiakastiedottamisen tärkeys 
perustuu asiakkaiden tarpeeseen pysyä tietoisena palveluiden etenemisestä. Kun kyse on asiak-
kaiden omaisuuteen liittyvistä palveluista, tiedottamisen tarve korostuu. Rakennusalalla raken-
nusurakat ovat monivaiheisia ja kohdistuvat usein asiakkaan omaisuuteen, joten rakennusalalla 
toimiva asiakastiedottaminen on erityisen tärkeää. Asiakastiedottaminen tehdään yrityksissä 
yleensä täysin manuaalisesti, joka kuluttaa tiedottajalta paljon resursseja. Rakennusalalla tiedo-
tettavat asiat ovat usein toistuvia ja sellaisia, jotka löytyvät yrityksen toiminnanohjausjärjestel-
mästä tai muista tietojärjestelmistä. Aiemmat tutkimukset osoittavat, että tämän tyyppisen ole-
massa olevan tiedon jakaminen automaation avulla on mahdollista ja tiedottamisen automati-
soinnista voisi saada merkittäviä hyötyjä. Vaikka tutkimukset osoittavat, että asiakastiedottami-
sen tehtävät ovat automatisoitavissa, ei automaation toteuttamisesta ole suoritettu vielä katta-
via tutkimuksia. Kattavammalle tutkimukselle on siis selkeä tarve, jonka vuoksi tässä tutkiel-
massa tutkitaan, minkälaisella alustalla asiakastiedottamisen automaatio voidaan toteuttaa oh-
jelmistorobotiikkaa hyödyntäen ja mitä tehtäviä asiakastiedottamisesta kannattaa automati-
soida. 
 
Tutkimuksen lähestymistapana toimii suunnittelutietiede ja tutkimus seuraa suunnittelutietei-
siin kehitetyn DSRM-mallin vaiheita. Suunnittelutiede on hyvä lähestymistapa tutkimukseen, sillä 
suunnittelutieteen tarkoituksena on luoda uutta ja innovoida sen sijaan, että käsiteltäisiin van-
hoja keksintöjä. DSRM-mallin toteuttamiseen hyödynnettävän aineiston keräämiseksi tässä tut-
kimuksessa on toteutettu teemahaastatteluja. Haastattelujen tarkoituksena on tukea tutkimuk-
sessa tehtäviä valintoja. Tutkimuksessa toteutettaviin haastatteluihin on valittu rakennusalalta 
asiakastiedottamisesta kokemuksia omaavia henkilöitä. 
 
Tutkimuksen tuloksena selvisi, että tehokas asiakastiedottamisen automaation alusta koostuu 
kahdesta eri alustasta. Tutkimuksen tuloksena syntynyt asiakastiedottamisen automaation alus-
tan prototyyppi sisältää tekstiviesteistä ja verkkosivusta muodostuvan alustakokonaisuuden. Ke-
hitetty alustakokonaisuus mahdollistaa kaiken asiakkaalle jaettavan tiedon jakamisen samassa 
paikassa niin, että asiakkaan on helpompi saavuttaa tietoa rakennusurakoista. Alustakokonaisuu-
den lisäksi tutkimuksessa selvisi, että asiakastiedottamisesta voidaan automatisoida kaikki tyy-
pillisimmät tiedottamiseen liittyvät tehtävät. On tärkeää huomioida, että tutkimus on suunnattu 
vain tietylle toimialalle ja tietyn tyyppiseen yritykseen. Vaikka tutkimus osoittaa asiakastiedotta-
misen automaatiosta tuovan merkittäviä hyötyä, on automaatiota harkitsevan yrityksen selvitet-
tävä tarkkaan, onko automaatiosta juuri heidän liiketoiminnassaan vastaavaa hyötyä.  
 

AVAINSANAT: Ohjelmistorobotiikka, Tietojärjestelmä, Asiakastiedottaminen, Automaatio 



3 

 
 
 

 

Sisällys 

1 Johdanto 6 

1.1 Tutkimuksen tavoite 7 

1.2 Tutkimusmenetelmät 7 

1.3 Tutkimuksen tulokset 8 

1.4 Tutkielman rakenne 8 

2 Ohjelmistorobotiikka 9 

2.1 Ohjelmistorobotiikan hyödyntäminen 9 

2.2 Ohjelmistorobotiikan hyödyntämisalueet 11 

2.3 Ohjelmistorobotiikka prosesseissa 14 

2.4 Ohjelmistorobotiikan käyttöönotto 16 

2.5 Ohjelmistorobotiikan rajoitukset 17 

3 Toiminnanohjausjärjestelmät ja asiakastiedottaminen 19 

3.1 Toiminnanohjausjärjestelmien hyödyntäminen 20 

3.2 Toiminnanohjausjärjestelmä pilvipalveluna 22 

3.3 Ohjelmistorobotiikka pilvipohjaisessa toiminnanohjausjärjestelmässä 27 

3.4 Ohjelmistorobotiikka asiakastiedottamisessa 29 

4 Tutkimusmenetelmät 33 

4.1 DSRM-malli 35 

4.2 DSRM-malli tässä tutkimuksessa 38 

4.3 Haastattelut 41 

4.4 Aineiston valinta ja käsittely 43 

5 Alustan suunnittelu ja kehittäminen 44 

5.1 Ongelman tunnistaminen ja motivaatio 44 

5.2 Tavoitteiden määrittäminen 51 

5.3 Suunnittelu ja kehitys 52 

5.3.1 Artefaktin suunnittelu 52 

5.3.2 Artefaktin kehittäminen 57 



4 

 
 
 

5.4 Demonstraatio 61 

6 Diskussio 68 

Lähteet 72 

  



5 

 
 
 

Kuvat 
 

Kuva 1. Ohjelmistorobotiikan hyödyntämisalue ........................................................... 14 

Kuva 2. Manuaalinen vs. ohjelmistorobotiikalla automatisoitu prosessi ...................... 16 

Kuva 3. Pilvipalveluiden arkkitehtuuri.......................................................................... 23 

Kuva 4. Pilvipohjaisten toiminnanohjausjärjestelmien hyödyt ..................................... 26 

Kuva 5 Toiminnanohjausjärjestelmien kehittyminen kohti automaatioita .................... 28 

Kuva 6. Tietojärjestelmien tutkimuskehys.................................................................... 34 

Kuva 7. DSRM-prosessimalli ........................................................................................ 36 

Kuva 8. DSRM-prosessimalli tässä tutkimuksessa ........................................................ 39 

Kuva 9. Rakennusurakan eteneminen .......................................................................... 45 

Kuva 10. Asiakastiedottamiseen kuluva resurssi rakennusurakan aikana ..................... 49 

Kuva 11. Tekstiviesti asiakastiedottamisen alustana .................................................... 59 

Kuva 12. Verkkosivu asiakastiedottamisen alustana ..................................................... 60 

Kuva 13. Prototyypin 1. näkymä .................................................................................. 62 

Kuva 14. Prototyypin 2. näkymä .................................................................................. 63 

Kuva 15. Prototyypin 3. näkymä .................................................................................. 64 

Kuva 16. Prototyypin 4. näkymä .................................................................................. 65 

Kuva 17. Prototyypin 5. näkymä .................................................................................. 66 

Kuva 18. Prototyypin muutokset ................................................................................. 67 

 

 
 

  



6 

 
 
 

1 Johdanto 

Liiketoiminnassa asiakkaiden palveleminen on yksi keskeisimmistä toimista. Toimiva asi-

akkaiden huomioiminen ja asiakastyytyväisyyden ylläpitäminen vaatii monenlaisia toi-

mia. Toimivan asiakaspalvelun kannalta yksi aikaa vievimmistä ja tärkeimmistä asioista 

on toimiva asiakastiedottaminen. Rakennusalalla lyhytkestoisten rakennusurakoiden pa-

rissa työskentelevät esimiehet, ovat kiinnittäneet huomiota asiakkaiden tyypillisimpiin 

tarpeisiin tiedottamisessa. Kun kyse on asiakkaiden omaisuuteen liittyvästä palvelusta, 

asiakkaat ovat erityisen halukkaita tietämään palvelun aikataulusta sekä toimenpiteistä 

aina kaupantekohetkeltä palvelun suorittamiseen saakka. Palvelun suorittaminen sisäl-

tää usein monia eri vaiheita, jotka lisäävät tiedotettavien asioiden määrää. Tiedotetta-

vista asioista useimmat ovat toistuvia ja sellaisia, joihin löytyy selkeä vastaus yrityksen 

toiminnanohjausjärjestelmästä tai muista tietojärjestelmistä.  Tämä tarkoittaa sitä, että 

asiakkaan tarvitsema tieto on jo olemassa ja siten tiedon jakaminen voidaan tehokkaasti 

automatisoida (Steinberg, 2020). Asiakastiedottaminen tehdään kuitenkin vielä tänä päi-

vänä usein täysin manuaalisesti, eikä asiakastiedottamisen automaation toteuttamista 

ole tutkittu juurikaan. Tutkimukset kuitenkin osoittavat, että asiakastiedottamisessa on 

sellaisia vaiheita, joita voidaan automatisoida (Dilmegani, 2021b; Tripathi, 2018, s. 7–8; 

Madakam ja muut, 2019). Tutkimukselle on selkeä tarve, sillä manuaalinen tiedottami-

nen vie tiedottajalta paljon resurssia, kun tiedotettavia asioita ja asiakkaita on paljon. 

Manuaalinen asiakastiedottaminen voi myös olla asiakastyytyväisyyden kannalta haital-

linen, sillä useiden asiakkaiden tiedottaminen yhtä aikaa voi altistaa tiedottajan virheisiin, 

kuten esimerkiksi unohtamaan tiedottamisen jonkin asiakkaan kohdalla.  

 

Tutkielman tarkoitus on keskittyä asiakastiedottamisen automatisointiin tietyllä toi-

mialalla. Tutkielman ratkaisu sopii erityisesti rakennusalan yrityksiin, joiden tarjoamat 

palvelut ovat urakkaluontoisia. Olennaista on myös se, että asiakas on kiinnostunut ura-

kan etenemisestä. Esimerkkinä kohdeyrityksestä voisi toimia rakennusalan yritys, jossa 

on noin 50-100 työntekijää ja yhtäaikaisesti kymmeniä urakoita työn alla. Tärkeintä on 

kuitenkin, että asiakas on kiinnostunut palvelun suorittamisen seurannasta ja halukas 

vastaanottamaan tietoa palvelun etenemisestä. 



7 

 
 
 

 

1.1 Tutkimuksen tavoite 

Tutkimuksen tavoitteena on selvittää, minkälaisia mahdollisuuksia asiakastiedottamisen 

automaatiolle on, ja kehittää aiemmin kuvatun liiketoiminnan tarpeisiin sopiva asiakas-

tiedottamisen automatisoinnin alusta. Tutkimuskysymyksiä ovat:   

- ”Millaisella alustalla asiakastiedottamisen automaatio kannattaa toteuttaa?” 

- ”Mitä tehtäviä asiakastiedottamisesta kannattaa automatisoida?” 

 

 

1.2 Tutkimusmenetelmät 

Tässä tutkielmassa pääasiallisena lähestymistapana toimii suunnittelutiede. Suunnitte-

lutieteellisenä tutkimusmenetelmänä hyödynnetään Peffersin ja muiden (2007) kehittä-

mää DSRM (Design Science Research Methodology) -mallia. Tutkimukseen suunnittelu-

tiede sopii erityisen hyvin, sillä suunnittelutiede lähestymistapana keskittyy luomaan uu-

sia tietoteknisiä esineitä eli artefakteja (Hevner ja muut, 2004, s. 98). DSRM-malli taas 

muodostaa yleisesti hyväksytyn kehyksen suunnittelutieteellisen tutkimuksen suoritta-

miselle. DSRM-malliin kuuluu yhteensä kuusi vaihetta, joista tässä tutkimuksessa suori-

tetaan neljä ensimmäistä vaihetta.  

 

Tutkimuksen aineisto koostuu teorialukujen sisällöstä, tutkijan omista kokemuksista sekä 

teemahaastatteluista. Teorialukujen sisältö perustuu olemassa olevaan kirjallisuuteen eli 

aiempiin tutkimuksiin. Tärkeimpiä kriteereitä kirjallisuuden valinnassa ovat olleet julkai-

suvuosi sekä julkaisija. Kirjallisuuden ikää ei kuitenkaan voida täysin rajata, sillä vanhem-

pia teorioita on hyödyllistä avata osittain myös vanhemman kirjallisuuden avulla. Teema-

haastatteluja tässä tutkielmassa hyödynnetään tutkimusosiossa luvussa viisi. Teema-

haastatteluja suoritetaan kahdelle rakennusalan asiantuntijalle, joilla on kokemusta tut-

kimusongelmiin liittyvistä asioista. 

 

 



8 

 
 
 

1.3 Tutkimuksen tulokset 

Tutkimuksessa kehitetään korkean tason suunnitelma asiakastiedottamisen automaa-

tion toteuttamisesta. Suunnitelma keskittyy asiakastiedottamisen alustan rakentami-

seen ja tuloksena syntyy prototyyppi alustasta, jossa on huomioitu teorian ja kokemus-

ten pohjalta kaikki keskeisimmät vaatimukset. Tutkimuksesta selviää alustan kehittämi-

sen myötä myös esimerkiksi, mitä tietoja asiakastiedottamisesta voi ja kannattaa auto-

matisoida ja miten automatisointi käytännössä onnistuu. Asiakastiedottamisen alustan 

suunnittelu ja kehitys toteutetaan DSRM-mallin vaiheiden mukaan niin, että sen toiminta 

on helppo omaksua ja ymmärtää. 

 

 

1.4 Tutkielman rakenne 

Tutkielma koostuu kuudesta pääluvusta. Tutkimus voidaan jakaa karkeasti kahteen osaan, 

joita ovat teoriaosuus ja tutkimusosuus. Teoriaosuuteen sisältyy johdannon lisäksi kaksi 

teorialukua. Teorialuvut käsittelevät tutkimusalueen keskeisimpiä teorioita eli ohjelmis-

torobotiikkaa ja toiminnanohjausjärjestelmiä. Toiminnanohjausjärjestelmien lisäksi toi-

sessa teorialuvussa käsitellään myös lyhyesti asiakaspalvelun ja asiakastiedottamien teo-

riaa. Tutkielman toinen puolisko eli tutkimusosuus sisältää luvut neljä, viisi ja kuusi. Nel-

jäs luku käsittelee tutkimusmenetelmiä, joissa määritellään johdantoa tarkemmin, miten 

tutkimusmenetelmiä hyödynnetään tässä tutkielmassa. Viides luku sisältää itse tutki-

muksen eli DSRM-mallin mukaisen suunnittelutieteellisen tutkimuksen. Viidennen luvun 

rakenne on DSRM-mallin mukainen, eli luku etenee mallin vaiheiden mukaisesti. Viimei-

nen eli kuudes luku sisältää diskussion tutkimuksesta. Siinä esitetään tutkimuksen tär-

keimmät tulokset ja analysoidaan mitä tulokset osoittavat ja mitä tuloksista on syytä 

huomioida sekä lukijan että tutkijan näkökulmasta. 

 

 



9 

 
 
 

2 Ohjelmistorobotiikka 

Ohjelmistorobotiikka (eng. Robotic Process Automation, RPA) tarkoittaa joukkoa ohjel-

mia ja algoritmeja, jotka jäljittelevät ihmisen ja tietokoneen välisiä vuorovaikutuksia (Tri-

pathi, 2018, s. 9; Ivančić ja muut, 2019, s.2–3 ; Casey, 2020). Boultonin (2018) mukaan 

ohjelmistorobotti on liiketoimintalogiikan ja jäsenneltyjen resurssien hallitsema tekno-

loginen sovellus, jonka tarkoituksena on automatisoida liiketoimintaprosesseja. Näiden 

määritelmien ja Tripathin (2018, s. 9) yksinkertaistetun selityksen mukaan ohjelmistoro-

botti sisältää ohjelmiston, joka jäljittelee ihmisen toimia samalla kun se on vuorovaiku-

tuksessa eri sovellusten kanssa.  

 

 

2.1 Ohjelmistorobotiikan hyödyntäminen 

Ivančićin ja muiden (2019, s. 2–3) mukaan ohjelmistorobottia ohjaavat enimmäkseen yk-

sinkertaiset säännöt sekä liiketoimintalogiikka, ja se on vuorovaikutuksessa useiden tie-

tojärjestelmien kanssa olemassa olevien graafisten käyttöliittymien kautta. Boultonin 

(2018) ja Kommeran (2019) mukaan ohjelmistorobotti sovelluksena on ohjelmoitu ”ro-

botiksi”, jonka tarkoitus on siepata olemassa olevia sovelluksia ja liittyä niihin, jotta niissä 

voitaisiin käsitellä tapahtumia ja tietoja, luoda vastauksia ja muodostaa vuorovaikutus-

suhde muihin digitaalisiin järjestelmiin. 

 

Edellä mainituilla tavoilla ohjelmistorobotilla voidaan korvata työntekijöiden toistuvat ja 

sääntöihin perustuvat työtehtävät tehokkaasti (Tripathi, 2018, s. 9; Ivančić ja muut, 2019, 

s. 2–3; Dilmegani, 2021a). Ohjelmistorobotiikan suorittaessa työntekijöille aiemmin kuu-

luneita yksinkertaisia tehtäviä, työntekijöille vapautuu aikaa osallistua monimutkaisem-

piin tehtäviin, mikä taas luo organisaatiolle enemmän arvoa (Ivančić ja muut, 2019, s. 2–

3; Kommera, 2019; IRPA, 2015). Ohjelmistorobotiikka luo arvoa myös vähentämällä vir-

heitä rutiininomaisista työtehtävistä, joissa ihmisillä on inhimillisesti alttius tehdä vir-

heitä (Ivančić ja muut, 2019, s. 2–3; Ma ja muut, 2019, s. 187). Kommeran (2019) mukaan 



10 

 
 
 

ohjelmistorobotiikalla yleensä luodaan arvoa, kun ohjelmistorobotti suorittaa automaa-

tiona liiketoiminnalle välttämättömiä toimenpiteitä, kuten siirtää tai täyttää tietoja mää-

rättyjen sijaintien välillä, dokumentoi auditointipolkuja, suorittaa laskelmia, suorittaa 

toimintoja ja käynnistää loppupään toimintoja. Ohjelmistorobotiikkaa voidaan siis hyö-

dyntää Kommeran (2019) mukaan niin suuriin kuin pieniinkin tehtäviin, ja samoilla lin-

joilla asiassa on myös Boulton (2018) mainitessaan ohjelmistorobotiikan kykenevän hoi-

taa niin yksittäistä sähköpostiliikennettä kuin kokonaista toiminnanohjausjärjestelmää-

kin. Kyse on siis vain siitä, mihin tehtäviin ihminen ohjelmistorobotin ohjelmoi. 

 

Ohjelmistorobotiikka ei ole aina keskittynyt liiketoimintaprosessien laajaan automati-

sointiin, vaan sen historia voidaan jakaa Dilmeganin (2021a) mukaan kolmeen osaan, 

joita ovat näytön kaapiminen (eng. screen scraping), liiketoimintaprosessien automati-

sointi sekä tekoäly (eng. Artificial Intelligence, AI). Ohjelmistorobotiikan hyödyntäminen 

näytön kaapimiseen oli ohjelmistorobottien ensimmäinen käyttökohde ja myöhemmin 

2010-luvulla ohjelmistorobotiikkaa alettiin hyödyntämään laajemmin monimutkaisem-

missa tehtävissä, kuten esimerkiksi liiketoimintaprosessien automatisoinnissa. Siitä läh-

tien ohjelmistorobotiikan hyödyntäminen on keskittynyt yhä vaativimpiin työtehtäviin. 

Tänä päivänä ohjelmistorobotiikka yhdessä tekoälyn kanssa luo33 yhä edistyksellisempiä 

automaatiokokonaisuuksia, joissa Dilmeganin (2021a) mukaan automaatio ylittää usein 

ihmisten kognitiiviset kyvyt esimerkiksi tekstin- ja kuvion tunnistamisessa. (Dilmegani, 

2021a.) 

 

Ohjelmistorobotiikan hyödyntäminen on sen käyttöalueen laajetessa myös lisääntynyt 

yleisesti. Yksi merkittävimmistä syistä ohjelmistorobotiikan käytön kasvuun on se, että 

se on kustannustehokkain ja tehokkain tapa automatisoida nykyaikaiset toistuvat toi-

mistotehtävät, joihin toimistotyöntekijät käyttävät keskimäärin 10–25% työajastaan 

(Antonoaie ja muut, 2017; Dilmegani, 2021a). Toistuvien työtehtävien lisääntyminen 

taas johtuu siitä, että organisaatioilla on yhä enemmän erilaisia ohjelmia käytössä ja si-

ten myös enemmän tietokoneen välityksellä suoritettavia tehtäviä. Usein organisaa-



11 

 
 
 

tioissa yksi merkittävimmistä tietokoneella suoritettavien tehtävien lisääjistä ovat toi-

minnanohjausjärjestelmät, joihin tämäkin tutkielman ohjelmistorobotiikkaratkaisu kes-

kittyy. (Dilmegani, 2021a) 

 

 

2.2 Ohjelmistorobotiikan hyödyntämisalueet 

Kuten edellisessä kappaleessa lyhyesti mainittiin, ohjelmistorobotiikka pystyy käsittele-

mään kaikki toistuvat ja rutiininomaiset työtehtävät ihmisen puolesta. Tripathi (2018, s. 

11) sekä Madakam ja muut (2019) korostavat, että ohjelmistorobotiikka kykenee yksin-

kertaisten tehtävien lisäksi suorittamaan myös monipuolisia tehtäviä. Ohjelmistorobotii-

kan hyödyntämisen tarkoituksena on auttaa organisaatiota optimoimaan liiketoiminnan 

tehokkuutta ja toiminnan tehokkuutta sekä parantamaan työn toteutuksen tarkkuutta 

(Kommera, 2019; Tripathi, 2018, s. 11; Madakam ja muut, 2019). Dilmegani (2021b), Tri-

pathi (2018, s. 7–8) sekä Madakam ja muut (2019) ovat listanneet teoksissaan ohjelmis-

torobotiikalla parhaiten automatisoitavien tehtävien tärkeitä piirteitä. Seuraavassa lis-

tassa on yhdistettynä näitä tärkeitä piirteitä, joita tutkijat ovat tunnistaneet: 

 Tehtävä sisältää toistuvia ja sääntöihin perustuvia vaiheita: Ohjelmistorobotii-

kalla voidaan automatisoida vain tehtävät, jotka perustuvat sääntöihin, sillä oh-

jelmistorobotit ovat ohjelmoitavia ohjelmia. Jos tehtävillä ei ole sääntöjä, ei ro-

bottia voida ohjelmoida.  

 Vaiheet ovat aikaa vieviä: Koska ohjelmistorobotti on ohjelma, joka toimii auto-

maattisesti, se voi suorittaa aikaa vieviä vaiheita tarvittaessa ympäri vuorokau-

den, seitsemän päivää viikossa. Tämä tuottaa suuria aikasäästöjä ja siten myös 

kustannussäästöjä. 

 Tehtävässä on suuret riskit: Riskialttiissa tehtävässä virheet voivat aiheuttaa mer-

kittäviä kustannuksia. Ohjelmistorobotiikka vähentää virheiden määrää huomat-

tavasti, joten mitä enemmän tehtävä altistaa virheille, sitä enemmän etua ohjel-

mistorobotiikasta on tehtävän suorittamisessa. 



12 

 
 
 

 Tehtävällä on suuri merkitys liiketoiminnan tuottoon: Ohjelmistorobotiikalla voi-

daan vapauttaa ihmiset tuottavampiin tehtäviin. Poistamalla ihmisen tekemä työ 

vähätuottoisista tehtävistä, liiketoiminnan tehokkuus ja tuotto paranee. 

 Tehtävän suorittamiseen liittyy useita ihmisiä ja useita vaiheita: Yksi ohjelmisto-

robotiikan tärkeimmistä eduista on ihmisen tekemän työn vähentäminen. Eli mitä 

enemmän ihmisen aikaa voidaan vapauttaa, sen parempi. 

 Tehtävän kiireellisyys: Ihmisen resurssin vapauttaminen kiireellisen tehtävän suo-

rittamiseen on haastavampaa kuin ohjelmistorobotin. Tästä syystä kaikki kiireel-

liset tehtävät, jotka voivat esimerkiksi viivästyttää palvelujen toimittamista asiak-

kaille, ovat sopivia ohjelmistorobotiikalle.  

 

Listan lisäksi Dilmegani (2021b) korostaa, että vaikka jokin prosessi ei olisikaan listan kri-

teereiden mukainen, se voidaan mahdollisesti jakaa automatisoitaviin aliprosesseihin, 

joissa osa prosessista saadaan automatisoitua. Tämä tietenkin edellyttää sitä, että ali-

prosessit ovat kriteereiden mukaisia. 

 

Ohjelmistorobotiikan hyödyntämisestä eri liiketoimintaosastoilla on useita esimerkkejä. 

Esimerkiksi Dilmeganin (2020b) sekä Lacityn ja Willcocksin (2016) artikkelien mukaan 

myynnin, henkilöstöhallinnon, asiakaspalvelun ja taloushallinnon prosesseja on yleisesti 

automatisoitu ohjelmistorobotiikan avulla paljon. Tässä tutkielmassa asiakaspalvelun 

prosessien automatisointi korostuu, kun tutkimuksessa on tarkoitus selvittää sopiva 

alusta asiakastiedottamisen automaatiolle. Dilmegani (2020b) antaa artikkelissaan asia-

kaspalvelussa automatisoitavista prosesseista useita esimerkkejä. Esimerkiksi yllättävät 

asiakkaiden yhteydenotot kiireelliseen aikaan saattavat johtaa siihen, että asiakas ei 

välttämättä tavoita asiakaspalvelijaa ja jää täten ilman etsimäänsä tietoa. Usein kyse 

saattaa olla yksinkertaisesta tiedosta, jonka asiakaspalvelija on kirjannut aiemmin järjes-

telmään tai tieto on muuten jo olemassa. Näissä tilanteissa ohjelmistorobotiikan ja au-

tomaatioratkaisujen avulla tieto voitaisiin jakaa asiakkaalle automaattisesti. Tällaisessa 

tilanteessa automaation puute on Dilmeganin (2020b) mukaan hyvä esimerkki siitä, 



13 

 
 
 

kuinka yritys voi tuhlata resursseja ylimääräisiin puheluihin ja aiheuttaen samalla tyyty-

mättömiä asiakaskokemuksia.  

 

Ohjelmistorobotiikan hyödyntämisalueen ymmärtämiseksi van der Aalst ja muut (2018)  

esittelevät kuvan 1 mukaisen esimerkin. Kuvassa X-akselilla näkyvät erityyppiset tapauk-

set. Jos kahta eri tapausta ei voi hoitaa samalla tavalla, ne luokitellaan erityyppisiksi. Jos 

taas kaksi eri tapausta voidaan hoitaa samalla tavalla, ne ovat samantyyppisiä. Y-akseli 

näyttää taas tapaustyyppien esiintymistiheyden. Tässä esimerkissä nähdään Pareto-ja-

kauma, eli 80% tapauksista voidaan selittää 20%:lla tapaustyypeistä. Tämä tarkoittaa sitä, 

että on olemassa monia tapaustyyppejä, jotka ovat melko harvinaisia. Automaation ja 

ohjelmistorobotiikan tavoitteena on käsitellä yleisimpiä tapaustyyppejä (eli 20% kaikista 

tapaustyypeistä). Harvempia tapauksia (80% kaikista tapaustyypeistä) ei oteta huomioon, 

koska ne ovat liian kalliita suorittaa ohjelmistorobotiikan avulla. Harvemmat tapaukset 

saattavat edellyttää esimerkiksi järjestelmäintegraatioita, ja ne aiheuttavat usein suuria 

kustannuksia. Siksi loput 20% tapauksista hoidetaan usein manuaalisesti, syöttämällä tie-

toja ja tekemällä päätöksiä. Tällaisissa olosuhteissa ihmiset toimivat ikään kuin liimana 

erilaisten tietojärjestelmien välillä. Nämä jäljellä olevat 20% tapauksista kattavat kuiten-

kin 80% tapaustyypeistä ja ovat paljon aikaa vievämpiä kuin tavalliset tapaukset. Ohjel-

mistorobotiikan avulla on mahdollista tukea näitä ihmiselle kuuluvia tapauksia esimer-

kiksi hyödyntämällä ohjelmistorobotiikkaa tietojärjestelmien väliseen tiedonvaihtoon. 

Samoilla linjoilla on Dilmegani (2021b) todetessaan artikkelissaan ohjelmistorobotiikan 

sopivan myös tiedon välittämiseen ja muihin aliprosesseihin niissä tapauksissa, joissa oh-

jelmistorobotiikkaa ei kannata hyödyntää koko prosessin suorittamiseen. Tämä ei kuiten-

kaan aina ole mahdollista tai taloudellisesti kannattavaa, ja siihen on Willcocksin ja mui-

den (2015, s. 4) mukaan kiinnitettävä huomiota. Siksi ihmisten on yleensä hoidettava osa 

tehtävistä manuaalisesti. 

 



14 

 
 
 

 

Kuva 1. Ohjelmistorobotiikan hyödyntämisalue (van der Aalst ja muut, 2018) 

 

 

2.3 Ohjelmistorobotiikka prosesseissa 

Ohjelmistorobotiikkaa voidaan käyttää prosesseissa monenlaisten vaiheiden suorittami-

seen. Dilmegani (2021a) sekä Madakam ja muut (2019) kertovat artikkeleissaan ohjel-

mistorobotiikan kykenevän muun muassa avaamaan, purkamaan, lukemaan sekä vertaa-

maan tiedostoja, syöttämään, kopioimaan ja liittämään tietoja sekä paljon muuta. Ohjel-

mistorobotit ovat usein integraatiossa eri järjestelmien kanssa, jotta tietoa tiedon siirto 

eri järjestelmien välillä onnistuu. Ohjelmistorobotti voisi siirtää tiedon myös näytön kaa-

vinta menetelmällä, mutta koska näytön kaapiminen aiheuttaa enemmän virheitä tiedon 

siirrossa, integraatiot ovat tiedon siirtämisen kannalta paras vaihtoehto.  

 



15 

 
 
 

Tiedon siirtäminen on yksi ohjelmistorobotiikan keskeisimmistä tehtävistä ohjelmistoro-

botiikkaa hyödynnettäessä (Aguirre ja Rodriguez, 2017). Tiedon siirtämistä tapahtuu läh-

tökohtaisesti jokaisessa organisaatiossa, sillä organisaatioiden useat eri järjestelmät vaa-

tivat paljon tiedonsiirtoa ja integraatioita järjestelmien välillä. Ihmiselle järjestelmien vä-

linen tiedon siirtäminen on aikaa vievää ja epämieluista sen rutiininomaisen ja toistuvan 

luonteen vuoksi. Ohjelmistorobotiikalle tällaiset tehtävät ovat taas optimaalisia. Ohjel-

mistorobotiikalla voidaan siirtää montaa eri tiedostomuotoa. Madakam ja muut (2019) 

esittävät, että ohjelmistorobotiikka kykenee käsittelemään tietoa, joka on teksti-, kuva-, 

ääni- tai videomuodossa. (Madakam ja muut, 2019.) 

 

Monesti ohjelmistorobotiikalla toteutetut automaatiot ovat erillisiä, mutta joskus pro-

sessin automaatiot halutaan yhdistää. Kokonaisen prosessin yhdistäminen edellyttää au-

tomaatioiden orkesterointia eli yhteensovittamista. Automaatioiden yhteensovittami-

nen helpottaa ohjelmistorobottien hallintaa. Yhteensovitettua automaatiokokonai-

suutta hallitsee Dilmeganin (2021a) mukaan orkesterinpitäjä, joka esimerkiksi tarjoaa 

hallintapaneelin ohjelmistorobotiikan hallinnoimille prosesseille sekä tunnistaa robot-

tien kohtaamia ongelmia. Huolimatta siitä, kuinka hyvin ohjelmistorobotiikka on ohjel-

moitu ja yhteen sovitettu, robottien kohdalle sattuu ylitsepääsemättömiä ongelmia. 

Näitä ongelmia on hallittava ja delegoitava saumattomasti henkilöstölle ratkaistaviksi en-

nen kuin ne johtavat suurempiin ongelmiin. (Dilmegani, 2021a.) 

 

Kuvassa 2 on esimerkki tyypillisestä liiketoiminnan prosessista, jossa henkilölle avataan 

käyttöoikeudet järjestelmään. Kuvan ylemmässä esimerkissä sihteeri toimii tehtävän 

suorittajana. Kuvan alemmassa esimerkissä toteutuksen sihteerin sijaan suorittaa ohjel-

mistorobotti. Kuva 2 osoittaa hyvin sen, kuinka ohjelmistorobotiikalla voidaan automati-

soida tyypillinen ja paljon aikaa vievä tehtävä alusta loppuun saakka. (The Lab, 2019.) 

 



16 

 
 
 

 

Kuva 2. Manuaalinen vs. ohjelmistorobotiikalla automatisoitu prosessi (The Lab, 2019) 

 

 

2.4 Ohjelmistorobotiikan käyttöönotto 

Ohjelmistorobotiikan käyttöönotto on melko yksinkertaista, jos se on hyvin perusteltu ja 

suunniteltu valmiiksi. Dilmeganin (2021b) mukaan ohjelmistorobotiikan käyttöönotto 

kestää yleensä alle 2 kuukautta, mutta käyttöönoton kestoon vaikuttavat useat asiat. On 

erilaisia tapoja ohjelmistorobotiikan käyttöönottoon, ja kaikilla niillä on omat hyötynsä. 

Kuitenkaan liian nopeasti ja suunnittelematta ohjelmistorobotiikkaa ei suositella otetta-

vaksi käyttöön. The Labin (2019) mukaan lähes puolet ohjelmistorobotiikan käyttöön-

otoista epäonnistuu, koska yritykset keskittyvät vääriin asioihin. Ohjelmistorobotiikan 

käyttöönottoon löytyy monia eri suosituksia ja tarkastuslistoja. Seuraavassa listassa on 

koottu yhteen Dilmeganin (2021b), The Labin (2019) ja Kommeran (2019) listat, joista 

selviää tärkeimmät vaiheet ohjelmistorobotiikan käyttöönotossa: 

 Automatisoitavien prosessien tunnistaminen ja priorisointi:  

o Selvitä, mitkä prosessit ovat yrityksesi ydinprosesseja ja mitkä prosessit 

ovat toissijaisia tai tarpeettomia. Koskaan ei kannata automatisoida tur-

hia prosesseja, koska niiden automatisoinnilla ei saada taloudellista hyö-

tyä. Esimerkiksi asiakassuhteiden hallinta on usein yksi yrityksen ydinpro-

sesseista, ja osittain tai kokonaan automatisoitavissa.  



17 

 
 
 

 Ohjelmistorobotiikan käyttötapausten tunnistaminen ja kehittäminen 

o Ennen ohjelmistorobotiikan käyttöönottoa on määritettävä robotiikan 

käyttötapaukset selkeästi. On viisasta aloittaa pienistä automatisoitavista 

tehtävistä ja laajentaa myöhemmin näitä tehtäviä suuremmaksi kokonai-

suudeksi. Hyödynnä käyttötapausten tunnistamisessa parhaita käytän-

töjä ja varmista valittujen komponenttien uudelleenkäytettävyys. 

 Ohjelmistorobotiikkaratkaisujen sijoitetun pääoman tuoton (ROI) varmistaminen 

o Listaa kaikki asiat, joihin ohjelmistorobotiikka vaikuttaa taloudellisesti. On 

tärkeää laskea jokaisen ohjelmistorobotiikkaratkaisun kustannusedut sel-

keästi. Laske ohjelmistorobotiikkaratkaisujen ROI eli sijoitetun pääoman 

tuottoaste ja karsi tässä vaiheessa kannattamattomat pois. 

 Ohjelmistorobottien kehittäminen ja ylläpitäminen 

o Ohjelmistorobotiikan kehittämiseen sisältyy yleensä SDLC-mallin eli jär-

jestelmän kehittämisen elinkaaren vaiheita, joita ovat suunnittelu, kehitys, 

testaus, käyttöönotto ja prosessin suuntaus. Seuraa tätä mallia säännölli-

sesti ja ylläpidä toimivaa automatiikkaa. 

 

 

2.5 Ohjelmistorobotiikan rajoitukset 

Vaikka termi ”robotti” esiintyy ohjelmistorobotiikassa, se ei tarkoita sitä, että kaikki teh-

tävät voidaan suorittaa ohjelmistorobotiikan avulla. Durjoy (2020) painottaa, että ohjel-

mistorobotiikka ei ole rakettitiedettä, vaikka saattaa siltä kuulostaa. Se ei ole esimerkiksi 

tarpeeksi älykäs oppimaan ja parantamaan prosesseja itse, mikä tarkoittaa sitä, että liian 

dynaamiset prosessit eivät sovellu sen automatisoitaviksi (Casey, 2019). Ohjelmistorobo-

tiikan avulla ei myöskään Durjoyn (2020) mukaan pysty lukemaan käsin kirjoitettuja ja 

painettuja vapaamuotoisia tekstejä. Joskus jopa skannattujen lomakkeiden lukeminen 

on ohjelmistorobotille suuri haaste. Ohjelmistorobotiikka on toimiva ratkaisu, kun kyse 

on selkeästä datankäsittelystä ja systemaattisesta tiedonsiirrosta. (Durjoy, 2020.) 

 



18 

 
 
 

Lisäksi muita rajoittavia asioita, jotka saattavat rajoittaa ohjelmistorobotiikan toimintaa 

ovat riittämätön verkkokapasiteetti, riittämätön laskentateho sekä standardisoimatto-

mat prosessit. Nämä johtuvat siitä, että ohjelmistorobotiikka on manuaalista työtä ras-

kaampaa ja vaatii suurempaa verkkokapasiteettia ja selkeämpiä prosesseja (Durjoy, 

2020). Rajoittavien tekijöiden lisäksi on asioita, jotka saattavat aiheuttaa ohjelmistoro-

botiikan käyttöönoton vaikeaksi. Tällaisia ovat esimerkiksi ammattitaitoisten ihmisten 

puute, teknologian liian suuret kustannukset, liian suuri muutosvauhti sekä puutteelli-

nen tietoturva (Kommera, 2019; Greene, 2019; Terra, 2020; Ansari ja muut, 2019.) 

 

 



19 

 
 
 

3 Toiminnanohjausjärjestelmät ja asiakastiedottaminen 

Tässä luvussa käsitellään toiminnanohjausjärjestelmiä ja asiakastiedottamista sekä oh-

jelmistorobotiikkaa osana näitä. Koska toiminnanohjausjärjestelmiä on saatavilla eri 

muodoissa, tässä luvussa käsitellään, minkälaisia erilaisia vaihtoehtoja toiminnanohjaus-

järjestelmien hyödyntämiselle on. Tässä luvussa on tarkoitus esitellä toiminnanohjaus-

järjestelmien hyötyjä sekä käsitellä ohjelmistorobotiikan ja toiminnanohjausjärjestel-

mien yhdistämistä asiakastiedottamisen toteuttamiseksi.  

 

Toiminnanohjausjärjestelmistä (eng. Enterprise Resource Planning system, ERP) on 

monta eri määritelmää, mutta kaikissa niissä on pitkälti sama ajatus. Ullahin ja muiden 

(2018, s. 379) mukaan toiminnanohjausjärjestelmät ovat liiketoiminnan hallintajärjestel-

miä, jotka koostuvat joukosta kattavia ohjelmistoja, jotka on suunniteltu integroimaan ja 

hallitsemaan kaikkia liiketoiminnan toimintoja organisaatiossa. O'Learyn (2000) mukaan 

toiminnanohjausjärjestelmät ovat tehokkaita ohjelmistopaketteja, joiden avulla yrityk-

set voivat integroida erilaisia toimintoja. Habadin ja muiden (2017, s. 1) sekä Al-Ghofailin 

ja Al-Masharin (2014, s. 135) artikkeleiden mukaan toiminnanohjausjärjestelmät ovat ja-

ettuja tietokantoja, jotka hallitsevat organisaatioiden prosesseja tukemalla useita toi-

mintoja ja integroimalla useita sovelluksia. Woo (2007) sekä Habadin ja muut (2017, s. 1) 

ovat yksimielisiä määrittäessään toiminnanohjausjärjestelmän olevan kattava tietojär-

jestelmä, joka tukee kaikkien liiketoimintojen tietotarpeita reaaliajassa, mukaan lukien 

henkilöstöresurssit, talous, markkinointi, toiminta, asiakastiedot, myynti ja toimitusket-

jut. Näissä määritelmissä on keskenään pieniä eroavaisuuksia. Katuu (2020) on havainnut 

saman artikkelissaan ja korostaa sitä, että toiminnanohjausjärjestelmät voidaan ymmär-

tää sekä konseptina, johon sisältyy liiketoimintaprosessien integrointi,että järjestelmänä, 

jonka ytimessä on integroitu tietokanta ja useita moduuleja. 

 

 



20 

 
 
 

3.1 Toiminnanohjausjärjestelmien hyödyntäminen 

Ensimmäisiä kertoja toiminnanohjausjärjestelmiä on ollut käytössä 1990- luvulla ja niitä 

on kehittynyt siitä lähtien jatkuvasti. Toiminnanohjausjärjestelmiin on tullut vuosien saa-

tossa paljon kehitystä etenkin integraatiokykyyn ja toiminnollisuuksiin. Nykyisin toimin-

nassa olevat toiminnanohjausjärjestelmät on luotu käytettäväksi internetissä, ja niissä 

on huomattavia määriä edistyksellisiä ominaisuuksia. 2000-luvulla ja 2010-luvun alku-

puolella toiminnanohjausjärjestelmiä on ollut tapana ostaa ja omistaa, mutta nykypäi-

vänä toiminnanohjausjärjestelmiä hankitaan yhä enemmän pilvipalveluna. (Berić ja 

muut, 2018, s. 402–403.) 

 

Toiminnanohjausjärjestelmien tarkoitus on Ullahin ja muiden (2017, s. 1) parantaa orga-

nisaation tuottavuutta sekä tuottaa tarkkaa ja ajantasaista tietoa organisaatiossa ja sen 

toimitusketjuissa. Toiminnanohjausjärjestelmän käyttöönotto parantaa lähtökohtaisesti 

organisaation suorituskykyä huomattavasti (Habad ja muut, 2017, s. 1; Ullah ja muut, 

2017, s.1; Berić ja muut, 2018, s. 400; Suprapto ja muut, 2017). Toiminnanohjausjärjes-

telmä yhdistää organisaatioiden keskeisimmät toiminnot, joihin Berićin ja muiden (2018, 

s. 400) sekä Ullahin ja muiden (2018, s. 1–2) mukaan kuuluvat esimerkiksi talous, kirjan-

pito, henkilöstöresurssit, ostot, valmistus, varastonhallinta, laadunhallinta, jakelu sekä 

myynti ja markkinointi. Näiden toimintojen yhdistämisestä ja toimivasta hallinnoinnista 

organisaatio saa monia hyötyjä. Habad ja muut (2017, s. 3) sekä Ullah ja muut (2018, s. 

2) ovat artikkeleissaan listanneet merkittävimpiä hyötyjä, joita organisaatio voi saada toi-

mivan toiminnanohjausjärjestelmän myötä. Seuraavassa listassa on yhdistetty keskei-

simpiä hyötyjä, joita näissä artikkeleissa mainittiin: 

 Auttaa järjestämään organisaation osastojen tietoja. 

 Vähentää tietojen redundanssia käyttämällä yhteistä tietokantaa. 

 Parantaa tehokkuutta ja vähentää riippuvuutta paperiin. 

 Parantaa osastojen, henkilöstön ja asiakkaiden välistä yhteistyötä. 

 Vähentää kuluja sekä säästää energiaa ja aikaa. 

 Tehostaa työnkulkua ja järjestää organisaation prosesseja. 



21 

 
 
 

 Tarjoaa korkealaatuisia palveluja sekä mahdollistaa automatisoinnit liiketoimin-

taprosesseissa. 

 Parantaa sisäistä viestintää ja tiedon jakamista. 

 

Pienillä ja keskisuurilla yrityksillä eli pk-yrityksillä on ollut pitkään vaatimattomat resurs-

sit ja budjetit tietojärjestelmiin ja tietotekniikkaan. Tästä syystä toiminnanohjausjärjes-

telmät ovat olleet enimmäkseen vain suurien yrityksien saatavilla. Viime vuosien aikana 

toiminnanohjausjärjestelmien hyödyntäminen on kuitenkin tullut pk-yrityksille mahdol-

liseksi. Yksi suuri syy siihen, miksi toiminnanohjausjärjestelmät ovat tulleet pk-yrityksille 

mahdolliseksi on se, että palveluntarjoajat ovat kehittäneet edullisempia ja mutkatto-

mampia toiminnanohjausjärjestelmiä (Baker ja Yusof (2017, s. 389). Syy tällaisten toi-

minnanohjausjärjestelmien kehittämiselle löytyy Bakerin ja Yusofin (2017, s. 389) artik-

kelin mukaan siitä, että pk-yritykset ovat vuosien saatossa suuntautuneet yhä enemmän 

kansainvälisille markkinoille, join toiminnanohjausjärjestelmät tuottavat merkittävää kil-

pailukykyä. Toiminnanohjausjärjestelmien saatavuus eri kokoisille yrityksille on ollut erit-

täin tärkeä kehitysaskel, sillä pk-yrityksille toiminnanohjausjärjestelmät mahdollistavat 

esimerkiksi tehokkaamman asiakassuhteiden hallinnan ja arvoverkkojen luomisen, pa-

remman sisäisen tiedonsiirron sekä automaation käyttöönoton (Haddara ja Zach, 2011, 

s. 1; Baker ja Yusof, 2017, s. 389). Ilman näitä pk-yritysten kilpailukyky suuria yrityksiä 

vastaan olisi merkittävästi huonompi. 

 

Tietojärjestelmien arkkitehtuurilla on tärkeä rooli määritettäessä niiden toimintaa ja te-

hokkuutta organisaatiossa. Nykyään toiminnanohjausjärjestelmille tunnetaan Habadin 

ja muiden (2017, s. 1) artikkelin mukaan neljä eri arkkitehtuuria, joita ovat kolmitasoinen 

arkkitehtuuri, verkkoarkkitehtuuri, palvelukeskeinen arkkitehtuuri sekä pilvipohjainen 

arkkitehtuuri, joista jokaisella on omat etunsa ja heikkoutensa. Ensimmäinen eli kolmi-

tasoinen arkkitehtuuri (eng. Three-Tier- architecture) on Katuun (2020) mukaan 2000-

luvulla kehitetyn ja nykyisin käytössä olevan laajennetun toiminnanohjausjärjestelmän 

yleinen arkkitehtuuri. Tämä kolmitasoinen arkkitehtuuri koostuu esitys-, sovellus- ja tie-

tokantakerroksesta. Arkkitehtuurin esityskerros on vastuussa vain tietojen selaamisesta 



22 

 
 
 

ja käyttöliittymän tarjoamisesta. Sovelluskerros on taso, josta tiedot haetaan ja siirretään 

tietokantakerroksen tietokantapalvelimille. Sovelluskerroksessa toteutetaan myös loogi-

set tehtävät ja liiketoimintasäännöt. Näistä neljästä arkkitehtuurista myös pilvipohjainen 

arkkitehtuuri on yleisesti paljon käytetty arkkitehtuuri varsinkin pk-yritysten toiminnan-

ohjausjärjestelmäratkaisuissa. Pilvipohjaista toiminnanohjausjärjestelmää käsitellään 

tarkemmin seuraavassa luvussa. (Habad ja muut, 2017, s. 1.) 

 

 

3.2 Toiminnanohjausjärjestelmä pilvipalveluna 

Samaan aikaan 2000-luvun alussa, kun toiminnanohjausjärjestelmät saavuttivat nykyi-

sen muotonsa integroituna kokonaisuutena, tuli tietojenkäsittelymaailmaan käyttöön 

pilvipalvelut. Berićin ja muiden (2018, s.403) määritelmän mukaan pilvipalvelu on tieto-

jenkäsittely-ympäristö, joka tarjoaa tietokoneen resurssien saatavuuden, skaalautuvuu-

den ja joustavuuden alhaisilla käyttökustannuksilla. Katuun (2020) artikkelissa Yhdysval-

tain Kansallinen Standardointi- ja Teknologiainstituutti (eng. National Institute of Stan-

dards and Technology, NIST) määritti pilvipalveluiden toiminnan seuraavasti: "kaikkialle 

ulottuvan, ketterän ja tilattavan verkkoyhteyden jakaminen konfiguroitavien tietokone-

resurssien kanssa (esim. verkot, palvelimet, varastointi, sovellukset ja palvelut), jotka voi-

daan tarjota nopeasti ja vapauttaa pienellä hallinnointitoimella tai suoraan palveluntar-

joajan toimesta.” Tämä tarkoittaa yksinkertaisesti sitä, että pilvipalveluilla mahdolliste-

taan kuvan 3 arkkitehtuurin mukaisesti verkkoyhteys tietokoneresursseihin, kuten esi-

merkiksi sovelluksiin, joita voi siten hyödyntää etänä verkon yli.  

 

Katuun (2020) artikkelissa NIST määritti aluksi kolme palvelumallia, joita ovat kuvan 3 

mukaisesti ohjelmisto palveluna, alusta palveluna sekä infrastruktuuri palveluna. Ohjel-

misto palveluna (eng. Software as a Service) eli SaaS, tarkoittaa ohjelmiston tarjoamista 

palveluna suoraan käyttäjälle. Tässä mallissa käyttäjä saavuttaa ohjelmistot asiakasraja-

pinnan kautta, joita käyttäjät eivät itse pysty hallitsemaan. Alusta palveluna (eng. Plat-

form as a Service) eli PaaS taas tarkoittaa sitä, että asiakkaalle tarjotaan väliohjelmisto, 

jota he voivat käyttää SaaS sovellusten rakentamiseen ja määrittämiseen. Infrastruktuuri 



23 

 
 
 

palveluna (eng. Infrastructure as a Service) eli IaaS on yksinkertaisin näistä. Sen ideana 

on tarjota asiakkaille laskentatehoa, kuten esimerkiksi tallennustilaa, verkkoa tai palve-

lujen käyttöä ohjelmistojen käyttöönottamista ja suorittamista varten. 

 

  

Kuva 3. Pilvipalveluiden arkkitehtuuri (Munir ja muut, 2013) 

 

Näistä kolmesta palvelumallista ohjelmisto palveluna on ollut yleisesti suosittu toimin-

nanohjausjärjestelmien käyttöönotossa (Katuu, 2020). Tämä johtuu siitä, että ohjelmisto 

palveluna mahdollistaa pienille ja keskisuurille yrityksille valmiin ja toimivan toiminnan-

ohjausjärjestelmän käyttöönoton sen sijaan, että kehitettäisiin oma toiminnanohjausjär-

jestelmä. 

 



24 

 
 
 

Katuun (2020) artikkelin mukaan toiminnanohjausjärjestelmien markkinoilla tapahtui 

merkittävä muutos 2000-luvulla, joka johtui pilvipalvelujen tulosta. Maailmassa oli tuota 

ennen pitkään yleinen malli, jonka mukaan tietotekniikan hankkimisessa noudatet-

tiin ”osta ja omista” mallia. Pilvipalvelujen yleistyttyä toiminnanohjausjärjestelmiäkin 

alettiin tarjota pilvipalveluna. Siitä lähtien pilvipohjaisille toiminnanohjausjärjestelmille 

on ollut suurta kysyntää, mikä on taas vähentänyt perinteisten toiminnanohjausjärjes-

telmien kysyntää. Suurin hyöty pilvipohjaisten toiminnanohjausjärjestelmien tulosta on 

ollut pk-yrityksille, joille omistettavat toiminnanohjausjärjestelmät olisivat liian suuri ku-

luerä (Katuu, 2020; Saini ja muut, 2014, s. 140). Pilvipohjaisten toiminnanohjausjärjes-

telmien tulo on vaikuttanut merkittävästi myös perinteisiä toiminnanohjausjärjestelmiä 

tarjoaviin yrityksiin, sillä pilvipalveluiden ketteryys on asettanut heille vaatimuksen to-

teuttaa järjestelmien muutoksia yhä nopeammin ja tiiviimmin kilpailukyvyn ylläpitä-

miseksi (Hailu & Rahman, 2012, s. 90–91). 

 

Toiminnanohjausjärjestelmät pilvipalveluna tarjotaan poikkeuksetta SaaS eli ohjelmisto 

palveluna muodossa (Berić ja muut, 2018, s.403; Katuu, 2020). Tästä johtuen toiminnan-

ohjausjärjestelmät pilvipalveluna tunnetaan Ivanuksen ja muiden (2018, s. 121) mukaan 

myös nimellä toiminnanohjaus SaaS ratkaisuna. Sørhellerin ja muiden (2018) mukaan 

pilvipohjainen toiminnanohjausjärjestelmä on toiminnanohjausjärjestelmä, jonka avulla 

kaikenkokoiset organisaatiot voivat tukea ja koordinoida keskeisiä liiketoimintaproses-

seja hyödyntämällä virtualisointia. Sørhellerin ja muut (2018) kuitenkin painottavat, että  

pilvipohjainen toiminnanohjausjärjestelmä ei ole kaikille sopiva, vaan sillä on myös huo-

not puolensa.  

 

Pilvipohjaisista toiminnanohjausjärjestelmistä on paljon hyötyä eri kokoisille yrityksille. 

Usein eniten hyötyä niiden käytöstä on pienille ja keskisuurille yrityksille. Ivanuksen ja 

muiden (2018, s. 121) artikkelissa tämä selitetään sillä, että pilvipohjainen toiminnanoh-

jausjärjestelmä pystyy tarjoamaan pienille ja keskisuurille yrityksille kaikki olennaiset toi-

minnot ja skaalautuvuuden ilman suuria ylläpito- ja kehityskustannuksia. Artikkelissaan 



25 

 
 
 

Gupta ja muut (2018) taas linjaavat merkittävän hyödyn syntyvän siitä, että pilvipohjais-

ten  toiminnanohjausjärjestelmien kehittyneet tietojenkäsittelyresurssit tarjoavat pie-

nemmille yritykselle mahdollisuuden parantaa tuottavuutta. Berić ja muut (2018, s. 403) 

ovat Guptan ja muiden (2018) sekä Ivanuksen ja muiden (2018, s. 121) kanssa samoilla 

linjoilla hyödyistä. Berić ja muiden (2018, s. 403) artikkelin mukaan pilvipohjainen toi-

minnanohjausjärjestelmä sekä auttaa organisaatioita säästämään kustannuksissa että 

parantamaan toiminnan tuottavuutta. Lisäksi Berić ja muut (2018, s. 403) muistuttavat, 

että koska pilvipohjainen palvelu tarkoittaa palveluntarjoajan valintaa, on yrityksellä 

mahdollisuus vertailla eri palveluntarjoajia ja valita parhaiten itselleen sopivan palvelun. 

Tämä mahdollistaa sen, että toiminnanohjausjärjestelmä vastaa täysin yrityksen tarpeita, 

eikä sisällä turhia ja joustamattomia ominaisuuksia. 

 

Koska hyötyjä on paljon ja kullakin yrityksellä on omat tarpeensa hyötyjen suhteen, on 

olennaista listata hyötyjä, joita eri artikkeleissa on listattu. Kuvan 4 listassa on poimittuna 

Ivanuksen ja muiden (2018, s. 122), Berićin ja muiden (2018, s.403) sekä Guptan ja mui-

den (2018) artikkeleista pilvipohjaisten toiminnanohjausjärjestelmien keskeisimmät hyö-

dyt. 

 



26 

 
 
 

 

Kuva 4. Pilvipohjaisten toiminnanohjausjärjestelmien hyödyt (Ivanus ja muut, 2018, s. 122; Berić 
ja muut, 2018, s.403;  Gupta ja muut, 2018) 

 

Kuvan 4 listauksessa mainittu automaatioiden käyttöönoton mahdollisuus on tämän tut-

kimuksen kannalta erittäin merkittävä ominaisuus, sillä tutkimuksen ratkaisu perustuu 

ohjelmistorobotiikan hyödyntämiseen toiminnanohjausjärjestelmässä. Lisäksi listassa 



27 

 
 
 

mainitut standardisointi sekä tiedon nopea hallinta helpottavat merkittävästi ohjelmis-

torobotiikan käyttöönottoa, sillä ohjelmistorobotiikan kannalta on tärkeää, että tieto on 

saatavilla ketterästi ja oikeassa muodossa (Durjoy, 2020). 

 

Sekä Sørheller ja muut (2018), että Ivanus ja muut (2018, s. 121) muistuttavat, että pilvi-

pohjaiset toiminnanohjausjärjestelmät eivät sovi aina kaiken kokoisille yrityksille. Ivanus 

ja muut (2018, s. 121) painottavat artikkelissaan, että keskisuurille ja suurille yrityksille 

toiminnanohjausjärjestelmien pilviratkaisut eivät ole aina täydellinen ratkaisu, joka kor-

vaa tehokkaasti perinteisen toiminnanohjausjärjestelmän ja muut yrityksen järjestelmät. 

Pilvipohjaista toiminnanohjausjärjestelmää voi suuremmissa yrityksissä kaiken toimin-

nan ohjaamisen sijaan hyödyntää yksittäisen osaston toiminnan ohjaamiseen, kuten esi-

merkiksi auttamaan henkilöstöosastoa hallitsemaan paremmin ansioluetteloitaan ja työ-

sopimuksiaan (Ivanus ja muut, 2018, s. 121). 

 

 

3.3 Ohjelmistorobotiikka pilvipohjaisessa toiminnanohjausjärjestel-

mässä 

Katuun (2020) artikkelissa on esitetty kuvan 5 mukaisesti kuinka toiminnanohjausjärjes-

telmien arvo on kasvanut toiminnanohjausjärjestelmien kehittyessä vuosikymmenten 

saatossa. Katuun (2020) artikkelin mukaan olemme tilanteessa, jossa aiemmassa luvussa 

esitellyt pilvipohjaiset toiminnanohjausjärjestelmät ovat yleistyneet ja yhä useampi hyö-

dyntää toiminnanohjausjärjestelmiä pilvipalveluiden kautta. Kuvassa 5 siniset nuolet ku-

vaavat tätä kehityksen tilaa ja askelia, joita on otettu kohti automaatioiden hyödyntä-

mistä. Kuten kuvan harmaasta nuolesta voidaan nähdä, toiminnanohjausjärjestelmien 

seuraava suuri kehitysaskel, nähdään automaatioiden lisäämisenä toiminnanohjausjär-

jestelmiin. Tämä askel kohti automatisointia on jo alkanut, mutta sitä ei ole vielä laajasti 

omaksuttu. Ohjelmistorobotiikka on tässä käynnissä olevassa harppauksessa olennai-

sena teknologiana sen käyttöalueen laajuuden vuoksi. (Katuu, 2020.) 

 



28 

 
 
 

 

Kuva 5 Toiminnanohjausjärjestelmien kehittyminen kohti automaatioita (Katuu, 2020) 

 

Useiden tutkimusten mukaan ohjelmistorobotiikka on ihanteellinen ratkaisu toiminnan-

ohjausjärjestelmien prosessien automatisointiin (Kohli, 2020; Katuu, 2020; Patel, 2020; 

Aguirre ja Rodriguez, 2017). Kuten aiemmissa luvuissa on käynyt ilmi, pilvipohjaisissa toi-

minnanohjausjärjestelmissä voidaan ketterästi hyödyntää automaatioteknologioita ku-

ten esimerkiksi ohjelmistorobotiikkaa. Katuu (2020), Patel (2020) sekä Terrell (2017) nos-

tavatkin artikkeleissaan juuri tämän ominaisuuden tärkeäksi. Katuu (2020) korostaa, että 

perinteisen toiminnanohjausjärjestelmän eli kuvan 5 mukaisen 2. sukupolven toimin-

nanohjausjärjestelmän sijaan pilvipohjaiset toiminnanohjausjärjestelmät tukevat pa-



29 

 
 
 

remmin automaatioita. Patel (2020) ja Terrell (2017) taas muistuttavat myös, että pilvi-

pohjaisen toiminnanohjausjärjestelmän käyttöönottanut yritys joutuu usein jatkamaan 

myös vanhojen järjestelmien käyttöä. Tämä taas tarkoittaa sitä, että integraatiot uusien 

ja vanhojen järjestelmien välille ovat tarpeellisia ja tässä ohjelmistorobotiikka toimii ket-

terästi integraation mahdollistajana (Patel, 2020). Toisin sanoen ohjelmistorobotiikka 

poistaa tehokkaasti esteet pilvipohjaisen toiminnanohjausjärjestelmän käyttöönotosta 

mahdollistamalla vanhojen järjestelmien liittämisen uusiin järjestelmiin (Terrell, 2017). 

 

Toiminnanohjausjärjestelmissä esiintyy paljon luvussa 2.2 listattuja ohjelmistorobotii-

kalle sopivia tehtäviä. Kohli (2020), Patel (2020) sekä Antonoaie ja muut (2017) listaavat 

artikkeleissaan useita ohjelmistorobotiikalle sopivia tehtäviä, joita esiintyy tyypillisesti 

toiminnanohjausjärjestelmissä. Esimerkiksi tavallisista toiminnanohjausjärjestelmien 

tehtävistä seuraavat sisältävät ohjelmistorobotiikan hyödyntämisalueen kannalta sopivia 

vaiheita: myyntitilausten ja laskujen käsittely, työntekijöiden hallinta, tietojen siirrot ja 

käsittelyt, asiakastiedottaminen sekä muu kontaktointi (Kohli, 2020; Patel, 2020; 

Antonoaie ja muut, 2017). Esimerkiksi laskujen käsittelyssä ohjelmistorobotiikkaa voi-

daan hyödyntää laskun tietojen tarkistamisessa sekä laskujen hyväksymisessä. Kohli 

(2020) muistuttaa, että toiminnanohjausjärjestelmissä on paljon toistuvien tietojen syöt-

tämistä ja ne ovat manuaalisia prosesseja työntekijöille. Tästä syystä toiminnanohjaus-

järjestelmissä on periaatteessa aina automatisoitavaa, sillä toistuvien tietojen syöttämi-

nen voidaan suorittaa ohjelmistorobotiikan avulla. Vaikka ohjelmistorobotiikan hyödyn-

täminen toiminnanohjausjärjestelmissä on ilmeisen tehokasta, Kohlin (2020) mukaan yli 

50 prosenttia toiminnanohjausjärjestelmän omaavista yrityksistä suorittavat tietojen kä-

sittelyn täysin manuaalisesti.  

 

 

3.4 Ohjelmistorobotiikka asiakastiedottamisessa 

Hyvä asiakaspalvelu on asiakastyytyväisyyden ja siten yrityksen menestymisen kannalta 

merkittävä tekijä. McGinnis (2019) mainitsee artikkelissaan hyvän asiakaspalvelun tason 

olevan tänä päivänä huomattavasti korkeammalla kuin koskaan aiemmin. McGinnis 



30 

 
 
 

(2019) määrittelee hyvän asiakaspalvelun olevan nopeaa, henkilökohtaista, yhdenmu-

kaista sekä ennakoivaa. Nopeus on asiakaspalvelussa tärkeää sillä asiakkaat haluavat tie-

don sillä hetkellä, kun he kokevat sille tarvetta. Mikäli tietoa ei asiakaspalvelun kautta 

saada reaaliaikaisesti, voi se vaikuttaa merkittävästi asiakastyytyväisyyteen. Henkilökoh-

taisuudella tarkoitetaan sitä, että asiakkaat haluavat tulla palvelluksi ihmisen toimesta, 

eivätkä halua kaikkea tietoa automaationa roboteilta. Henkilökohtaisuuden ja nopeuden 

kohdalla on yrityksen oltava tarkka, sillä yhä useammin asiakaspalvelun tehtäviä auto-

matisoidaan niiden toistuvan luonteen vuoksi (Redbord, 2020). Kuitenkaan kaikkia teh-

täviä ei tule siirtää ihmisiltä roboteille tai tekoälylle. (McGinnis, 2019.) 

 

Vaikka asiakaspalvelu onkin merkittävässä roolissa yritysten menestymisen kannalta, 

asiakaspalvelujen tarjonta ja laatu vaihtelevat yrityksestä riippuen. Asiakaspalvelun laa-

dun vaihtelun vuoksi hyvällä asiakaspalvelulla voidaan Kanovskan (2009) mukaan erottua 

kilpailijoista ja saavuttaa siten kilpailuetua. Kanovska (2009) nostaa asiakaspalvelun jopa 

parhaaksi tavaksi erottua kilpailijoista. Sharman ja Pattersonin (1999) hieman vanhempi 

tutkimus osoittaa, että asiakaspalvelulla ja viestinnällä on ollut aina suuri vaikutus me-

nestymiseen. Sharman ja Patterson (1999) mainitsevat tutkimuksessaan, että asiakas-

palvelun ja etenkin viestinnän tehokkuus vaikuttaa suoraan asiakkaiden sitoutumiseen 

ja siten myös yrityksen menestymiseen. 

 

Yrityksen asiakaspalvelusta suuri osa on asiakastiedottamista eli viestintää asiakkaan 

suuntaan. Asiakastiedottaminen on merkittävä tekijä asiakassuhteiden hallinnan kan-

nalta, sillä toimiva ja säännöllinen tiedottaminen auttaa asiakasta kehittämään rauhan 

tunnetta asiakassuhteesta ja siten auttaa asiakasta luomaan tunnesiteen yritykseen. Te-

hokkaan ja toimivan tiedottamisen ansiosta asiakkaan ja yrityksen välille voi syntyä side, 

joka kestää ongelmia ja suvaitsee virheitä, jotka taas saattaisivat johtaa asiakassuhteen 

päättymiseen. Parhaimmillaan tehokas tiedottaminen ja viestintä auttavatkin asiakkaita 

ymmärtämään suuriakin virheitä ja pysymään edelleen lojaaleina yritystä kohtaan. Te-

hokkaalla tiedottamisella tässä tarkoitetaan merkityksellistä ja ajankohtaista tietoa, joka 



31 

 
 
 

jaetaan asiakkaalle ymmärrettävissä ja siten sisäistettävässä muodossa. (Sharma & Pat-

terson, 1999.) 

 

Asiakastiedottamisesta puhuttaessa on kyse monenlaisten eri tietojen jakamisesta. Pro-

jektiluonteisista ja urakkatöistä puhuttaessa asiakas haluaa usein tietää tulevasta työstä 

usein aikataulun, työtavat, turvallisuusmääräykset sekä muut vaatimukset. Tämän lisäksi 

asiakkaat haluavat tietää myöhemmin työn alettua, miten työ on edennyt ja onko mihin-

kään aiemmin tiedotettuun tullut muutoksia. Tämän tyyppiset tiedot sekä asiakkaan yh-

teystiedot löytyvät yleensä toiminnanohjausjärjestelmistä, asiakkuudenhallintajärjestel-

mistä (eng. Customer Relationship Management, CRM) sekä muista järjestelmistä. Nyky-

aikaiset pilvipohjaiset toiminnanohjausjärjestelmät toteutetaan usein siten, että käyttäjä 

pääsee käsiksi kaikkiin olennaisiin tietoihin aina asiakastiedoista työn aikatauluun suo-

raan toiminnanohjausjärjestelmässä. Usein tiedottaminen tapahtuu siten, että asiakas-

palvelija etsii tiedon toiminnanohjausjärjestelmästä ja tarvittaessa muistakin järjestel-

mistä ja jakaa tiedon edelleen asiakkaalle manuaalisesti. (Stevens, 2017.) 

 

Kuten Stevensin (2017) artikkelista kävi ilmi, asiakkaalle jaettava tieto on usein toistuvaa 

ja toiminnanohjausjärjestelmistä ja muista järjestelmistä suoraan haettavissa. Koska täl-

laisen yksinkertaisen tiedon jakaminen voi viedä Redbordin (2020) mukaan jopa 90 pro-

senttia asiakaspalvelijan ajasta ja jaettava tieto on usein jo olemassa eri järjestelmissä, 

on tiedottamisen automatisointiin mahdollista hyödyntää ohjelmistorobotiikkaa. Asiak-

kaalle jaettava tieto voidaan ohjelmistorobotiikan avulla kerätä useammastakin järjestel-

mästä ohjelmistorobotiikalla toteutettujen järjestelmien välisien integraatioiden avulla. 

Integroitavia järjestelmiä voivat olla esimerkiksi asiakkuudenhallintajärjestelmä (eng. 

Customer Relationship Management, CRM) ja toiminnanohjausjärjestelmä. (Stevens, 

2017; Redbord, 2020.) 

 

Asiakastiedottamista ei kuitenkaan aina voida tai kannata toteuttaa kokonaan automaa-

tiona, sillä joidenkin tietojen jakaminen saattaa edellyttää sellaista ihmisten välistä kom-

munikointia, joka automatisoituna aiheuttaisi tyytymättömyyttä asiakkaassa. Tällaisissa 



32 

 
 
 

tilanteissa ohjelmistorobotiikalla voidaan automatisoida ne tehtävät, joihin ihmistä ei 

tarvita. Tällaisia tehtäviä voi olla esimerkiksi järjestelmien väliset integroinnit ja kaiken 

tiedon kokoaminen yhteen paikkaan asiakaspalvelijaa varten. Loput tehtävät, kuten tie-

don lopullinen jakaminen ja täydentäminen voidaan hoitaa asiakaspalvelijoiden toi-

mesta. Joka tapauksessa toiminnanohjausjärjestelmien ja asiakastiedottamisen yhteys 

on vahva, sillä yhä useammin kaikki asiakkaalle jaettava tieto löytyy toiminnanohjausjär-

jestelmistä. Ohjelmistorobotiikan yhteys näihin kahteen on myös mahdollista, mikäli yri-

tys pitää hyödylliseksi asiakastiedottamisen osittaisen tai täydellisen automatisoinnin. 

(Stevens, 2017.) 

 



33 

 
 
 

4 Tutkimusmenetelmät 

Tässä tutkimuksessa lähestymistapana toimii suunnittelutiede (eng. Design Science, DS). 

Hevnerin ja muiden (2004, s. 98) mukaan tietojärjestelmien suunnittelutieteellisessä tut-

kimuksessa (eng. Design Science Research, DSR) keskitytään luomaan ja arvioimaan in-

novatiivisia tietoteknisiä esineitä, joiden avulla organisaatiot voivat hoitaa tärkeitä tie-

toon liittyviä tehtäviä. Sekä Carcary (2011), että Gregor ja Hevner (2013) määrittävät 

suunnittelutieteellisen tutkimuksen keskittyvän esineiden eli artefaktien rakentamiseen 

ja arviointiin organisaation ongelmien ratkaisemiseksi. Suunnittelutieteellinen tutkimus 

on sovitettu eri tieteenaloille, mutta sen perusidea on yksinkertainen: Suunnittelutiede 

on lähestymistapa tutkimukseen, jonka tarkoituksena on rakentaa uutta sen sijaan, että 

selitettäisiin ja paljastettaisiin vanhoja asioita. Suunnittelutieteellisessä tutkimuksessa 

aikaisemmat tutkimustulokset ja tiedot kuitenkin käsitellään uusien ratkaisujen luo-

miseksi (Peffers ja muut, 2007). Suunnittelutiede lähestymistapana sopii hyvin tähän tut-

kimukseen, sillä se on kehitetty alun perin ongelmanratkaisuprosessiksi ja soveltuu eri-

tyisen hyvin uusien ratkaisujen luomiseen (Hevner ja muut, 2004, s. 82; Peffers ja muut, 

2007; Carcary, 2011, s. 109; Gregor ja Hevner, 2013). 

 

Jotta suunnittelutiede tietojärjestelmissä ymmärrettäisiin oikealla tavalla, on tehtävä tär-

keä kahtiajako. Suunnittelutieteessä suunnittelu koostuu sekä prosessista että artefak-

tista. Tällä tarkoitetaan sitä, että prosessilla kehitetään artefakti, joka taas arvioinnin lä-

pikäytyään synnyttää uutta tietoa, jonka avulla suunnitteluprosessia ja artefaktia voidaan 

edelleen parantaa. Tämä kehittämisen ja arvioimisen silmukka toistetaan Hevnerin ja 

muiden (2004, s. 78) mukaan yleensä useita kertoja ennen lopullisen artefaktin muodos-

tamista. Kuten kuvan 6 mukaisesti Hevner ja muut (2004, s. 80) ovat havainnollistaneet, 

tämä sykli jakaa tutkimuksessa opittua tietoa ympäristöön sekä tieteisiin. Kuva 6 osoittaa 

myös sen, mistä tutkimukseen tuleva tieto koostuu. Kuvan mukaisesti suunnittelutieteel-

liseen tutkimukseen tulee ympäristöltä tarpeet ja merkityksellisyys ja tiede tuottaa tut-

kimukselle eksaktia sovellettavaa tietoa (Hevner ja muut, 2004, s. 80). Myös Peffers ja 

muut (2007) esittävät kuvan 7 mukaisesti, kuinka tietojärjestelmissä suunnittelutiede 

muodostuu rakentamisesta ja arvioinnista, joiden välille muodostuu syklejä (nuolet). 



34 

 
 
 

Näissä kahdessa kuvassa kehittämisen ja arvioinnin välille syntyy syklejä, joissa opittua 

tietoa käytetään edelleen uusien artefaktien kehittämiseen. 

 

 

Kuva 6. Tietojärjestelmien tutkimuskehys (Hevner ja muut, 2004) 

 

 



35 

 
 
 

4.1 DSRM-malli 

Suunnittelutieteellisen tutkimuksen toteuttamiseksi on määritelty useita eri malleja. 

Hevnerin ja muiden (2004, s. 83) artikkelissa esitetään suunnittelutieteellisen tutkimuk-

sen suorittamiseksi seitsemänvaiheinen malli. Peffersin ja muiden (2007) artikkelissa 

taas esitellään kuusivaiheinen DSRM-malli (kuva 7), joka toimii tässä tutkimuksessa 

suunnittelutieteellisenä tutkimusmenetelmänä. DSRM-malli on kehitetty tarjoamaan 

yleisesti hyväksyttävän kehyksen suunnittelutieteellisen tutkimuksen suorittamiseen. 

Malli koostuu kuvan 7 mukaisesti kuudesta eri vaiheesta. (Peffers ja muut, 2007.) 

 



36 

 
 
 

 

Kuva 7. DSRM-prosessimalli (Peffers ja muut, 2007) 

 



37 

 
 
 

Ensimmäinen vaihe on ongelman tunnistaminen ja motivaatio. Tässä vaiheessa määrite-

tään erityinen tutkimusongelma eli perustellaan kehitettävän artefaktin tarkoitus ja laa-

juus (Gregor ja Hevner, 2013, s. 349). Koska ongelman määrittelyä käytetään artefaktin 

kehittämiseen, voi olla hyödyllistä jakaa ongelma käsitteellisesti, jotta ratkaisussa voi-

daan paremmin huomioida ongelman monimutkaisuus. Ratkaisun arvon perustelemi-

nen on tärkeä tehdä perusteellisesti, koska se motivoi tutkijaa sekä tutkimuksen lukijoita 

etsimään ratkaisua ja ymmärtämään saadut tulokset. Ratkaisun arvon perustelemisessa 

kerrotaan tietoa ongelman tilasta ja sen ratkaisemisen tärkeydestä. (Peffers ja muut, 

2007.) 

 

Toisessa vaiheessa päätetään ratkaisun tavoitteet, jotka perustuvat ensimmäisessä vai-

heessa määriteltyihin ongelmiin, ja siihen mikä on mahdollista ja mikä ei. Tavoitteet voi-

vat olla määrällisiä, kuten ehdot, joilla uusi ratkaisu olisi parempi kuin nykyiset, tai laa-

dullisia, kuten kuvaus siitä, kuinka uuden artefaktin odotetaan tukevan ratkaisuja ongel-

miin. Koska tavoitteet perustuvat yleensä määriteltyihin ongelmiin, tulisi tässä vaiheessa 

olla tarkat tiedot ongelman tilasta ja mahdollisista olemassa olevista ratkaisuista ja nii-

den toimivuudesta. (Peffers ja muut, 2007.) 

 

Kolmannessa vaiheessa toteutetaan ratkaisun suunnittelu ja kehittäminen. Tässä vai-

heessa luodaan artefakti. Artefaktit ovat yleensä rakenteita, malleja, menetelmiä tai il-

mentymiä (Winter, 2008, Peffers ja muut, 2007; Hevner ja muut, 2004). Winter (2008) 

kuitenkin painottaa artikkelissaan sitä, että artefakti voi olla muukin kuin rakenne, malli, 

menetelmä tai ilmentymä, mutta nämä ovat yleisimpiä. Artefaktin suunnitteluun ja ke-

hittämiseen kuuluu artefaktin toiminnollisuuksien ja arkkitehtuurin määrittäminen, joi-

den kautta syntyy lopullinen artefakti. Jotta tämä vaihe voidaan suorittaa ja ratkaisu ke-

hittää, on tunnettava tutkimusalueen teoria, johon artefakti suurimmaksi osaksi lopulta 

pohjautuu. (Peffers ja muut, 2007; Hevner ja muut, 2004, s. 78; Winter, 2008) 

 



38 

 
 
 

Neljäs vaihe eli demonstraatio näyttää artefaktin käytön yhden tai useamman ongelman 

ratkaisemiseksi. Tähän vaiheeseen voi kuulua artefaktin käyttäminen kokeilussa, simu-

laatiossa, tapaustutkimuksessa, todistuksessa tai muussa vastaavassa toiminnassa. Tä-

män vaiheen toteuttamiseen tarvitaan laajat tiedot siitä, miten artefaktia voidaan käyt-

tää ongelman ratkaisemiseksi. (Peffers ja muut, 2007.) 

 

Viidennessä vaiheessa toteutetaan arviointi. Arvioinnissa tarkkaillaan ja mitataan arte-

faktin pätevyyttä, käyttökelpoisuutta, laatua sekä tehokkuutta (Gregor ja Hevner, 2013, 

s. 351). Tässä vaiheessa vertaillaan toisessa vaiheessa määriteltyjä ratkaisun tavoitteita 

sekä neljännessä vaiheessa saatuja havaintoja artefaktin toimivuudesta. Arviointi voi si-

sältää mitä tahansa empiiristä tai loogista todistetta. Mittareita arvioinnin tekemiseksi 

voivat olla toisessa vaiheessa määriteltyjen tavoitteiden luonteesta riippuen esimerkiksi 

budjetit, tuotto, tyytyväisyystutkimuksen tulokset, asiakaspalautteet tai simulaatiot. Ar-

viointivaiheen lopussa voidaan päättää, palataanko takaisin kolmanteen vaiheeseen pa-

rantamaan artefaktin tehokkuutta vai jatketaanko seuraavaan vaiheeseen. (Peffers ja 

muut, 2007.) 

 

Kuudes ja viimeinen vaihe sisältää viestinnän. Tässä vaiheessa kerrotaan tutkijoille ja lu-

kijoille havaitusta ongelmasta ja sen merkityksestä sekä sen perusteella kehitetystä arte-

faktista ja sen hyödyllisyydestä, tarkkuudesta ja tehokkuudesta. Tämän vaiheen sisältöä 

muut tutkijat voivat edelleen hyödyntää omissa tutkimuksissaan parantaakseen ratkai-

sua tai kehittääkseen uuden sen perusteella. (Peffers ja muut, 2007.) 

 

 

4.2 DSRM-malli tässä tutkimuksessa 

Peffers ja muut (2007) korostavat artikkelissaan, että DSRM-mallia voidaan toteuttaa 

muillakin tavoilla ja tätä mallia voidaan parantaa ja muutella. DSRM-malliin on valittu 

yleisesti hyväksi koetut vaiheet, joten artikkelissa ehdotetaan, että sitä ei tulisi käyttää 

jäykkänä tutkimuksen mallina, jota noudatetaan pilkun tarkasti. Koska Peffersin ja mui-

den (2007) DSRM-mallin vaiheita on tähän tutkimukseen liikaa tutkimuksen laajuudesta 



39 

 
 
 

johtuen, tässä tutkimuksessa DSRM-mallista käsitellään kuudesta vaiheesta kuvan 8 mu-

kaisesti neljä ensimmäistä vaihetta.  

 

 

Kuva 8. DSRM-prosessimalli tässä tutkimuksessa 

 

Peffersin ja muiden (2007) DSRM-mallin neljä ensimmäistä vaihetta sopivat hyvin tähän 

tutkimukseen, sillä nämä vaiheet liittyvät eniten uuden ratkaisun luomiseen, ja niiden 

avulla voidaan kehittää uusi ratkaisu ongelmaan. Viimeisten vaiheiden puute ei aiheuta 

tutkimuksen kannalta suuria puutteita ja nämä vaiheet voidaan suorittaa edelleen jatko-

tutkimuksena, mikäli sellainen koetaan tarpeen. 

 



40 

 
 
 

Ensimmäisessä vaiheessa, eli ongelman tunnistamisessa ja motivaatiossa käsitellään 

asiakastiedottamiseen liittyviä ongelmia. Ongelmien tunnistamisessa hyödynnetään toi-

mialan käytännön kokemuksia sekä laskelmia asiakastiedottamisen resurssien tarpeista.  

Tässä vaiheessa tarkennetaan myös asiakastiedottamisen tehtävien luonnetta ja perus-

tellaan mainittujen ongelmien ratkaisemisen merkityksellisyyttä.  

 

Toisessa vaiheessa määritellään ratkaisulle selkeät tavoitteet, joihin ratkaisun tulee vas-

tata. Tavoitteet perustuvat ensimmäisessä vaiheessa määriteltyihin asiakastiedottami-

sen ongelmiin, joten tavoitteita voi olla havaituista ongelmista riippuen useita. Tässä ar-

tefaktiin kohdistuu laadullisia tavoitteita. Tavoitteiden toteutuminen käydään yleensä 

läpi viidennessä vaiheessa, mutta koska viidettä vaihetta tässä tutkimuksessa ei toteu-

teta, tavoitteiden toteutuminen käydään läpi neljännessä vaiheessa. 

 

Kolmannessa vaiheessa aloitetaan toisessa vaiheessa määriteltyjen tavoitteiden mukai-

sesti uuden ratkaisun, eli artefaktin suunnittelu ja kehittäminen. Artefaktin suunnitte-

lussa hyödynnetään tutkimuksen teorialuvuissa käsiteltyä teoriaa sekä toimialan koke-

muksia teemahaastattelujen avulla. Lisäksi suunnittelussa ja kehityksessä hyödynnetään 

Markuksen ja muiden (2002) havaintojen mukaisesti tutkijan kokemusta, luovuutta ja 

ongelmanratkaisutaitoa. Markus ja muut (2002) nostavat artikkelissaan esille, että tutki-

muksessa tutkijan oma kokemus, luovuus ja ongelmanratkaisutaidot toimivat merkittä-

vinä tekijöinä. Kehittämisvaiheessa luodaan suunnitelman pohjalta optimaalinen asia-

kastiedottamisen automaation alustan prototyyppi, jota voidaan seuraavassa vaiheessa 

eli demonstraatiossa esitellä ja arvioida. 

 

Neljännessä vaiheessa esitellään kolmannessa vaiheessa kehitetty ratkaisu eli proto-

tyyppi asiakastiedottamisen automaation alustasta, jolla osoitetaan ongelmien ratkai-

suun mahdollisuus. Esitys perustuu prototyypin esittelemiseen tilanteessa, jossa tiedot-

taminen on edennyt tiedottamisen alkuvaihetta pidemmälle. Tällaisen tilanteen avulla 

prototyypin toimivuus voidaan havaita helpoiten. Ennen neljättä vaihetta on aiempien 



41 

 
 
 

vaiheiden tietojen oltava selkeästi saatavilla, sillä tämä vaihe perustuu aiempien vaihei-

den aikaansaannoksiin ja niiden esille tuomiseen. Tässä vaiheessa prototyypille suorite-

taan myös asiantuntijahaastattelujen avulla kevytarviointi, joka toimii tämän tutkimuk-

sen ainoana arviointina. Kevytarvioinnin valitseminen tähän vaiheeseen perustuu Vena-

blen ja muiden (2016) Quick & Simple strategiaan. Quick & Simple strategiassa tutkimuk-

selle suoritetaan vain vähän tai vain yksi arviointijakso, mikä mahdollistaa tutkimuksen 

nopean loppuunsaattamisen kevyen arvioinnin myötä (Venable ja muut, 2016). Quick & 

Simple strategia sopii tutkimukseen, sillä tässä tutkimuksessa DSRM-mallin seuraaminen 

päättyy neljänteen vaiheeseen eikä tutkimus siten sisällä viidettä vaihetta, joka sisältäisi 

kattavamman arvioinnin. Myös Sonnenbergin ja vom Brocken (2012) artikkeli tukee va-

lintaa, sillä heidän mukaansa tutkimuksen eri vaiheiden välillä suoritettavat kevyet arvi-

oinnit ovat hyödyllisiä, sillä prototyypistä voidaan siten nähdä jo aikaisessa vaiheessa, 

toimiiko se toivotulla tavalla. Kevyiden arviointien avulla voidaan vetää myös johtopää-

töksiä prototyypin hyödyllisyydestä (Sonnenbergin ja vom Brocken, 2012). 

 

 

4.3 Haastattelut 

Kuten aiemmasta luvusta kävi ilmi, tässä tutkimuksessa toteutetaan haastatteluja. Haas-

tatteluaineiston tehtävänä on määrittää kehitettävälle artefaktille linjat. Lisäksi haastat-

teluaineistoa hyödynnetään kehitetyn artefaktin arvioinnissa. Haastattelut tässä tutki-

muksessa toteutetaan teemahaastatteluina, joita kutsutaan myös puolistrukturoiduiksi 

haastatteluiksi niiden luonteen vuoksi (Hirsjärvi & Hurme, 2015, s. 47). Teemahaastattelu 

on haastattelumalli, jolle on tyypillistä ennalta määrättyjen ja määrittelemättömien ky-

symysten suhde (Hirsjärvi & Hurme, 2015, s. 47). Tämä tarkoittaa sitä, että teemahaas-

tatteluissa osa kysymyksistä on ennalta määrättyjä ja osa muodostuu haastattelun yh-

teydessä. Teemahaastattelut eivät myöskään pakota haastattelua laadulliseksi tai mää-

rälliseksi, eikä haastattelukertojen määrällä ole merkitystä. Nämä mahdollistavat haas-

tattelujen keskittymisen tiettyyn teemaan sitomatta haastattelua mihinkään tiettyyn 

runkoon tai järjestykseen. Vaikka teemahaastattelut ovat suhteellisen vapaita, ne poik-

keavat kuitenkin esimerkiksi vapaasta haastattelumallista, eli syvähaastattelusta siten, 



42 

 
 
 

että teemahaastatteluissa aihepiirit ja teema-alueet pysyvät aina samana. (Hirsjärvi & 

Hurme, 2015, s. 47–48.) 

 

Jokaisella haastattelutyypillä on omat hyötynsä. Hirsjärven ja Hurmeen (2015, s. 14) mu-

kaan haastattelut yleisesti ja varsinkin teemahaastattelut sopivat niiden joustavuuden 

ansiosta hyvin moniin eri tilanteisiin ja tarpeisiin. Joustavuudella tarkoitetaan etenkin 

kielellisen vuorovaikutuksen tuomaa vapautta. Kielellinen ja kasvokkain käytävä vuoro-

vaikutus antaa Hirsjärven ja  Hurmeen (2015, s. 34) mukaan haastattelijalle mahdollisuu-

den tiedon haun suuntaamiseen kesken haastattelun. Lisäksi kasvokkain käytävä vuoro-

vaikutus mahdollistaa vastausten tarkemman analysoinnin haastateltavan eleitä tulkit-

semalla (Hirsjärvi & Hurme, 2015, s. 34). 

 

Haastatteluja tässä tutkimuksessa toteutetaan DSRM-mallin vaiheissa kolme ja neljä eli 

suunnittelu- ja kehitysvaiheessa sekä demonstraatiovaiheessa. Haastateltavina toimii 

kaksi rakennusalalla työskentelevää henkilöä. Haastateltavat ovat töissä johdannossa 

määritetyn yrityksen mukaisessa yrityksessä, ja heillä on esimiesaseman myötä koke-

muksia asiakastiedottamisesta usean vuoden ajalta. Haastateltavien pienestä määrästä 

johtuen haastattelut suoritetaan yksittäin. Yksittäin toteutettava haastattelu on Hirsjär-

ven ja  Hurmeen (2015, s. 60) mukaan hyvä myös haastateltavan kokemuksen kannalta, 

sillä yksittäin haastateltuna haastateltava kokee olevansa arvostetumpi kuin ryhmähaas-

tattelussa. DSRM-mallin kolmannessa vaiheissa haastatteluilla on tarkoitus tukea ratkai-

sun suunnittelun päätöksiä ja perustella ratkaisuun päättyviä valintoja. 

  

Haastattelut toteutetaan etänä videopuhelun kautta ja niistä tallennetaan sekä kuva että 

ääni. Haastattelun suorittaminen videoyhteydellä mahdollistaa paremman kommuni-

kaation haastattelijan ja haastateltavan välillä. Lisäksi videoyhteys mahdollistaa haasta-

teltavien vastausten tarkemman tulkinnan. Hirsjärven ja  Hurmeen (2015, s. 60) mukaan 

haastatteluaineiston kuvaileminen tarkoittaa henkilöiden, tapahtumien ja kohteiden 



43 

 
 
 

ominaisuuksien ja piirteiden tulkintaa. Tässä tutkimuksessa haastatteluaineiston tulkin-

nassa huomioidaan haastateltavien vastausten lisäksi haastateltavien reaktiot sekä ke-

honkieli.  

 

 

4.4 Aineiston valinta ja käsittely 

Hirsjärven ja Hurmeen (2008, s. 138) mukaan haastatteluaineisto voidaan purkaa kah-

della tavalla, eli joko litteroimalla tai tulkitsemalla tallennettua aineistoa, joka on video- 

ja/tai äänimuodossa. Haastatteluaineiston purkaminen ja analysointi tapahtuu tässä tut-

kimuksessa jälkimmäisellä vaihtoehdolla, eli suoraan tallennetusta aineistosta, joka tässä 

tutkimuksessa on videonauha äänillä. Haastatteluaineiston analysointi alkaa osittain jo 

haastatteluvaiheessa, havaitsemalla haastatteluista ilmiöitä, jotka toistuvat tai painottu-

vat. Lisäksi tässä tutkimuksessa haastattelija tulkitsee haastateltavan näkemyksiä jo 

haastattelun aikana, jotta haastateltavalla on mahdollisuus vahvistaa tulkintojen oikeel-

lisuus, ja haastattelijalla on mahdollisuus ohjata keskustelua haastattelun aikana kohti 

olennaisen tiedon saamista (Hirsjärvi ja Hurme, 2008, s. 137). Hirsjärven ja Hurmeen 

(2008, s. 136) mukaan haastattelun aikana tapahtuvan analysoinnin perusteella voidaan 

luoda alustavia päätelmiä haastattelun aikana syntyneistä havainnoista. Pääosin analy-

sointi tapahtuu kuitenkin vasta haastattelun suorittamisen ja aineiston purkamisen jäl-

keen. Tässä tutkimuksessa haastatteluaineistoa analysoidaan teemoittain tyypittele-

mällä haastateltavien näkemyksiä. Teemoittain ja tyypittelemällä tapahtuva analysointi 

mahdollistaa synteesin luomisen eri haastateltavien näkemysten välille. Käytännössä 

tämä tarkoittaa haastateltavien näkemysten vertailemista ja yhdenmukaisten näkemys-

ten yhdistämistä, ja sitä kautta laajempien tulkintojen luomista. (Hirsjärvi ja Hurme, 2008, 

s. 173–174.) 

 

 



44 

 
 
 

5 Alustan suunnittelu ja kehittäminen 

Tässä luvussa käsitellään erillisissä alaluvuissa DSRM-mallin neljä ensimmäistä vaihetta. 

DSRM-mallin ensimmäiset kaksi vaihetta määrittävät pääosin kolmatta vaihetta, jossa lo-

pullista artefaktia kehitetään. Neljännessä vaiheessa esitellään artefakti ja toteutetaan 

kevyt arvio sen toimivuudesta asiantuntijahaastattelujen avulla. 

 

 

5.1 Ongelman tunnistaminen ja motivaatio 

Rakennusalalla tarjottavat palvelut ovat usein urakkaluonteisia töitä eli rakennusurakoita. 

Rakennusurakka on urakoitsijan, eli yrityksen vastiketta vastaan suorittama palvelu asi-

akkaalle (Minilex, 2021). Rakennusurakka voi Minilexin (2021) mukaan sisältää tyypilli-

sen rakentamisen lisäksi esimerkiksi korjausrakentamista, eli mitä vain huomattavaa pe-

ruskorjausta, jolla on vaikutusta korjattavan kiinteistön arvoon. Asiakkaana voi olla sekä 

yksityinen kuluttaja että yritys. Riippumatta osapuolten asemasta, rakennusurakalle luo-

daan yleensä yleisten sopimusehtojen mukainen molempia osapuolia sitova urakkasopi-

mus, jossa sovitaan urakan toteuttamisesta tarkemmin (Minilex, 2021). Urakkasopimuk-

sessa voidaan sopia esimerkiksi urakan suorittamisen aikataulusta, sisällöstä, hinnasta 

sekä maksutavoista. Urakoiden luonteen vuoksi on tärkeää sopia jo sopimusvaiheessa 

mahdollisimman tarkkaan urakan suorittamiseen vaikuttavista asioista, eli aikatauluista, 

työmenetelmistä sekä mahdollisista materiaalivalinnoista. Asiakastyytyväisyyden kan-

nalta urakkasopimukset ovat keskeisiä, sillä asiakkaan odotukset perustuvat suurim-

maksi osaksi sopimuksessa sovittuihin asioihin. Koska urakat suoritetaan yleensä tiiviissä 

aikataulussa ja kaikkea urakkaan liittyvää ei voida tietää ja sopia urakkasopimuksessa, on 

asiakastiedottamisella suuri vaikutus asiakkaan kokemukseen ja sitä kautta asiakastyyty-

väisyyteen. Asiakastiedottamista urakan suorittamisen aikana voi tapahtua monesta 

syystä. Tällaisia asioita voivat olla esimerkiksi urakan suorittamisen aikana ilmenevät 

muutokset aikatauluissa tai työvaiheissa. (Sharma & Patterson, 1999; Minilex, 2021). 

 



45 

 
 
 

Kuten kuvasta 9 voi nähdä, rakennusalan rakennusurakoissa asiakastiedottaminen alkaa 

yleensä sopimusten teosta ja voi jatkua vielä pitkään työn suorittamisen jälkeenkin. Ku-

vassa 9 on listattuna merkittävimmät vaiheet rakennusurakan suorittamisesta. Kuvan 

kaikki vaiheet on luokiteltu vielä asiakastiedottamisen toteuttamisen havainnollista-

miseksi neljään eri vaiheeseen. Tämä jako on havainnollistettu kuvassa vihreillä nuolilla. 

Vaiheet etenevät kuvan 9 mukaisesti ylhäältä alaspäin seuraavasti: myyntivaihe, urakan 

aloittaminen, urakan suorittaminen sekä urakan valmistuminen. Seuraavaksi määritel-

lään tarkemmin mitä asiakastiedottaminen tarkoittaa kussakin vaiheessa. 

 

 

Kuva 9. Rakennusurakan eteneminen 

 



46 

 
 
 

Myyntivaiheessa asiakastiedottaminen on usein urakkasopimuksen solmimiseen liitty-

vää. Tässä vaiheessa tiedotettavia asiat voivat liittyä esimerkiksi urakan suorittamisen ai-

katauluun, materiaaleihin, turvallisuusmääräyksiin tai asiakkaan pyytämiin toiveisiin 

urakkaan liittyen. Myyntivaiheessa asiakastiedottaminen vaihtelee paljon tilanteesta 

riippuen. Pienemmissä urakoissa myyntivaiheessa ei välttämättä ole tarpeen tiedottaa 

mitään ja suuremmissa urakoissa, kuten esimerkiksi taloyhtiöiden kanssa sovituissa ura-

koissa tiedotettavaa voi olla paljonkin. 

 

Kun sopimuksen mukainen urakan aloitusaika lähenee, alkaa urakan aloittamiseen liit-

tyvä tiedottaminen. Tässä vaiheessa olennaisinta on urakan suorittamisen tarkemmista 

tiedoista, kuten aloitusaikataulusta ja työvaiheista tiedottaminen. Urakan aloittamisesta 

tiedottaminen tehdään yleensä hyvissä ajoin ennen tarkempaa arvioitua aloitusaikaa, 

sillä asiakkaalla on tiedossa vain urakkasopimuksessa sovittu alustava aikataulu. Asiak-

kaat haluavat usein tietää urakan tarkemman aikataulun heti kuin se on mahdollista, sillä 

urakan suorittaminen voi vaikuttaa heidän omaan arkeensa merkittävästi. Aikataulun li-

säksi tässä vaiheessa tiedotetaan mahdollisista muista urakan aloittamiseen liittyvistä 

asioista. Tällaisia asioita voivat olla esimerkiksi urakan suorittavien henkilöiden tiedot ja 

mahdolliset materiaalitoimitukset kohteeseen ennen urakan alkamista. 

 

Kun urakka alkaa, tiedottaminen muuttuu tiheämmäksi urakan suorittamisen varrella ta-

pahtuvien lisääntyvien tapahtumien vuoksi. Ensinnäkin urakan aloittamisen yhteydessä 

suoritetaan usein alkutarkastus, jossa tiedotetaan asiakkaalle urakan aikana suoritetta-

vista vaiheista tarkemmin sekä mahdollisista asiakkaan velvollisuuksista. Urakan suorit-

tamisen aikana asiakkaalle tiedotetaan yleensä kunkin suoritetun työpäivän jälkeen ura-

kan etenemisen tilanne sekä tulevat työvaiheet. Lisäksi työpäivien jälkeen tiedotetaan 

mahdollisista urakkaan liittyvistä muutoksista, jotka asiakkaan on hyvä huomioida. Yksi-

tyishenkilöille suoritettavissa urakoissa asiakkaalle tiedotettavia asioita voi olla huomat-

tavasti enemmän kuin yrityksille suoritettavissa urakoissa. Tämä johtuu siitä, että yksi-

tyishenkilöille suoritettavat urakat kohdistuvat usein asiakkaiden koteihin, mikä taas tar-

koittaa sitä, että kohteessa ei usein ole omistajia paikalla heidän ollessa töissä. 



47 

 
 
 

 

Työn valmistuessa asiakastiedottaminen vähenee, mutta voi jatkua vielä pitkäänkin. 

Työn valmistuttua asiakkaan kanssa käytävä kommunikaatio liittyy suurimmaksi osaksi 

urakan laskutukseen ja mahdolliseen lopputarkastukseen, joka suoritetaan usein urakan 

päätteeksi. Lisäksi asiakkaat ovat innokkaita esittämään vielä pitkään urakan suorittami-

sen jälkeen kysymyksiä toteutettuun urakkaan liittyen, mikä voi lisätä tiedottamisen 

määrää. Vähentääkseen asiakkaiden myöhempiä kysymyksiä, asiakkaalle voidaan tiedot-

taa ennakkoon esimerkiksi ohjeita, kuinka kiinteistöä tulisi hoitaa urakan jälkeen. 

 

Asiakastiedottaminen voi yrityksestä riippuen kuulua eri henkilöiden toimenkuvaan. 

Asiakastiedottaminen voi olla esimerkiksi työnjohtajan tai työpäällikön tehtävä, mutta se 

voi olla myös esimerkiksi pienemmissä organisaatioissa suoraan urakan toteuttavan 

työntekijän tehtävä. Asiakastiedottamisen vastuu voi myös siirtyä eri henkilöiden välillä 

urakan edetessä. Usein rakennusalalla asiakastiedottamisen suorittaa kuitenkin työnjoh-

taja, joka myös aikatauluttaa ja suunnittelee urakan suorittamisen ennen sen alkamista 

ja johtaa urakkaa sen suorittamisen aikana. Asiakastiedottaminen voi kuluttaa työnjoh-

don resurssia paljonkin, mikäli työnjohtajalla on useita urakoita johdettavana. Tästä 

syystä asiakastiedottamisen vastuu voi urakan suorittamisen aikana siirtyä enemmän 

urakan suorittaville työntekijöille. Lisäksi työntekijöillä voi olla enemmän tarkempia tie-

toja urakasta kuin työnjohtajalla, joten työntekijän voi olla helpompi tiedottaa suoraan 

asiakasta ja työnjohtajaa kuin välittää tieto työnjohtajan kautta asiakkaalle. Asiakastie-

dottaminen voi siis kuulua yhtä aikaa usealle henkilöille. 

 

Asiakastiedottamiseen kuluvat resurssit vaihtelevat riippuen urakan osapuolista ja sisäl-

löstä, kuten aiemmissa kappaleissa on käynyt ilmi. Tästä syystä asiakastiedottamiselle 

kuluvaa resurssia voi olla vaikeaa määritellä tarkkaan. Aiemmissa kappaleissa määritet-

tyjen asiakastiedottamisen vaiheiden avulla voidaan kuitenkin laskea suuntaa antava ar-

vio asiakastiedottamiseen kuluvasta ajasta. Kuvassa 10 on esitetty yhteydenottojen mää-

rät kussakin vaiheessa. Kuvan laskelmissa on käytetty arviota asiakastiedottamisen tar-

peista rakennusurakoissa, joiden suorittamisen kesto on keskimäärin noin 6 vuorokautta. 



48 

 
 
 

Kuvan 10 esimerkki koskee lyhempää rakennusurakkaa, joten pidemmässä urakassa tie-

dottamista on huomattavasti enemmän. Tässä esimerkissä ensimmäisessä vaiheessa eli 

myyntivaiheessa asiakastiedottamiseen sisältyy keskimäärin yksi yhteydenotto, joka ta-

pahtuu yleensä puhelimitse ja voi sisältää esimerkiksi tietoa urakan materiaalivalintoihin 

liittyen. Toisessa vaiheessa eli urakkaa aloittaessa yhteydenottoja on keskimäärin kaksi. 

Nämä yhteydenotot voivat sisältää esimerkiksi tietoa urakan tarkemmasta aikataulusta 

ja yhteydenotto voi tapahtua joko tekstiviestillä tai puhelimitse. Kolmannessa vaiheessa 

eli urakan suorituksen aikana yhteydenottoja tapahtuu noin 8 kertaa. Yhteydenotot tässä 

vaiheessa liittyy pitkälti urakan aikataulun tarkennuksiin ja suoritettujen työvaiheiden 

kuittaamiseen päivittäin. Kolmannen vaiheen tiedot välitetään asiakkaalle yleensä teks-

tiviestillä, sillä aikatauluihin liittyvä tieto ei yleensä ole kiireellistä, mutta se on hyvä olla 

asiakkaalle helposti saavutettavissa. Viimeisessä vaiheessa eli urakan jälkeen yhteyden-

ottoja tapahtuu enää vähän, mutta tässä esimerkissä loppuvaiheeseen on laskettu kek-

simäärin yksi yhteydenotto, joka voi liittyä esimerkiksi urakan laskutukseen. Tällaiset 

asiat eivät ole yleensä kiireisiä, joten tämä tieto voidaan välittää esimerkiksi sähköpos-

titse tai tekstiviestillä puhelun sijaan. Tämä esimerkki on suuntaa antava ja tässä esimerk-

kiarviossa on laskettu vain välttämättömät tiedotettavat asiat. On mahdollista, että jois-

sakin urakoissa yhteydenottoja on huomattavasti enemmän kuin kuvan 10 esimerkissä. 

On myös mahdollista, että joissain urakoissa tiedotettavien asioiden määrä on pienempi 

kuin esimerkissä, sillä kaikissa urakoissa tiedotettavia asioita ei ole esimerkin mukaisesti. 

 



49 

 
 
 

 

Kuva 10. Asiakastiedottamiseen kuluva resurssi rakennusurakan aikana 

 

Kuvan 10 esimerkin mukainen asiakastiedottamisen resurssin tarve on laskettu siten, 

että jokainen yhteydenotto vie 5 minuuttia aikaa. 5 minuuttia on määritetty yhteyden-

ottoon kuluvaksi ajaksi, sillä se sisältää kaiken tiedon mahdollisesta hankinnasta yhtey-

denottoon. Tämän esimerkin mukaan aikaa yhden asiakkaan tiedottamiseen rakennus-

urakan aikana kuluu 60 minuuttia. Tämän laskelman avulla voidaan laskea esimerkki tyy-

pillisen yrityksen asiakastiedottamiseen kuluvasta resurssista vuodessa. Käytetään esi-

merkkinä kuvitteellista rakennusalan yritystä, jolla on vuodessa yhteensä 350 asiakasta 

eli urakkaa, ja heille toteutettavat rakennusurakat ovat kestoltaan keskimäärin 6 vuoro-

kautta, kuten kuvassa 10. Tällaisessa tapauksessa 60 minuuttia kerrotaan 350 rakennus-

urakalla eli tällöin asiakastiedottamiseen kuluu yhteensä 21 000 minuuttia eli noin 350 

tuntia. 350 tuntia tarkoittaa 7,5 tunnin työpäivillä noin 47 työpäivää. 47 työpäivää vastaa 

yhden työntekijän reilun kahden kuukauden työaikaa, joka voi tarkoittaa kuluna noin 

9000 – 12 000 euroa vuodessa. Tämä esimerkki vastaa noin 3 500 000 euroa liikevaihtoa 

tekevän yrityksen tilannetta, kun yrityksen rakennusurakoiden arvonlisäveroton keski-

hinta on noin 10 000 euroa ja rakennusurakoita 350.  

 

Kuten aiemmasta laskelmasta voidaan huomata, ongelmana asiakastiedottamisessa on 

se, että siihen saattaa kulua työnjohtajilta ja työntekijöiltä kymmeniä tunteja työtä, mikä 



50 

 
 
 

taas voi tarkoittaa kustannuksissa tuhansia euroja. Ongelmana ajan kuluminen asiakas-

tiedottamisen tehtäviin on merkittävä, mutta ei ainoa. On myös huomioitava se, että kun 

asiakastiedottamisen hoitaa työnjohtaja tai työntekijä, voi heillä olla useita rakennusura-

koita saman aikaisesti tiedotettavana. Lisäksi tämä tarkoittaa sitä, että asiakkaalle jaet-

tava tieto ei sijaitse samassa paikassa asiakkaan saatavilla vaan se voi keskittyä moneen 

eri kanavaan. Tämä voi pahimmillaan tarkoittaa sitä, että asiakkaat eivät saa tarvittavaa 

tietoa ajallaan tai tieto on vaikeasti saavutettavissa. Tällaiset puutteet voivat taas aiheut-

taa asiakastyytyväisyyden huonontumista.  

 

Asiakastiedottamisen toteuttaminen osittain automaationa voi vaikuttaa huomattavasti 

sekä ajan säästämiseen, että asiakastyytyväisyyteen. Asiakastyytyväisyyden osalta asia-

kastiedottamisen automaatio saattaisi tuoda jopa kilpailuetua, sillä se saattaisi erottaa 

yrityksen positiivisesti muista toimijoista. Tätä ajatusta puoltaa Kanovska (2009) maini-

tessaan artikkelissaan hyvän asiakaspalvelun laadun mahdollistavan erottumisen kilpai-

lijoista ja sitä kautta mahdollistavan kilpailuedun saamisen. Reaaliaikaisen ja toimivan 

asiakastiedottamisen ja asiakaspalvelun puolesta puhuu myös McGinnis (2019) maini-

tessaan nopeuden ja reaaliaikaisuuden olevan asiakaspalvelussa ja asiakastiedottami-

sessa yhä tärkeämpää. Tämä johtuu siitä, että asiakkaat odottavat koko ajan parempaa 

asiakaspalvelua ja vaativat asiakaspalvelulta joustavuutta ja nopeutta enemmän kuin 

koskaan. Tämän trendin myötä myös asiakaspalveluun panostetaan yleisesti enemmän 

kuin ennen, ja se aiheuttaa kaikille yrityksille tarvetta pysyä kilpailukykyisenä asiakaspal-

velun osalta. On siis selvää, että asiakastiedottamisen automaatiolla voidaan parhaassa 

tapauksessa saavuttaa merkittävää kilpailuetua. On kuitenkin tiedostettava asiakkaiden 

tarpeet ja mahdollistettava myös ihmisen kanssa kommunikointi asiakaspalvelussa. Tä-

män tutkimuksen tarkoituksena ei ole automatisoida kaikkea ja sulkea pois ihmisen to-

teuttamaa tiedottamista, vaan kehittää asiakastiedottamisen automaatiolle alusta, jonka 

avulla tiedottaminen voidaan automatisoida ja siten saada kilpailuetua ja säästää aikaa. 

Lisäksi alusta mahdollistaa rakennusurakan tietojen keskittämisen yhteen paikkaan, 

jossa ne ovat asiakkaalle nopeasti saatavilla. 

 



51 

 
 
 

 

5.2 Tavoitteiden määrittäminen 

Kehitettävään artefaktille eli asiakastiedottamisen automaation alustalle luodaan edelli-

sen luvun ongelmien pohjalta tavoitteet, jotka täytetään artefaktin suunnittelu- ja kehi-

tysvaiheessa. Keskeisimpiä ongelmia edellisessä luvussa havaittiin kaksi. Niitä ovat asia-

kastiedottamiseen kuluva aika sekä riittämätön tiedottaminen ja sen aiheuttama asia-

kastyytyväisyyden huonontuminen. Tavoitteet tässä tutkimuksessa ovat laadullisia.  

 

Tavoite asiakastiedottamisen resurssiongelman eli ajan kulumisen ratkaisemiseksi sisäl-

tää laadullisen tavoitteen. Tavoitteena on vähentää asiakastiedottamisesta ihmisen te-

kemää työmäärä puoleen siitä, mitä se on tyypillisesti manuaalisesti toteutettuna. Tar-

kemmin ottaen tämän toteutuminen tarkoittaisi sitä, että kehitettävä alusta eli artefakti 

kattaisi suurimman osan asiakastiedottamisesta. Tavoitteen toteutuminen eli ajan säästö 

voidaan todeta, mikäli suurin osa yleisesti manuaalisesti tiedotettavista asioista voidaan 

toteuttaa automaation avulla artefaktin ollessa käytössä. 

 

Asiakastyytyväisyyden osalta tavoitteet ovat myös laadullisia ja perustuvat pitkälti kehi-

tettävän alustan, eli artefaktin saavutettavuuteen sekä tiedon välittämisen nopeuteen. 

Tavoitteita ovat seuraavat: 

1. Artefaktin avulla asiakastiedottaminen on reaaliaikaisempaa aikataulujen ja työ-

vaiheiden osalta kuin mitä se olisi manuaalisesti tehtynä. 

2. Artefaktin avulla asiakkaalla on selkeämmin saatavilla tiedot rakennusurakkaan 

liittyen. 

 

Ensimmäisen laadullisen tavoitteen tarkoitus on ratkaista asiakkaiden reaaliaikaisen tie-

dottamisen tarve. Tavoitetta on rajattu aikatauluista sekä työvaiheista tiedottamiseen, 

sillä nämä asiat ovat helpoimmin automatisoitavissa niiden selkeän ja toistuvan sisällön 

vuoksi. Lisäksi nämä tiedot löytyvät yrityksen toiminnanohjausjärjestelmästä yksinker-

taisemmin kuin muut tiedotettavat asiat. Muiden tiedotettavien asioiden sisällyttäminen 

tavoitteeseen ja sitä kautta artefaktiin saattaisi vaikuttaa negatiivisesti liiketoimintaan 



52 

 
 
 

myös siksi, että asiakkaat haluavat edelleen tulla palvelluksi myös ihmisten toimesta 

(McGinnis, 2019). Automaation tarkoituksena on vain vähentää ihmisen tekemää työtä 

ja vapauttaa ihminen vaativampiin tehtäviin. 

 

Toisen laadullisen tavoitteen tarkoituksena on tarjota asiakkaalle tieto mahdollisimman 

selkeästi yhdessä paikassa. Ongelmana puhelimitse ja viesteillä tiedottamisessa on 

yleensä se, että tieto ei jää asiakkaalle yhteen paikkaan eli tieto on vaikeasti saavutetta-

vissa. Tämän ratkaisemiseksi tavoitteena on, että artefakti mahdollistaa kaiken raken-

nusurakkaan liittyvän tiedon keskittämisen yhteen alustaan, jossa tieto on aina helposti 

asiakkaan saatavilla. 

 

 

5.3 Suunnittelu ja kehitys 

Tämä luku keskittyy tutkimuksen lopputuloksen eli artefaktin suunnitteluun ja kehittä-

miseen. Artefaktilla tarkoitetaan innovaatiota, joka voi olla esimerkiksi rakenne, malli, 

menetelmä tai ilmentymä (Hevner ja muut, 2004, s. 76; Peffers ja muut, 2007). Tässä 

tutkimuksessa artefakti on asiakastiedottamisen alusta. Koska alusta esitetään proto-

tyyppinä, voidaan artefaktia kutsua ilmentymäksi (Hevner ja muut, 2004, s. 76). Artefak-

tin suunnittelussa ja kehittämisessä hyödynnetään asiantuntijahaastatteluja, tutkielman 

teorialuvuissa käsiteltyjä teorioita sekä tutkijan omaa kokemusta, luovuutta ja ongel-

manratkaisutaitoa. Tämän luvun sisältö koostuu kahdesta alaluvusta, joita ovat artefaktin 

suunnittelu ja kehittäminen. Suunnittelussa käsitellään alustassa jaettavaa tietoa ja sen 

käsittelyä sekä alustavaihtoehtoja. Kehittämisessä pääpaino on prototyypin kehittämi-

sessä. 

 

5.3.1 Artefaktin suunnittelu  

Asiakkaalle tiedotettavia asioita voivat olla yrityksen toimialasta ja liiketoiminnasta riip-

puen monenlaisia. Rakennusalalla tiedotettavat asiat ovat kuitenkin usein samantyyppi-

siä, kun kyse on rakennusurakoista. Jotta tässä tutkimuksessa keskityttäisiin olennaisten 



53 

 
 
 

tietojen jakamiseen, on tunnistettava mitä tietoja tyypillinen rakennusalan yritys asiak-

kailleen jakaa, ja mitä asiakkaat haluavat urakoista yleensä tietää. Seuraavissa neljässä 

kappaleissa on kahden haastattelun perusteella määritetty tarkemmin, mitä asiakastie-

dottamisen eri vaiheiden kohdalla tulisi tiedottaa. Asiakastiedottamisen vaiheet perus-

tuvat kuvaan 9. 

 

Ensimmäisessä vaiheessa eli myyntivaiheessa tulisi asiantuntijahaastattelujen perus-

teella tiedottaa asiakkaalle, milloin myyntitilanteessa määritettyä urakan alustavaa aloi-

tusaikaa tullaan tarkentamaan ja kuka urakan työnjohtajana eli tiedottajana jatkossa toi-

mii. Tämä on asiantuntijoiden mukaan tärkeä asia tiedottaa, sillä asiakkaat ovat herkästi 

yhteydessä suoraan myyjään, mikäli tarkkaa tietoa tiedottamisen jatkajasta ei ole. Asian-

tuntijat korostavat näiden lisäksi, että asiakasta olisi hyvä tiedottaa heti myyntivaiheessa, 

mikäli asiakkaalle kuuluu jokin velvollisuus urakan mahdollistamiseksi. Esimerkkinä voi 

toimia kalusteiden siirtäminen remontin tieltä tai jotain muuta vastaavaa. 

 

Toisessa vaiheessa, eli lähempänä urakan alkamista ja urakan alkaessa tiedottaminen 

painottuu suurimmaksi osaksi aikataulujen tarkentamiseen. Asiantuntijahaastattelun 

mukaan noin kaksi viikkoa ennen urakan alkamista asiakkaalle tulee tiedottaa tarkemmin 

urakan arvioidusta aikataulusta, eli aloitusajankohta muutamien päivien tarkkuudella. 

Tätä tietoa taas tulisi tarkentaa edelleen viimeistään muutamaa vuorokautta ennen ura-

kan alkamista. Asiantuntijoiden mukaan noin vuorokautta ennen urakan alkamista tie-

dottaminen siirtyy usein myös rakennusurakalla toimivien työntekijöiden vastuulle. 

Tämä tarkoittaa sitä, että työnjohtajan lisäksi tiedottamista voi hoitaa siitä lähtien myös 

työntekijä. Usein työntekijä ilmoittaa urakan aloittamista edellisenä päivänä tarkan kel-

lonajan, jolloin urakka aloitetaan seuraavana päivänä. 

 

Kolmannessa vaiheessa eli urakan ollessa käynnissä tiedotettavia asioita kertyy huomat-

tavasti enemmän kuin aiemmissa vaiheissa. Asiantuntijat huomauttavat haastatteluissa, 

että kaikki asiakkaat eivät vaadi tässä vaiheessa paljoa tietoa, mutta tiedottaminen on 



54 

 
 
 

silti suoritettava säntillisesti ja tiheään, sillä lähtökohtaisesti asiakkaat haluavat pysyä hy-

vin tarkkaan ajan tasalla urakan etenemisestä. Urakan aikana päivittäin tulisi asiantunti-

joiden mukaan tiedottaa siitä, mikä on urakan tilanne, eli mitä työvaiheita on suoritettu, 

mitä työvaiheita on jäljellä ja milloin työtä jatketaan. Näiden tietojen lisäksi molemmat 

asiantuntijat korostavat, että asiakkaalle olisi suotavaa jakaa kuvasisältöä merkittävien 

työvaiheiden väliltä. Suoritetuista työvaiheista tiedottaminen on asiantuntijoiden koke-

musten mukaan erityisen tärkeää, sillä asiakkaalla ei välttämättä ole mahdollista havaita, 

missä vaiheessa urakka on. Asiantuntijoiden mukaan tämä voi johtua esimerkiksi siitä, 

että urakka voi kohdistua kohteessa sellaiseen osaan, jota asiakkaan on vaikea nähdä tai 

urakka voi kohdistua kohteeseen, jossa asiakas ei käy urakan aikana. Haastatteluissa asi-

antuntijat perustelevat tarkan tiedottamisen tärkeyttä myös sillä, että urakka liittyy usein 

asiakkaan omaisuuteen, josta asiakas on hyvin tarkka, joten asiakas on halukas tietä-

mään menetelmistä ja työn etenemisestä tarkkaan. 

 

Neljännessä vaiheessa eli urakan lopussa ja urakan suorittamisen jälkeen tiedottaminen 

vähenee huomattavasti. Asiantuntijoiden näkemys on, että asiakkaalle tulisi tiedottaa 

mahdollisimman aikaisin urakan valmistumisen aikataulu ja sopia lopputarkastuksen 

ajankohta ennakkoon. Asiantuntijat korostavat lisäksi, että lopputarkastuksen yhtey-

dessä asiakkaalle luovutettava lopputarkastuspöytäkirja sisältää tietoja, joita asiakkaan 

on hyvä tietää urakan valmistumisen jälkeen, joten tiedotettavaa on siitä syystä vähem-

män tässä vaiheessa. 

 

Stevens (2017) korostaa artikkelissaan, että suurin osa asiakkaalle jaettavasta tiedosta 

löytyy yrityksen nykyaikaisesta pilvipohjaisesta toiminnanohjausjärjestelmästä. Haastat-

telujen perusteella rakennusalalla asiakastiedottaminen sisältää pääasiassa aikatauluista 

sekä työn etenemisestä tiedottamista. Asiantuntijahaastattelujen mukaan tämä asiak-

kaille jaettava tieto on pääsääntöisesti yksinkertaista ja yleensä saatavilla joko teksti- tai 

kuvamuodossa yrityksen toiminnanohjausjärjestelmästä. Tämän vuoksi urakan aikana 

tiedottaminen tarkoittaa usein toiminnanohjausjärjestelmästä tiedon etsimistä ja sen ja-

kamista asiakkaalle. Koska aikataulut ovat merkittynä toiminnanohjausjärjestelmässä 



55 

 
 
 

päivämäärinä ja työvaiheet ovat yleensä etukäteen määrättyjä ja tiettyjen mallien mu-

kaisia, on niiden jakaminen automaation avulla mahdollista. Kuitenkin automaation 

mahdollistamiseksi tiedon on oltava saatavilla tietojärjestelmästä sellaisessa muodossa, 

että sitä voidaan käsitellä ja edelleen jakaa asiakkaalle. Aikatauluihin liittyvän tieto löytyy 

poikkeuksetta toiminnanohjausjärjestelmästä muodossa, jossa sitä voidaan käsitellä, 

mutta työvaiheet eivät välttämättä ole kaikilla yrityksillä missään järjestelmässä ylhäällä. 

Mikäli työvaiheet eivät ole saatavilla toiminnanohjausjärjestelmässä, ne voidaan tallen-

taa toiminnanohjausjärjestelmään esimerkiksi työntekijöiden tuntikirjausten yhteydessä. 

Tämä onnistuisi yksinkertaisesti esimerkiksi siten, että urakkaa suorittava työntekijä kir-

jaisi tuntikirjausten yhteydessä, mitä työvaiheita urakasta on suoritettu. Aikataulujen ja 

työvaiheiden lisäksi on muistettava, että kuvien jakaminen työvaiheista tulee ottaa huo-

mioon. Kuvat on mahdollista tallentaa toiminnanohjausjärjestelmään, joten niiden jaka-

minen muiden tietojen kanssa on myös mahdollista. 

 

Vaikka voidaan todeta, että asiakkaille jaettava tieto on saatavilla toiminnanohjausjärjes-

telmästä ja siten mahdollista jakaa automaation avulla, on hyvä tunnistaa, mitkä näistä 

tiedoista soveltuvat ohjelmistorobotiikan käsittelyyn. Madakamin ja muiden (2019) mu-

kaan ohjelmistorobotiikka kykenee käsittelemään tietoa, joka on teksti-, kuva-, ääni- tai 

videomuodossa. Koska aiemmassa kappaleessa mainitut asiakkaille jaettavat tiedot ovat 

yleensä joko teksti- tai kuvamuodossa, on niiden käsittely mahdollista ohjelmistorobotii-

kan avulla. Tiedon käsittelyn lisäksi on huomioitava tiedon siirtäminen. Kun ohjelmisto-

robotiikka kykenee käsittelemään tietoa, kykenee se myös siirtämään tietoa. Tiedon siir-

tämistä voi tapahtua esimerkiksi eri järjestelmien välillä. 

 

Kun asiakastiedottaminen on todettu mahdolliseksi toteuttaa ohjelmistorobotiikan 

avulla, on määritettävä, millä alustalla asiakkaille tiedotetaan asiat. Alustan valinnassa 

hyödynnetään haastatteluista saatua tietoa käytännön kokemuksista. Käytännön koke-

musten perusteella alustoista voidaan sulkea pois sellaiset vaihtoehdot, jotka on koettu 

jostain syystä huonoiksi. Haastattelujen on tarkoitus toimia alustavaihtoehtojen arvioin-



56 

 
 
 

tina ja helpottaa parhaan mahdollisen alustan valintaa. Alustan valinnassa on ensisijai-

sesti tärkeintä huomioida se, onko ohjelmistorobotiikalla mahdollista jakaa tiedot alus-

talla. Toiseksi on huomioitava alustan saavutettavuus yleisellä tasolla. Tällä tarkoitetaan 

sitä, että alustan täytyy olla sellainen, jonka käytön asiakkaat hallitsevat tai todennäköi-

sesti oppivat hallitsemaan. 

 

Haastatteluissa asiantuntijoilta kysyttiin, mikä tai mitkä seuraavista alustoista sopisi hei-

dän mielestään parhaiten asiakastiedottamiseen: 

 Tekstiviesti 

 Sähköposti 

 WhatsApp 

 Toiminnanohjausjärjestelmä 

 Verkkosivu 

 Jokin muu (esimerkiksi yhdistelmä alustoja) 

 

Esimerkkialustoiksi valikoitui haastattelujen ja tutkijan kokemusten perusteella parhaat 

vaihtoehdot. Haastateltavien tarkoitus oli valita vaihtoehdoista sellainen, joka heidän ko-

kemustensa mukaan olisi parhaiten asiakkaan saatavilla eli sellainen, jonka kautta tieto 

kulkisi tehokkaimmin. Haastatteluissa asiantuntijat olivat sitä mieltä, että WhatsApp on 

ollut toimivin alusta tiedottamiseen tähän asti. WhatsApp on kuitenkin saavutettavuu-

deltaan vajavainen, sillä kaikki asiakkaat eivät käytä sitä, joten sen hyödyntäminen alus-

tana ei toimisi tehokkaasti. Mikäli WhatsApp alustavaihtoehtona unohdetaan, asiantun-

tijat ovat sitä mieltä, että tekstiviestit ovat toimineet WhatsAppin tavoin tehokkaasti, jo-

ten tekstiviestit voisi olla toimiva alusta WhatsAppin sijaan. Tekstiviestit ovat tehokkaita 

viestinnässä, sillä lähtökohtaisesti kaikilla aikuisilla ihmisillä on käytössä matkapuhelin, 

joihin on mahdollista vastaanottaa tekstiviestejä. Samanlaista saavutettavuutta ei voida 

todeta muilla alustoilla. Asiantuntijoilla on tästä kokemusta, sillä he mainitsivat haastat-

telussa tekstiviestien saavuttavan lähtökohtaisesti aina asiakkaan hyvin nopeasti, kun 

kyse on ollut tiedottamisesta. Toinen asiantuntijoista nosti esille vielä esimerkin sähkö-



57 

 
 
 

postien saavutettavuuden ongelmasta. Asiantuntijan mukaan ihmisillä on edelleen ta-

pana lukea sähköposteja pelkästään tietokoneella. Tämä aiheuttaa sen, että tieto ei 

mene nopeasti perille eikä tiedottaminen siten ole tehokasta. Haastattelun edetessä asi-

antuntijat kokivat tekstiviestien lisäksi verkkosivuston tai toiminnanohjausjärjestelmän 

tehokkaana alustana tiedottamisessa. Asiantuntijoiden kokemusten mukaan toiminnan-

ohjausjärjestelmä tiedottamisen alustana saattaisi tuottaa saavutettavuusongelmia siinä 

vaiheessa, kun asiakkaan täytyy kirjautua palveluun. Kirjautuminen edellyttää aina tun-

nuksia ja haastateltavien mukaan tunnusten muistaminen saattaisi olla asiakkaille haas-

tavaa. Asiantuntijoiden mielestään olisi tehokkainta, että asiakkaan ei pitäisi kirjautua 

erikseen