1 
 

 

VAASAN YLIOPISTO 

TEKNIIKAN JA INNOVAATIOJOHTAMISEN YKSIKKÖ 

TUOTANTOTALOUS 

 

 

 

 

 

 

 

Roope Kanerva 

IT:N ROOLI YRITYSTEN TOIMITUSKETJUSSA: HANKINNAN 

AUTOMATISAATIOSTA LASKUJENKÄSITTELYN 

AUTOMATISAATIOON: 

Case Yritys X ja Yritys Y. 

 

 

 

                                                                                                                           

Tuotantotalouden 

pro gradu -tutkielma 

 

 

                                                                                      Tuotantotalouden                                                                                                                                 

maisterikoulutusohjelma 

 

 

VAASA 2020 



2 
 

 

 



1 
 



1 
 

SISÄLLYSLUETTELO 

 

TIIVISTELMÄ ............................................................................................................................ 6 

ABSTRACT ................................................................................................................................. 7 

1. Johdanto ............................................................................................................................... 8 

1.1. Tutkimuksen tausta 9 

1.2. Tutkielman tavoite 10 

1.3. Tutkimusote 11 

1.4. Tutkimuksen pääpiirteet ja rakenne. 13 

2. Toimitusketjujen rakenne. ............................................................................................... 15 

2.1. Sähköinen toimitusketju 17 

2.2. Erilaiset hankintakanavat 18 

2.3. Tilausmuodot 20 

2.4. IT:n hyödyntäminen toimitusketjussa 20 

2.4.1. Tilauksen muodostuminen 22 

2.4.2. Hankintajärjestelmät (Saas) 22 

2.4.3. Automatisaatio 23 

2.4.4. ERP – Toiminnanohjausjärjestelmä 25 

2.5. Hankintajärjestelmän käyttöönottoprosessi 26 

2.5.1. Projektin skaala 27 

2.5.2. Projekti workshop 29 

2.5.3. Ohjelmiston konfigurointi ja rakentaminen 30 

3. Tutkimuksen metodologia ................................................................................................ 33 

3.1. Menetelmät aineiston keruuseen. 33 

3.2. Tutkimuksen strategia 34 

3.3. Haastattelut ja projektimäärittelyt 35 

3.4. Aineiston analysointi 36 

3.5. Tutkimuksen luotettavuus 36 

4. Hankintajärjestelmäprosessin määrittäminen ............................................................... 39 

4.1. Projektimäärittelyjen aloittaminen 39 

4.2. Hankinnan automatisointi Yritys X 43 

4.2.1. Hankinnan prosessin rakentuminen Yritys X 45 

4.2.2. Käänteisen hankinnan prosessin määrittäminen 48 

4.3. Kenttätietojen automatiikka Yritys X 51 

4.4. Yritys X:n laskujenhallinan prosessin rakentaminen 53 



2 
 

4.5. Automaattinen täsmäytys 53 

4.6. Maksusuunnitelman täsmäytys 56 

4.7. Viitehenkilön etsiminen 57 

4.8. Automaattinen laskujen siirto kirjanpitoon 58 

4.9. Hankinnan automatisointi Yritys Y 59 

4.9.1. Hankinnan prosessin rakentuminen Yritys Y 61 

4.10. Kenttätietojen automatiikka Yritys Y 64 

4.11. Yritys Y:n laskujenhallinnan prosessin rakentaminen 66 

4.11.1. Automaattinen täsmäytys 66 

4.11.2. Maksusuunnitelman täsmäytys 69 

4.11.3. Viitehenkilön etsiminen 71 

5. Johtopäätökset ja kehitysehdotukset ............................................................................... 73 

5.1. Tutkimuksen tavoitteiden läpikäynti 73 

5.2. Tutkimuskysymyksiin vastaaminen 76 

5.3. Johtopäätökset ja kehitysideat tulevaisuudessa 80 

5.4. Yhteenveto Error! Bookmark not defined. 

Lähteet ........................................................................................................................................ 85 

 

 

 

 

 

 

 

 

 

 



3 
 

 

LYHENNE - JA TERMILUETTELO 

 

XML Ohjelmointikieli (Extensible Markup Language) ja sillä määritellään                    

rakenteellisia merkkauskieliä. 

ERP Toiminnanohjausjärjestelmä (Enterprise Resource Planning) yritysten 

käyttöön. 

IT / ICT Informaatioteknologia (Automaattinen tietojenkäsittely). Tietojen erilaista 

muokkaamista tietokoneiden ja digitaalisen tietoliikenteen avulla. 

SQL IBM:n kehittämä kyselykieli (Structured Query Language), jonka avulla 

voidaan esimerkiksi relaatiotietokantaan tehdä hakuja, kyselyitä, muutoksia 

ja lisäyksiä. 

Saas (Sofware as a Service) eli yritys hankkii ohjelmiston palveluna eikä 

esimerkiksi lisenssipohjaista ohjelmiston asennusta tehdä. Ei tehdä 

yksittäisten asiakkaiden tuotantoympäristöjä. 

P2P (Peer-to-Peer) verkostot. Näissä verkoissa ei ole kiinteitä palvelimia vaan 

jokainen yksittäinen tietokone toimii palvelimena niin kauan kun sovellus on 

käytössä. 

OCI (Open Catalogue Interface) on avoin ja standardisoitu rajapinta, jonka on 

kehittänyt SAP. Rajapinnassa voidaan lähettää tietoa standardisoiduissa 

kentissä kahden ohjelmiston välillä. Esimerkiksi hankintajärjestelmä ja 

verkkokauppa. 

 

 

 

 



4 
 

 

KUVALUETTELO 

Kuva 1. Laadullisen tutkimusmenetelmän prosessi. (Gorman, Clayton, Shep & Clayton2005) 12 

Kuva 2. Tutkielman rakenne 14 

Kuva 3. Toimitusketjun rakenne (Logistiikan Maailma) 15 

Kuva 4. Kiertotalouden toimitusketjumalli (Euroopan parlamentti 2015) 16 

Kuva 5. Kahdentuva materiaalivirta 19 

Kuva 6. IT:n hyödyntäminen toimitusketjun eri osissa 21 

Kuva 7.  Automaation testauksen tasot (Rauf & Reddy 2015) 24 

Kuva 8. Toiminnanohjausjärjestelmän osa-alueet 26 

Kuva 9. Esimerkki projektiaikataulusta taulukkomuodossa 29 

Kuva 10. Esimerkki hankintaehdotuksen prosessista 32 

Kuva 11. Yritys X:n organisaatio hierarkia 40 

Kuva 12. Yritys Y:n organisaatio hierarkia 41 

Kuva 13. Esimerkki kentistä 42 

Kuva 14. Yritys X:n hankintaprosessin kuvaus 43 

Kuva 15.  OCI – sanomien palautuminen ulkoisesta verkkokaupasta 45 

Kuva 16. Käänteinen tilausprosessi 49 

Kuva 17. Yritys X:n otsikkotason tiedot laskujenhallinnassa. 51 

Kuva 18. Ostotilausnumero - kenttä automaattisessa täsmäytyksessä 55 

Kuva 19. Maksusuunnitelman viite - kenttä maksusuunnitelman täsmäytyksessä 57 

Kuva 20. Viitehenkilön etsiminen 57 

Kuva 21.  Yritys Y:n hankintaprosessin kuvaus 60 

Kuva 22. Yritys Y:n otsikkotason tiedot laskujenhallinnassa. 64 

Kuva 23. Yritys Y:n ostotilausnumero - kenttä automaattisessa täsmäytyksessä. 68 

Kuva 24.  Maksusuunnitelman viite - kenttä maksusuunnitelman täsmäytyksessä 71 

Kuva 25.  Esimerkki hankintaehdotuksen tiliönnin kenttäpopuloitumisesta 75 

Kuva 26.  Esimerkki validointisäännön taulusta, josta koodi hakee tiedon 76 

Kuva 27.  Analytiikasta saatu raportti täsmäytyksestä (Yritys X). 78 

Kuva 28.  Analytiikasta saatu raportti täsmäytyksestä (Yritys Y). 78 

 

TAULUKKOLUETTELO 

Taulukko 1.  Esimerkki laajennetusta käyttöoikeudesta 47 

Taulukko 2. Täsmäytyskategoriat 55 

Taulukko 3. Esimerkki laajennetuista käyttöoikeuksista. 63 

Taulukko 4. Yritys Y:n täsmäytyksen kategoriat 69 

Taulukko 5. Esimerkki ylläpitotaulusta, jolla viitehenkilö on linkitetty aliakseen. 72 

 

 



5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



6 
 

______________________________________________________________________ 

VAASAN YLIOPISTO 
Teknillinen tiedekunta 

Tekijä:    Roope Kanerva 

Tutkielman nimi:   IT:n Rooli Yritysten Toimitusketjussa: Hankinnan              

automatisaatiosta Laskujenkäsittelyn automatisaatioon – Case 

Yritys X ja Yritys Y 

Tutkinto:    Kauppatieteiden maisteri 

Oppiaine:   Industrial Management 

Työn ohjaaja:  Ari Sivula, Jussi Kantola & Ville Tuomi 

Aloitusvuosi:  2014 

Valmistumisvuosi:  2020               Sivumäärä: 91 
______________________________________________________________________ 

TIIVISTELMÄ 

Hankintajärjestelmät ovat yleistyneet yritysten keskuudessa ja IT-alan yritysten tarjoamista 

järjestelmistä käydään mittavaa kilpailua markkinoilla. Nykyään hankintajärjestelmien halutaan 

sisältävän sekä hankinnan että laskujen käsittelyn ominaisuudet, jotta kaikki toiminnot 

tapahtuisivat yhdessä järjestelmässä. Tämän tutkimuksen tarkoituksena on antaa lukijalle 

ymmärrys hankintajärjestelmien käyttöönotosta ja rakentumisesta projektimuodossa. Kuinka 

automaatiota on mahdollista lisätä koodien avulla, jotta manuaalinen työnteko jäisi 

mahdollisimman vähäiseksi. Prosessin rakentumista seurataan ohjelmiston toteuttajien 

näkökulmasta, jossa toteutus on pyritty luomaan asiakkaiden mieltymyksien mukaan. 

Tutkimuksen teorialuvussa esitetään yrityksen IT - roolin merkitystä ja asemaa toimitusketjussa, 

jossa kuvataan mihin kohtiin toimitusketjuissa IT:llä on vaikutusta. Miten hankintajärjestelmän 

projektit etenevät yleisesti IT - maailmassa ja minkälaisia asioita tulee jokaisessa projektissa ottaa 

huomioon. 

Tutkimuksen empiirisessä luvussa tarkastellaan kahta eri alan yritystä, joiden liikevaihto ja 

henkilöstömäärä on samankaltainen. Molemmat tutkittavat yritykset ottivat käyttöönsä saman 

ohjelmistotalon tuottaman hankinta - ja laskujenkäsittely ohjelmiston. Näiden kahden eri 

yrityksen hankinta - ja laskujenkäsittelyn prosesseja tutkitaan ja kuvataan automaatiolla tehtyjä 

ominaisuuksia, jotka ovat laskeneet yritysten päivittäisiä manuaalisia työtehtäviä. Automaatiolla 

tehdyt koodit on tutkittu ja selitetty auki, kuinka nämä toiminnot toimivat ja miten ne vaikuttavat 

prosesseihin ja yritysten päivittäiseen liiketoimintaan. 

Tutkimuksen lopussa vastataan tutkielman tutkimuskysymyksiin ja kerrataan kuinka tavoitteet 

ovat onnistuneet. Lisäksi tutkimuksen lopussa on kirjattu kehityskohteita, joita voisi harkita 

ohjelmiston sisäänrakennetuksi ominaisuudeksi. Kehityskohteissa on kuvattu myös kuinka ne 

vaikuttaisivat yrityksen päivittäiseen liiketoimintaan. 

______________________________________________________________________ 

AVAINSANAT: Prosessi, hakintajärjestelmä, laskujenkäsittely,Automaatio 

 

 



7 
 

______________________________________________________________________ 

VAASAN YLIOPISTO 
Faculty of Technology 

Author:    Roope Kanerva 

Topic of the Master’s Thesis:  IT:n Rooli Yritysten   Toimitusketjussa:  

Hankinnan automatisaatiosta Laskujenkäsittelyn 

automatisaatioon – Case Yritys X ja Yritys Y 

Degree:    Master of Science in Economics 

Major:   Industrial Management 

Instructor:                        Ari Sivula, Jussi Kantola & Ville Tuomi 

Year of Entering the University:          2014 

Year of Completing Master’s Thesis: 2020                           Number of pages: 91 
______________________________________________________________________ 

ABSTRACT 

Procurement Systems have become more common among different companies and systems that 

ICT companies are offering in the market, are in heavy competition. Nowadays, companies are 

expecting systems to contain both invoice and purchase features, so that all business action would 

happen within one system. The purpose of this research is to give the reader an understanding of 

how these procurement systems are initialized and how they are built in projects. Furthermore, 

automatization can be increased with programming so that manual labor would decrease as much 

as possible. The development of the processes is viewed through the eyes of the designers and the 

execution is done with consideration of the unique needs of the customer.  

The theoretical chapter of this research presents the importance and position of ICT’s role in 

supply chains and describes to which section the ICT has an impact on. Additionally, it explains 

how procurement system projects move ahead in the ICT world and what kind of things needs to 

be considered. 

The empirical chapter is surveying two companies from different industries whose revenue and 

workforce are quite close to each other. Both companies implemented the same procurement 

system from the same ICT company. The empirical section describes and surveys both 

companies’ invoice and purchase processes, which are enhanced with automation that contains 

the programming codes. The codes decreased manual work assignments in both companies. The 

codes that increased the automation in processes and effected the companies daily work, are 

explained and described in the chapter. 

In the end of the research, the research questions and objectives are answered. Moreover, a few 

development ideas that could be executed in the future will be listed and explained. Lastly, 

insights on how they could impact the companies business will be given. 

______________________________________________________________________ 

KEYWORDS: Process, Procurement System, Invoice, Automation 

 



8 
 

 

1. Johdanto 

Teknologia kehittyy päivä päivältä, mikä tuo uusia mahdollisuuksia yritysten 

liiketoiminnan kehittämiselle. Teknologian mukana tuomat mahdollisuudet avaavat 

markkinoiden ovia erilaisille toimijoille. Teknologia  muuttaa toimijoiden ohella 

yritysmaailmaa, mutta vain parempaan suuntaan.  

Toimitusketjut ovat olleet kauan olemassa ja uudempia ja muokattuja toimitusketjuja on 

saapunut ihmisten tietoisuuteen. Uusien toimitusketjujen syntymiseen on  vaikuttanut 

esimerkiksi ilmastonmuutos ja pyrkiminen hidastamaan sitä. Toimitusketjut ovat yleisesti 

perusrakenteeltaan samankaltaisia, mutta esimerkiksi toimijat, yhteistyökumppanit, 

yhteistyökumppanien lukumäärä vaihtelevat melkein aina. Mitä lähemmäs olemme 

tulleet vuotta 2019, sitä enemmän teknologia on murtautunut yritysten toimitusketjuihin. 

Toimitusketjut ja toimitusketjujen johtaminen kuuluvat yritysten yhteen tärkeimmistä 

päivittäisistä toiminnoista ja pitkänajan suunnittelusta (Xu, Cui, Hu, Xu, Zhang, Liang & 

Qu 2019). Toimitusketjut pitävät sisällään koko yrityksen liiketoiminnan. Ilman 

toimitusketjua, yritys tuskin pystyisi ylläpitämään omaa liiketoimintaa normaaliin 

tapaansa. Toimitusketjut kehittyvät koko ajan  ja toimitusketjujen uudistamisesta on tullut 

elintärkeää varsinkin B2B liiketoiminnassa (Wong & Ngai 2019). Toimitusketjut ovat 

alkaneet ottaa käyttöönsä enemmän markkinoilla olevaa teknologiaa. Tarkemmin 

sanottuna, yritykset, jotka ovat osana toimitusketjua, ovat nähneet potentiaalia 

teknologiassa ja sen tuomissa mahdollisuuksissa, tämän vuoksi sitä on alettu käyttämään 

yhä enemmissä määrin. 

IT - alojen yritykset kehittävät tuotteitaan jatkuvasti ja samaan aikaan toimitusketjut 

muuttavat muotoaan kohti sähköisempää toimitusketjua. Tilaukset tehdään erilaisilla 

hankintajärjestelmillä, jossa data ja informaatio kulkevat läpi toimitusketjun ja 

arkistoituvat yrityksille säilöön. Yritykset kilpailuttavat toiminnanohjaus - ja 

hankintajärjestelmiä ja pyrkivät valitsemaan heille sopivat järjestelmät, jotka edistäisivät 

heidän liiketoimintaansa.   



9 
 

Toiminnanohjausjärjestelmät ja erilaiset hankintajärjestelmät nopeuttavat ja tehostavat 

yritysten liiketoimintaa, mutta viime vuosina ohjelmistojen automatisaation kehitys on 

ollut valtavaa. Tutkimuskysymykset tässä tutkielmassa ovat: 

• Miten yritys hyötyy automatisaatiosta hankintajärjestelmissä? 

• Millä tavalla automaatio vaikuttaa yrityksen toimintaan toimitusketjussa?  

1.1. Tutkimuksen tausta 

Tämän tutkimuksen taustana on esittää teoriaosiossa IT:n roolia yrityksen 

toimitusketjussa ja tutkia IT-alan yrityksen tietyn ohjelmiston vaikutusta case-yritysten 

hankintaan ja laskujenkäsittelyyn. IT:llä on merkittävä rooli tämän päivän yritysten 

toimitusketjuissa. IT - sanana ei kuvaa tarkasti mitä sillä tarkoitetaan, joten pureudutaan 

syvemmin. Kun puhutaan IT:n roolista toimitusketjussa, tarkoitetaan tällä esimerkiksi 

sähköisten sanomien välitystä asiakkaalta toimittajalle. Sähköisten sanomien 

edellytyksenä (esimerkiksi tilaussanomat, vahvistusviestit, laskujen sisäänluku) on, että 

sanomien koodit käyttävät standardeja kuljetussanomia, kuten UBL 2.0 tai UBL 2.1 

(Logistiikanmaailma 2017). IT roolina kuvaa myös, millaisia ohjelmia yritykset käyttävät 

toimitusketjuissaan ja millaisiin tehtäviin näitä ohjelmia käytetään. Yritykset, jotka 

omaavat toimitusketjuissaan ohjelmistoja, tulee tyydyttää sekä toimittajat että 

loppukäyttäjät viimeistellyllä integraatiolla (Hartmann, Keren, Matsinger, Rubin, Trew 

& Yatskar-Haham 2012:2313). 

Ohjelmistojen käyttöönotto tuo mukanaan aina haasteita. Miten ohjelmistot integroidaan 

jo olemassa oleviin järjestelmiin? Ohjelmistointegraatiolla tarkoitetaan tässä, kuinka 

kaksi eriävää ohjelmistoa saadaan toimimaan mahdollisimman tehokkaasti yhdesssä 

(Lee, Siau & Hong 2003:56). Integraation lisäksi, uusien ohjelmistojen käyttöönotossa 

on otettava huomioon konfiguroinnin mahdollisuudet. Kuinka ohjelmistoja saadaan 

muutettua yrityksen käyttötapaa vastaaviksi ja onko se ohjelmistolla mahdollista. 

Ohjelmistojen konfigurointi muun muassa mahdollistaa toimitusketjuissa / 

toimitusketjussa paremman yhteistyökumppanien valinnan. Esimerkiksi tietyillä 

toimittajilla, jotka kuuluvat yrityksen toimittajapiiriin, saattaa olla omat ohjelmistot 



10 
 

valmiina, joiden avulla heillä on mahdollisuus ottaa luotettavampaa ja nopeampaa 

sähköistä tilaussanomaa vastaan (A.Mondragon, C.Mondragon, Hogg & Rodriguez-

Lopez 2018: 69). 

Empiirisessä osiossa tutkielma tutkii laajasti kahden eri aloilla operoivan yrityksen 

hankinnan ja laskujenkäsittelyprosessin eroavaisuuksia sekä porautuu prosessien taakse 

ja vertailee automatisaatioasteen eroja. Molemmat case – yrityksistä ottivat käyttöön 

saman IT – alan yrityksen Saas - hankintaohjelmiston, mutta ohjelmistoa konfiguroitiin 

yrityksille eri tavalla.  

Toinen tutkimuksen yrityksistä omaksui itselleen projektin määrittelyssä 

mahdollisimman suuren automatisaatioasteen ja toinen yritys vaati useamman projekti 

workshopin (projektityöpajan), jossa heille demostroitiin, kuinka vanhoista 

toimintatavoista luopuminen edesauttaisi ja nopeuttaisi heidän prosessiaan hankinnassa 

ja laskujenkäsittelyssä. Molemmissa tutkittavissa yrityksissä tuotteiden saanti eri 

toimittajilta on erityisen tärkeää. Suurelta osin hankinnassa tapahtuvaa ostoa tukevat 

laskujenkäsittelypuolella tapahtuvat maksut ja maksusopimukset toimittajien kanssa. 

Hankinnan automatisointi tai ylipäätänsä hankinnassa tapahtuvat ostot voivat pysähtyä, 

jos rahaliikenne pysähtyy eikä toimittaja saa itselleen osto- ja myyntikanssakäymisestä 

luvattua maksua.  

1.2.  Tutkielman tavoite 

Tutkielman tavoite peilaa edellä kuvattua tutkimuksen taustaa. Tavoitteena on avata 

lukijalle automatisaatiota ja kuinka sitä ollaan hyödynnetty hankinnassa ja 

laskujenkäsittelyssä, kahdessa tutkittavassa yrityksessä; Millä tavalla prosesseja 

lähdettiin rakentamaan, mitä asioita prosessien suunnittelussa tuli ottaa huomioon, kuinka 

prosessien rakentaminen onnistui ja kuinka uusien prosessien myötä automatisaatioaste 

nousi. Prosessit tulevat käsittelemään prosessien integraatiota ja konfigurointia, joita 

avaan teoriaosuudessa ja jota hyödynnetään myöhemmin tutkimuksen osiossa. 

Tutkielma tulee osittain nostamaan puutteita ohjelmistosta, joita molemmat tutkittavat 

yritykset aloittivat käyttämään projektien loputtua ja tuotantoon siirryttyä. Osittain vain 



11 
 

siksi, että tutkielman tavoitteena on antaa kokonaisvaltainen kuva IT:n roolista 

toimitusketjussa ja kuinka näillä IT - alan ohjelmistoilla pystytään nostamaan yrityksen 

toimitusketjujen automatisaatiota. Tämä edesauttaa esimerkiksi yritysten hankintojen 

läpimenoaikojen lyhentymistä ja laskujen saamista maksuun. Laskujen kirjanpitoon 

siirto, analytiikka ja kolmannen osapuolen tarjoama sovellus, joka on integroitu tähän 

kyseiseen ohjelmistoon, jäävät osittain tämän tutkielman ulkopuolelle. Nämä tulevat 

saamaan maininnan tutkielmassa, mutta niihin ei pureuduta sen syvemmin. 

1.3.  Tutkimusote  

Tutkielma tulee keskittymään kahteen tutkimuskysymykseen: Kuinka ohjelmistojen 

tuoma automatisaatio vaikuttaa toimitusketjuihin ja mitä hyötyjä ja haittoja ohjelmistojen 

automatisaatioasteen nostamisesta on. Tutkielmassa on käytetty osittain suunnittelu- ja 

laadullista tutkimusmenetelmää.  

Suunnittelututkimus (Design Research)  tarjoaa tutkijalle mahdollisuutta lähestyä 

tutkittavaa asiaa käytännöllisen ja teoreettisen näkökulmasta (Wolcott, Lobczwoski, 

Lyons & McLaughlin, 2018: 1-2). Suunnittelututkimusmenetelmä tuki tutkielmaa hyvin, 

sillä hankinnan- ja laskujenkiertoprosessi suunniteltiin yhdessä projektiryhmän kanssa. 

Ryhmään kuului sovellusarkkitehti, joka määritti prosessinkuvauksen toisessa 

projekteista sekä sovellus- ja integraatiokonsultit, jotka toteuttivat prosessin ja 

suunnittelivat projektin aikana tapahtuneet muutokset. Kaikki prosessit, koodit ja 

automatisaation hyödyntäminen on suunniteltu projektiryhmän kesken itse. Harto Pönkä 

(2008: 5) määrittelee suunnitelututkimuksen tutkimusstrategiana, jonka tehtävänä on 

pyrkiä kehittämään jo olemassa olevaa teoriaa ja käytäntöä. Tässäkin tutkielmassa 

prosessit ohjelmistossa ovat standardeina tehty ja ne räätälöidään asiakkaan 

mieltymyksien mukaan. 

Suunnittelututkimuksen hyväksyminen tutkimusmenetelmäksi on kulkenut pitkän tien. 

Kuten edellä mainittiin, suunnittelututkimus yhdistää teorian ja käytännön. 

Tutkimusmenetelmän tarkoituksena onkin juuri nostaa tutkimuksen relevanttiutta näiden 

kahden näkökulman kautta (Van den Akker, Gravemeijer, McKenney & Nieveen 

2006:3). Daniel C. Edelson (2009) näkee suunnitelututkimuksen kuvaavan suunnitelua 



12 
 

strategiana, jolla pyritään kehittämään ja jalostamaan teorioita. Suunnittelun kautta 

teorioita voidaan muokata, eikä pelkästään tutkimalla. Tässäkin tutkimuksessa prosessit 

ja koodit suunniteltiin, ja niiden kautta mahdollisuuksia havaittiin ja otettiin käytäntöön. 

Laadullinen tutkimusmenetelmän prosessi muodostuu seitsemästä eri kohdasta (Gorman, 

Clayton, Shep & Clayton 2005:35). 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 1. Laadullisen tutkimusmenetelmän prosessi. (Gorman, Clayton, Shep & 

Clayton2005) 

Ongelma 

Kirjallisuus / materiaalit 

tutkittu 

Hypoteesi muodostettu 

Tutkimuksen suunnittelu 

Datan keräys 

Datan analysointi 

Loppuraportti 



13 
 

 

Tutkimuksen empiirisessä osiossa kuvataan selkeästi projektien prosessien eteneminen. 

Yllä oleva lineaarinen tutkimusprosessi sisältää kohtia, millä tavalla tätä tutkimusta 

lähdettiin myös toteuttamaan. Vaikkakaan kaikkia kohtia ei tässä tutkimuksessa käytetty, 

tutkimuksessa käytettiin myös laadullista tutkimusmenetelmää suunnittelututkimuksen 

ohella. Aineistoa tutkielmaan kerättiin jo olemissa olevista dokumenteista, 

havaintomuistiinpanoilla sekä kyselyillä. Laadullinen ja määrällinen tutkimusmenetelmä 

kulkee osittain yhdessä, kuten myös tässä tutkielmassa. Kyselyillä ja 

havaintomuistiinpanoilla kerätty aineisto kirjoitettiin määrittelydokumenttiin, jossa tuli 

ilmi asiakkaan tarpeet, toiveet ja vaatimukset ohjelmiston konfiguroimiseksi. Nämä 

asiakkaan sanalliset toiveet muutettiin osittain koodin valossa numeroiksi ohjelmiston 

automatisaation toteuttamiseksi. Tällä tarkoitan, että tietyt prosessikuvaukset ja 

prosessien ehdot koodattiin toteuttamaan asiakkaan antamien toiveita prosessista. 

Esimerkiksi sääntöjä ja ehtoja, jolloin tiettyjen toimittajien hankintaehdotukset siirtyvät 

eri prosessiin. Lopulta automatisaatiosta saaduilla numeroilla on pystytty havainnoimaan 

automatisaatioasteen edistymistä. Näitä ovat mm. missä ajassa hankintaehdotuksen 

muodostuminen ostotilaukseksi tapahtuu ja kuinka laskun kiertonopeus näkyy 

läpimenoajassa. Nämä ovat loppupäätelmiä, jotka tullaan esittämään tutkielman lopussa. 

1.4. Tutkimuksen pääpiirteet ja rakenne. 

Kuten tutkimuksen taustoissa ja tavoitteissa kerrottiin, tutkimuksessa pyrittiin löytämään 

käyttännöllisin ja automatisaatioltaan kattavin tapa luoda järjestelmä, joka edesauttaisi 

yrityksen hankinnasta maksuun tapahtuvaa liiketoimintaa.  

Tutkimus rakentuu viidestä pääluvusta. Tutkimus alkaa yhdestä pääluvusta, jonka 

tarkoituksena on avata mikä IT:n rooli yrityksien toimintaketjussa on. Luvuissa kaksi ja 

kolme tullaan käsittelemään empiirisiä tutkimusosioita ja tutkielman metodologiaa. 

Ensimmäisen johdantoluvun tarkoituksena on avata tutkittavaa ongelmaa, tutkimuksen 

taustaa ja tavoitteita. Ennen johdantoa on lisätty määritelmälista, jossa keskeisiä 

lyhenteitä ja sanoja on avattu lukijalle tarkemmin. 



14 
 

 

 

 

 

 

 

 

 

 

Kuva 2. Tutkielman rakenne 

 

Toisessa luvussa käsitellään toimitusketjuja ja minkälainen rooli IT:llä toimitusketjuissa 

on. Kuinka toimitusketjut ylipäätänsä rakentuvat ja mistä eri osastoista toimitusketjut 

muodostuvat. Minkälainen rooli automatiikalla ja IT - alan yritysten ohjelmistoilla 

toimitusketjussa on. 

Kolmannessa luvussa käsitellään tutkimuksen toteutusta ja metodologiaa, kuten kuinka 

aineistoa kerättiin tutkimukseen, tutkimuksen strategiaa, aineiston analysointia ja 

tutkimuksen luotettavuutta. 

Neljännessä luvussa kerrotaan kuinka ohjelmistoja aloitettiin rakentamaan yrityksille, 

kuinka projektit etenivät ja minkälaista ohjelmistoa heille oltiin rakentamassa. Tässä 

luvussa tullaan vertamaan näiden kahden tutkittavan yrityksen prosesseja ja 

konfigurointeja. 

Viidennessä luvussa esitetään tutkimuksen johtopäätökset, jossa vastataan 

tutkimuskysymyksiin ja kuinka hyvin projektien läpivienti onnistui. 

 

Johdanto 

Teoria 

Metodologia 

Empiirinen tutkimus 

Johtopäätelmät 



15 
 

2. Toimitusketjujen rakenne. 

Toimitusketjuilla on useita erilaisia variaatoita, jotka riippuvat yrityksen koosta, alasta ja 

ajattelutavasta. Esimerkiki kiertotaloudessa (Circular Economy) pyritään ajattelemaan 

ympäristöä ja kestävää kehitystä, ja kuinka valmistetuista tuotteista voidaan valmistaa 

niiden eliniän jälkeen uusia tuotteita markkinoille, saastuttamatta ympäristöä. 

Kiertotalouden toimitusketjussa erinäiset yhteistyökumppanit valitaan ajattelutavan 

mukaan (Kirchherr, Reike & Hekkert 2017: 221-232). Toisin sanoen käytetyt 

lopputuotteet päätyisivät toimitusketjussa saman yhteystyökumppanin luokse, jossa 

käytetyistä tuotteista luotaisiin uusia tuotteita hyödyntäen vanhan tuotteen materiaaleja 

(Nasir, Genovese, Acquaye, Koht & Yamoah 2017: 443-457). 

Toimitusketju määritellään yleisesti olevan kokonaisvaltainen ketju eri toimijoiden 

välillä. Esimerkiksi toimittajilta valmistajille, valmistajilta jakelijoille ja jakelijoilta 

jälleenmyyjille (Soliman & Janz 2005 :77). Tämä on yleisin näkemys toimitusketjusta. 

 

 

 

Kuva 3. Toimitusketjun rakenne (Logistiikan Maailma) 

 

Yllä oleva kuva mukailee Tilaustoimitusketjun näkymään ja kuinka ketjussa olevat 

yhteistyökumppanit toimivat ketjussa. Alla oleva kuva esittää kiertotalouden 

toimitusketjua. Nämä kaksi erilaista toimitusketjua eroavat toisistaan esitystavan ja 

ajattelutavan muodossa. Kiertotaloudessa pyritään kierrättämään materiaaleja 

uusiokäyttöön, kun taas vanhemmassa toimitusketjussa uutta tavaraa tilataan toimittajilta, 

jotka eivät välttämättä kierrätä materiaaleja. Voi olla, että toimittajalla, jolta myymälä 



16 
 

tavaransa saa, käyttää muita toimittajia, jotka toimittavat kierrätettyä materiaalia heille, 

mutta myymälä ei välttämättä ole tietoinen tästä asiasta, eikä se ole ollut myymälän tai 

toisten yhteistyökumppanien kriteeri toimittajaa valittaessa. 

 

Kuva 4. Kiertotalouden toimitusketjumalli (Euroopan parlamentti 2015) 

Toimitusketjuista puhuttaessa, keskitytään yleisesti puhumaan toimitusketjujen 

hallinnasta ja johtamisesta. Toimitusketjujen johtaminen (Supply Chain Management) 

ajatellaan johtavan SCO:n (Supply Chain Orientation) luokse, jossa toimitusketjun 

uskotaan olevan omatoiminen kokonaisuus, jonka tarkoituksena on viedä toimitusketju 

kohti parempia lopputuloksia (Signori, Flint & Golicic 2015: 536-564). Toimitusketju on 

mielestäni omatoiminen ja itsenäinen kokonaisuus, joka pystytään vielä erottelemaan 

itsenäisiin osiin. 

 



17 
 

2.1. Sähköinen toimitusketju 

Kaksi erilaista toimitusketjua kuvailtiin edellisessä kappaleessa, jotka havainnollistettiin 

myös kahdella erilaisella toimitusketjun kuvilla. Tiedämme kuinka toimitusketjut 

muodostuvat ja kuinka tuotteet siirtyvät toimitusketjussa seuraavalle. Ei ole salaisuus, 

että teknologia kehittyy ja että se tuo omat uudet mahdollisuutensa toimitusketjuihin.  

Sähköinen hankinta on tuonut omat mahdollisuutensa edistääkseen toimitusketjuja. 

Toimitusketjuissa on kyse hankinnasta, maksusta ja valmistuksesta. Ilman näitä asioita, 

toimitusketjun toimintoa ei voida toteuttaa. On tutkittu että sähköinen hankinta vähentää 

yritysten kustannuksia 8-12% kokonaishankinnasta (Centobelli, Cerhione, Converso & 

Murino 2014:8). Jotta sähköinen hankinta voitaisiin ottaa yritysten toimitusketjuissa 

käyttöön, tulisi yrityksen tehdä muutoksia organisaatioon ja organisaation prosesseihin 

Centobelli, Cerhione, Converso & Murino 2014:9). 

Sähköinen hankinta tarjoaa yritykselle mahdollisuuden toteuttaa toiminnot sähköisesti, 

yleisesti internetissä tai tietyn ohjelmiston avulla, johon voidaan tuoda 

hankintaehdotuksia internetistä, esimerkiksi ulkoisista verkkokauppoista. Tämä 

sähköinen hankinta on luonut myös uuden portaan toimitusketjun loppupäähän. Ennen 

sähköista hankintaa, loppukäyttäjät joutuivat fyysisesti kävelemään ostoksille 

myymälöihin, josta tuote saatiin ostettua. ICT (Information and communication 

technologies) eli tietotekniikka, edistää ja parantaa toimitusketjujen tehokkuutta ja 

vastuullisuutta (Hung, Lin, Tai, Ho & Jou 2013: 3). Nykyään loppukäyttäjät voivat 

hankkia haluamansa tuotteen ostamalla sen internetistä kauppaan kävelemisen sijaan. 

Samoin on tehty tuotteen palautuksen suhteen. 

Sähköinen hankinta tuo tehokkuuden ja vastuullisuuden lisäksi läpinäkyvyyttä ja 

auditointia toimitusketjuihin. Yrityksillä, jotka omaavat sähköisiä hankintajärjestelmiä 

toimitusketjuissaan, on mahdollista tarkkailla rahavirtaa tarkemmin kuin yrityksillä, jotka 

hoitavat hankintansa ja toimituksena ilman sähköisiä järjestelmiä. BT (Business 

Transaction) on P2P (peer-to-peer) verkko-ohjelma, joka pitää kirjaa jokaisesta 

kaupankäynnistä, eli jokaisesta siirrosta, jota yritys lähettää tai yritys saa (Min 2019: 36).  

Miksi toimitusketjuihin olisi tarvetta saada enemmän teknologiaa käyttöön yrityksillä? 

Mietitäänpä tilannetta, jossa yritys lähettää tietyn määrän tuotteita jälleenmyyjälle, ilman 



18 
 

että tarkkaa lukua olisi tiedossa. Yleisesti voimme sanoa että tarkat luvut ovat tiedossa, 

mutta ovatko esimerkiksi tarkat ajankohdat ja tarkat tilausmäärät ajankohtaan verrattuna 

tiedossa. Teknologialla toimitusketjut voivat lisätä informaatiovirran kulkemaan 

tilausvirran kanssa samaa rataa pitkin kohti seuraavaa päämäärää. Kyky seurata tämän 

hetkistä dataa on yrityksille elintärkeä kilpailuasetelmien kannalta ja yrityksen 

liiketoiminnan seurannan kannalta (Basole & Nowak 2018:350). 

2.2. Erilaiset hankintakanavat  

Hankintakanavat antavat ensisijaisesti tärkeän palautteen asiakkaan luottamuksesta 

liiketoiminnassa (Verhoef & Donkers 2005:31). Tämän tulkitaan yleensä koskevan vain 

loppukäyttäjän ja myymälän välistä suhdetta, kuten mistä loppukäyttäjä ostaa vaatteensa: 

Internetistä vai tukeeko hän kenties pientä vaateyrittäjää kotikunnallaan, jossa yrittäjällä 

on kivijalkakauppa. Toimitusketjussa on kyse myös asiakassuhteista. Kaksi eri 

toimittajayritystä ovat toimitusketjussa asiakkaita, jos esimerkiksi valmistajayritys 

käyttää heidän tuotteitaan ja palveluitaan omassa liiketoiminnassaan. Hankintakanavat 

eivät siis pelkästään esiinny B2C (Business to Consumer), vaan myös B2B (Business to 

Business) liiketoiminnassa.  

Yksi merkittävin muutos, jonka sähköinen toimitusketju on tuonut teknologian 

kehittyessä, on ns. kahdentuva materiaalivirta (Dual – channel in supply chain). Tällä 

tarkoitetaan kahta tapaa toimittaa materiaalia ostajalle. Ennen teknologian kehittymistä, 

valmistajat myivät tuotteensa jälleenmyyjille, joilta loppukäyttäjät tai ostajat ostivat 

tuotteita. Nykyään on käytössä toinenkin materiaalivirta. Toisessa materiaalivirrassa 

valmistajat myyvät tuotteensa suoraan loppukäyttäjälle tai ostajalle (Batarfi, Jaber & 

Zanoni 2016:9454). Ostajalla tarkoitetaan tässä yritystä ja loppukäyttäjällä normaalia 

kuluttajaa, joka ei omaa toiminimeä tai toimi ostajana millekkään yritykselle, vaan tekee 

ostoksensa omaan käyttöönsä. 

Sama tuote voidaan myydä kahta materiaalivirtaa pitkin: toinen liikkuu perinteistä 

kanavaa pitkin suoraan jälleenmyyjälle ja toisessa tuote myydään yleisesti verkkokaupan 

kautta suoraan ostajalle tai loppukäyttäjälle (Saha, Sarmah & Modak 2018:148). 

Materiaalivirta, joka kanavoidaan suoraan esimerkiksi verkkokaupan kautta ostajille ja 



19 
 

loppukäyttäjille, antaa valmistajille mahdollisuuden suurempiin voittoihin liiketoiminnan 

kannalta katsottuna (Aslani & Heydari 2019). Esimerkkinä mainittakoon Dell tai Apple. 

Molemmat näistä yrityksistä valmistavat elektroniikkatuotteita ja molempia voidaan 

tilata suoraan heidän omasta verkkokaupastaan tai sitten jälleenmyyjiltä kuten 

esimerkiksi Gigantilta. Tämä on oiva esimerkki kuvaamaan kahta erilaista 

materiaalivirtaa, josta sama tuote on saatavissa. 

 

 

 

  

 

  

 

 

 

 

 

 

Kuva 5. Kahdentuva materiaalivirta 

 

Yllä oleva kaavio näyttää selkeältä, mutta täytyy muistaa, että nuolien välissä saattaa ja 

yleensä on muitakin toimijoita, kuten jakelijoita tai maahantuojia (Tukes 2019), joiden 

tuomat kustannukset on otettava huomioon. 

Hankintakanavia toimitusketjussa on monia, mutta teknologian kehitys on yleistänyt 

suoria materiaalivirtoja toimitusketjuissa. Millä tavalla hankintakanavat eroavat 

Tilausmuodoista? 

Valmistaja 

Jälleenmyyjä Verkkokauppa 

Ostaja / 

Loppukäyttäjä 



20 
 

2.3. Tilausmuodot 

Tilausmuodoilla tarkoitetaan metodia, missä muodossa tilaus tehdään. Yleisesti 

tilausmuoto- sanalla viitataan tapaan ja metodiin, jolla tilaus on tehty 

tietokoneohjelmstossa (Allocca, Hay, Leblang, McQueen & Prudente 2010). 

Tilausmuoto kuvaa kuinka tilaus on tapahtunut. Tilaus voidaan tehdä suullisesti, 

puhelimitse, hankintaohjelmistolla tai sähköpostitse. Tapa, jolla tilaus tehdään, riippuu 

yleisesti yrityksestä, jolle tilaus tehdään. Millaiset käytännöt yrityksellä on rekisteröidä 

tilaus. Suullisesti tehty tilaus on pakko kirjata johonkin, jotta tilattu tuote löytää perille. 

Pienissä yrityksissä tilaukset saatetaan vielä tehdä sähköpostin välityksellä, jossa tehty 

tilaus kirjataan esimerkiksi Exceliin, jossa pidetään kirjaa tilauksista ja tilauksen 

vastaanotoista. Suurissa yrityksissä on yleisesti käytössä hankintajärjestelmät, joissa 

hakinta tehdään ja lähetetään toimittajalle joko sähköpostina tai XML-muotoisena 

tilauksena. Sähköposti on ollut kauan yleisesti käytetty tilausmuoto. XML- muotoinen 

data on laajasti hyväksytty dataformaatti, jossa pystytään toimittamaan tietoa 

järjestelmistä toisiin (El-Sayed, Dimitrova & Rundensteiner 2005:356). 

Jos asiakas lähettää tilauksensa XML-muodossa, tulee toimittajan päässä olla XML 

pohjainen kysely, joka poimii XML-sanomasta tilauksen tiedot. SQL (Structured Query 

Language) on IBM:n kehittämä  kyselykieli, jolla voidaan tehdä erilaisia kyselyitä 

tietokannoissa (IBM Knowledge Center 2019). XML:ään on helppo upottaa SQL:llä 

tehtyjä kyselyitä, joilla esimerkiksi voidaan hakea XML – muotoisesta tilauksesta tiedot 

ja syöttää ne tietokantaan oikeille paikoilleen. 

2.4. IT:n hyödyntäminen toimitusketjussa 

Internet on tuonut paljon uusia mahdollisuuksia jalkautuessaan liiketoimintaan. Sen 

suurin hyöty ollaan nähty toimittajien ja asiakkaiden kommunikoinnin nopeudessa, 

puhumattakaan palvelutasojen noususta tai kuljetuskustannuksien pienentymisistä 

(Lancioni, Smith & Oliva 2000). 

IT (Information Technology) eli tietotekniikka on laaja-alainen käsite. IT:hen luokitellaan 

miltein kaikki tietokoneella tapahtuva työ, kuten ohjelmistojen ja järjestelmien  



21 
 

kehittäminen ja ylläpitäminen. Tähän sisältyy ohjelmistojen käyttämät prosessit ja datan 

käsittely (Market Business News). 

Jos toimitusketju puretaan osiin, voimme tarkastella, missä kohdin toimitusketjua IT - 

alan tuomia teknologisia ratkaisuja voidaan hyödyntää. Alla olevassa kuvassa 

havainnollistetaan yksinkertainen toimitusketju, jossa yksi valmistaja toimittaa tuotteita 

yhdelle toimittajalle, jolta kaksi eri yritystä ostavat tuotteensa. Lopulta loppukäyttäjä 

toimii kuluttajana näiden kahden yrityksen tarjoamille tuotteille. 

 

  

 

 

 

Kuva 6. IT:n hyödyntäminen toimitusketjun eri osissa 

  

Punaiset ympyrät kuvaavat IT:n tuoman teknologian hyödyntämistä toimitusketjussa. 

Minkälaisesta hyödyntämisestä on kyse? Yleisin teknologia, jota toimitusketjussa 

käytetään on tilausjärjestelmät ja laskujenhallintajärjestelmät. Jokainen toimija edellä 

olevassa kuvassa käyttää varmasti IT:n yritysten luomia teknologisia ratkaisuja yrityksen 

Toimittaja

Valmistaja

Yritys

B

Yritys 
A

Loppukäyttäjä 



22 
 

sisällään, mutta tässä keskitytään kuvaamaan teknologisia ratkaisuja toimijoiden välillä. 

Miten ja millä teknologisella ratkaisulla saadaan aikaan toimijoiden välinen 

kanssakäyminen? 

Toimitusketjussa kyse on hankinnasta. Toimitus sanana kuvaa toimittamista ja jotta 

pystytään toimittamaan, on tilauksen oltava tullut jostain. Tilaus muodostuu taas 

hankintapäätöksestä. On oltava tietynlainen tarve jollekin tuotteelle, jotta hankintapäätös 

tehdään ja lopulta hankinnasta muodostuu tilaus. 

2.4.1. Tilauksen muodostuminen 

Tilaus on yleisin kanssakäymisen tapa toimittajan ja ostajan kanssa (Waller, Johnson & 

Davis 2001). Tilauksen prosessi aloitetaan hankintaehdotuksesta. Hankintaehdotusta 

aletaan muodostamaan heti, kun toimittaja on valittu (Monczka, Handfield, Giunipero & 

Patterson 2015). Hankintaehdotuksessa tulee täyttää halutut tiedot. Hankintaehdotukset 

vaihtelevat yleisesti yrityksittäin, hankintajärjestelmittäin tai toimittajittain. 

Hankintaehdotuksen luomisen jälkeen ehdotuksesta muodostuu ostotilaus. 

Ostotilaukseen yleisesti halutaan saada toimittajalta vahvistusviesti, jolloin ostotilauksen 

tila on vahvistettu ja luvattu toimittajan puolelta, että tilaus tullaan toimittamaan ostajalle.  

2.4.2. Hankintajärjestelmät (Saas) 

IT on tuonut mukanaan toimitusketjuihin mahdollisuuden tehdä tilaukset sähköisesti. 

Sähköisesti tapahtuva kaupankäynti eri toimijoiden välillä voi vähentää yrityksillä 

kustannuksia, tarjota laadultaan parempia ja nopeampia palveluita, kohentaa tuotteiden 

myyntiä ja vähentää tehokkuuden puutosta toimitusketjuissa (Pearson & Gardon 2005:2).  

Internet ja mobiilikäytettävyys ovat kasvaneet viime vuosina suuresti, mikä on 

tarkoittanut erilaisten ohjelmistojen käytettävyysasteiden nousua ja kehitystä. Tämä on 

tarkoittanut myös tekoälyn kehittymistä, joka taas on vaikuttanut ohjelmistojen 

kehittymiseen, joka näkyy liiketoiminnassa kustannuksien pienenemisenä ja 

tehokkuuden kasvamisena (Chen, Liu & Li 2019). 



23 
 

Koska kasvu teknologiassa on ollut suurta, ovat monet toimijat toimitusketjuissa 

siirtyneet käyttämään sähköisiä järjestelmiä, sillä ne ovat joustavia ja 

kustannustehokkaita (Mital, Pani & Rameshi 2014:821). Nykyään yritykset ovat 

siirtyneet tai ovat siirtymässä kohti Saas-pohjaisia (Software as a service) sähköisiä 

hankintajärjestelmiä. Millä tavalla Saas-pohjaiset hankintajärjestelmät eroavat 

vanhanaikaisista hankintajärjestelmistä? 

Saas-ohjelmistot ovat pilvipohjaisia palveluita, joita ei asenneta asiakkaiden palvelimille. 

Asiakkaat eivät hallinnoi palvelimia, operaattoreita, tallennustilaa, verkkoa tai 

ohjelmiston konfigurointia (Mital, Pani & Rameshi 2014:821). Nykyään suurin osa 

ohjelmistoista voidaan muokkauttaa eli konfiguroida asiakaslähtöisesti. Ennen 

ohjelmistot myytiin lisenssipohjaisina tuotteina, jotka asennettiin asiakkaan serveihin, 

jossa ohjelmistot pyörivät. Tällä hetkellä Saas-pohjaiset ohjelmistot eivät vaadi 

servereihin asennusta tai pakolla edes ERP-liittymää (Mital, Pani & Rameshi 2014:821). 

Osa Saas-pohjaisista ohjelmistoista ei kuitenkaa tarjoa ERP-

toiminnanohjausjärjestelmää, jolloin yrityksellä on pakollista olla toinen ohjelmisto 

käytössä, josta toiminnanohjausjärjestelmäliittymä löytyy. 

Saas-pohjaiset ohjelmistot vaativat pääsyn Internetiin. Sähköisen 

toiminnanohjausjärjestelmän tarkoituksena on automatisoida mahdollisimman pitkälle 

hankintaprosessi, jossa samanaikaisesti informaatio hankintaehdotuksista ja tilauksista 

säilyisi koko toimitusketjun läpi (Mital, Pani & Rameshi 2014:825). 

2.4.3. Automatisaatio 

Automatisaatio rinnastetaan usein robotteihin, jotka korvaisivat ihmisten tekemät työt. 

Tämä oletus ei ole täysin väärä, mutta automatisaatiolla on tarkoitus pyrkiä helpottamaan 

ja auttamaan ihmisten tekemää työtä. Ohjelmistojen aloilla automatisaation rooli on 

merkittävä (Rauf & Reddy 2015:949). Manuaalista, eli ihmisten tekemää työtä, ei voida 

kuitenkaan korvata täysin automaatiolla. Manuaaliset toiminnot lisäävät yrityksillä 

joustavuutta, mutta tuotettavuus on vähäisempää verrattaessa täysin automaatiolla 

toimiviin järjestelmiin. Jotta tuottavuutta voidaan lisätä, mutta samalla säilyttää 

joustavuus, on tulevaisuudessa järjestelmien omattava myös automaatiota suuremmilla 

tasoilla, joka täydentäisi inhimillisten ”operaattoreiden” eli ihmisten tekemää työtä 



24 
 

(Fletcher, Johnson, Adlon, Larreina, Casla, Parigot, Alfaro & Del Mar Otero 2019). 

Suuremmilla tasoilla tarkoitetaan esimerkiksi toimintoja, jotka eivät vaadi inhimillistä 

toimintoa, mutta toiminto on tarpeeksi laajaa ja jonka automaatiolla voidaan nostaa 

tuottavuutta. Hankintajärjestelmässä esimerkkinä voisi olla automaattisesti ostotilauksen 

muodostaminen, kun hankintaehdotus on tarkastettu. Tarkastuksen jälkeen 

hankintaehdotus muodostuisi ostotilaukseksi, josta ostotilaus lähtisi toimittajalle. 

Kenenkään ei tarvitsisi manuaalisesti käydä valitsemassa toimittajaa ja lähettämässä 

ostotilausta esimerkiksi toimittajan sähköpostiin, vaan tämä voitaisiin toteuttaa 

automaatiolla. Automatisaatiota pystytään hyödyntämään myös ohjelmiston testauksessa. 

 

  

 

  

   

 

 

Kuva 7.  Automaation testauksen tasot (Rauf & Reddy 2015) 

 

Automaation soveltuvuudessa on tarkoitus tarkastatella, tarvitaanko automaatiota 

kyseiseen kohtaan vai ei. Tämä ensimmäinen automaation käyttöönottopäätös on 

kriittiinen, sillä väärä valinta voi aiheuttaa esimerkiksi prosessin epäonnistumisen 

myöhemässä vaiheessa (Rauf & Reddy 2015:950) 

Automaation suunnittelussa tarkoituksena on ratkoa se kuinka automaatiota voidaan tai 

kannattaisi testata ja kuinka se tullaa totetuttamaan (Rauf & Reddy 2015:952). 

Automaation kehittämisessä ja käyttöönotossa on tarkoituksena Raufin ja Reddyn (2015) 

mukaan määritellä koodit ja laskelmat valmiiksi ennen automaation toteuttamista. Tässä 

kohtaa on hyvä kuitenkin tietää, että vaikka automaation ja siinä käytettyjen koodien 

Automaation 

soveltuvuus 

Automaation 

suunnittelu 

Automaation 

kehittäminen 

Automaation 

käyttöönotto 

Automaation 

totuttaminen 

Automaation ylläpito 

ja korjaus 



25 
 

hyödyntäminen epäonnistuisi, on epäonnistuminen yleensä tapahtunut testiympäristössä. 

Automaatiota ei koskaan oteta suoraan käyttöön tuotannossa, vaan koodit testataan 

ensiksi testiympäristössä erilaisilla skenaarioilla. 

Automaation toteuttamisessa ja ylläpidossa erilaiset testiskenaariot testataan rakennetun 

automatisaation avulla. Rauf ja Reddy (2015) esittävät kaksi eri vaihtoehtoa 

automaatiotestaukselle: Ensimmäisenä vaihtoehtona on toteuttaa testiskenaario 

automaatiolla ja lopettaa testi heti, jos rakennettu logiikka automaatiolla epäonnistuu. 

Toinen vaihtoehto on jatkaa automaation testaamista loppuun asti ja koota virhelokeilta 

data ja tutkia, missä kohtaa epäonnistumiset tapahtuvat ja täten tutkia asiaa jälkikäteen. 

 

2.4.4. ERP – Toiminnanohjausjärjestelmä 

ERP-Toiminannohjausjärjestelmä (Enterprise Resource Planning) ovat standardoituja 

ohjelmistopaketteja, jotka voidaan rakentaa alakohtaisesti yrityksille. Ne luodaan 

vastaamaan integroituja ratkaisuja, joita yritykset tarvitsevat korvaamaan vanhanaikaiset 

järjestelmät. ERP-toiminnanohjausjärjestelmät luodaan minimoimaan kustannuksia, 

automatisoimaan prosesseja ja nostamaan yrityksen tehokkuutta (Osnes, Olsen, 

Vassilakopoulou & Hustad 2018:542). ERP-toiminnanohjauksen tarkoituksena on 

integroida eri organisaation eri toiminnot ja informaatiot toimimaan keskenään 

(Movahedi & Koupei 2011), kuten esimerkiksi kirjanpito, hankinta ja laskujenkäsittely. 

Sähköisen toiminnanohjausjärjestelmän käyttöönotto on liiketoiminnallisesti ja 

strategiatasoisesti haastava ja työläs projekti. ERP – ohjelmistot on rakennettu niin, että 

ne ovat yhteensopivia monien erilaisten yritysten liiketoimintaan (Movahedi & Koupei 

2011:489). Kun ERP-toiminnanohjausjärjestelmää aloitetaan implementoimaan 

organisaatioon, on otettava huomioon muut käytössä olevat ohjelmistot. Tutkimuksien 

mukaan suurin huolen aihe ERP:n käyttöönotossa on käyttäjien vastustus uudistusta 

vastaan. ERP tuo muutoksia kaikkiin organisaation muihin käytössä oleviin 

ohjelmistoihin, joka vaikuttaa käyttäjien toimintatapamuutoksiin (Haddara & Moen 

2017:860). ERP:n käyttöönotto tuo myös muutoksia, kuten teknillisiä ongelmia, joka 

esimerkiksi tarkoittaa, että kaikki vanhat ohjelmistot eivät ole integroitavissa uuteen 



26 
 

ERP:hen. Teknillisiin ongelmiin vaikuttavat esimerkiksi kiireisyys, liian vähäiset 

resurssit tai todella tiukoiksi määritetyt projektiaikataulut (Matende & Ogao 2013:520). 

Toisaalta myös muut hankintajärjestelmiä valmistavat yritykset kehittävät ohjelmistoja, 

jolloin kilpailijalta saattaa löytyä organisaatiota paremmin palveleviä ohjelmistoja ja 

järjestelmiä. 

  

 

Kuva 8. Toiminnanohjausjärjestelmän osa-alueet 

 

Edellä olevassa kuvassa on kuvattu kolme tärkeää osa-aluetta, jotka sisältyvät 

toiminnanohjausjärjestelmään. Nämä edellä mainitut kolme osa-aluetta tulevat olemaan 

tutkimuksessa esillä ja näitä tutkitaan yhdessä markkinoiden suurimassa 

hankintajärjestelmän ohjelmistossa.  

2.5. Hankintajärjestelmän käyttöönottoprosessi 

Edellisessä kappaleessa kuvailtiin toimitusketjun luonnetta ja millainen rooli IT – alan 

yritysten tuottamilla ohjelmistoilla on yrityksien toimitusketjuissa yleisesti. 

Hankintajärjestelmät kehittyvät koko ajan ja niiden tarjoama automatisaatio tuo 



27 
 

merkittävää arvoa yrityksille. Automatisaatiolla pystytään edistämään prosesseja ja 

vähentämään ihmisten tekemää työtä.  

Hankintajärjestelmät helpottavat yritysten liiketoimintaprosesseja, mutta niiden 

käyttöönotto vaatii yleisesti monien kuukausien työtä.  

Toiminnanohjausjärjestelmät ovat tällä hetkellä yritysten yleisin IT hankinta ja sijoitus 

yritysmaailmassa. Toiminnanohjausjärjestelmien odotetaan tuovan yrityksille lisää 

kilpailuvalttia, integraatiota muihin ohjelmistoihin ja läpinäkyvyyttä datan käsittelyyn 

koko organisaatiossa (Mahendrawathi, Zayin & Pamungkas 2017:217). Motiwallan ja 

Thompsonin (2012) mukaan ERP käyttöönottoprojekti pystytään jakaamaan eri osioihin: 

projektin skaalaan, omistautumiseen projektille, analyyseihin, suunnitteluun, 

kehittämiseen, hakkimiseen, itse käyttöönottoon ja ERP käyttöönoton toimenpiteisiin. 

Tämän tutkielman empiirisessä osiossa hankintajärjestelmän käyttöönotossa prosessi on 

hyvin samankaltainen, mutta erovaisuuksia löytyy. Motiwallan ja Thompsonin 

toiminnanohjausjärjestelmän ajattelutavan avulla voidaan tutkia tarkemmin mitä näihin 

osa-alueisiin tarkemmin kuuluu. 

2.5.1. Projektin skaala 

Projektin skaala on tärkein määrittää ensin. Projektin skaala määritellään lähes aina 

myynnissä ja projekti määrittelyissä (workshopeissa). IT projekteilla on tapana 

epäonnistua: puuttellisen taustatyön takia, puutteellisten projektisääntöjen takia, 

puutteellisen workshopin takia, epäonnistuneen projektitiimin vakiinnuuttamisen takia tai 

epäonnistutaan projekin johtamisessa (Hass 2006). 

Esimerkiksi vuonna 2004 Standish Group Internatiolin johtaman tutkimuksen mukaan, 

18 % Yhdysvalloissa tapahtuvista IT projetkeista epäonnistui, 53 % niistä ylitti 

määritetyn aikataulun ja budjetin ja vain 29 % IT projekteista onnistui. Heidän tuottama 

tutkimus osoitti, että suurin ja yleisin syy huonoille onnistumisasteikolle oli, että monet 

projektit aloitettiin toteuttamaan ilman huolella suunniteltua projektisuunnitelmaa (Hass 

2006). Projektisuunnitelma pitää sisällään projektin skaalan. Skaalalla siis tarkoitetaan 

projektin rajoja. Mitkä ovat projektin rajojen sisään kuuluvat asiat ja mitkä asiat 

totetutetaan projektin edetessä esimerkiksi muutospyyntöinä. Muutospyynnöt voidaan 



28 
 

ottaa mukaan, mutta ne ovat lisätyötä aiheuttavia muutoksia, jotka eivät sisälly projektin 

budjettiin. Täten näistä muutospyynnöistä asiakas maksaa erikseen. 

IT – alan ohjelmisto projekteissa on erittäin tärketä määrittää, mitkä asiat pystytään 

toteuttamaan ja mitkä ei. Näillä pystytään rajaamaan projektin rajat (Hussan, Ahmad & 

Zuhaira 2018). Ilman tarkasti määriteltyä projektin skaalaa, on suuri todennäköisyys, että 

projetki epäonnistuu (Hussan, Ahmad & Zuhaira 2018). 

IT – ohjelmistoprojektien skaalan muodostaminen on erityisen vaikea määritellä projekin 

monimuotoisuuden ja informaation koon vuoksi (Hussan, Ahmad & Zuhaira 2018). 

Hussan, Ahmad ja Zuhaira (2018) lajittelevat informaation kahteen eri luokkaa: 

Informaatio projektissa itsessään ja informaatio tuotteesta tai palvelusta. 

Informaatio projektissa sisältää informaation kulkemisen projetkiryhmälle sekä 

toteuttajan, että asikkaan puolelle. Budjetin informaation ja aikataulutuksen (Hussan, 

Ahmad & Zuhaira 2018). Budjetti informaatio pitää kulkea projektipäälliköiden välillä 

sekä myös sisäisesti. Aikataulutus myös sekä ulkoisesti että sisäisesti. Ulkoisesti tarkoitan 

esimerkiksi kun asiakas testaa ohjelmistoa oman projektiryhmän sisällä ja sisäisesti kun 

ohjelmistoa rakennetaan ja konfiguroidaan projetkimäärittelyjen mukaan asiakkaalle. 

Kun puhutaan informaatiosta tuotteesta tai palvelusta, tarkoitetaan tässä Human, Ahmad 

ja Zuhairan (2018) mukaan erilaisia vaatimuksia. Esimerkiksi asiakkaiden tarpeita tai 

mitä asiakas haluaa ohjelmiston tekevän. 

Vaikka projektin skaalan määrittelyvaiheessa onkin yleisin syy projektien 

epäonnistumiselle, voi syy löytyä myös asiakkaan puolelta. Esimerkiksi asiakkaan 

resurssien vähäisyys, asiakkaan epäkäytännölliset odotukset ohjelmiston suhteen, 

asiakkaan testauksen suunnittelemattomuus tai vähäiset tietotekniset taidot (Hussan, 

Ahmad & Zuhaira 2018). 

Projektin skaala ja sen sisältö olisikin hyvä olla selkeämuotoisessa ja rakenteellisessa 

taulukossa. Taulukkoa voisi seurata sekä asiakas että ohjelmiston tuottava yritys, jossa 

jokainen tehtävä olis merkitty ja ajoitettu projektiaikataulun mukaan. 

 



29 
 

 

 

Kuva 9. Esimerkki projektiaikataulusta taulukkomuodossa 

2.5.2. Projekti workshop 

Projektityöpajat (Workshop) ovat osa projektin skaalaa. Projetki työpajoja on erilaisia. 

Niitä pidetään alussa projektin määrittelyissä, testaustyöpajoja ja lopulta esimerkiksi kun 

asiakas ottaa liike-elämässään käyttöön uuden ohjelmiston, eli toisin sanoen lähdetään 

tuotantoon. Tällöin voidaan pitää esimerkiksi tuotannon tuen työpaja, jossa tuetaan 

asiakasta ohjelmiston käyttöönotossa. 

Projektin alkuvaiheessa tarkoituksena on käydä kattavasti läpi molempien projektitiimien 

kesken määrittelyt projektista ja että kaikki ymmärtävät projektin tarkoituksen ja skaalan 

(Burger, White & Yearworth 2019:161). Projetkityöpajoissa määritellään skaalan tavoin 

aikataulutut, resurssit, ohjelmiston ominaisuudet, jotka on mahdollista toteuttaa ja 

konfiguroida asiakkaan mieltymyksien mukaan. Projekti työpajojen tärkeimpänä 

toimintona on koota kaikki tärkeät toteuttajat samaan tilaan maksimoidakseen ajankäytön 

tehokkuuden, kerätä työpajoissa vaadittavat informaatiot asiakkaalta, asettaa tavoitteita, 

tutkia projektia monista näkökulmista ja kerätä ja jakaa ymmärrystä asioista (Lawrence 

2018). 

Lawrencen (2018) mukaan workshopeista on sekä laadullista että määrällistä hyötyä. 

Määrällinen hyöty: 

 



30 
 

• Paljon suurempi tuottavuus tuotteen toimittavuudessa. 

• Vähentää ylimääräisiä kommunikointeja osapuolten välillä 

• Vähentää virheviestinnän määrää, asioiden väärin ymmärrystä 

• Yleisesti kustannusten pienemistä 

 

Laadullinen hyöty: 

 

• Päätöksien läpikäynti ja niiden viimeistely 

• Parempi tietoisuus kaikista projektiin osallistuvista  

• Yhteydenoton parantuminen osapuolien kesken 

• Dokumentaation ja työkalujen (ohjeiden) kohonnut toimitettavuus 

• Tehokkaammat projektiryhmät molemmilla osapuolilla. 

 

IT- ohjelmistoissa on tärketä muistaa, että sovellukset ja ohjelmistot ovat tulosta monien 

ihmisten työstä (Fajtak 2005). Tämän vuoksi on tärkeätä, että  muistetaan pitää projektit 

tiedossa myös projektin ulkopuolisille ihmisille, jotka ovat olleet rakentamassa 

ohjelmiston perusrakenteita. Heiltä on mahdollista saada nopeasti tukea ja vastauksia jos 

ongelmatilanteita tulee eteen. 

2.5.3. Ohjelmiston konfigurointi ja rakentaminen 

Jos vertaamme projektin koostumusta Motiwallan ja Thompsonin teoriaan ja kuinka he 

jakoivat ERP - ohjelmiston käyttöönottoprosessin, sisältyy omistautuminen projektille 

(analyysit, suunnittellu, kehittäminen ja hankkiminen) ohjelmiston konfigurointiin ja 

rakentamiseen. Projektimäärittelyjen jälkeen äsken luettelemani asiat, tapahtuvat kaikki 

ennen kuin ohjelmiston käyttöönotto tapahtuu. 



31 
 

Ohjelmiston rakentaminen aloitetaan yleensä prosessin rakentamisesta. Kaikkein 

tehokkain tapa rakentaa ja kehittää ohjelma on kerätä dataa ja tietoa asiakkaan ja 

käyttäjien päivittäisistä toiminnoista, eri toimintojen yhteyksistä ja yhteyksistä 

kolmansiin osapuoliin, kuten toimittajiin. Tämän jälkeen tulisi analysoida nämä tiedot ja 

määrittää prosessi (Zota & Ciovica 2015:697). Prosessia (workflow) rakentaessa on 

tärkeätä seurata jokaisen eri toimintoa ohjaavan käyttäjän päivittäisi toimintoja. 

Toiminnot kuvaavat asiakkaan sisäisiä – ja ulkoisia tehtäviä. Tämän jälkeen yleensä 

arkkitehti määrittää prosessi kuvauksen (Zota & Ciovica 2015:697). Zota ja Ciovica 

(2015) näkemyksen mukaan asiakkaan liiketoiminta prosessin seuraamisen jälkeen on 

olemassa kolme tärkeätä etua, jotka prosessin teossa pitää ottaa huomioon. 

 

• Prosessissa tulee heti  huomata mahdolliset prosessin pysäyttäjät tai pullonkaulat 

• Pystytään määrittämään heti rakennuksen alussa tarkka prosessin aloituspiste, 

josta lähdetään rakentamaan kaikkia yrityksen toimintoja prosessissa. Tällöin 

prosessi pystytään rakentamaan siten, että vastaa käyttäjien todellisia tarpeita. 

• Erilaiset komponentit ja palveluiden osat voidaan optimoida siten, että ne 

helpottavat kommunikointia yrityksen ja kolmansien osapuolten kesken. 

 

Alla on kuvattu esimerkkikaavio, millainen arkkitehtuuri esimerkiksi yrityksen 

hankintaprosessiin voidaan tehdä ja mitä asioita siinä tullaan ottamaan huomioon. Kuva 

on yksinkertaistettu, mutta siitä ilmenee toiminnot, jotka voisivat olla esimerkiksi 

asiakkaan prosessin toimintoja. Prosessikuvauksessa olisi hyvä aina esittää toiminnot ja 

vaatimukset (Zota & Ciovica 2015:697) 

 

 

 

 

 



32 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 10. Esimerkki hankintaehdotuksen prosessista 

Hankintaehdot

uksen 

luominen 

Ulkoinen 

verkkokauppa 

Katalogituote 

Noudetaan 

tuote 

Luodaan 

hankintaehdotus 

Tarkastus 

vaaditaan? 

Hankintaehdotus 

viimeistelyyn? 

Hankintaehdotuksen 

hyväksyntä 

Tarkastus 

vaaditaan? 

Ostotilaus 

muodostuu 

Ostotilaus vahvistus 

vaaditaan? 

EI 

Tavara toimitettu 

Tehdään 

vastaanottokuittaus 

Ehdollinen 

hyväksyntä? 

EI 



33 
 

3. Tutkimuksen metodologia 

Ennen kuin siirrymme tutkielmassa tarkastelemaan case - yrityksiä ja niiden projektien 

toteutumista, selvennetään vielä tämän tutkimuksen metodologiaa. Tutkimuksessa on 

tutkittu kahta eri alan yritystä, jotka molemmat ottivat käyttöön saman IT - alan yrityksen 

hankinnan - ja laskujenkäsittelyn ohjelmiston. Tarkoituksena oli tutkia kahden eri 

yrityksen automatisaation hyödyntämistä ohjelmistoissa ja pyrkiä tehostamaan heidän 

liiketoimintaprosesseja. Prosesseja suunnitellessa, päätöksentekoja tapahtuu koko ajan. 

Prosessiarkkitehtuurissa prosessiarkkitehdeillä on korkea näkemys sekä liiketoiminnasta 

että myös teknisestä puolesta (Razavian, Paech & Tang 2019). Esimerkiksi suunnitellessa 

laskunkierto - ja hankinnanprosessia. Tässä tutkimuksessa prosessien suunnittelun 

näkökulmaa on pyritty avaamaan projektin määrittelyissä ja kahden erilaisten yritysten 

prosessia on verrattu toisiinsa ja millä tavalla ohjelmistot parantavat yrityksen asemaa 

toimitusketjussa. 

3.1. Menetelmät aineiston keruuseen. 

Tämän tutkimuksen empiirisen tutkimuksen materiaalit kerättiin osittain 

haastattelemalla, suunnittelemalla uudet prosessit itse ja sovellusarkkitehdin avulla. 

Automaattiset liiketoimintaprosessit suunniteltiin itse ja koodit tehtiin osittain itse. 

Haastattelu ei tapahtunut virallisella haastattelumallilla, missä keskitytään vastaamaan 

ennakkoon kirjoitettuihin kysymyksiin. Tässä haastattelut olivat enemmänkin dialogia 

asiakkaiden kanssa, jossa heitä pyydettiin kuvaamaan heidän nykyinen liiketoiminnan 

prosessi, jonka jälkeen toisessa projektissa sovellusarkkitehti suunnitteli alkuperäisen 

prosessin ja toisessa sovelluskonsultit integraatiokonsultin kanssa suunnittelivat 

prosessin. Alkuperäisiin prosesseihin sovelluskonsultit ja integraatiokonsultti lisäsivät 

automatisaatiota. Kaikki dialogia, joka koski prosessimuutoksia ja ohjelmiston 

päivittämistä nykyaikaisempaan malliin, kirjattiin ylös loppudokumentteja varten. 

Laadullisen tutkimuksen tiedonkeruumenetelmänä haastattelu voidaan toteuttaa 

syvähaastatteluilla tai ryhmähaastatteluilla (Heikkilä 2014). Projektimäärittelyt voidaan 

tulkita ryhmähaastatteluiksi. Haastatteluissa on tärkeätä esittää tarkkaan harkittuja 

kysymyksiä, sillä ne auttavat keräämään tarkempaa dataa (Rosenthal 2016). Näissä 



34 
 

molemmissa tutkittavien yritysten projektimäärittelyissä peruskysymykset olivat samat, 

mutta automaatioasteen eroavaisuus erotti jatkokysymykset yritysten välillä.  

Prosessien suunnitteluun osallistuvan arkkitehdin tekemä prosessi kuuluu 

projektidokumentin sovellus-osioon, joka on yksi käytetty aineisto tässä tutkimuksessa. 

Automaattiset liiketoimintaprosessit suunniteltiin itse, jolloin itse tehty aineisto kuuluu 

myös tähän tutkielmaan. Itse tehdyissä automaatioissa konsultointia on saatu myös 

kokeneemmilta konsulteilta kysymyllä mielipiteitä, joka kuuluu haastatteluosioon. 

Tutkielmassa käytetyt koodit ovat suurimaksi osaksi itse kirjoitettuja koodeja, mutta 

pohja niihin on saatu tämän IT - alan yrityksen Intranetistä. Aineisto on siis yrityksen 

omistamaa, minkä vuoksi tätä aineistoa ei voida yrityksen oikealla nimellä mainita. 

3.2. Tutkimuksen strategia 

Tutkimus perustui kahteen case - yritykseen, jotka ottivat käyttöön saman hankinnasta 

maksuun - järjestelmän, joka kattoi hankinnan ja laskujenhallinnan osa-alueet. Case - 

tutkimus valittiin tähän strategiaksi sen perusteella, että se pyrkii kuvailemaan ja 

selittämään tutkimuksen ja siihen liittyvät kysymykset (Yin 2009:2). Tutkimus 

toteutettiin rakentamalla heille asiakaskohtaisesti konfiguroidut järjestelmät, joissa 

tutkittiin miten yritys hyötyi automaatiosta hankintajärjestelmässä ja millä tavalla se 

vaikutti heidän asemaansa toimitusketjuissa.  

Projektien määrittelyvaiheessa oli tärkeää keskustella ja kysyä asiakkaalta heidän 

mielipiteitään nyky prosessista. Miksi prosessit toimivat nyt näin, miksi prosessien 

halutaan toimivan näin, miten he haluaisivat prosessin toimivan nyt. Näiden kysymysten 

vastauksien perusteella prosessit piirreettiin ja luotiin dokumentteihin. Mitä edemmäs 

projektit menivät, sitä enemmän hankinnan ja laskujen kiertoa testattiin ja lopulta 

havaittiin, että prosesseista saadaan tehtyä vieläkin tehokkaampia, jos automatisaatiota 

lisätään. 



35 
 

3.3. Haastattelut ja projektimäärittelyt 

Haastattelut ja dialogiat käytiin alkuun kasvotusten projektien määrittelyissä ja 

projetkityöpajoissa. Statuspalaverit käytiin asiakkaiden kanssa skypen avulla, jossa on 

mahdollista näytönjaon avulla esitellä tämänhetkistä prosessia ja tehdä mahdollisia 

lisäyksiä samalla kun asiakas näkee prosessin kulun. Nämä kaksi projektia valittiin 

tutkimukseen, sillä molemmat yritykset ovat liikevaihdoiltaan melkein samankokoiset ja 

molemmat ottivat käyttöönsä sekä hankinnan - että laskujenhallinan järjestelmän. Nämä 

kaksi asiaa tekivät yrityksistä vertailukelpoiset tutkimusta ajatellen. 

Yritys Y:n projektimäärittelyihin osallistui ohjelmistoa tuottavan yrityksen puolelta 

projektipäällikkö, kaksi sovelluskonsulttia, sovellusarkkitehti ja integraatiokonsultti. 

Asiakkaiden puolelta osallistui myös projektipäällikkö, hankintapäällikkö ja kolme 

hankinnan pääkäyttäjää, järjelmävastaava, laskujenhallinnan pääkäyttäjä sekä kolme 

laskujenhallinnan (reskontran) käyttäjää.  

Yritys X:n projektimäärittelyihin osallistui samat henkilöt ohjelmistoa tuottavan 

yrityksen puolelta, mutta asiakkaan puolella oli eroavaisuuksia. Asiakkaalla oli myös 

projektipäällikkö, hankintapäällikkö, kolme hankinnan pääkäyttäjää, kolme 

laskujenhallinnan pääkäyttäjää. Järjestelmävastaava oli tässä projektissa ulkoistettu, jotka 

rakensivat liittymät, jotka integroitiin ohjelmistoa tuottavan yrityksen liittymiin. 

Kaikki määrittelyissä keskustellut asiat kirjattiin ylös sovellus - ja 

integraatiodokumentteihin. Nämä dokumentit määrittelivät projektien skaalan, jotka 

toimitettiin asiakkaille luettavaksi, jonka jälkeen saatii heidän hyväksyntänsä. 

Hyväksyntien jälkeen skaalat olivat määritelty, joka projektissa tarkoitti sitä, että mikään 

mikä ei kuulu määrittelyissä tehtyyn dokumenttiin, ei rakenneta ilman lisäkustannuksia. 

Kustannuspoliittisesti skaalan määrittäminen oli erittäin tärkeätä. Projekteihin 

osallistuvien nimiä eikä dokumentteja ole liitetty tähän tutkimukseen yritysten 

salassapitovelvollisuuksien vuoksi. 



36 
 

3.4. Aineiston analysointi 

Analysoinnilla tarkoitetaan aineistomateriaalin tutkimista (Flick, von Kardoff & Steinke 

2004). Haastattelulla saadun aineiston analysoinnin ensimmäinen tehtävä on aineiston 

purkaminen pienempiin osiin, jotta aineistoa on helpompi lähteä tutkimaan (Jovero). 

Tässä tutkimuksessa asiakkaiden kanssa käyty dialogi ja siitä saadut tiedot antoivat 

perustan prosessien rakentamiselle. Kysymyksiin saadut vastaukset eivät olleet 

tutkimustuloksia, vaan tutkimustulokset saatin vasta kun ohjelmisto, prosessit ja 

automatisaatio oltiin rakennettu asiakkaan toiveiden mukaan. Puheessa tulleet 

asiakastarpeet muutettiin koodeiksi, parametreiksi, prosessiresolvereiksi ja 

prosessikuvaukseiksi, joiden jälkeen saatin rakennettua tutkimus ja tutkimustulokset. 

Aineisto, joka taas saatiin ohjelmistoa tuottavalta yritykseltä, kuten perusprosessit, 

parametrien nimet ja tarkoitus, resolverit ja koodipohjat, pitivät ne kaikki suunnitella ja 

muokata toimimaan näissä asiakaskohtaisissa prosesseissa. Nämä prosessit, 

prosessikuvaukset ja automatisaatiota parantavat koodit käydään lävitse empiirisessä 

osiossa. 

Tärkein aineisto, joka tässä tutkimuksessa saatiin, oli lopputulokset. Lopputuloksissa 

tutkittiin ja tarkasteltiin täsmäytyneiden laskujen määrää ostotilauksiin, ohiostojen 

vähenemistä, kiertonopeutta sekä hankinnoissa että laskuissa ja tehtävien määrää. 

Lopputuloksia tullaan esittämään tutkielman johtopäätökset – osiossa. 

3.5. Tutkimuksen luotettavuus 

Tutkimuksen luotettavuus on yksi tärkeä tekijä, joka mahdollistaa ymmärtämään, kuinka 

tutkimustulokset ja tuloksiin viittaavat johtopäätökset muodostuivat tutkimuksessa. Mitä 

edemmäs tutkimus eteni, sitä enemmän haasteita eteen ilmeni. 

Projekimäärittelyissä käydyt keskustelut ohjelmistosta ja sen tuomasta automatisaatiosta 

olivat yksi haasteista. Haasteena oli saada asiakas ymmärtämään, kuinka prosessit 

toimivat nyt ja millaista automaatiota siihen voidaan rakentaa, ja kuinka paljon 

rakennettava automaatio voisi nopeuttaa heidän päivittäistä liiketoimintaa. Tutkimuksen 



37 
 

päätavoitteena oli kuitenkin tutkia automatisaation hyötyä hankintajärjestelmässä ja 

miten se vaikuuttaa yrityksen asemaan toimitusketjussa. 

Mitä edemmäs tutkimus eteni, huomattiin, että asiakas ei ollut täysin ymmärtänyt kuinka 

automatisaatio oltiin määritelty, sillä he olivat tottuneet aikaisemmin tekemään 

manuaalisesti suurimman osan töistä, kun nyt koodilla voitiin tutkia samoja asioita 

nopeammin ja automaatiolla toteuttaa erilaisia manuaalisia toimenpiteitä. Mikä 

määrittelyissä ja projektien etenemisessä myös aiheutti haasteita, oli teknillisten termien 

ymmärtäminen ja asiakkaan laskujen ja hakinnan prosessien testaus. Teknillisillä 

termeillä kuvattiin prosessia ja koodeja, joilla pyrittiin tuottamaan automaatiota heidän 

liiketoimintaansa, mutta asiakkaan täysi ymmärtäminen termeistä aiheutti haasteita. 

Termien ja teknillisten käsitteiden ymmärtämisellä ei kuitenkaan ollut saatujen tulosten 

kannalta minkäänlaista oleellista merkistystä. 

Tutkimukseen valitut yhtiöt eivät olleet kooltaan aivan saman mittakaavan yrityksiä, 

vaikka liikevaihdoltaan olivat lähes samankokoisia. Toisella yrityksellä oli keskistetty 

osto-organisaatio ja toisella yrityksellä hajautettu osto-organisaatio. Keskitetyssä ostossa 

tai hankinnassa hankintatiimi valitsee toimittajat, joiden kanssa tehdään liiketoimintaa ja 

harjoitetaan hankintaa (Munson & Hu 2010:582). Hajautetussa ostossa ei ole 

hankintatiimiä, vaan yleisesti kuka tahansa voi tehdä hankintoja yritykselle, mutta 

yleisesti nämä hankinnat on jollain tapaa rajattu. Yleisesti käytetään toimittaja - ja 

summarajauksia, jolla pystytään eväämään tietyiltä henkilöiltä ja osastoilta mahdolliset 

hankinnat. 

Tutkimuksen aineiston koko oli yksi erottava tekijä. Aineistolla tarkoitetaan tässä datan 

määrää, joka saatiin yrityksien ERP - järjestelmästä. Esimerkiksi toimittaja-, 

kustannuspaikka-, tili-, projekti-, alatilit-, henkilö- tai maksusuunnitelmadataa. 

Datamäärien eroavaisuus vaikutti automaatioon ja sen hyödyntämiseen. Suuremmasta 

määrästä dataa on helpompi rakentaa hyödyllistä automaatiota, sillä ero on helpommin 

huomattavissa. 

Ohjelmistot olivat yrityksillä samat, joka taas helpotti samojen koodien käyttämistä 

molemmissa tutkittavissa yrityksissä. Saman ohjelmiston käyttäminen antoi 

tutkimukselle vakaamman pohjan, sillä vertailu kahden saman ohjelmiston välillä kavensi 

tutkimustuloksien mahdollisia virhelukuja. Koska nämä kaksi omasivat hyvin 



38 
 

samantyyppiset laskujenhallinan – ja hankinnan prosessit, oli tutkimustuloksia helpompi 

vertailla. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



39 
 

4. Hankintajärjestelmäprosessin määrittäminen 

Tutkimuksen projektimäärittelyistä saadaan esitettyä todellinen katsaus, kuinka 

projekteja lähdettiin toteuttamaan ja mihin asioihin määrittelyissä keskityttiin. Tärkeätä 

on selvittää ensiksi, kuinka näiden kahden yrityksen ohjelmistoa lähdettiin 

konfiguroimaan ja rakentamaan ja mistä koko rakennus aloitettiin. Ensimmäisenä 

tarkastellaan miten projektit lähtevät liikkeelle ja kuinka projekteissa edetään. Tämän 

tarkastelun jälkeen tutustutaan ja kerrotaan kuinka projektityöpajojen jälkeen ohjelmiston 

rakentaminen aloitetaan. 

Luvun edetessä tarkastellaan prosessien rakentamista molemmille yrityksille, jonka 

jälkeen avataan rakennettuja prosesseja ja analysoidaan rakennettuja prosesseja ja kuinka 

kahden tutkittavan yrityksen prosessit eroavat toisistaan. Vaikka prosessit muistuttavat 

paljolti toisiaan, on niiden eroavaisuuksissa suuria eroja. Prosessit on kuvattu 

tutkimuksessa usella tavalla ja ne on esitetty tekstissä. Sovellusdokumentti on lisättynä 

liitteenä, mutta yrityssalaisuuksien vuoksi, liitettä ei ole nähtävillä lukijalle. Näissä 

kahdessa prosessi tutkija havainnoi prosessien samanlaisuudet sekä eroavaisuudet. 

Prosesseissa erityisesti keskitytään avaamaan termit, prosessin muodostaminen ja 

prosessipolku, jotta epäselvyyksiä tutkimuksesta ei syntyisi. Prosessiin tehdyt lisäykset 

konsulttien toimesta poimitaan myös prosesseista, jotka tekivät prosesseista ja 

ohjelmistosta automaatioasteeltaan vieläkin suuremman ja tehostetumman. 

4.1. Projektimäärittelyjen aloittaminen 

Tutkimuksen aloittaminen tapahtuu projektimäärittelyistä. Projektimäärittelyissä 

keskityttiin määrittelemään ohjelmiston rakentaminen mahdollisimman pitkälle. 

Määrittelyt etenivät sovellusdokumentin sisällön mukaan. Ensimmäisenä määrittelyissä 

käytiin läpi yrityksien  organisaation hierarkia. Hierarkian avulla pystytään ohjelmistossa 

määrittämään käyttäjien, käyttäjäryhmien, ERP – järjestelmien ja prosessien vaikutukset 

ja rajoitukset. Esimerkiksi jos tietty automatisaatio halutaan vain yhdelle yritykselle, 

voidaan se organisaatio hierarkian avulla rajata siten, että muutokset vaikuttavat vain 

yhteen ja tiettyyn yhtiöön. 



40 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kuva 11. Yritys X:n organisaatio hierarkia 

 

 

 

Ylin taso 

Alustan 

taso 

ERP taso 

Maa 1 

Maa 2 

yhtiö 

yhtiö 

yhtiö 

yhtiö 

yhtiö 

Maa 3 

yhtiö 

yhtiö 



41 
 

 

 

 

 

 

 

 

 

 

Kuva 12. Yritys Y:n organisaatio hierarkia 

Yläpuolella on esitetty projektimäärittelyistä näiden molempien tutkittavien yritysten 

organisaatiohierarkia. Organisaatiot muodostuivat tutkittavilla yrityksillä erilaisiksi, 

mutta tämä johtui organisaation yhtiöiden määrästä ja levinnäisyydestä. Yhtiöiden 

erottaminen alkuvaiheessa oli tärkeätä, jotta tulevia prosesseja voitaisiin suunnitella 

tarkemmin.  

Organisaatiohiearkia määrittelyjen jälkeen määriteltiin tulevat käytettävät kentät 

ohjelmistoon. Kentillä tarkoitetaan tässä ohjelmistossa olevia kenttiä, joihin käyttäjä ja 

automaatio ottaa kantaa. Esimerkiksi laskujenhallinnassa tilinumero, tilin nimi ja selite, 

ovat kuvattu alla olevassa kuvassa. 

 

 

Ylin taso 

Alustan 

taso 

ERP taso 

yhtiö 

yhtiö 

yhtiö 

yhtiö 



42 
 

 

Kuva 13. Esimerkki kentistä 

 

Kentät määriteltiin sekä hankinnan, että laskujenhallinnan puolelle. Kenttämäärittelyt 

pitivät sisällään 

• Laskun otsikkokentät 

• Laskun tiliöintikentät 

• Maksusuunnitelman tiliöintikentät 

• Hankinnan Hankintaehdotuksen otsikkokentät 

• Hankinnan Hankintaehdotuksen osoitekentät 

• Hankinnan Hankintaehdotuksen rivitietokentät 

• Hankinnan Hankintaehdotuksen tiliöintikentät 

• Hankinnan Hankintaehdotuksen ostotilauskentät 

• Hankinnan Ostotilauksen otsikkokentät 

• Hankinnan Ostotilauksen osoitekentät 

• Hankinnan Ostotilauksen rivitietokentät 

• Hankinnan Ostotilauksen tiliöintikentät 

• Hankinnan Ostotilauksen ostotilauskentät. 

 

Kenttämäärittelyt kertoivat projektissa, mitä kenttiä yritykset tarvitsevat päivittäisessä 

liiketoiminnassaan. Kenttien määrittelyllä oli suuri merkitys automatiikan 

rakentamisessa. Mitä enemmän erilaisia kenttiä halutaan tai tarvitaan päivittäisessä 



43 
 

liiketoiminnassa, sitä suurempi määrä dataa on yrityksellä hyödynnettävänä ja sitä 

enemmän automatiikkaa on mahdollista hyödyntää. 

4.2. Hankinnan automatisointi Yritys X 

Yritys X:n hankinta perustui ennen projektia automatiikaltaan hyvin alhaiseen tasoon. 

Tavoitteena oli luoda hankinnassa erilaisia prosessikiertoja, jotta hankinnat menisivät 

oikeille ihmisille hyväksyttäväksi, eikä vääriä ja turhia hankintoja tapahtuisi yrityksessä. 

Hankinnassa määritettiin ensimmäisenä hankintakanavat, joista hankintoja tultaisiin 

tekemään. Hankintakanavat olivat katalogiostot, ulkoiset verkkokaupat ja 

vapaatekstilomakkeet. Hankinnan prosessi muodostettiin seuraavalla tavalla. 

 

 

 

 

Kuva 14. Yritys X:n hankintaprosessin kuvaus 



44 
 

Hankinnassa automaatiota rakennettiin hankintaehdotuksen lähettämiseen eteenpäin 

seuraavalle henkilölle, tilaustietojen täydentymiseen automaattisesti, kun tuote haetaan 

ulkoisesta verkkokaupasta, katalogilta tai kun vapaatekstilomake on täytetty. Ulkoiset 

verkkokaupat rakennettiin järjestelmään sisään sen sijaan, että tuote ostettaisiin ensiksi 

verkkokaupasta, jonka jälkeen tuotteesta tehtäisiin erillinen tilaus tilausjärjestelmään.  

Ulkoiset verkkokaupat tehtiin ohjelmistoon käyttäen OCI (Open Catalog Interface) 

rajapintakuvausta. OCI rajapinnassa pystytään siirtämään toimittajan ulkoisen 

verkkokaupan tuotetiedot tarkasti asiakkaan hallussa olevaan ERP – järjestelmään tai 

hankintajärjestelmään (Lapp Group 2019). Alla esimerkkikuvas sanomasta, joka tuodaan 

kenttäkohtaisina tietoina ulkoisesta verkkokaupasta hankintajärjestelmään. QueryString 

osiossa määritellään SiteId (johon sanoma tuodaan), OrganizationId (organisaatio, joka 

tuotteen ostaa) ja returnUrl (eli mihin ostoskori palautetaan). Name – osiossa määritellään 

hankintajärjestelmän kentät, joihin ulkoisesta verkkokaupasta tuodut tuotetiedot ajetaan 

sisään, kun käyttäjä palaa takaisin hankintajärjestelmään. Tässä tutkimuksessa 

ohjelmistoon lisättiin automaation kannalta kaksi muuta kenttää, jotka automatisoivat 

prosessia ja vähentävät manuaalista työtä. NEW_ITEM-EXT_SCHEMA_TYPE ja 

NEW_ITEM-EXT_CATEGORY_ID. Näihin kenttiin tuotiin tuotteiden UNSPSC -  

koodit. UNSPSC - koodit ovat ensimmäisiä numeerisia koodeja, joilla voidaan erotella 

tuotteet ja palvelut toisistaan (Xu, Zou,Gu,Wei & Zhou 2012:1863). 

Tässä prosessissa UNSPSC – koodit kytkettiin asiakkaan hankintakategorioihin. Tätä 

kutsutaan ristiviittaustaulukoksi. Ristiviittaustaulukossa jokainen UNSPSC – koodi 

kytkettiin niihin hankintakategorioihin, joita Yritys X käytti. Hankintakategoriat kertovat, 

mitä milläkin kategorialla on tarkoitus ostaa. Jokaiseen kategoriaan kytkettiin tili ja 

verokoodi. Tämä tarkoitti automaatiossa sitä, että kun ohjelmisto tunnisti UNSPSC – 

koodin ulkoiselta verkkokaupalta tai katalogiostolta, ohjelmisto automaattisesti täytti 

hankintaehdotuksessa hankintakategorian, tilin ja alvkoodin ja laski hankintaehdotuksen 

summan. Käyttöpääomaraportin kannalta tämä tarkoitti sitä, että raporteista tuli tarkkoja, 

eikä ohiostoja syntynyt kategoriakohtaisesti. Käyttäjä ei voinut tehdä ostoja väärällä 

kategorialla, joka oli kytketty tiettyyn tiliin.  



45 
 

 

 

Kuva 15.  OCI – sanomien palautuminen ulkoisesta verkkokaupasta 

4.2.1. Hankinnan prosessin rakentuminen Yritys X 

Tutkimuksessa hankinnan prosessin rakentaminen oli automatisoitava mahdollisimman 

pitkälle. Prosessin piti olla selkeä ja tukea Yritys X:n keskitettyä ostoa, mutta myös 

mahdollistaa muiden yrityksen työntekijöiden tehdä hankintaehdotuksia. Hankinnan 

prosessin tehtävät olivat seuraavat. 

 

• Hankintaehdotuksen luominen (Luonnos) 

• Hankintaehdotuksen validointi 

• Hankintaehdotuksen tarkastus (valinnainen: Jos hankinta tehtiin IT – 

hankintakategorioilla, ohjasi prosessi hankintaehdotukset kategoriatarkastukseen) 

• Hankintaehdotuksen viimeistely eli ValidityReview (Kaikki 

vapaatekstihankintaehdotukset ohjettiin keskistetylle ostolle viimeistelyyn) 



46 
 

• Hankintaehdotuksen hyväksyntä. 

• Ostotilauksen muodostuminen (Automaattinen) 

• Ostotilauksen vahvistaminen (Jos toimittaja lähetti UBL XML 2.0 sanomalla 

sähköisen tilausvahvsituksen, vahvistettiin tilaus automaattisesti. Muute tilauksen 

vahvistaminen tehtiin manuaalisesti) 

• Vastaanottokuittauksen tekeminen (Automaattinen tai manuaalinen riippuen 

Condition – säännöistä) 

 

Prosessin tehtävät määriteltiin yhdessä Yritys X:n kanssa. Jokainen hankintaehdotus 

muodostuisi automaattisesti luonnokseksi, kun sitä alettaisiin luomaan. Esimerkiksi jos 

ulkoisesta verkkokaupasta ostettaisin tämän ohjelmiston kautta tuotteita, muodostaisi 

ohjelmisto automaattisesti hankintaehdotukset riveittäin ja täyttäisi automaattisesti tiedot 

niille kentille, jotka tulevat mukana verkkokaupan paluusanomissa. Tämän ohjelma 

muodostaisi siis automaattisesti. Seuraavaksi haluttiin ottaa huomioon 

vapaatekstilomakkeilla tehtävät hankintaehdotukset. Vapaatekstilomakkeet ovat sanansa 

mukaisesti vapaasti tehtäviä lomakkeita, joissa ei automaatiota ole, vaan käyttäjä itse 

muodostaa hankintaehdotuksen ja täyttää manuaalisesti kenttätiedot, jotka 

hakintaehdotukselle tarvitsee. Koska vapaatekstilomakkeet täytetään vapaasti, sisältävät 

ne usein virheitä, mikä aiheuttaa virheellisten tilauksien määrää. Virheelliset tilaukset 

olivat Yritys X:lle suuri ongelma, sillä ne veivät yrityksen käyttömenoa ja myöhästyttivät 

erilaisten projektien aikataulua. Tämän vuoksi jokainen hankintakanava nimettiin 

tuotetyypiksi (ProductType). Ulkoinen verkkokauppa määriteltiin ProductType 1, 

vapaatekstilomakkeet ProductType 2 ja katalogiostot ProductType 3. Tämän jälkeen 

prosessiin tehtiin tehtävä nimeltään ”ValidityReview”. Tämä tehtävä luotiin keskitetylle 

ostolle, jolle kaikki vapaatekstillä tehdyt tilaukset tulisi tarkastettavaksi, ennenkuin ne 

lähtisivät hyväksyntään. LISTCONTAIN ([WorkflowRequisitionLines],”ProductType”, 

2 – ehto kertoo, että jos hankintaehdotuksella on edes yksi rivi, joka on muodostettu 

vapaatekstilomakkeella, tulee hankintaehdotus tarkastettavaksi keskitetylle ostolle. 

Keskitetty osto voi ennen tilauksen muodostamista tarkistaa varastosaldot, projektin ja 

työnumeron, että ne ovat valideja. Tämä pois sulkee virheellisten tilausten syntymistä 



47 
 

Jos hakintaehdotus ei sisällä vapaatekstilomakkeilla tehtyä hankintaehdotusta, lähtee 

hankintaehdotus aina suoraan hyväksyntään. Hyväksyjän löytämiseen tehtiin myös 

automaatiota. Käyttäjän ei koskaan tarvitse etsiä oikeata henkilöä, joka 

hankintaehdotuksen tulisi hyväksyä. Logiikka, jota käyttettiin oikean henkilön 

etsimiseen, kutsuttiin laajennetuksi käyttöoikeudeksi. Ennen Yritys X:n käyttäjät etsivät 

oikean henkilön henkilölistalta, jolle hankintaehdotus oli lähetettävä hyväksyttäväksi. Jos 

valittu henkilö oli väärä, lähetti tämä henkilö hankintaehdotuksen eteenpäin seuraavalle 

henkilölle. Tämä prosessi vei aikaa oikean henkilön etsimiselle, mistä haluttiin päästä 

eroon. Tämän vuoksi uusi logiikka rakennettiin oikean henkilön etsimiselle. 

Logiikka rakennettiin perustumaan dimensioihin eli kenttäkohtaisiin datoihin ja datan 

pituuksiin. Logiikkaan rakennettiin seitsemän dimensiota. Jokaisen käyttäjän 

henkilötietojen taakse tuotiin seitsemää eri tietoa. Nämä tiedot olivat projektikoodit, 

organisaatiotunnus, henkilönumero, yhtiön tunnus, varasto ID, hyväksymisraja 

organisaation summissa ja prioriteettijärjestys. Jos henkilöllä oli useampi projekti, johon 

hänellä oli oikeudet hyväksyä hankintaehdotuksia, monistettiin hänet useampan kertaan 

tämän logiikan sisältämään tauluun, jonka nimi oli laajennetut käyttöoikeudet.  

 

Taulukko 1.  Esimerkki laajennetusta käyttöoikeudesta 

Nimi Organisaatio Yhtiö projekti henkilönumero varasto ID Hyväksyntäraja priotiteetti 

Test Org 1 00 5678-

5690 

123 5678943 100 000 € 1 

 

 

Taulukossa 1 on kuvattu esimerkkinä taulun rakenne. Oletetaan että hakintaehdotus on 

tehty Organisaatiolle 1 ja yhtiölle 00. Tämän jälkeen koodi etsii taulusta kaikki henkilöt, 

joiden organisaatio on 1 ja yhtiö tunnus on 00. Tämän jälkeen kun hankintaehdotuksen 

täyttämistä jatketaan ja siihen syötetään projekti, jonka koodi on esimerkiksi 5679, 



48 
 

pyörähtää koodi jälleen ja etsii taulusta ne henkilöt, joiden organisaatio on edelleen 1, 

yhtiötunnus 00 ja projekti 5679. Projektien takaa populoituu myös henkilönumero 

hankintaehdotusta luodessa, mutta vain sen henkilön henkilönumero, jonka prioriteetti on 

pienin. Jos hankintaehdotuksessa vielä käytettäisii varasto ID:tä ja valittaisiin ID:ksi 

5678943 ja hankintaehdotuksen kokonaiskustannukset alittaisivat 100 000 € rajan, 

löytyisi hyväksyjäksi taulusta vain henkilö Test, jolle hankintaehdotus lähtisi 

automaattiseti hyväksyttäväksi, ilman että käyttäjän tarvitsisi ottaa kantaa hyväksyjään. 

Jos tapahtuisi niin että kun hankintaehdotus olisi täytetty ja se olisi valmiina 

lähetettäväksi hyväksyntään, mutta hyväksyjä haluttaisiin vaihtaa johonkin muuhun, olisi 

hyväksyjälista filteröitynyt samojen sääntöjen mukaan pienemmäksi. Toisin sanoen 

listalta avautuisi vain hankintaehdotuksen dimensioiden kriteerit täyttävät henkilöt. Tällä 

automaatiolla hankintaehdotukset saatiin lähtemään nopeammin oikealle henkilölle 

käsittelyyn, ilman ylimääräistä hankintaehdotuksen uudelleen ohjaamista toiselle 

henkilölle. 

4.2.2. Käänteisen hankinnan prosessin määrittäminen 

Yritys X:n normaaliin hankintaprosessiin haluttiin lisäksi toiminnallisuus, joka vähentäisi 

analytiikassa väärien käyttömenoraporttien tuloksia. Toisin sanoen, osa hankinnoista 

tehtiin soittamalla tai sähköpostilla toimittajalle, jolloin toimittajan lähettämässä 

laskudatassa oleva ostotilausnumero ei täsmäydy järjestelmän ostotilaukseen, koska 

ostotilausta ei oltu tehty järjestelmällä. Tämän vuoksi toimittajilta tulevat laskut kirjattiin 

kululaskuina, joka tarkoittaa hankinnassa myös ohiostamista. Ohiostot eivät kuulu 

suunnitellun käyttömenon piiriin, mikä tarkoittaa raportoinnin kannalta sitä, että ohiostoja 

joudutaan tutkimaan ja selvittämään syyt näille. Tämä vei yritykseltä resursseja turhaan, 

sillä suurin osa näistä ohiostoista oli suunniteltua ostoa, mutta kun järjestelmä ei löydä 

laskulla olevaa ostotilausnumeroa, ei laskua voida laskea suunniteltuun käyttömenoon. 

Toinen ongelma näissä ohiostoissa oli, että jokainen kululasku jouduttiin lähettämään 

tarkastettavaksi ja hyväksyttäväksi, vaikka niillä oli ostotilausnumero. Suuren 

laskumassan kanssa haluttiin tehdä niin että myös nämä äkilliset ostot puhelimitse tai 

sähköpostitse haluttiin saada täsmäytyksen piiriin. Tämän vuoksi Yritys X:lle 

rakennettiin käänteinen tilausprosessi, joka liitettiin heidän normaaliin hankinnan 

prosessin. 



49 
 

Käänteisessä tilausprosessissa toimittaja luo hankintaehdotuksen tai ostotilauksen, 

riippuen kummasta on toimittajan kanssa käyty keskustelua. Normaalisti jos yrityksellä 

on tarve tilata tavaraa toimittajalta, tekee hankintaehdotuksen Yritys X:ssä työskentelevä 

ihminen, jolta tilaus lähetetään toimittajalle. Käänteisessä tilanne on toisinpäin.  

Käänteinen prosessi lähtee toimittajalta Yritys X:lle. Alla on kuvattu käänteinen 

tilausprosessi lohkokaaviolla. 

 

 

 

 

Kuva 16. Käänteinen tilausprosessi 



50 
 

Prosessi alkaa toimittajan toimenpiteestä. Riippuen siitä onko toimittajaa pyydetty 

tekemään ehdollinen hankintaehdotus vai suoraan ostotilaus. Jokainen käänteinen tilaus 

tai hankintaehdotus saa järjestelmässä juoksevan ExtOrderNumber:n tai 

ExtRequisitionNumber:n. Hankintaehdotukset tulevat sisään järjestelmään otsikolla: 

ReversePurchaseRequistion ja tilaukset nimellä: ReversePurchaseOrder. Riippuen 

nimestä, luo järjestelmä näille juoksevan ulkoisen hankintaehdotusnumeron 

(ExtRequisitionNumber) tai ulkoisen ostotilausnumero (ExtOrderNumber). Jos otsikkona 

on ReverseRequisitionNumber ei tälle hankintaehdotukselle synny ExtOrderNumber:ia, 

joka tarkoittaa prosessissa sitä, että se pysähtyy keskitettylle ostolle prosessin Condition 

säännön mukaan. [WorkflowRequisition.ExtOrderNumber] = NULL. Aina kun 

sisäänluvussa järjestelmä ei luo ulkoista ostotilausnumeroa, oletetaan sen olevan 

käänteinen hankintaehdotus, joka jää keskistetylle ostolle tarkistettavaksi. Samoin 

Review - tehtävästä FinalApprove - tehtävään mennään saman säännön mukaisesti. 

Koska Review – tehtävään ei mennä koskaan, lähtee käänteinen hankintaehdotus 

keskitetyltä ostolta aina hyväksyntään. Ulkoista ostotilausnumeroa ei voida manuaalisesti 

syöttää hankintaehdotukselle, jonka takia sen prosessia ei voida enää muuttaa, kun 

hankintaehdotus on tullut toimittajalta sisään järjestelmään. Kun käänteinen ostotilaus 

tulee sisään otsikolla ReversePurchaseOrder, saa se järjestelmältä juoksevan ulkoisen 

ostotilausnumeron, jonka vuoksi ehto [WorkflowRequisition.ExtOrderNumber]=NULL 

ei päde siihen ja se menee suoraan prosessissa OrderConfirmation:sta CreateOrder 

tehtävää, joka on tehty automaattiseksi. Tällöin ulkoisille ostotilauksille ei tarvitse tehdä 

muutakuin vastaanottokuittaus, kun tuote tai palvelu on vastaanotettu. 

Automaattiseen - ja manuaaliseen vastaanottoon tehtiin sisäänlukuun logiikka, joka 

tarkistaa ostotilauksen summasta, voidaanko se merkitä heti vastaanotetuksi kun ulkoinen 

ostotilaus on tullut järjestelmään. Jos ulkoisen ostotilauksen summa on alle 500€, saa 

ostotilausdata tyhjään NUM_5 kenttään arvon 1, joka tarkoittaa että ostotilauksen tila 

muuttuu tilatusta vastaanotettuun. Tällä tavoin pienten tavaroiden vastaanottoa ei tarvitse 

kenenkään manuaalisesti enään tehdä. Tämä logiikka rakennettiin sen vuoksi, koska alle 

500€ ostotilauksista saapuu toimittajilta nopeammin laskut kuin suurista ostotilauksista. 

Jotta lasku voidaan automaattisesti täsmätä järjestelmän luomaan ostotilaukseen, tulee 

tavara tai palvelu olla vastaanotettu kokonaan. Kun tavara tai palvelu on vastaanotettu 

kokonaan, voidaan laskua täsmätä ostotilaukseen, jolloin lasku siirtyy järjestelmässä 



51 
 

automaattisesti automaattiseen täsmäytykseen, jossa laskulla olevaa ostotilausnumeroa 

verrataan järjestelmässä olevaan ostotilaukseen, jonka jälkeen lasku saa tiliöintinsä 

ostotilaukselta ja se voidaan suoraan laittaa valmiiksi odottamaan siirtoa kirjanpitoon. 

Tämä automaattinen täsmäytys rakennettiin laskujenhallinnan puolelle tukemaan 

hankinnan puolella tehtäviä ostotilauksia. Jokainen lasku, jolta luetaan ostotilausnumero 

ja se voidaan löytää hankinnan puolelta tehtyyn ostoon, voidaan automaattisesti täsmätä, 

jolloin kenenkään käyttäjän ei tarvitse ottaa kantaa laskun tarkastukseen.  

4.3. Kenttätietojen automatiikka Yritys X 

Yritys X:n otsikkotason laskun otsikkotason kentät määräytyvät seuraavanlaiseksi. 

 

Kuva 17. Yritys X:n otsikkotason tiedot laskujenhallinnassa. 

Otsikkotason kentillä tarkoitetaan tässä laskulta luettavaa otsikkotason tietoja, kuten 

toimittaja, laskun numero, mahdollinen ostotilausnumero, burottsumma, veron määrä, 

nettosumma, viitenumero, laskun päivämäärä, laskun eräpäivä, maksuehto jne.  



52 
 

Yritys X:n tapauksessa automatiikkaa rakennettiin laskun sisäänlukuun, jolla tunnistetaan 

kaikki laskun otsikkotasolla olevat tiedot ja viedään laskusanoman elementtien sisällä 

olevat arvot suoraan kuvan 17 osoittamiin kenttiin. Tämä tarkoitti tässä uudessa 

prosessissa sitä, että normaalin ostoreskontran henkilön ei tarvitse enään laskun kuvalta 

manuaalisesti asettaa laskun kuvalla olevia arvoja otsikkotason kenttiin, vaan laskun 

sisäänluvun logiikka rakennettiin siten, että arvot päivittyvät suoraan otsikkotason 

kenttiin. 

Sisäänluku logiikka rakennettiin perustumaan laskusanomassa oleviin elementtien  

nimiin ja niitä verratiin ohjelmiston kenttien objektien nimiin. Tämä logiikka rakennettiin 

kohdistumaan kaikkiin otsikkotason kenttiin. Jokaiselle kentälle tehtiin oma niin sanottu 

”haistelija”, joka etsii laskusanomalta oikeita arvoja oikeista paikoista ja löytäessään 

arvot, asettaa se arvot omille määritellyille kentille. 

Yhtenä automatiikan ongelma havaittiin tässä laskun sisäänluvussa toimittajien tuottamat 

laskusanomat. Jos laskusanomassa olevat arvot olivat asetettu vääriin ryhmiin, ei arvoja 

pystytty etsimään. Tässä koodissa pystyttiin etsimään vain tietyn xml – ryhmän sisällä 

olevaa tietoa. Toisin sanoen, jos toimittaja, jolta lasku saatiin, oli merkinnyt laskun 

numeron esimerkiksi arvolisäverotunnisteeseen (VAT – number), ei laskun numeroa 

voida tuoda laskun numero - kenttään, sillä laskun numero sijaitsi tässä tapauksessa 

väärässä elementissä. Tälläisissä tapauksissa, jossa toimittaja lähettää niin sanottua 

viallista dataa, on tehtävä ilmoitus toimittajalle, jolloin heidän on korjattava oma 

laskudatansa siihen muotoon, että tämä ohjelmisto löytää aina arvot oikeista elementeistä. 

Yritys X:llä on myös mahdollisuus tilata tuotteita tai palveluita muilta toimittajilta, joten 

kilpailutus tuli tässä ottaa myös huomioon. Toimittajat pitävät Yritys X:ää heidän  

asiakkaanaan ja jos Yritys X vetäytyisi heidän tilauslistoiltaan pois, heijastuisi se 

toimittajan myynnissä. 

 



53 
 

4.4. Yritys X:n laskujenhallinan prosessin rakentaminen 

Tutkimuksessa prosessien rakentaminen oli pääosassa. Millainen prosessi ajaisi Yritys 

X:n liiketoiminnan kannalta parhaiten asiansa? Prosessia rakentaessa piti tiedostaa 

asiakkaan tarpeet, mitkä olivat tulleet esille projektimäärittelyissä. Automatiikkaa oli 

rakennettava mahdollisimman paljon. 

Prosessia muutettiin projektin aikana kolme kertaa, mutta prosessin runko pysyi samana. 

Muutokset prosesseissa koskivat pieniä lisäyksiä automatiikan parantamiseksi. 

Prosessin perusrakenteen jälkeen tutkiminen keskitettiin automaatioasteen nostamiseen. 

Tärkeimmät automatiikan kannalta olevat tehtävät olivat Automaattinen täsmäytys, 

conditionien määrittäminen, viitehenkilön etsiminen, Automaatinen laskujen siirto 

kirjanpitoon ja Maksusuunnitelmatäsmäytys. 

4.5. Automaattinen täsmäytys 

Automaattisella täsmäytyksellä tarkoitetaan menetelmää, jossa ohjelmistoon sisään tullut 

lasku täsmäytetään ostotilaukseen. Tämä tarkoittaa sitä, että laskulta on löydyttävä 

ostotilausnumero ja tämä ostotilausnumero pitää olla validi. Ohjelmisto etsii 

tietokannasta laskulla olevaa ostotilausnumeroa ja vertaa laskulla olevaa dataa, kuten 

esimerkiksi bruttosummaa, nettosummaa, kustannuspaikkaa, toimitusaikaa ja yhtiötä 

ostotilauksen dataan. Jos datat ovat samanlaiset, täsmäytetään lasku ostotilaukseen, eli 

tällöin lasku saa tiliöintirivit suoraan ostotilaukselta ja lasku voidaan siirtää kirjanpitoon 

ilman kenenkään ostoreskontran manuaalista käsittelyä. 

Yritys X:lle tehtiin useampia täsmäytyskategorioita. Tutkimuksessa havaittiin, että jos 

täsmäytyskategorioita tehdään liian vähän, on suurempi mahdollisuus, että laskut eivät 

täsmäydy kategorioihin tai että virheelliset laskut täsmätään väärin ostotilauksiin. 

Molemmat kuvatut skenaariot aiheuttaisivat manuaalista työtä ostoreskontralle, kuten 

myös laskujen tarkastajille ja hyväksyjille. 

Paras ratkaisu oli tehdä useampia täsmäytyskategorioita. Täsmäytyskategoriat jaettiin 

viiteen erilaiseen kategoriaan. Ensimmäiseen kategoriaan ohjattiin kaikilta yhtiöiltä 



54 
 

sellaiset toimittajat, jotka toimittavat suuria määriä tuotteita ja palveluita, mutta laskut 

eivät ole suuria. Tällöin jos laskun summa heittää alle 2 prosenttia ostotilauksen 

summasta, ohjataan tämän toimittajan toimittama lasku ensimmäiseen kategoriaan. 

Kategoriat 50, 100 ja 200 euron absoluuttiset toleranssit ovat kategorioita, jotka kytkettiin 

kaikille muille toimittajille. Tämä tarkoitti sitä, että kaikki laskut, joiden summa heittää 

50, 100 tai 200 euroa ostotilauksen summasta, ohjautuvat näihin kategorioihin. 

Ostotilaukset 0,05 euron kategoria tehtiin niille toimittajille, joilta tilataan paljon kalliita 

tuotteita ja palveluita. Tällöin näiden toimittajien laskut ohjautuvat tähän kategoriaan. 

Kategorioita tehtiin useampi, jotta ensimmäisen vuoden päästä pystytään näkemään 

toimittajakohtaisia tuloksia, mihin kategorioihin heidän laskut ovat täsmäytyneet. 

Kategorioista tehtiin myös helposti muokattavia. Toisin sanoen, jos jatkossa halutaan 

muuttaa joidenkin toimittajien laskujen siirtoa toiseen kategoriaan, tehtiin 

täsmäytyskategoriaan toimittajalistaus, josta voidaan kytkeä toimittaja aktiiviseksi 

itsenäisesti. Tämä tarkoittaa sitä että sovelluskonsultin työvarausta ei tarvita, ja asiakas 

pystyy helposti itse hallinnoimaan täsmäytyskategorioita. Laskun lähetys automaattiseen 

täsmäytykseen tapahtuu seuraavasti. Lasku menee validoinnista pre-matching tehtävään, 

johonon koodattu condition eli sääntö: Jos laskun tila on valid, ja tilausnumerokentässä 

oleva arvo on erisuuri kuin tyhjä tai ei ole nolla, mennää tähän tehtävään silloin. Tämä 

tarkoittaa sitä, että jos laskun status on 3, eli lasku on validi eikä siinä ole mitään 

virheellistä dataa (esimerkiksi väärä toimittaja, laskun numero on sama kuin jossain 

aikasemmassa laskussa tai jokin pakollinen kenttä on tyhjä) niin lasku jatkaa seuraavaan 

sääntöön, jossa katsotaan että laskun otsikolla ostotilausnumero ei saa olla nolla tai tyhjä. 

Jos nämä ehdot täyttyvät, lasku menee pre-match - tehtävään, josta se menee 

automatchingiin ja automatchingissä sille yritetään löytää jokin taulukosta 2 löytyvästä 

täsmäytyskategorioista. 

 



55 
 

 

 

Kuva 18. Ostotilausnumero - kenttä automaattisessa täsmäytyksessä 

Taulukko 2. Täsmäytyskategoriat 

Nimi Kuvaus 

Invoice Automation – Ostotilaukset (2% 

prosenttia) 

 

Ostotilaukset summa yli 0€, mutta hintaero 

saa olla 2% prosenttia kokonaissummasta 

 

Invoice Automation - Ostotilaukset(50 eur 

absoluuttinen) 

 

Ostotilaukset joiden hintaero saa olla 50€ 

 

Invoice Automation – Ostotilaukset (100 eur 

absoluuttinen) 

 

Ostotilaukset joiden hintaero saa olla 100€ 

 

Invoice Automation - Ostotilaukset(0,05 eur 

absoluuttinen) 

 

Ostotilaukset joissa hintaeroa saa olla 0,05€ 

 

Invoice Automation – Ostotilaukset (200 eur 

absoluuttinen) 

 

Ostotilaukset joiden hintaero saa olla 200€ 

 

 



56 
 

4.6. Maksusuunnitelman täsmäytys 

Toinen tärkeä automaation kannalta oleva elementti oli maksusuunnitelman täsmäytys 

(PayPlan Matching). Maksusuunnitelman täsmäytys rakennettiin hyvin samankaltaisesti 

kuin automaattinen täsmäytys. Suurin ero automaattiseen täsmäytykseen oli, että 

maksusuunnitelman täsmätyksessä tehtiin vain yksi kategoria, johon kaikki laskut 

yritetään täsmäyttää. 

Maksusuunnitelmassa käytettiin kenttää nimeltä ”maksusuunnitelman viite”, kun 

automaattisessa täsmäytyksessä etsittiin ostotilauksen numeroa ostotilausnumero - 

kentästä. 

Laskun sisäänluvussa etsittiin <PaymentPlan_Reference></PaymentPlan_Reference> 

elementin sisältä maksusuunnitelman numeroa tai nimeä. Jos tämä löytyi, ohjattiin lasku 

sitä vastaavaan maksusuunnitelmaan. Maksusuunnitelmia voitiin luoda niin paljon kuin 

mahdollista, mutta vain yksi maksusuunnitelmakategoria voitiin luoda. Kategorian 

säännöt olivat, että laskun yhtiötunnuksen, maksusuunnitelmanviitteen ja toimittajan on 

oltava samat, jotta laskua voidaan edes yrittää täsmäyttää maksusuunnitelmaan. Jos 

maksusuunnitelma löytyi ja vaaditut säännöt täyttyvät, menee lasku tällöin prosessissa 

automaattisesti maksusuunnitelman täsmäytykseen ilman yhtäkään manuaalista 

kosketusta.  

Tälläisellä säännöllä tarkastellaan taas, että laskun statuksen on oltava validi ja että 

maksusuunnitelmanviite (PaymenPlanReference) kenttä ei saa olla nolla tai tyhjä. Jos 

tämä sääntö pätee, lasku jatkaa matkaansa automaattisesti maksusuunnitelman 

täsmäytykseen. 

 

 



57 
 

Kuva 19. Maksusuunnitelman viite - kenttä maksusuunnitelman täsmäytyksessä 

4.7. Viitehenkilön etsiminen 

Viitehenkilön automaattisella etsimisellä pyrittiin rajaamaan ostoreskontran toimintojen 

määrää. Ilman automatiikkaa, joutusi ostoreskontra etsimään oikean henkilön laskulle 

sisäisesti tai lähettämään laskun tarkastettavaksi henkilölle, jonka hän luulisi olevan oikea 

henkilö tarkastamaan laskun. Tämä johti esimerkkitapauksissa tilanteisiin, joissa 

tarkastajakaan ei tiennyt, kenelle lasku kuului. Laskun historiasta nähtiin, kuinka laskua 

kierrätettiin henkilöltä toiselle ja täten laskun maksuaika väheni huomattavasti. 

Viitehenkilön etsimiseen tutkimuksessa jouduttiin ”rikastamaan” kaikkia organisaation 

datoja, joilla pystyttiin viittaamaan henkilöön. Esimerkiksi työnumerot, kustannuspaikat, 

projektit, esimiehet ja toimittajadataan lisättiin aina joku oikea henkilö, jolla on eniten 

tietoa kyseisestä laskusta. Alla on kuvattu viitehenkilön etsimisen prosessi. 

 

 

Kuva 20. Viitehenkilön etsiminen 



58 
 

Koskaan ei tässä automaatiikassa tule tilannetta, että lasku pysähtyisi ostoreskontralle, 

vaan lasku lähtisi automaattisesti oikealle henkilölle, joka pystyisi tarkastamaan ja 

hyväksymään laskun. Tällä tavalla manuaaliset toimenpiteet ja henkilöstömäärä 

ostoreskontrassa pystyttiin vähentämään. Kaikki masterdata, eli kustannuspaikka-, tili-, 

tilaus-, työnumero-, projekti-, toimittaja- ja henkilöstötiedot tallennettiin eri tauluihin 

tietokantaan, joihin lisättiin henkilö, joka on vastuussa laskuista, jotka tulevat esimerkiksi 

tietyllä työnumerolla, kustannuspaikalla tai projektitunnuksella. Logiikka sille, kuinka 

XML-pohjaiseen koodiin lisättiin SQL-kielinen kysely, jolla etsittiin taulusta 

EXT_INV_LIST_20 text_3 kentästä olevaa arvoa ja verrattiin sitä arvoa laskujen 

sisäänluvussa olevaan arvoon ja katsottiin, onko text_1 kentässä oleva arvo samalla rivillä 

taulussa kuin laskudatassa ja text_3 kentässä. Jos tämä on tosi, otetaan taulusta 

EXT_INV_LIST_20 taulusta text_3 kentässä oleva arvo ja syötetään se laskun 

otsikkotiedolle viitehenkilö-kenttään (ReferencePerson). Tällä tavalla automaattisesti 

etsitään tietoa, ilman että kukaan henkilö joutuisi arvuuttelemaan, kenelle lasku kuuluu. 

4.8. Automaattinen laskujen siirto kirjanpitoon 

Yritys X:n automatiikan aste hankinta - ja laskujenhallinnan ohjelmassa tehtiin korkeaksi. 

Mitä pidemmälle projekti eteni, huomasimme että laskut, jotka ovat täsmäytyneet 

ostotilauksiin täsmäytyskategorioissa, maksusuunnitelmissa tai ovat tulleet 

hyväksynnästä läpi ostoreskontralle, odottavat vielä manuaalista siirtoa kirjanpitoon. 

Laskuilla, jotka ovat käyneet koodilla rakennetun täsmäytyksen lävitse, ei virheitä pitäisi 

syntyä. Samoin jos normaali kululasku on käynyt läpi tarkastajan ja hyväksyjän, pitäisi 

laskun olla valmis siirrettäväksi kirjanpitoon. Tämän vuoksi ehdotimme Yritys X:lle, jos 

rakentaisimme prosessiin uuden tehtävän, joka siirtäisi automaattisesti laskut 

kirjanpitoon, ilman että kenenkään ostoreskontrasta pitäisi tarkastaa enää laskua. 

Säännöiksi Yritys X:lle tehtiin seuraavat: 

 

 

• Veron summan pitää olla sama laskun otsikkotiedoilla ja tiliöintitiedoilla 



59 
 

• Nettosumman pitää olla sama laskun otsikkotiedoilla ja tiliöintitiedoilla 

• Bruttosumman pitää olla sama laskun otsikkotiedoilla ja tiliöintitiedoilla 

• Tiliöinnissä Hankintakategorian takana oleva ALV-koodi tulee olla sama kuin 

mitä ollaan tiliöinnissä käytetty. Eli jos Hankintakategorian 10001003 takana on 

oletuksena annettu ALV-koodi 24 ja tiliöinnissä ollaan muutettu ALV-koodi 

joksikin muuksi, ei laskua voida automaattisesti siirtää ellei se jokin muu ALV-

koodi oli R0, joka on käänteinen ALV-koodi. 

 

Näiden sääntöjen lisäksi loimme asiakkaalle pääsyn tiettyyn kantatauluun, jossa 

automaattisiirto voidaan laittaa päälle ja pois päältä. AutomaticTransferONOFF saa arvon 

1, jos automaattisiirto on päällä ja arvon 0, jos automaattisiirto on otettu pois päältä. 

Samoin jos säännöt täsmäävät laskuun, saa lasku arvon 1 jolloin se siirtyy automaattisesti 

kirjanpitoon ja arvon 0, jos jokin säännöistä antaa virheen. Tällä toimintatavalla saatiin 

toimitettua laskuja automaattisesti kirjanpitoon, ilman että se veisi resursseja 

ostoreskontralta laskujen manuaalisessa siirrossa. 

4.9. Hankinnan automatisointi Yritys Y 

Yritys Y:n hankinnan prosessi perustui Yritys X:n kaltaisesti alhaiseen automatisaation 

tasoon. Yritys X:n projekti saatiin melkein päätöksiin, kun Yritys Y:n projekti alkoi. 

Koska yri