Joonas Jokinen Toiminnanohjausjärjestelmien kehittämisen kriittiset menestystekijät teollisuudessa Vaasa 2023 Tekniikan ja innovaatiojohtamisen yksikkö Pro Gradu -tutkielma Tietojärjestelmätieteen koulutusohjelma 2 VAASAN YLIOPISTO Tekniikan ja innovaatiojohtamisen yksikkö Tekijä: Joonas Jokinen Tutkielman nimi: Toiminnanohjausjärjestelmien kehittämisen kriittiset menestystekijät teollisuudessa Tutkinto: Kauppatieteiden maisteri Oppiaine: Tietojärjestelmätiede Työn ohjaaja: Tero Vartiainen Valmistumisvuosi: 2023 Sivumäärä: 73 TIIVISTELMÄ: Toiminnanohjausjärjestelmät ovat usean yrityksen selkäranka nykypäivänä. Monet yritykset ja organisaatiot ovat riippuvaisia niistä ja hakevat kaupallista kilpailukykyä näiden järjestelmien avulla. Toiminnanohjausjärjestelmien erilaisten käyttötarkoituksien vuoksi valmiita järjestelmiä ei käytännössä ole aina saatavilla ”pakettiratkaisuina”, vaan järjestelmät joudutaan suunnittelemaan ja kehittämään käyttötarkoituksensa mukaisesti. Monia toimintoja kattavan järjestelmän ohjelmistokehitys on tyypillisesti huomattava prosessi, joka vaatii paljon aikaa ja muita resursseja. Tästä syystä kehitykselle kriittisten osa-alueiden, eli menestystekijöiden, tunnistaminen etukäteen on erittäin tärkeää. Tässä tutkimuksessa tarkasteltiin, miten toiminnanohjausjärjestelmän kehityksen kriittiset menestystekijät vaikuttavat kehitysprojektiin järjestelmän tilaavan ja vastaanottavan teollisuusyrityksen näkökulmasta. Tavoitteena oli tutkia kohdeyrityksen näkemyksiä kehitysprojektista sen elinkaaren jokaisen vaiheen kohdalla, lukuun ottamatta ylläpitoa ja jatkokehitystä, ja yhdistää nämä näkökulmat aikaisemmassa tutkimuksessa laadittuun viitekehykseen toiminnanohjausjärjestelmien kehitysprojektien menestystekijöistä valmistavan teollisuuden toimialoilla. Tutkimus toteutettiin case-tutkimuksena, eli tapaustutkimuksena, ja tutkimusmateriaalin keräämisessä hyödynnettiin teemahaastatteluja. Tutkimuksessa analysoitiin kansainvälisillä markkinoilla toimivaa suomalaista tevanake- teollisuuden yritystä. Yritys työllistää noin 500 työntekijää ja sillä on kaksi tuotantolaitosta, jotka molemmat sijaitsevat Suomessa. Yritys on juuri uusinut toiminnanohjausjärjestelmänsä, jonka kehitysprojekti on tämän tutkimuksen kohteena. Koska kehitysprojekti on ulkoistettu, tutkimuksessa käsitellään vain projektin asiakasroolissa toimivaa yritystä, eikä järjestelmän kehittävän osapuolen näkemyksiä tuoda esille. Tutkimuksessa havaittiin miten toiminnanohjausjärjestelmän vastaanottavan yrityksen henkilöstön asenteet ja näkökulmat vaikuttivat järjestelmän kehitykseen. Suuri osa käytetyn viitekehyksen menestystekijöistä identifioitiin tarkastellusta kehitysprojektista, minkä lisäksi projektista tunnistettiin kaksi uutta viitekehyksen ulkopuolista menestystekijää. Tutkimuksen tuloksia voidaan hyödyntää vastaavien toiminnanohjausjärjestelmien kehityksessä kriittisen osa-alueiden tunnistamisessa ja ennakoimisessa. AVAINSANAT: toiminnanohjausjärjestelmät, ohjelmistokehitys, kriittiset menestystekijät, teollisuus, tapaustutkimus 3 Sisällys 1 Johdanto 6 1.1 Tutkimuksen tavoite 7 1.2 Tutkimusmenetelmä 7 1.3 Tutkimuksen kohde 8 1.4 Tutkielman rakenne 9 2 Kirjallisuuskatsaus 10 2.1 Ohjelmistokehitys 10 2.1.1 Ohjelmistojen elinkaari 10 2.1.2 Projektinhallinta laajamittaisissa ohjelmistoprojekteissa 13 2.1.3 Kriittiset menestystekijät 16 2.2 Toiminnanohjausjärjestelmät 17 2.2.1 Toiminnalliset alueet 17 2.2.2 Käyttötarkoitukset 18 2.3 Toiminnanohjausjärjestelmien kehittämisen menestystekijät 19 2.3.1 Organisatoriset menestystekijät 22 2.3.2 Tekniset menestystekijät 30 2.3.3 Projektin menestystekijät 33 3 Tutkimussuunnitelma 36 3.1 Tutkimusongelma 36 3.2 Tutkimuksen toteutus 37 3.3 Kohdeyrityksen käsittely 38 4 Tutkimustulokset 39 4.1 Tutkimusmateriaalin keräys ja käsittely 39 4.2 Projektin menestystekijät 41 4.2.1 Projektin alkuvaiheet 41 4.2.2 ERP-järjestelmän toteutus 44 4.2.3 Projektin lopetus ja järjestelmän käyttöönotto 50 4.2.4 Monivaiheiset menestystekijät 51 4 4.3 Päivitetty viitekehys 54 5 Diskussio 58 5.1 Tulokset ja johtopäätökset 58 5.2 Rajoitteet ja tutkimuksen arviointi 59 5.3 Jatkotutkimusaiheet 60 Lähteet 62 Liitteet 68 Liite 1. Haastattelun kysymykset 68 Liite 2. Saatekirje kohdeyritykselle 73 5 Kuvat Kuva 1. Tietojärjestelmän elinkaari (mukaillen Haikala & Mikkonen, 2011, s. 30–31). 11 Kuva 2. Ketterä kehitys ja vesiputousmalli (mukaillen Escott, 2017). 14 Kuva 3. Toiminnanohjausjärjestelmän toimintoja (mukaillen Ippolito, 2021). 19 Taulukot Taulukko 1. Kriittisten menestystekijöiden viitekehys (mukaillen Jokinen, 2021). 20 Taulukko 2. Päivitetty kriittisten menestystekijöiden viitekehys. 54 Lyhenteet ERP Yrityksen toiminnanohjaus ja/tai siihen liittyvä järjestelmä (Enterprise Resource Planning) HR Henkilöstöhallinta (Human Resources) IBM Teknologiayritys (International Business Machines Corporation) IT Informaatiotietotekniikka (Information Technology) MS Teknologiayritys (Microsoft Corporation) SAP Toiminnanohjausjärjestelmiä valmistava teknologiayritys Tevanake Tekstiilien, vaatteiden, nahkatuotteiden ja kenkien valmistus UX Käyttäjäkokemus (User Experience) 6 1 Johdanto Yrityksen toimintojen hallinta voidaan toteuttaa monella eri tapaa. Lähestymistapa voidaan valita yrityksen harjoittaman toiminnan, tarkoituksen, koon ja saatavilla olevien mahdollisuuksien mukaan. Useassa organisaatiossa yritystoimintaa hallitaan vain muutaman avainhenkilön toimesta, esimerkiksi pienessä mainostoimistossa työtehtävät ja prosessit määräytyvät toimitusjohtajan ja hänen tiiminsä mukaan. Tämä lähestymistapa ei kuitenkaan toimi vaikkapa suuressa teollisuusyrityksessä. Tällaisessa tilanteessa yrityksellä on monia sisäisiä ja ulkoisia toimintoja sekä sidosryhmiä, joiden ohjaaminen on mahdotonta ilman täsmällisiä työrooleja ja rakenteellisia apuvälineitä. Tästä syystä isoilla yrityksillä on apuna monenlaisia ohjelmistoja ja järjestelmiä. (Greasley, 2007, s. 3–4; Kumar & Suresh, 2009, s. 53) Toiminnanohjausjärjestelmät, tai ERP-järjestelmät (enterprise resource planning, ERP), ovat usean teollisuusyrityksen työvälineenä yrityksen toimintojen hallinnassa. Nykypäivän toiminnanohjausjärjestelmiä käytetään muun muassa teknisten toimintojen, resurssien, inhimillisten tekijöiden ja taloudellisten prosessien ohjaamisessa sekä kaupallisen kilpailukyvyn hakemisessa (Jacobs & Weston, 2007). Päätarkoituksena toiminnanohjausjärjestelmillä on integroida yrityksen osastot yhteen helpommin hallittavaan kokonaisuuteen (Shehab ja muut, 2004). Tämän kokonaisuuden avulla yhdellä järjestelmällä voidaan hallita esimerkiksi asiakkaan ostotilaus, tilauksen tuotteiden valmistus ja varastointi, sekä lopullinen toimitus. Kyseinen lähestymistapa yksinkertaistaa ja yhtenäistää monia yrityksen tärkeitä prosesseja. Toiminnanohjausjärjestelmien monimuotoisten käyttötarkoituksien vuoksi kyseisiä järjestelmiä ei kuitenkaan ole aina saatavilla ”pakettiratkaisuna”, vaikka markkinoilla onkin toiminnassa monia yrityksiä, jotka tarjoavat erilaisia ratkaisuja toiminnanohjausjärjestelmien kehittämiseen ja integroimiseen yritystoimintaan (GrandViewResearch, 2021). ERP-järjestelmät joudutaankin usein kehittämään ja suunnittelemaan käyttötarkoituksensa mukaisesti. Tämä kehitystyö on tyypillisesti merkittävä ja resursseja kuluttava projekti, jonka epäonnistumisella voi olla huomattavat 7 vaikutukset yritystoimintaan (Zeng & Skibniewski, 2013). Tästä syystä kehitystyölle tärkeiden osa-alueiden eli kriittisten menestystekijöiden (critical success factors, CSFs) tunnistaminen ennen kehitysprojektin alkua ja sen aikana on erittäin tärkeää. 1.1 Tutkimuksen tavoite Tutkimuksen tarkoituksena on tutkia, miten toiminnanohjausjärjestelmän kehityksen kriittiset menestystekijät vaikuttavat kehitysprojektiin tilanteessa, jossa järjestelmän kehitys on ulkoistettu. Tutkimuksessa käytetään pohjana aiemmassa tutkimuksessa laadittua viitekehystä ERP-järjestelmien kehityksen menestystekijöistä teollisuudessa. Viitekehyksessä on yhteensä 30 erilaista kriittistä menestystekijää, jotka on jaoteltu kolmeen osa-alueeseen: organisaatio, tekniikka ja projekti. Tavoitteena on tutkia kohdeyrityksen, eli toiminnanohjausjärjestelmän tilaavan yrityksen, näkemyksiä kehitysprojektista sen elinkaaren jokaisen vaiheen kohdalla, lukuun ottamatta ylläpitoa ja jatkokehitystä, ja yhdistää nämä näkökulmat aikaisemmassa tutkimuksessa laadittuun viitekehykseen. Tutkimuskysymys on ”Millainen vaikutus toiminnanohjausjärjestelmien kehityksen kriittisillä menetystekijöillä on kehitysprojektiin järjestelmän tilaavan ja vastaanottavan teollisuusyrityksen näkökulmasta?”. Tutkimuksessa on tarkoituksena laajentaa hyödynnettyä viitekehystä tarkastellusta kehitysprojektista löydettävillä havainnoilla. 1.2 Tutkimusmenetelmä Tutkimusstrategiana on kuvaileva case-tutkimus eli tapaustutkimus (case study). Tällä ratkaistaan kaksi ongelmaa. Ensinnäkin, toiminnanohjausjärjestelmiä tilaavia yrityksiä on erittäin vaikea löytää, sillä näiden järjestelmien elinaika on alkujaankin suunniteltu kestämään pitkään, jolloin näitä kehitysprojekteja toteutetaan vähissä määrin. Eri ERP- järjestelmien valmistajien mukaan toiminnanohjausjärjestelmien ikä voi vaihdella 5–12 8 vuoden välillä ja jotkut järjestelmät ovat käytössä jopa 20 vuoden jälkeen niiden käyttöönotosta (Rootstock Software, 2019; SpiceWorks, 2016; Trek Global, 2014). Samalla kaikki yritykset eivät näe tarpeellisena ”mainostaa” muutoksia sisäisiin järjestelmiinsä, mikä myös vaikeuttaa tutkimuskohteiden löytämistä. Näin ollen tutkimusmateriaalin kerääminen monelta eri toimijalta olisi erittäin hankalaa ja aikaa vievää, minkä seurauksena rakentavampi lähestymistapa on kvalitatiivinen. Toiseksi, case-tutkimus mahdollistaa perusteellisen ja kattavan kokonaisnäkemyksen rakentamisen aiheesta (Rashid ja muut, 2019; Schell, 1992). Näin tutkimuksessa voidaan keskittyä erityisesti kehitystyöhön vaikuttaviin inhimillisiin tekijöihin ja näkemyksiin. Tutkimusmenetelmänä hyödynnetään teemahaastattelua (semi-structured interview). Tämänkaltaiset haastattelut eivät etene suoraan tarkkoja ja yksityiskohtaisia kysymyksiä seuraten, vaan kysymykset ovat vapaampia ja kohdentuvat tiettyyn teemaan, kuten toiminnanohjausjärjestelmien menestystekijöihin (Saaranen-Kauppinen & Puusniekka, 2006). Haastattelut on toteutettu kahdessa kierroksessa, jotka molemmat on suoritettu jokaisen haastatellun henkilön kohdalla yhden haastattelukerran aikana. Ensimmäisessä kierroksessa yrityksen avainhenkilöitä on haastateltu vapaasti kehitysprojektin kulusta ja heidän näkemyksistään sen etenemisestä. Toisessa kierroksessa haastattelut on toteutettu viitekehystä seuraamalla. Aineiston keräämisen ja analysoinnin jälkeen tunnistetut kriittiset menestystekijät on yhdistetty hyödynnettyyn viitekehykseen. 1.3 Tutkimuksen kohde Tutkimuksessa analysoidaan kansainvälisillä markkinoilla toimivaa suomalaista tevanake-teollisuuden yritystä (tekstiilien, vaatteiden, nahkatuotteiden ja kenkien valmistus). Sen nimeä ei tässä tutkimuksessa esitetä, sillä yritys on pyytänyt pysyä nimettömänä. Yrityksen liikevaihto oli vuonna 2021 noin 190 miljoonaa euroa, josta viennin osuus on 50 %. Yrityksen vienti kohdistuu yli 40 eri maahan, mutta sijoittuu pääasiallisesti Eurooppaan. Yritys työllistää noin 500 työntekijää ja pohjautuu kahteen tuotantolaitokseen, jotka molemmat sijaitsevat Suomessa. 9 Yrityksellä on useita myyntitoimistoja ympäri Eurooppaa, muun muassa Saksassa, Ruotsissa, Tanskassa ja Iso-Britanniassa. Yrityksen nykyinen kehitysprojekti on korvata vanha IBM AS/400 -toiminnanohjausjärjestelmä modernimmalla ja helpommin ylläpidettävällä järjestelmällä. Koska tämä uusi järjestelmä on käyttötarkoitukseltaan erittäin spesifinen ja koska sen ohjelmointikieli on eri kuin vanhassa järjestelmässä, on uusi järjestelmä rakennettava alusta alkaen. Tutkielman kirjoittamisen aikana projekti on edennyt uuden järjestelmän käyttöönottoon. 1.4 Tutkielman rakenne Tutkielma aloitetaan kirjallisuuskatsauksella kappaleessa 2. Tarkastelussa ovat ohjelmistokehityksen ja toiminnanohjausjärjestelmien erilaiset ominaisuudet ja muut tutkimukselle oleelliset yksityiskohdat. Käsittelyssä ovat muun muassa ohjelmistojen elinkaarivaiheet, kehitystyön kriittiset menestystekijät yleisestä näkökulmasta ja toiminnanohjausjärjestelmien monimuotoiset käyttötarkoitukset. Katsauksen painopisteenä ovat teollisuuteen tarkoitetut toiminnanohjausjärjestelmät. Näiden jälkeen kirjallisuuskatsauksessa esitellään vielä tutkimuksessa hyödynnetty viitekehys ja sen erilliset osa-alueet. Kirjallisuuskatsauksen jälkeen tutkielmassa tuodaan esille tutkimussuunnitelma kappaleessa 3. Kyseisessä osiossa otetaan tarkempaan käsittelyyn tutkimusongelma ja käytetty tutkimusmenetelmä, minkä lisäksi tutkimuksen varsinainen toteutus käydään läpi. Tutkimuksen tulokset ja niistä tehty analyysi esitellään kappaleessa 4. Tutkielma päättyy diskussioon tutkimuksen löydöistä ja rajoitteista kappaleessa 5. Tutkimukselle oleelliset liitteet löytyvät tutkielman lopusta; nämä sisältävät muun muassa haastatteluissa hyödynnetyt kysymykset. 10 2 Kirjallisuuskatsaus Kirjallisuuskatsauksessa käsittelyssä on ensimmäisenä ohjelmistokehitys. Tämän aiheen kohdalla pohditaan, miltä ohjelmiston normaali elinkaari näyttää ja miten laajamittaisia ohjelmistoprojekteja toteutetaan projektinhallinnan näkökulmasta. Tämän lisäksi katsauksessa käydään läpi kriittisten menestystekijöiden käsite yleismaailmallisesta perspektiivistä sekä ohjelmistokehityksen näkökulmasta. Tämän jälkeen tutkielmassa otetaan tarkasteluun toiminnanohjausjärjestelmät alakappaleessa 2.2. Kyseisestä aiheesta nostetaan esiin ERP-järjestelmien toiminnalliset alueet ja käyttötarkoitukset. Kirjallisuuskatsaus päättyy analyysiin tutkimuksessa hyödynnettävästä toiminnanohjausjärjestelmien kehittämisprojektien kriittisten menestystekijöiden viitekehyksestä. 2.1 Ohjelmistokehitys Ohjelmistokehitys, tai toiselta nimeltään ohjelmistotuotanto, on prosessi, jonka tarkoituksena on tuottaa sovelluksia, ohjelmia tai tietojärjestelmiä erilaisiin käyttötarkoituksiin (Haikala & Märijärvi, 2004, s. 16). Tämä ohjelmistojen tuotantoprosessi pitää sisällään muun muassa projektinhallintaa, määrittelyä, suunnittelua, toteutusta eli ohjelmointia, dokumentointia ja laadunvarmistusta sen muiden osa-alueiden ohella. Tässä alakappaleessa tarkastellaan, mitä työvaiheita sisältyy ohjelmistokehitykseen, miten ohjelmistoprojekteja toteutetaan ja mitä ovat kriittiset menestystekijät tässä kontekstissa. 2.1.1 Ohjelmistojen elinkaari Ohjelmistokehitykselle ominaisia työvaiheita, ja täten ohjelmistojen tai järjestelmien elinkaaren kehitysvaiheita, voidaan Haikalan ja Mikkosen (2011, s. 30–31) mukaan luokitella seitsemään vaiheeseen. Nämä vaiheet ovat: esitutkimus, määrittely, 11 suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito (ks. Kuva 1). Näiden lisäksi ohjelmistotuotannon elinkaareen (software development life cycle, SDLC) voidaan laskea mukaan myös järjestelmän jatkokehitys, joka kuitenkin yleensä nähdään osana kehitetyn järjestelmän ylläpitoa. Nämä kehitysvaiheet lasketaan osaksi jokaisen järjestelmän tavanomaista elinkaarta. Kuva 1. Tietojärjestelmän elinkaari (mukaillen Haikala & Mikkonen, 2011, s. 30–31). Toisaalta, Holcomben (2008, s. 4) mukaan ketterän kehityksen mallissa (agile software development) ohjelmisto on usein jatkuvassa kehityksessä ja siihen voidaan lisätä uusia toimintoja käyttäjien vaatimuksien mukaan. Tässä mielessä ohjelmisto ei olekaan ”koskaan” valmis käyttäjien vaatimusten kasvaessa, minkä seurauksena lineaarisen elinkaaren hahmottaminen ei ole kokonaan yksiselitteistä. Tästä huolimatta vastaavia työvaiheita Haikalan ja Mikkosen määritykseen verrattuna voidaan tunnistaa myös ketterän ohjelmistotuotannon menettelytavasta. Täten näiden vaiheiden tarkasteleminen ja niiden ymmärtäminen on tarkoituksenmukaista tutkimuksen tavoitteisiin nähden. Määritetyn elinkaaren vaiheissa kehitettävän ohjelmiston tai järjestelmän käyttötarkoituksen kartoittaminen ja vaatimusten huolellinen määrittely tapahtuu Haikalan ja Mikkosen (2011) mukaan kahdessa ensimmäisessä vaiheessa: 12 esitutkimuksessa ja määrittelyssä. Näissä askeleissa kartoitettuja ohjelmiston vaatimuksia tarkastellaan läheisemmin seuraavassa vaiheessa, jossa järjestelmä pyritään suunnittelemaan vastaamaan näitä määrityksiä. Näitä kolmea ensimmäistä askeletta voidaan mieltää ohjeiden kirjoittamiseksi tai kehitysstrategian muodostamiseksi myöhemmille vaiheille. Seuraavat kaksi vaihetta ovat toteutus ja testaus. Tällöin rakennettava järjestelmä ohjelmoidaan aiempien vaiheiden ohjeiden eli määrityksien avulla. Jotta järjestelmä voidaan ottaa myöhemmin käyttöön, on se myös testattava. Tässä vaiheessa yritetään tunnistaa mahdolliset virheet ohjelmistosta ja korjata ne ennen kuin järjestelmää aletaan käyttämään. Näiden vaiheiden jälkeen ohjelmistokehitysprojekti voidaan mieltää valmiiksi sen alkuperäiseen ja suunniteltuun käyttötarkoitukseen nähden. (Haikala & Mikkonen, 2011). Jokainen näistä ohjelmistokehityksen elinkaaren vaiheista sisältävää projektitoiminnan periaatteiden mukaan aloitus- ja lopetusajankohdat ja ne seuraavat toisiaan askel askeleelta (Haikala & Mikkonen, 2011). Kehityksessä voidaan toki hyödyntää iteratiivista lähestymistapaa kuten ketterää ohjelmistokehitystä varsinaisen vesiputousmallin sijaan, mutta ohjelmistoprojektin varsinaisten työvaiheiden tulisi pääasiallisesti seurata tätä elinkaarta. Esimerkiksi järjestelmän toteutus eli ohjelmointi ei käytännössä onnistu ilman sen käyttötarkoituksen määrittelyä ja toimintojen oleellista suunnittelua – uudelleenmäärittelyä voidaan toki myös tehdä projektin toteutuksen aikana ja ohjelmiston vaatimusten vaihtuessa. Ketterässä kehityksessä nämä vaiheet sisällytetäänkin kokonaisuudessaan tai osittain osaksi jokaista iteraatiota, jossa kehitetään yksi tai vain muutama järjestelmän toiminto ennen kuin uusi iteraatio aloitetaan (Holcombe, 2008, s. 2–5). Joka tapauksessa, tässä tutkimuksessa keskitytään Haikalan ja Mikkosen määrittämään ohjelmistojen elinkaaren ensimmäisiin kuuteen vaiheeseen ja ylläpidon sekä 13 jatkokehityksen tarkastelua ei täten toteuteta. Rajaus on tehty seuraamalla tutkimuksessa hyödynnettävän viitekehyksen kehittämisessä käytettyjä perusteluja: Rajaus on tehty siksi, koska nämä vaiheet voidaan käytännössä mieltää kaikkein tärkeimmiksi kehitysprojektin lopputuloksen eli toteutettavan toiminnanohjausjärjestelmän kannalta; ylläpidossa käytössä olevan järjestelmän muuntaminen toisenlaiseksi voi olla erittäin vaikeaa ja siksi järjestelmän kehittäminen tulisi olla perinpohjaista jo sen alkuvaiheilla. Tämän seurauksena tässä tutkimuksessa kiinnitetään huomiota vain kehitysprojektin alkuvaiheiden menestystekijöihin ja viimeinen vaiheista, ylläpito, jätetään täten tutkimuksesta pois. (Jokinen, 2021, s. 11) 2.1.2 Projektinhallinta laajamittaisissa ohjelmistoprojekteissa Monimutkaisten ja suurien ongelmien kohdalla on luontevaa jakaa alustava ongelma pienempiin ja paremmin hallittaviin osiin. Näin ongelmat eivät ole ylitsepääsemättömiä ja toteutettavat tehtävät ongelman ratkaisemiseksi ovat selvempiä. Projektinhallinnan näkökulmasta tämä ongelmien ratkaiseminen toteutetaan käytännössä projektin jakamisella työvaiheisiin ja näihin vaiheisiin kuuluviin tehtäviin, mikä on olennaista myös ohjelmistoprojektien kohdalla. Projektinhallinnassa näitä työvaiheita ovat: projektin aloitus, suunnittelu, toteutus, seuranta ja lopetus, jotka voidaan rinnastaa edellisessä kappaleessa käsiteltyihin järjestelmien elinkaarivaiheisiin. (Ahmed, 2011, s. 3–7). Yleisimpiä projektinhallinnan menetelmiä tai prosesseja, joita hyödynnetään ympäri maailmaa eri yrityksissä, ovat ketterän kehityksen mallit, kuten XP (extreme programming), kanban tai scrum, sekä vesiputousmalli. Vuonna 2019 tehdyn projektinhallinnan parissa työskenteleville suunnatun kyselyn mukaan ketterä kehitys on suosituin projektinhallintamenetelmä ja vesiputousmalli on seitsemäs (Aston, 2022). Molemmat menetelmät ovat käytössä erityisesti myös IT-alan laajamittaisissa ohjelmistoprojekteissa, minkä takia niitä tarkastellaan läheisemmin myös tässä tutkimuksessa. Ketterässä metodologiassa ohjelmistoprojektit jaetaan pienempiin osiin, joista kukin sisältää pienen osan koko projektin laajuudesta ja toimivuudesta. Tavoitteena on sitten 14 viedä läpi näitä pieniä osia eli kehitysvaiheita (sprintti tai sykli), joissa toteutetaan yksi osa tulevasta järjestelmästä (ks. Kuva 2). Kun kehitysvaihe on saatu päätökseen ja kehitetty toiminto on testattu ja hyväksytty, aloitetaan uusi kehitysvaihe. Näitä kehitysvaiheita suoritetaan iteratiivisesti ja kehitettävään järjestelmään lisätään toimintoja, kunnes lopputuote saavutetaan. Huomattava seikka ketterän kehityksen lähestymistavassa on se, että asiakas on aina kehityksessä mukana antamassa lisätietoa tarvittavista ominaisuuksista ja tarjoamassa palautetta osatuloksista. Näin voidaan varmistaa, että lopputuote, eli järjestelmä tai ohjelma, on asiakkaan toiveiden mukainen. Menetelmän painopiste on yleensä joustavissa, poikkitoiminnallisissa tiimeissä ja tiimityössä, mikä tekee projektitiimin hallinnasta ja johtamisesta erittäin tärkeää. (Holcombe, 2008, s. 2–5; Stare, 2013). Kuva 2. Ketterä kehitys ja vesiputousmalli (mukaillen Escott, 2017). Vesiputousmalli on lineaarisempi kuin ketterän kehityksen menetelmät ja se sisältää yksityiskohtaisia suunnitelmia pitkälle aikavälille. IT-projektin kehittämisen ja toteutuksen aikana projekti käy läpi kaikki kehitysvaiheet vuoron perään ennen kuin lopputuote julkaistaan täysin valmiina (ks. Kuva 2). Tämän seurauksena projektin tila on yleensä melko selvä sen suhteen, mitä on tapahtunut ja mitkä ovat seuraavat kehitysvaiheet. Vesiputousmallissa on ketterän kehityksen menetelmiin verrattuna 15 jäykemmät tiimiroolit. Tämän lisäksi projektinhallinta on erittäin rakenteellista sekä prosesseja noudattavaa (plan driven). Asiakas on myös yleensä mukana kehitysprosessissa vain sen alussa ja lopussa, minkä takia muutoksiin reagointi voi olla haastavaa. (Ahmed, 2011, s. 15–16, 247–250; Holcombe, 2008, s. 3). Rodovin ja Teixidón (2016) mukaan yhdistämällä molemmat kehitysstrategiat, projektille hyödylliset tekijät voidaan nostaa esille molemmista menetelmistä. Tällöin kehitysprojektiin voidaan sisällyttää muun muassa asiakkaan osallistuminen, kommunikointi sidosryhmien kesken, alustava ja perinpohjainen suunnittelu sekä kyky reagoida tarvittaessa nopeasti muutoksiin. Rodov ja Teixidó argumentoivat, että molempien menetelmien yhdistäminen tulisi aloittaa jo projektin alkaessa. Esimerkiksi scrum-kehitysmenetelmän hyödyntämiseksi kehitettävälle ohjelmistolle on luotava kehitysjono, joka sisältää listauksen sen vaatimuksista. Tässä tilanteessa vesiputousmalli on varsin hyödyllinen, sillä yksityiskohtainen ja kattava suunnitelma projektin alussa tukee myöhempää kehitystä – jos suunnitelman laajuus (scope) on väärä tai siihen on lisättävä uusia ominaisuuksia, kehitysjonoa voidaan helposti muokata ketterillä menetelmillä. Rodovin ja Teixidón (2016) mukaan vesiputousmallin selkeä määritelmä tiimirooleista ja sen jäsennelty kehityslähestymistapa projektin alkuperäisen tarkoituksen toteuttamiseksi ovat "välttämättömiä tekijöitä onnistuneelle projektille". Esimerkiksi tilanteessa, jossa turvaudutaan pelkästään käyttäjätarinoihin (user story) ja järjestelmän dokumentaatio jätetään kokonaan tekemättä, voi projektin laajuus kasvaa ajan myötä, mikä taasen tulee aiheuttamaan tarpeettomia viiveitä. Tällöin yhdistämällä vesiputousmallin prosessinomaisen suunnittelun ja toteutuksen sekä ketterän kehityksen käyttäjäläheisyyden, voidaan projektissa käsitellä muuttuvia vaatimuksia ja ominaisuuksia unohtamatta projektin alkuperäistä tarkoitusta. 16 2.1.3 Kriittiset menestystekijät Kriittiset menetystekijät voidaan määritellä Bullenin ja Rockartin (1981, s. 7) kirjoituksen mukaan asioiksi, joiden täytyy mennä oikein, jotta yrityksen johdon tavoitteet saavutetaan. He kuvailevat kriittisiä menestystekijöitä yleisellä tasolla ”rajalliseksi määräksi alueita, joilla tyydyttävät tulokset takaavat onnistuneen kilpailullisen suorituskyvyn yksilölle, osastolle tai organisaatiolle”. Tämän yleismaailmallisen näkemyksen mukaan menestystekijöiksi luokitellaan onnistumiselle olennaisia asioita, jotka ovat kontekstista riippuvia. Toisin sanoen, menestystekijät vaihtuvat asiayhteyden mukaan. Esimerkiksi ohjelmistokehitysprojekti sisältää onnistuakseen erilaisia yksityiskohtia ja toteutettavia tehtäviä verrattuna vaikkapa markkinointikampanjaan. Toiminnanohjausjärjestelmien kehitysprojektien kohdalla näitä menestystekijöitä voidaan kuvata yleistason näkemyksen tavoin asioiksi, joita yrityksen tai organisaation täytyy tehdä ja toteuttaa onnistuakseen ohjelmistokehityksen aikana (Nestell & Olson, 2017, s. 117). Jotta ohjelmistoja ja järjestelmiä kehittävä yritys ymmärtäisi mihin asioihin sen tulisi kiinnittää huomiota ja panostaa erityisesti, tulee kyseisen yrityksen tarkastella etupäässä näitä tekijöitä. Näin toiminnanohjausjärjestelmiä kehittävä yritys voi ennaltaehkäistä yleisiä ja tärkeitä virheitä sekä luoda työskentelytapoja ja ratkaisuja ennen kuin ohjelmistokehitys kohtaa näistä menestystekijöistä ilmaantuvia ongelmia (Ngai ja muut, 2008, s. 548–549). Yksityiskohtaisempaa pohdintaa kriittisistä menestystekijöistä ERP-järjestelmien kohdalla on tehty tässä tutkimuksessa hyödynnettävässä toiminnanohjausjärjestelmien kehitysprojektien menestystekijät -viitekehyksessä. Tämä viitekehys ja sen kriittiset menestystekijät käsitellään tarkemmin kappaleessa 2.3. 17 2.2 Toiminnanohjausjärjestelmät Toiminnanohjausjärjestelmien rakenne ja toiminta vaihtelee niiden käyttötarkoituksen mukaisesti. Tämän seurauksena ERP-järjestelmiä on monenlaisia (Winkelmann & Leyh, 2010). Tässä kappaleessa tarkastellaan näille järjestelmille ominaisia piirteitä ja käyttötarkoituksia. Tavoitteena on saada kokonaisvaltainen kuva toiminnanohjausjärjestelmistä, niiden toiminnallisista alueista, ominaisuuksista ja käyttötarkoituksista teollisuudessa. 2.2.1 Toiminnalliset alueet O’Leary (2000, s. 27–28) kuvaa toiminnanohjausjärjestelmiä tietojärjestelmiksi, jotka on suunniteltu käsittelemään organisaation tapahtumia (transaction), helpottamaan integroitua ja reaaliaikaista suunnittelua (real-time planning), hallitsemaan tuotantoa sekä prosessoimaan sen käyttäjien erinäisiä pyyntöjä. ERP-järjestelmä on tyypillisesti integroitu osaksi yrityksen prosesseja varsin laaja-alaisesti, jolloin sen avulla voidaan teoriassa ohjata koko yrityksen toimintaa. Toiminnanohjausjärjestelmät ovat käytännössä eräänlaisia ohjelmistopaketteja, jotka on kehitetty perinteiseen tai web- pohjaiseen asiakaspalvelinympäristöön. Tietojenhallinnan näkökulmasta ERP-järjestelmät käyttävät koko yrityksen kattavaa tietokantaa ja yleensä tallentavatkin oleellisen datan vain kerran tähän tietokantaan. Tämä laaja tietokanta mahdollistaa esimerkiksi reaaliaikaisen pääsyn sen sisältämiin tietoihin. Lisäksi ERP-järjestelmillä oletetaan yhä useammin olevan toiminnallisuus mukautua käyttäjän tarpeisiin muokkaamatta lähdekoodia hyödyntämällä erilaisia asetuksia ja moduuleja. Samalla toiminnanohjausjärjestelmissä on myös usein tuki useille valuutoille ja kielille, mikä on erityisen tärkeää monikansallisille yrityksille. (O’Leary, 2000). 18 Toiminnanohjausjärjestelmiä voidaan ottaa käyttöön monella eri toimialalla. Parthasarathyn (2007, s. 1–3) mukaan ERP-järjestelmät kehitettiin alun perin avuksi teollisuuteen yritysten ydintoimintojen hallintaan, mutta niiden käyttö on laajentunut myös muille toimialoille mahdollisuuksien laajentuessa. Parthasarathy kertoo, että ERP- järjestelmät tarjoavat etuja esimerkiksi yritysten toimintojen integroinnissa, käytön joustavuudessa, analyysi- ja suunnitteluprosessien edistymisessä sekä uuden teknologian käyttöönotossa. Näistä syistä ERP-järjestelmien kehitys ja käyttö onkin laajentunut maailmanlaajuiselle tasolle. 2.2.2 Käyttötarkoitukset Samaran (2015, s. 13–14) mukaan toiminnanohjausjärjestelmät voidaan jakaa kahteen sukupolveen. Näistä ensimmäinen kuvaa ERP-järjestelmiä, jotka toteuttavat yrityksien sisäisiä toimintoja. Näihin lukeutuu muun muassa henkilöresurssien, laadun ja materiaalien hallintaa; yrityksen talouden seuraamista niin talouden- kuin kirjanpidon muodossa; myynnin johtamista; jakelun organisointia sekä tuotannon suunnittelua muiden tärkeiden toimintojen ohella. Toiminnanohjausjärjestelmät voidaan taasen luokitella toiseen sukupolveen, kun ne sisältävät ulkoisia toimintoja, esimerkiksi toimitusketjujen tai asiakkuuksien hallintaa. Vaikka ratkaisevana erottimena on järjestelmien kytkeminen yrityksen ulkopuolelle, voivat nämä toisen sukupolven järjestelmät sisältää ensimmäisen sukupolven toimintoja. Toisin sanoen, toiminnanohjausjärjestelmät voivat sisältää niiden käyttötarkoituksen puolesta monia yrityksen toimintoja (ks. Kuva 3). (Samara, 2015). 19 Kuva 3. Toiminnanohjausjärjestelmän toimintoja (mukaillen Ippolito, 2021). 2.3 Toiminnanohjausjärjestelmien kehittämisen menestystekijät Toiminnanohjausjärjestelmien kehitykselle ominaisia kriittisiä menestystekijöitä on tarkasteltu hyvin pitkään ja monia näkemyksiä on saatavilla tutkimusyhteisössä. Tässä kappaleessa tarkastellaan ERP-järjestelmien kehityksen menestystekijöitä valmistavan teollisuuden toimialalla. Tätä tarkoitusta varten tutkimuksessa hyödynnetään aiemmassa tutkimuksessa laadittua viitekehystä näistä menestystekijöistä. Viitekehys sisältää 30 erilaista menestystekijää kolmesta osa-alueesta: organisaatio, tekniikka ja projekti. Viitekehys on laadittu vuonna 2021 hyödyntämällä integroivaa kirjallisuuskatsausta ja tarkastelemalla AIS-organisaation (Association for Information Systems) ”Basket-of-Eight” 20 -julkaisulistaa. Tämä lista sisältää kahdeksan julkaisua tietojärjestelmätieteen alalta. Tarkasteltujen julkaisujen artikkeleita karsittiin sopimaan tutkimuksen kriteereihin. Toisin sanoen, tieteellisen artikkelin tuli tarkastella ERP-järjestelmien kriittisiä menestystekijöitä teollisuuden toimialalla, vastata ohjelmistokehityksestä tunnistettavaa ensimmäistä kuutta elinkaarivaihetta sekä tutkia menestystekijöitä suoraan, eikä vain sivuta toiminnanohjausjärjestelmien aihealuetta. Koottuja artikkeleita analysoitiin ja löydetyt menestystekijät koottiin alla olevaan taulukkoon (ks. Taulukko 1). (Jokinen, 2021). Taulukko 1. Kriittisten menestystekijöiden viitekehys (mukaillen Jokinen, 2021). Menestystekijä Englanniksi Osa-alue ERP-elinkaaren toimivaihe Johdon tuki Top management support Organisaatio Kaikki Kokonaisvaltainen yrityskuva ja järjestelmän soveltuvuus yrityksen prosesseihin Holistic enterprise view / System fit with business processes Organisaatio Esitutkimus, määrittely, suunnittelu Konsultit Consultant support Organisaatio Kaikki Koulutus ja pätevät työntekijät (sis. tehokäyttäjät) Training and retention of skilled workers Organisaatio Käyttöönotto Kulttuuriristiriita Culture clash Organisaatio Käyttöönotto Ulkoinen toimittaja Supplier/vendor selection Organisaatio Esitutkimus Pitkäaikaiset kumppanuudet Long-term partnerships Organisaatio Kaikki Sidosryhmien sitoutuminen Stakeholder commitment Organisaatio Kaikki Sidosryhmien kommunikaatio Stakeholder communication Organisaatio Kaikki Sisäinen kommunikaatio Internal communication Organisaatio Kaikki Luottamus sidosryhmien kesken Trust / Teamwork Organisaatio Kaikki Minimaalinen ohjelmiston mukauttaminen Minimal software customisation Organisaatio Suunnittelu, toteutus Organisaation resurssit Organisational resources Organisaatio Kaikki Projektin perustelu Project justification Organisaatio Esitutkimus 21 Prosessi- ja muutosjohtaminen Business process re- engineering/management (BPR/BPM) Organisaatio Käyttöönotto Muutosvastarinta Resistance to change / Organizational inertia Organisaatio Kaikki Suorituskyvyn arviointi Performance evaluation Organisaatio Testaus, käyttöönotto Vaatimusmäärittely System requirements Tekniikka Esitutkimus, määrittely Käyttäjäkokemus User experience (UX) Tekniikka Suunnittelu, toteutus, käyttöönotto Ohjelmatestaus Software testing Tekniikka Testaus Perinnejärjestelmien hallinta Legacy system management Tekniikka Esitutkimus Tiedonhallinta Data management Tekniikka Toteutus Tietostandardit Data standards Tekniikka Toteutus Tiedon laatu Data quality Tekniikka Toteutus Tiedon tarkkuus Data accuracy Tekniikka Toteutus Projektinhallinta/- johto (sis. aikataulutus) Project management/ownership Projekti Kaikki Suunnittelu Robust planning Projekti Suunnittelu Budjetti / kustannukset Budget / Costs Projekti Kaikki Loppukäyttäjän sisällyttäminen kehitysprojektiin End user involvement Projekti Esitutkimus, määrittely, suunnittelu, testaus Selkeä ja realistinen projektivisio Clear and realistic project vision Projekti Kaikki Kriittiset menestystekijät on luokiteltu taulukossa kolmeen osa-alueeseen. Tämän lisäksi jokainen menestystekijä on pyritty kohdentamaan ERP-järjestelmän elinkaarivaiheeseen. Tämän jaottelun avulla viitekehystä hyödyntävä ohjelmistokehittäjä voi tarkistaa, että kehitystyölle tärkeät tekijät on huomioitu projektin aikana. Tämän lisäksi kehitysprojektissa voidaan ennakoida ja varautua mahdollisia sudenkuoppia vastaan projektin jokaisen työvaiheen kohdalla seuraamalla eri toimivaiheiden menestystekijöitä viitekehyksestä. (Jokinen, 2021). 22 2.3.1 Organisatoriset menestystekijät Viitekehyksessä ensimmäinen osa-alue on organisaatio. Tämä osa-alue pitää sisällään lukumääräisesti eniten kriittisiä menestystekijöitä, minkä perusteella sen voidaan arvioida olevan tärkein tarkasteltu toimialue. On kuitenkin hyvä huomata, että viitekehyksen menestystekijöistä ja niiden vaikutuksista ei ole tehty varsinaista riskianalyysiä, joten tärkeintä osa-aluetta ei voida tässä mielessä tunnistaa varmuudella. Organisaation osa-alue sisältää menestystekijöitä, jotka liittyvät vahvasti organisaation hallintaan sekä sen sisäisiin ja ulkoisiin toimintoihin. Muun muassa toimintojen ja prosessien hallinta, kumppanuuksien ja työntekijöiden johtaminen sekä yrityksen sisäisten resurssien ohjaaminen sisältyvät tähän osa-alueeseen. (Jokinen, 2021). Viitekehyksessä on nostettu esille, miten suuri osa organisatorisista kriittisistä menestystekijöistä ovat aktiivisia koko kehitysprojektin ajan. Toisin sanoen, näiden menestystekijöiden vaikutukset voidaan tunnistaa kehitystyössä niin määrittelyn ja suunnittelun vaiheissa, kuin toteutuksessa ja käyttöönotossa. Tämä viittaa siihen, että organisaation toimintaan ja siihen liittyviin menestystekijöihin ei ole panostettava vain yhdessä elinkaarivaiheessa, vaan että nämä tekijät vaativat jatkuvaa käsittelyä ERP- järjestelmää kehittävän yrityksen ja projektitiimin toimesta. (Jokinen, 2021). Ensimmäinen osa-alueen tunnistettu menestystekijä on johdon tuki (top management support). Elbanna (2013, s. 278) kuvailee tätä menestystekijää yhtenä tärkeimpänä tekijänä ERP-järjestelmien kehitysprojekteissa. Projektin onnistumisen kannalta johdon tuki on ratkaisevaa muun muassa hallinto- ja ihmissuhderistiriitojen selvittämisessä, organisaation rutiinien ja kehitystyötä lamauttavien prosessien vapauttamisessa sekä järjestelmän tulevan rutiininomaisen käytön vahvistamisessa rakenteellisilla muutoksilla. Shao ja muut (2016, s. 132, 140–142) kirjoittavat, että kehitysprojekteissa, joissa ylimmän johdon tuki ei ole tuloksellista ja aiheuttaa itsessään projektissa ongelmia, voidaan näistä projekteista tunnistaa monia konfliktitilanteita. Vaikka tämä menestystekijä on erityisen tärkeä projektityöskentelyssä, Tan ja muut (2020, s. 1782– 23 1783) kuitenkin huomauttavat, että johdon tuki ei ole ainoa tekijä, joka voi johdattaa ERP-järjestelmän kehitysprojektia onnistumisen polulle. Toinen viitekehyksen kriittisistä menestystekijöistä johdon tuen jälkeen organisaation osa-alueella on kokonaisvaltainen yrityskuva ja järjestelmän soveltuvuus yrityksen prosesseihin (holistic enterprise view / system fit with business processes). Tämä menestystekijä kuvaa, miten kehitysprojektin näkemyksillä yrityksestä ja sen toiminnoista sekä tulevan toiminnanohjausjärjestelmän soveltuvuudesta näihin näkemyksiin on suuri vaikutus projektin onnistumiselle. Tämä kokonaisvaltainen yrityskuva tarkoittaa käytännössä holistista ja reaalista näkemystä, jossa yritys nähdään yhtenä kokonaisuutena sen sijaan, että se olisi kokouma erillisistä osista (Koh ja muut, 2011, s. 389–394). Näin ERP-järjestelmän kehitysprojektissa saadaan hyvä näkemys yrityksen ydintoiminnoista ja -osaamisesta, jolloin järjestelmän vaatimusten määritteleminen on helpompaa ja projektista voidaan vähentää sen mahdollisia haittapuolia ja täten riskiä. Tan ja muut (2020, s. 1775, 1793) nostavat esille, että holistinen yrityskuva auttaa erityisesti ulkoistetun ohjelmistokehityksen projekteissa. Tilanteissa, joissa toiminnanohjausjärjestelmän kehittävän yrityksen näkemys asiakasyrityksen ydintoiminnoista ja tulevasta järjestelmästä eivät sovi keskenään yhteen, ohjelmistokehitys voi ohjautua väärään suuntaan. Tällöin järjestelmän lopullinen käyttötarkoitus ei ole tarkoituksenmukainen tai pahimmassa tapauksessa se ei vastaa järjestelmää tarvitsevan yrityksen tarpeita (system misalignment). Verrattuna näihin kahteen ensimmäiseen menestystekijään, joita voidaan luonnehtia osittain kehitysprojektin sisäisiksi menestystekijöiksi, yrityksen ulkoiset konsultit (consultant support) voivat tarjota uusia ratkaisuja ja näkemyksiä, joita projektin kehitystiimi ei itse välttämättä tulisi ajatelleeksi. Konsulttien tarjoama tuki ja ammattitaito on suositeltavaa hyödyntää varsinkin, kun ERP-järjestelmää rakennetaan yrityksen sisäisesti (Tan ja muut, 2020, s. 1774, 1782–1783). Tällöin kehitysprojektiin 24 tuodaan tietoa ja osaamista, joita tiimillä ei välttämättä ole itsessään, mikä taasen tehostaa järjestelmän kehitystä ja nostaa mahdollisuutta projektin menestymiseen. Nämä ulkoiset konsultit ovat projektissa eräänlaisia mallitoimijoita (reference actor), joiden avulla voidaan ratkaista vaikeitakin ongelmia tuomalla esille heidän kokemuksensa työuriensa aikana kohtaamistaan ongelmista (Pollock & Hyysalo, 2014, s. 489–493). Neljäs organisaation osa-alueen kriittisistä menestystekijöistä on pätevät työntekijät ja heidän koulutuksensa (training and retention of skilled workers). Tämä menestystekijä on viitekehyksen muodostamisessa käytetyn tutkimusaineiston mukaan yksi tärkeimmistä menestystekijöistä johdon tuen ohella ja se on tunnistettavissa projektista erityisesti käyttöönoton elinkaarivaiheessa (Jokinen, 2021). Olivatpa nämä työntekijät ERP-järjestelmän tilaavan yrityksen työntekijöitä, jotka kuvailevat järjestelmän toiminnot sen suunnittelussa, antavat palautetta ohjelmoiduista toiminnoista ja ottavat sen lopulta käyttöön tai järjestelmän kehitysprojektissa toimivia henkilöitä, heidän pätevyytensä, ammattitaitonsa ja yhteistyönsä ovat suuressa osassa projektin onnistumista. Yrityksien onkin tästä syystä tärkeä pitää ammattitaitoisen henkilöstön vaihtuvuus mahdollisimman matalana ja tarjota työntekijöilleen hyvin organisoitua sekä korkealaatuista koulutusta (Koh ja muut, 2011, s. 395; Veiga ja muut, 2014, s. 692). Koulutusta tulisi tarjota työtekijän tehtävien mukaan muun muassa tulevaisuudessa käyttöön otettavasta ohjelmistosta tai järjestelmästä (software usage), työnkulusta (workflow) tai muuten vain yleisellä tasolla (general). Henkilöstön koulutusta voidaan samalla tukea ja tehostaa tarjoamalla erilaisia tukirakenteita kuten helpdesk-neuvontaa ja online-tukipalveluja sekä kehittämällä työntekijöiden välisiä neuvontaverkkoja (advice networks), eli toisin sanoen vertaisneuvontaa. Samalla koulutuksen aikana tai sen jälkeen yritykset voivat tunnistaa työntekijöiden joukosta henkilöitä, jotka ovat teknisesti päteviä tai ymmärtävät toiminnanohjausjärjestelmää työtovereihinsa verrattuna paremmin. Näitä henkilöitä kutsutaan ”tehokäyttäjiksi” (power users) ja heidät tulisi 25 sijoittaa asemiin, joista he voivat tarjota tukeaan muulle henkilökunnalle esimerkiksi järjestelmän käyttöönotossa. (Sykes, 2015 s. 482; Sykes ja muut, 2014, s. 51–67). Viidentenä menestystekijänä on kulttuuriristiriita (culture clash). Tällä menestystekijällä on taustansa kehitysprojektien monikansallisissa tiimeissä sekä yrityksien eri toimipisteiden toisistaan eroavissa työkulttuureissa (work culture / subculture) (Meissonier & Houzé, 2010, s. 543). Menestystekijän voi tunnistaa esimerkiksi, jos ERP- järjestelmä kehitetään eri maassa kuin se otetaan lopulta käyttöön tai jos järjestelmä kehitetään yritykselle, joka tulee hyödyntämään sitä monessa eri toimipaikassa – olivatpa nämä lähellä toisiaan maantieteellisen sijainnin ja siellä vallitsevan kulttuurin mukaan tai kaukana toisistaan. Koh ja muut (2011, s, 393–394) nostavat analyysissään esille esimerkin työkulttuurin eroavaisuuksista yrityksen sisällä: muun muassa tavoitteiden määritteleminen tai työhön liittyvän suorituskyvyn mittaaminen saatetaan toteuttaa eri tavoin. Kulttuuriristiriitaa voi esiintyä toiminnanohjausjärjestelmien kehitysprojekteissa myös työntekijöille jaettavissa kannustuspalkinnoissa ja toimipisteiden yleisissä hallintotoimissa (Kumar ja muut, 2016, s. 99). Jos kulttuuriristiriitaa esiintyy ja siitä esille nousevia ristiriitoja ei kyetä hallitsemaan, kehitysprojektin kulku voi hidastua ja vaikeutua. Pahimmassa tapauksessa erilaisista kulttuureista aiheutuvat väärinymmärrykset voivat johtaa tilanteeseen, jossa järjestelmän vaatimukset ja lopullinen toteutus eivät sovi yhteen ja on odotusten vastaista. Esimerkiksi jos järjestelmän käyttöönotto vaatii jokaiselta toimipisteeltä tiettyjä toimia, kuten tietokantojen migraatiota tarkoin määriteltyjen toimien mukaan, eriävät implementoinnit johtavat kieltämättä ongelmatilanteisiin. Kulttuuriristiriitaa voidaan osittain hallita pohtimalla seuraavaa menestystekijää: tehdäänkö toiminnanohjausjärjestelmä yrityksen toimesta sisäisesti vai otetaanko kehitystyöhön alihankkija, eli ulkoinen toimittaja (supplier / vendor selection). Jos projekti toteutetaan esimerkiksi yrityksen sisällä ja yrityksen kehitystiimi on tottunut tekemään yhteistyötä, kulttuuriristiriitaa ei välttämättä esiinny ollenkaan järjestelmän 26 kehityksen aikana. Kysymys ulkoisen toimittajan palkkaamisesta onkin ollut tärkeä ERP- järjestelmien kontekstissa jo monta vuotta (Pollock & Hyysalo, 2014, s. 476). Kysymystä pohditaan viitekehyksessä yrityksien omien resurssien ja henkilöstön pätevyyden kautta; jos yritys ei ole kykenevä kehittämään uutta toiminnanohjausjärjestelmää, pitäisi sen hankkia ulkoinen toimittaja kehitysprojektin toteutukseen (Jokinen, 2021). Tällöin palkattu ulkoinen toimittaja voi tarjota yritykselle järjestelmän kehittämisen lisäksi muita palveluita, kuten jatkokehitystä ja ylläpitoa järjestelmän käyttöönoton jälkeen sekä loppukäyttäjien koulutusta. Seuraava kriittinen menestystekijä edellyttää yritykseltä pitkäaikaisen kumppanuuden (long-term partnership) harkintaa sen sidosryhmien kanssa (Koh ja muut, 2011, s. 389). Mahdolliset liittymäkohdat tulevan toiminnanohjausjärjestelmän ja yrityksen tavarantoimittajien, alihankkijoiden, jälleenmyyjien, asiakkaiden ja muiden yhteistyökumppaneiden järjestelmien kesken voivat tarjota suuriakin etuja kilpailukyvyn edistämiseen. Esimerkiksi teollisuudessa tuotteiden tilaaminen voi tapahtua suoraan ja automaattisesti yrityksen asiakkaiden omista tietojärjestelmistä, mikä mahdollistaa nopeammat vasteajat toimituksien suhteen (Koh ja muut, 2011, s. 392). Edellä mainituissa kriittisissä menestystekijöissä ei ole huomioitu suoraan kehitysprojektin tiimin sisäistä ihmisten välistä vuorovaikutusta ja siitä ilmeneviä tekijöitä. Vaikka henkilöstön ammattitaito ja koulutus sekä johdon tuki saattavat sivuta tätä aihetta, ei niissä varsinaisesti keskitytä tähän asianhaaraan. Viitekehyksessä tämä seikka on sisällytetty edellä mainittuun kulttuuriristiriidan menestystekijään sekä sidosryhmien sitoutumiseen (stakeholder commitment) sekä sidosryhmien väliseen kommunikaatioon (stakeholder communication / internal communication). Näillä kahdella menestystekijällä on vahva vaikutus niin kehitystiimin toimintaan, sidosryhmien vuorovaikutukseen kuin koko projektin onnistumiseen. (Jokinen, 2021). Tilanteessa, jossa yrityksen ja sen kumppaneiden, erityisesti ulkoisen toimittajan, näkemykset eivät ole selkeitä tai eroavat toisistaan huomattavasti, on viestintä näiden 27 ryhmien välillä erittäin tärkeää eroavaisuuksien ratkaisemisessa (Koh ja muut, 2011, s. 396). Samalla yrityksen sisäisten sidosryhmien sitoutuminen projektin toteutukseen on tärkeässä asemassa. Jos esimerkiksi yrityksen osastojen ja tiimien näkemykset projektin toteutumisesta ovat positiiviset, ovat nämä sisäiset sidosryhmät todennäköisemmin sitoutuneita järjestelmän kehitysprojektiin ja sen onnistumisen varmistamiseen (Mueller ja muut, 2019, s. 612, 619). Näiden kahden menestystekijän lisäksi kehitysprojektin tiimin sisäinen vuorovaikutus näkyy erityisesti myös sidosryhmien ja kehitystiimin sisäisessä luottamuksessa (trust / teamwork). Tämä menestystekijä on Schlichterin ja Rosen (2013, s. 455–456) mukaan erittäin tärkeä projektin onnistumisen kannalta. Heidän mukaansa luottamuksen puute voi johtaa vakaviin ongelmiin kehitystyössä, esimerkiksi projektityöntekijöiden sitoutuminen projektiin ja muuhun tiimiin voi heikentyä tiimin keskinäisten sosiaalisten suhteiden ohella. Tämä taasen saattaa johtaa yhteistyön vähenemiseen sekä pahimmassa tapauksessa työtekijöiden eroamiseen ja ammattitaidon menettämiseen. Koh ja muut (2011, s. 396) nostavat tutkimuksessaan esille myös luottamuksesta ilmeneviä positiivisia puolia. He kuvaavat, miten esimerkiksi toisiinsa luottavien yrityskumppaneiden välinen aktiivinen kommunikaatio voi johtaa tehokkaaseen ja nopeaan tuotteiden vaihtamiseen ja täten tuloksellisempaan kilpailukykyyn. Toiminnanohjausjärjestelmän kehittämisessä yrityksien välinen luottamus mahdollistaa esimerkiksi kauppakumppaneiden järjestelmien tiukemman nivoutumisen yhteen ja tämän integraation mahdollistamien etujen hyödyntämisen. Luottamusta seuraava kriittinen organisatorinen menestystekijä on minimaalinen ohjelmiston mukauttaminen (minimal software customisation). Vaikka menestystekijän vaikutukset ovat näkyvissä vasta ERP-järjestelmän käytössä, on tämä menestystekijä perusteellinen osa kehitystyötä. Schneider ja muut (2018, s. 159–160) kuvaavat, miten järjestelmän käyttöönoton jälkeen ylläpidossa voi esiintyä ongelmia silloin, kun järjestelmää on mukautettu tai integroitu liian paljon. Tämä näkyy ylläpidossa 28 esimerkiksi siten, että ohjelmistopäivitysten tekeminen vaatii paljon vaivaa yrityksen IT- osastolta mukautusten, laajennusten ja kokoonpanojen suhteen. Menestystekijä on tunnistettavissa erityisesti markkinoilta saatavien ”valmiiden” pakettiratkaisujen kohdalla, mutta se voi olla osa alusta alkaen kehitetyn järjestelmän kehitysprojektia. Ohjelmiston minimaalinen mukauttaminen on olennaista esimerkiksi seuraavassa tilanteessa. Jos järjestelmän ydintoimintoihin on jäänyt ohjelmistokehityksen ajalta virheitä ja järjestelmään on kehitetty valtava määrä aliohjelmia näiden ydintoimintojen varaan, on järjestelmän ylläpito ja näiden virheiden korjaaminen jälkikäteen niin vaikeaa, monimutkaista kuin kallista. Tällöin monimuotoinen ja paljon mukautettu ERP- järjestelmä on ongelmallinen. Tämän seurauksena toiminnanohjausjärjestelmä tulisi kehittää ensisijaisesti sen tärkeimpien toimintojen mukaan, jolloin järjestelmä voidaan ottaa käyttöön ja sen päätoiminnot testata ennen kuin vähemmän tärkeät ja ydintoiminnoista riippuvat toiminnot lisätään osaksi muuta kokonaisuutta. (Schneider ja muut, 2018, s. 159–160). Seuraava organisaation osa-alueeseen kuuluva kriittinen menestystekijä on organisaation resurssit (organisational resources). Nämä resurssit ovat toiminnanohjausjärjestelmän kehitysprojektin näkökulmasta asioita, joilla on vaikutusta projektiin, kuten yrityksen talous, henkilöstö, infrastruktuuri ja IT-kyvykkyydet. Esimerkiksi aiemmin käsitelty kysymys järjestelmän ulkoisesta toimittajasta on suurilta osin riippuvainen siitä, millaiset resurssit yrityksellä on toteuttaa projekti oman talon sisällä. Yrityksen resursseja voidaan mieltää myös eräänlaisena esteenä projektin aloittamiselle – jos yrityksellä ei ole tarvittavaa IT-kyvykkyyttä aloittaa projekti itse ja jos sillä ei ole pääomaa palkata ulkoista toimittajaa, ei projekti tule toteutumaan. (Koh ja muut, 2011, s. 393–395). Organisaation resurssit liittyvät osittain myös projektin perusteluun (project justification). Tämä menestystekijä kuvaa yrityksen alkuperäistä syytä, miksi projekti on tarpeellinen ja miksi uusi järjestelmä tulisi rakentaa. Koska toiminnanohjausjärjestelmä 29 on suuri investointi yritykselle, vaatii sen kehitysprojekti perinpohjaisia perusteita ja syitä ennen kuin se voidaan aloittaa. Samalla, mitä enemmän yrityksen johdon ja henkilöstön halutaan tukevan kehitysprojektia, sitä paremmin ja aikaisemmin tulee projekti olla kartoitettu ja perusteltu. Näin kehitysprojektille voidaan varmistaa sen tarvittavat resurssit ja organisatorinen tuki. (Bernroider, 2013, s. 235–236, 245). Seuraavat kaksi organisaation osa-alueen kriittistä menestystekijää vaikuttavat toisiinsa vahvasti, minkä takia niitä on tarkasteltu viitekehyksessä yhdessä (Jokinen, 2021). Nämä menestystekijät ovat yrityksen henkilöstön muutosvastarinta (resistance to change / organizational inertia) ja organisaation prosessi- ja muutosjohtaminen (business process re-engineering/management, BPR/BPM). Muutosvastarinta on ilmiö, jossa yrityksen työntekijä ei halua tai kykene syystä tai toisesta mukautumaan uuteen tapaan, prosessiin tai teknologiaan ja haluaa säilyttää yrityksessä vallitsevan nykytilanteen (status quo). Esimerkiksi yrityksessä kauan toiminut työntekijä ei välttämättä näe uutta toiminnanohjausjärjestelmää positiivisena asiana ja ei tarjoa tukeaan projektille tai vastustaa järjestelmän kehitystä, vaikka järjestelmä olisikin edistysaskel ja parannus edelliseen järjestelmään verrattuna. (Laumer ja muut, 2016, s. 320–326). Laumer ja muut (2016) argumentoivat, että muutosvastarinta voi saada alkunsa virheellisistä näkemyksistä ja mielipiteistä. Heidän mukaansa uusi ERP-järjestelmä voi aiheuttaa joissakin työntekijöissä pelkoa muutoksesta. Esimerkiksi pelot joko yrityksen pääoman menetyksestä, oman vaikutusvallan heikentymisestä, tulevan järjestelmän huonosta käytettävyydestä ja monimutkaisuudesta tai siirtymäkustannuksista voivat aiheuttaa vastustusta. Koh ja muut (2011, s. 393) tuovat esille muutosvastarinnan yhdeksi ratkaisuksi muutosjohtamisen. Sen avulla organisaatiossa voidaan keskittyä uuden teknologian ja muuttuvien työrutiinien sisällyttämiseen osaksi yrityksen työkulttuuria niin viestinnän kuin koulutuksen muodossa. Erityisen tärkeää on tiedottaa yrityksen henkilöstölle miksi ja miten muutos tapahtuu (Laumer ja muut, 2016, s. 334). Tämän takia myös edellinen menestystekijä, projektin perustelu, on olennainen osa myös muutosjohtamista. 30 Viimeinen organisatorinen menestystekijä on suorituskyvyn arviointi (performance evaluation). Jotta toiminnanohjausjärjestelmän suorituskyvystä ja sen hyödyllisistä vaikutuksista yrityksen toimintaan voidaan varmistua, tulee sitä seurata ja arvioida jo järjestelmän käyttöönoton aikana (Koh ja muut, 2011, s. 389, 395). Tämän seurauksena projektin kehitysvaiheissa tulisi kiinnittää huomiota järjestelmän tarkkojen ja selkeiden suorituskykymittareiden (key performance indicator, KPI) rakentamiseen. Järjestelmää voidaan arvioida esimerkiksi sen perusteella, miten sen toiminnot vastaavat liiketoimintaprosesseja, miten järjestelmästä aiheutuvaa riskiä voidaan hallita, antaako järjestelmä tarkkaa ja ajantasaista liiketoimintatietoa (business intelligence) ja niin edelleen. Suorituskyvyn puutteellinen seuranta aiheuttaa Dohertyn ja muiden (2012) mukaan toisinaan ongelmia kehitysprojektissa perusteellisesta ja muuten huolellisesta työstä huolimatta. 2.3.2 Tekniset menestystekijät Organisatorisia kriittisiä menestystekijöitä seuraava osa-alue on tekniikka. Tämä osa-alue käsittelee sen nimen mukaisesti kehitystyölle ominaisia teknisiä tekijöitä, kuten ohjelmointia. Viitekehyksessä tästä osa-alueesta löytyy kahdeksan menestystekijää, jotka voidaan yhdistää pääasiallisesti kehitettävän ERP-järjestelmän elinkaaressa sen toteutusvaiheeseen. Tämä seikka tekee tekniikan osa-alueesta poikkeuksellisen muihin viitekehyksen osa-alueisiin verrattuna – muut osa-alueet sisältävät menestystekijöitä laaja-alaisemmin muista järjestelmän elinkaaren ja kehitystyön vaiheista. Viitekehyksessä on huomautettu tästä yksityiskohdasta se seikka, että vaikka toteutuksen elinkaarivaihe onkin havaittavissa monesta tekniikan osa-alueen menestystekijästä, toteutus ei ole tärkein elinkaarivaihe koko kehitysprojektissa muiden osa-alueiden menestystekijöiden takia. Tässä mielessä toiminnanohjausjärjestelmän kehityksessä ei voida keskittyä vain yhteen kehitysvaiheeseen, vaan kaikki elinkaarivaiheet vaativat jatkuvaa ja huolellista tarkastelua. (Jokinen, 2021). 31 Ensimmäinen osa-alueen menestystekijöistä on kehitysprojektin alkuvaiheista tunnistettava vaatimusmäärittely (system requirements). Tämä esitutkimuksen ja määrittelyn vaiheissa esiintyvä menestystekijä on yksi projektin kriittisimmistä toimista ja on tehtävä huolella. Jos projektin alussa epäonnistutaan vaatimusmäärittelyssä, pahimmassa tapauksessa kehitettävä järjestelmä ei tule vastaamaan sen suunniteltua käyttötarkoitusta. Tästä syystä perinpohjaisen vaatimusmäärittelyn laiminlyöminen onkin tavallisesti huomattava syy kehitysprojektien epäonnistumiseen. (Schneider ja muut, 2018, s. 151–152). Toinen kriittinen menestystekijä vaatimusmäärittelyn jälkeen tekniikan osa-alueessa on käyttäjäkokemus (user experience / UX). Termillä UX viitataan perinteisesti ohjelmiston ulkoasuun, mutta sen käyttö on laajentunut tarkoittamaan myös ohjelmiston käytettävyyttä. Käyttäjäkokemuksella viitataankin nykyään ohjelmistokehityksessä tietokoneohjelman tai järjestelmän ja sen käyttäjien väliseen vuorovaikutukseen (human computer interaction, HCI), jota myös tämä menestystekijä kuvastaa. Menestystekijän kuvauksen perusteella on helppo huomata, että tämä menestystekijä ei ole suoranaisesti aktiivinen kehitystyön aikana; sen vaikutuksen tulevat vasta esiin, kun järjestelmä otetaan lopulta käyttöön. Tästä huolimatta menestystekijä tulee huomioida jo järjestelmän suunnittelun aikana. (Hassenzahl & Tractinsky, 2006). Käyttäjäkokemuksella on vaikutusta muun muassa työntekijän nopeuteen ja tehokkuuteen työtehtävien hoidossa järjestelmän avulla. Osatekijöitä, jotka sisältyvät tähän menestystekijään, ovat muun muassa järjestelmän käytettävyys, vasteajat eri toiminnoissa, käyttöliittymä sekä loppukäyttäjän kokemus järjestelmän käytöstä (Schneider ja muut, 2018, s. 156, 160). Tilanteessa, jossa uusi toiminnanohjausjärjestelmä kehitetään vanhan tilalle, voidaan kehitysprojektissa hyödyntää vanhan järjestelmän käyttöliittymää, toimintojen työnkulkua sekä sen käyttäjien kokemuksia. Viitekehyksessä on huomautettu, että vaikka UX on mainittu menestystekijänä vain yhdessä tutkimusmateriaalin artikkelissa, on sillä suuri vaikutus lopullisen ERP-järjestelmän käytettävyyteen (Jokinen, 2021). 32 Kolmas osa-alueen kriittisistä menestystekijöistä on ohjelmatestaus (software testing). Tämä menestystekijä esiintyy viitekehyksen tutkimusmateriaalissa käyttäjäkokemuksen tavoin pienissä määrin, mutta on tästä huolimatta kehitysprojektille erittäin tärkeä työvaihe. Kuten tutkielman kappaleessa 2.1.1 ohjelmistojen elinkaarista mainittiin, on ohjelmistotestauksen varsinaisena tarkoituksena etsiä ja korjata mahdollisia virheitä kehitettävästä järjestelmästä ennen sen käyttöönottoa (Haikala & Mikkonen, 2011, s. 30, 205–206). Tässä mielessä ohjelmistotestaus ei ole ainutlaatuinen menestystekijä ERP- järjestelmien kehitysprojekteissa, vaan se voidaan identifioida myös muiden ohjelmistojen kehityksestä. (Koh ja muut, 2011, s. 389, 395). Seuraava kriittinen menestystekijä on perinnejärjestelmien hallinta (legacy system management). Perinnejärjestelmät ovat käytännössä yrityksissä jo käytössä olevia, vanhoja järjestelmiä. Nämä järjestelmät tarjoavat tavanomaisesti hyvän lähtökohdan uuden järjestelmän kehitykselle, sillä ne toimivat tietynlaisena mallina tai perustana uuden järjestelmän vaatimuksista. Tällöin uutta ERP-järjestelmää kehittävä projektitiimi voi tarkastella korvattavan järjestelmän käyttötarkoituksia ja toimintoja. Tämä mahdollistaa selkeämmän näkemyksen kehitysprojektista verrattuna tilanteeseen, jossa uusi järjestelmä kehitetään kokonaan alusta alkaen. (Koh ja muut, 2011, s. 396). Woo (2007) kuvailee perinnejärjestelmiä myös yhtenä tekijänä uuden toiminnanohjausjärjestelmän investointipäätöksessä. Hänen mukaansa perinnejärjestelmät voivat olla toisistaan hajautuneita, erillisiä ja yhteensopimattomia järjestelmiä sekä pahimmassa tapauksessa rasittaa yrityksen talouskasvua. Tällöin ERP- järjestelmän päätarkoituksen, eli yrityksen osastojen integroiminen yhteen helpommin hallittavaan kokonaisuuteen, hyödyntäminen hajautuneiden järjestelmien yhdistämisessä onkin erittäin pragmaattista (Shehab ja muut, 2004). Viitekehyksen viimeiset neljä kriittistä menestystekijää tekniikan osa-alueessa liittyvät vahvasti toisiinsa ja ovat suuri osa projektin toteutusta (Jokinen, 2021). Nämä menestystekijät ovat tiedonhallinta (data management), tietostandardit (data 33 standards) sekä tiedon laatu ja tarkkuus (data quality and accuracy). Koska yritykset ovat usein riippuvaisia järjestelmien sisältämästä datasta ja informaatiosta ja toimivat niiden varassa, on näiden yrityksien varmistettava, että käytetty data ja siitä johdettu informaatio on luotettavaa ja johdonmukaista (consistent data / correct information) (Koh ja muut, 2011, s. 393). Tämän seurauksena tietostandardit, ja suuremmalta osin tiedonhallinta, ovat tärkeitä tekijöitä kehitysprojektissa ja tulevan järjestelmän toiminnassa. 2.3.3 Projektin menestystekijät Viimeinen viitekehyksen osa-alueista on projekti. Tämä osa-alue keskittyy pääasiallisesti itse tietojärjestelmäprojektiin ja tarkastelee aihetta suoraan projektityöskentelyn näkökulmasta. Lukumääräisesti osa-alue sisältää pienimmän määrän viitekehyksestä löytyviä toiminnanohjausjärjestelmien kehityksen menestystekijöitä; osa-alueeseen on sisällytetty vain viisi menestystekijää. Huomioitavaa on se, että tästä osa-alueesta ei voida tunnistaa merkittävintä projektin elinkaarivaihetta organisaation osa-alueen tavoin, vaan projektin osa-alueen menestystekijät vaikuttavat olevan jakautuneita tasaisesti kaikkien työvaiheiden kesken. (Jokinen, 2021). Ensimmäinen viitekehyksen kriittinen menestystekijä on projektinhallinta (project management / ownership). Doherty ja muut (2012, s. 1–2) toteavat, että projektin sisäiseen tiimityöskentelyyn voidaan vaikuttaa kokonaisvaltaisesti projektinhallinnalla. Tämän avulla voidaan myös varmistaa, että projektissa toteuttava ERP-järjestelmä kehitetään sille suunnitellun aikataulun, vaatimusten ja budjetin mukaan. Puutteellinen projektinhallinta kehitysprojektin aikana nähdään Bernroiderin (2013, s. 240) mukaan esimerkiksi työtehtävien pitkittymisenä ja aikataulun venymisenä. Poba-Nzaou ja Raymond (2011, s. 185) kertovat, että heikkotasoinen projektinhallinta voi johtaa myös muihin kriittisiin ongelmiin aikataulullisten vaikeuksien lisäksi, mikä taasen nostaa projektin riskiä ja mahdollisuutta epäonnistumiseen. 34 Viitekehyksessä nostetaan esiin projektinhallinnan ohella projektin kokonaisvaltainen suunnittelu (robust planning). Hyvin toteutettu suunnittelu onkin yksi tukipilari tilanteissa, joissa yritys kohtaa korkean riskin muutoksia sen toiminnassa – kuten toiminnanohjausjärjestelmän kehittäminen ja sen käyttöönotto (Koh ja muut, 2011, s. 395). Suunnittelun aikana laadittava projektin kehys (project framework) on erityisen tärkeä, sillä se tarjoaa näkemyksen ERP-järjestelmän tarjoamista rajoitteista ja eduista (Al-Mashari ja muut, 2003; Markus ja muut, 2000). Tähän suunnitteluun sisältyy Fui- Hoon Nahin ja muiden (2001) mukaan kehitettävän ERP-järjestelmän vaatimusten ja toimintojen rajaamisen lisäksi projektin tehtävien määrittämistä (well-defined tasks) ja näiden tehtävien keston, monimutkaisuuden ja vaikeusasteen arviointia. Kolmas projektin osa-alueen kriittisistä menestystekijöistä on yrityksen budjetti ja projektin kustannukset (budget / costs). Vaikka projektin kustannusarvion laatiminen voidaan nähdä osana suunnittelua, nostetaan se hyvin usein erilliseksi menestystekijäksi (Jokinen, 2021). ERP-järjestelmän kehitysprojekti ei ole erityinen muihin projekteihin verrattuna sen budjetin näkökulmasta; mitä tarkemmin alustava talousarvio laaditaan projektin alussa, sitä paremmin projektin riskitasoa ja kustannuksia voidaan hallita (Poba-Nzaou & Raymond, 2011, s. 177–178, 181). Samalla kustannukset voivat nousta esteeksi projektin toteutumiselle yrityksen johdon tai sen osakkeenomistajien näkökulmasta; jos kehityskustannukset arvioidaan liian suureksi projektin kartoittamisessa, projekti tullaan näkemään liian kalliina investointina ja sitä ei tulla aloittamaan (Koh ja muut, 2011, s. 393). Täten projektin budjetti ja sen kustannukset tunnistetaan yleisenä menestystekijänä projektitoiminnassa. Projektin osa-alueen seuraava menestystekijä on loppukäyttäjän sisällyttäminen kehitysprojektiin (end user involvement). Loppukäyttäjät tarjoavat kehitysprojektissa mielipiteitä esimerkiksi siitä, miten he tulevat käyttämään uutta ERP-järjestelmää työssään ja miten tämän järjestelmän tulisi toimia. Erityisesti yrityksessä kauan työskennelleet käyttäjät (senior users) voivat tarjota yksityiskohtaista tietoa työprosessien kulusta. Tämän takia loppukäyttäjiä tulisi sisällyttää osaksi kehitystyötä 35 varsinkin esitutkimuksen, määrittelyn, suunnittelun sekä testauksen vaiheissa. (Elbanna, 2010, s. 45; Schneider ja muut, 2018, s. 160–165). Viimeinen viitekehyksen menestystekijä on selkeä ja realistinen projektivisio (clear and realistic project vision). Toiminnanohjausjärjestelmän kehitystiimin on ymmärrettävä, miten projekti tullaan toteuttamaan ja mitä siihen sisältyy. Viitekehyksessä projektivisiosta nostetaan esille esimerkkeinä projektin resurssit, työjärjestys ja aikataulu. Nämä osatekijät ovat merkittäviä ja jokaisen kehitystiimin kuuluvan jäsenen on oltava tietoinen omista työtehtävistä ja osittain ainakin siitä, miten nämä sitoutuvat osaksi suurempaa kokonaisuutta. (Jokinen, 2021; Shao ja muut, 2016, s. 136, 140–141). 36 3 Tutkimussuunnitelma Tässä tutkielman osiossa käydään läpi tutkimuksen suunnitelma. Tähän tarkasteluun sisältyy tutkimusongelman arviointia, tutkimuksessa hyödynnettävän menetelmän käsittelyä sekä tutkimuksen varsinaisen toteutuksen kartoittamista. Tavoitteena kappaleessa on selittää, miten tutkimus on käytännössä toteutettu. 3.1 Tutkimusongelma Kuten tutkielman johdannossa on mainittu, tämän tutkimuksen tavoitteena on tutkia toiminnanohjausjärjestelmän kehityksessä ilmeneviä kriittisiä menestystekijöitä tilanteessa, jossa järjestelmän kehitys on ulkoistettu. Tutkimus on rajattu siten, että siinä tarkastellaan vain teollisuudessa esiintyviä ERP-järjestelmien kehitysprojekteja. Suunnitelmana tutkimuksessa on analysoida kohdeyrityksen, eli toiminnanohjausjärjestelmän tilaavan ja vastaanottavan yrityksen, näkemyksiä ja tulkintoja kehitysprojektin kriittisistä menestystekijöistä ja lopulta yhdistää nämä kappaleessa 2.3 esitettyyn viitekehykseen. Tutkimuksen tavoitteen takia tutkimuksessa ei tulla olemaan vuorovaikutuksessa toiminnanohjausjärjestelmän kehittävän yrityksen kanssa, vaan huomio kiinnitetään pelkästään kohdeyritykseen. Järjestelmän kehittävää yritystä, jota tullaan nimittämään tutkimuksessa myös kehitysyrityksenä, analysoidaan vain osittain kohdeyrityksen näkökulmasta. Tutkimuksessa tarkastelussa on toiminnanohjausjärjestelmän elinkaarivaiheista ensimmäiset kuusi askelta: esitutkimus, määrittely, suunnittelu, toteutus, testaus ja käyttöönotto. Rajaus on tehty seuraamalla viitekehyksen kehittämisessä noudatettuja perusteluja kuten kirjallisuuskatsauksessa on mainittu; elinkaarivaiheiden ensimmäiset kuusi askelta voidaan tulkita tärkeimmiksi kehitettävän ERP-järjestelmän lopputuleman kannalta. Tutkimuskysymys on ”Millainen vaikutus toiminnanohjausjärjestelmien kehityksen kriittisillä menetystekijöillä on kehitysprojektiin järjestelmän tilaavan ja vastaanottavan teollisuusyrityksen näkökulmasta?”. Päämääränä tutkimuksessa on 37 laajentaa hyödynnettyä viitekehystä tarkastellusta kehitysprojektista löydettävillä havainnoilla. Tutkielman tuloksissa tullaan nostamaan esille viitekehystä vahvistavat näkemykset, minkä lisäksi tuloksissa analysoidaan ja määritellään viitekehyksen rakenteesta ja käsityksistä poikkeavat havainnot. 3.2 Tutkimuksen toteutus Tutkimusstrategiana tutkimuksessa tullaan hyödyntämään case-tutkimusta eli tapaustutkimusta. Näin tutkimuksessa voidaan keskittyä syvällisemmin itse toiminnanohjausjärjestelmän kehitysprojektiin kuin kvantitatiivisessa tutkimuksessa olisi mahdollista. Lähestymistapa mahdollistaa kehitystyölle ominaisten kriittisten menestystekijöiden tarkastelun niin inhimillisestä näkökulmasta kuin organisaation perspektiivistä, mikä on olennaista menestystekijöiden osa-alueiden analysoinnissa. Tutkimus tullaan toteuttamaan pääasiallisesti teemahaastatteluina. Haastattelut tullaan toteuttamaan etänä hyödyntämällä MS Teams viestintä- ja yhteistyöalustaa. Haastatteluissa tullaan kysymään kohdeyrityksen avainhenkilöiden mielipiteitä ja näkemyksiä yrityksen ERP-järjestelmän kehitysprojektista. Kuten johdannossa on mainittu, haastattelut toteutetaan kahdessa kierroksessa. Ensimmäisessä kierroksessa avainhenkilöiden annetaan kertoa omasta taustasta ja yrityksen kehitysprojektista vapaasti, johtamatta keskustelua sen tarkemmin. Toisessa kierroksessa avainhenkilöille esitetään avoimia kysymyksiä viitekehystä seuraamalla. Kummatkin kierrokset järjestetään saman haastattelukerran aikana. Avainhenkilöiksi on valittu kohdeyrityksestä neljä henkilöä: yrityksen toimitusjohtaja, talouspäällikkö, IT-arkkitehti ja ostopäällikkö. Näin tutkimuksessa saadaan laaja näkemys kehitysprojektista haastattelemalla kohdeyrityksen eri osastojen henkilöstöä. Tutkimusmateriaalia kerätään seuraamalla liitteistä löytyviä haastattelukysymyksiä (ks. Liite 1), kirjoittamalla kokousmuistiinpanoja, nauhoittamalla ja litteroimalla haastattelut sekä arvioimalla muuta kommunikointia kohdeyrityksen kanssa, kuten sähköposteja. 38 Tutkimusmateriaalin keräämisen jälkeen materiaalia tullaan analysoimaan ja siitä esiin nousevia tekijöitä verrataan viitekehyksen näkemyksiin. Tunnistetut menestystekijät tullaan nostamaan esiin ja mahdolliset eroavaisuudet viitekehykseen eritellään kappaleessa 4. 3.3 Kohdeyrityksen käsittely Olennaista on huomioida, että eettiset näkökohdat ovat erittäin tärkeitä kaikissa tutkimuksissa. Täten myös tälle tutkimukselle on perusteltua, että tutkimukseen osallistuvat osapuolet ovat täysin tietoisia osallistumisestaan ja roolistaan. Tutkimuksessa pyritään suojaamaan tutkimuksessa analysoitavan yrityksen liikesalaisuuksia ja identiteettiä yrityksen esittämän pyynnön mukaisesti. Tämä on toteutettu muun muassa viittaamalla tarkasteltuun yritykseen vain termillä ”kohdeyritys” ja kuvailemalla yritystä ja sen henkilöstöä vain siinä tarkkuudessa, mikä on tutkimukselle oleellista. Kohdeyrityksen nimen ja tietojen suojaamisen lisäksi kohdeyrityksen haastatteluista koottua ja muuten kerättyä tutkimusmateriaalia hyödynnetään vain kohdeyrityksen johdon luvalla. Yrityksellä on oikeus kieltäytyä tarjoamasta tietoa tekijöistä, jotka voivat aiheuttaa vahinkoa toiminnalle tai paljastaa yrityksen identiteetin, ja vaatia näiden tietojen muuttamista tai poistamista tutkimuksesta ennen sen julkaisua. Tutkimuksessa toteutetut toimet kohdeyrityksen informaation ja tutkimusmateriaalin käytöstä on kommunikoitu niin haastatteluissa kuin liitteistä löytyvän saatekirjeen muodossa (ks. Liite 2). 39 4 Tutkimustulokset Tässä tutkielman kappaleessa tullaan tarkastelemaan tutkimuksen kulkua sekä sen tuloksia. Siinä kerrotaan, miten tutkimusmateriaali kerättiin ja miten sitä on käsitelty analysointia varten. Tutkimustulokset on esitelty seuraamalla toiminnanohjausjärjestelmän elinkaarivaiheita eli projektin varsinaista kulkua. Kappaleen lopussa esille nostetaan tutkimuksen havaintojen perusteella muokattu ja päivitetty viitekehys. 4.1 Tutkimusmateriaalin keräys ja käsittely Tutkimuksessa tarkasteltu tutkimusmateriaali on kerätty haastatteluista ja muusta kommunikaatiosta kohdeyrityksen kanssa. Haastattelut toteutettiin 60–90 minuutin etätapaamisissa hyödyntämällä MS Teams -sovellusta. Nämä haastattelut dokumentoitiin niin kokousmuistiinpanojen avulla kuin nauhoittamalla keskustelut. Nauhoitettua materiaalia käytettiin vastausten litteroinnissa. Tässä prosessissa hyödynnettiin MS Office 365 Stream -toimintoa, joka mahdollistaa videomateriaalin automaattisen suomenkielisen tekstityksen. Tämä tekstitys käännettiin tekstitiedostoon, jossa esiintyvät virheet korjattiin seuraamalla alkuperäisiä nauhoituksia. Litteroitu materiaali jäsenneltiin ja analysoitiin seuraamalla kirjallisuuskatsauksessa käsiteltyä ERP- järjestelmien elinkaarta ja sen erinäisiä vaiheita. Yrityksen liikesalaisuuksia sekä henkilöstön ja yrityksen identiteettiä suojattiin hävittämällä haastatteluiden nauhoitukset ja litteroinnit ennen tutkimuksen julkaisua. Haastattelut etenivät liitteistä löytyvien kysymysten varassa (ks. Liite 1). Yrityksen avainhenkilöitä pyydettiin aluksi kertomaan lyhyesti työasemastaan sekä vastuualueistaan kohdeyrityksessä. Tämän lisäksi henkilöt kertoivat omista näkemyksistään kehitysprojektista vastaamalla avoimiin kysymyksiin, kuten ”Miten kehitysprojekti on edennyt?”, ”Mitä ongelmia kehitysprojektissa on kohdattu?” ja ”Mikä on onnistunut projektin aikana?”. Tämän lisäksi henkilöitä ohjeistettiin ilmaisemaan 40 näkemyksiään projektista vapaalla kommentilla. Taustaa ja omia näkemyksiä selvittäviä kysymyksiä (kierros I) hyödynnettiin avainhenkilön toimenkuvan ymmärtämisessä ja viitekehyksestä poikkeavien menestystekijöiden tunnistamisessa. Toisessa kierroksessa esitetyillä kysymyksillä tutkimuksessa pyrittiin ymmärtämään suoraan viitekehyksen kriittisiä menestystekijöitä. Nämä kysymykset (ks. Liite 1, kierros II) seurasivat kehitystyön ja järjestelmän elinkaarivaiheiden määrittelemää menestystekijöiden esiintymisjärjestystä viitekehyksessä esiintyvän kriittisten menestystekijöiden järjestyksen sijaan. Tämä jäsentely nähtiin olevan sopivampi haastatteluihin sekä selkeämpi haastatelluille avainhenkilöille. Jäsentelyn lisäksi osa menestystekijöiden aihealueista yhdistettiin yhteen kysymykseen. Esimerkiksi kysymykset yrityksen resursseista ja budjetista on esitetty peräkkäin menestystekijöiden samankaltaisten aiheyhteyksien takia ja kysymykset tietojenhallinnasta, -standardeista, sekä informaation tarkkuudesta ja laadusta on yhdistetty yhdeksi kysymykseksi. Merkittävä huomioon otettava asianhaara ensimmäisen kierroksen kysymysten vastauksista oli se yksityiskohta, että jokainen yrityksen eri osastoilla toimiva avainhenkilö kuvaili yrityksen niin vanhaa kuin uutta ERP-järjestelmää työlleen välttämättömäksi työkaluksi. Esimerkiksi informaation kerääminen ja analysointi, yritysprosessien ohjaaminen, työn johtaminen ja päätösten tekeminen muiden aihealueiden ohella ei onnistuisi kohdeyrityksessä ilman käyttökelpoista toiminnanohjausjärjestelmää. Tämä näkemys havainnollistaa projektin ja sen lopputuleman merkitystä kohdeyrityksessä. Havainnon perusteella yrityksen voidaan tulkita kiinnittäneen paljon huomiota projektin ongelmakohtiin. Toisin sanoen, avainhenkilöiden sitoutuminen projektiin on mahdollistanut kriittisten menestystekijöiden tarkastelun yrityksessä monesta eri näkökulmasta ja toiminnallisesta alueesta. 41 4.2 Projektin menestystekijät Kohdeyrityksen toteuttama projekti sisälsi suuren osan viitekehyksen kriittisistä menestystekijöistä. Osa menestystekijöistä on esiintynyt projektin aikana kohdeyrityksessä viitekehyksen näkemyksistä eroavalla tavalla. Näitä havaintoja ja eroavaisuuksia on käsitelty seuraavissa alaluvuissa. 4.2.1 Projektin alkuvaiheet Kohdeyrityksen alkuvaiheissa tärkeimpänä tekijänä nähtiin projektin perustelu. Kohdeyrityksessä koettiin, että käytössä ollut vanha toiminnanohjausjärjestelmä oli esteenä toivotuille kehitystoimille. Esimerkiksi yrityksen asiakkaiden pyytämät muutokset tai lisäykset eivät käytännössä olleet mahdollisia tai niiden toteutus olisi vienyt jopa pahimmassa tapauksessa vuosia. Vanhan järjestelmän hyödyntämä teknologia oli jämähtänyt vuosikymmenten taakse, jolloin yrityksen IT-kyvykkyydet ERP- järjestelmän suhteen jäivät kriittisten, toimintaa uhkaavien ohjelmistovirheiden ja vikojen korjaamiseen. Uutta järjestelmää lähdettiin määrittelemään ja suunnittelemaan näiden ongelmien ratkaisemiseksi. Projektin tarpeellisuutta yrityksessä kuvailtiin koko kohdeyrityksen yhteisenä näkemyksenä niin johdon kuin muun henkilökunnan puolesta. Projektin aloittamisesta ja sen perusteista kommunikointi tapahtui yrityksen intranetin tiedotteen kautta. Henkilöstön alustavat näkemykset vanhan järjestelmän heikkouksista tukivat tätä päätöstä ja esitettyjä syitä projektin toteuttamisesta ei kyseenalaistettu. Tämän pohjalta projektin perustelu on tarjonnut hyvän lähtökohdan kehitystyölle. Kyseinen menestystekijä onkin ollut suuressa asemassa yhtenä projektin kriittisenä menestystekijänä. Toinen projektille tärkeimmistä kysymyksistä projektin perustelun jälkeen oli kehitysyrityksen valinta. Kehitysyritys valittiin projektiin alihankkijaksi yritysten projektia 42 edeltävän yhteistyön ja historian vuoksi. Kehitysyritys oli ollut mukana vanhan ERP- järjestelmän ylläpidossa ja oli tätä kautta saanut paremman näkemyksen kohdeyrityksestä ja vanhasta järjestelmästä. Kun esitutkimus järjestelmästä ja projektista saatiin alkuun, kohdeyrityksessä tarkasteltiin vaihtoehtoja kumppanista kehitysprojektiin. Tämä tarkastelu ei vienyt pitkään edellä mainittujen seikkojen takia. Päätökseen vaikutti kuitenkin myös projektille sopivan ohjelmistotalon saatavuus. Kehitysprojektin koon ja sen laajojen vaatimusten vuoksi pienet ohjelmistoja kehittävät yritykset eivät soveltuneet projektiin. Tämä pienensi valikoimaa huomattavasti ja vahvisti vanhan yhteistyökumppanin asemaa valintaprosessissa. Kehitystyön alussa projektissa kartoitettiin uuden järjestelmän vaatimuksia. Tavoitteena uuden järjestelmän kehityksessä oli luoda toiminnanohjausjärjestelmä, joka modernisoi ja toteuttaa vanhan järjestelmän toiminnallisuuden kokonaisuudessaan uudella teknologialla. Kohdeyrityksen toimitusjohtaja kertoi, että uuden ERP-järjestelmän tuli olla vanhan järjestelmän nykyaikaistamisen lisäksi joustava ja jatkokehitettävä. Vaatimusten takia markkinoilta saatavat pakettiratkaisut karsiutuivat projektista ulos. Esimerkiksi SAP:in tarjoama toiminnanohjausjärjestelmä koettiin ”äärettömän hankalaksi ja kalliiksi” tilanteessa, jossa järjestelmän toiminnot tai käyttö tulisi muuttumaan sen alkuperäisestä kehitystarkoituksesta. Valmisratkaisujen tarjoamien etujen ja haittojen tarkastelussa hyödynnettiin muun muassa nelikenttäanalyysiä kohdeyrityksen projektille laatiman johtoryhmän toimesta. Vaatimusmäärittelyn elinkaarivaihetta johdatti kohdeyrityksen monipuolinen ja selkeä näkemys oman yrityksen prosesseista. Tämä kokonaisvaltainen yrityskuva auttoi kohdeyritystä ymmärtämään omat tavoitteensa ja tarpeensa niin projektin kuin tulevan järjestelmän suhteen, mikä taasen paransi kommunikaatiota aiheesta kehitysyrityksen kanssa. Tällainen menestystekijän ilmentymä tukeekin viitekehyksen visiota kokonaisvaltaisesta yrityskuvasta toiminnanohjausjärjestelmän ulkoistetun kehityksen kohdalla. Haastatteluissa havaittu avainhenkilöiden ajattelutapa kohdeyrityksestä, oman osaston toiminnasta ja osastojen välisestä yhteistoiminnasta kuvastavat vahvaa 43 ymmärrystä yrityksen ydin- ja tukitoiminnoista. Yrityksen holistinen näkemys on ollut olennaista niin projektin määrittelyssä ja suunnittelussa, kuin toteutuksessa. Kokonaisvaltaisen yrityskuvan tarjoaman näkökulman lisäksi vaatimusten määrittelyssä oli mukana myös projektiin valitun ulkoisen toimittajan näkemykset. Kehitysyritys tarjosi vaihtoehtoja muun muassa valmisratkaisuista sekä omia näkemyksiään siitä, mitä järjestelmältä tulisi vaatia. Käytännön esimerkki yhdestä toimittajan ehdottamasta järjestelmän toiminnallisuudesta ilmentyi hakutoiminnoissa. Vanhan järjestelmän ikääntynyt ja vaillinainen funktionaalisuus tiedon hakemisessa nykyaikaisella teknologialla toteutettuihin järjestelmiin verrattuna oli normalisoitunut kohdeyrityksen ajattelutapaan ja siten sitä ei suoraan vaadittu. Tällainen järjestelmän toiminta nähtiinkin kohdeyrityksessä jossain määrin ylimääräisenä, jatkokehityksen alaisena aihealueena. Näin kehitysyritys kykeni tuomaan projektiin uusia ja hyödyllisiä vaatimuksia, jotka olisivat jääneet muuten sen alkuperäisen laajuuden ulkopuolelle. Vaatimusmäärittelyssä projektille asetetut vaatimukset ohjasivat kehitysyritystä toiminnanohjausjärjestelmän suunnittelussa. Tässä projektin työvaiheessa kehitysyritys keräsi kohdeyrityksestä käyttäjätarinoita jokaiselta vanhan ERP-järjestelmän käyttäjältä, tallensi järjestelmän toimintoja niin videolle kuin kirjallisiin kuvauksiin ja visualisoi käyttöjärjestelmää ja sen valikoita. Näiden toimien lisäksi kehitysyritys kävi läpi vanhan järjestelmän lähdekoodia. Kohdeyritys oli mukana suunnittelun elinkaarivaiheessa esittelemässä kehitysyritykselle vanhan järjestelmän toimintoja ja selventämässä yritystoimintoja, joita järjestelmän tuli toteuttaa. Kohdeyrityksen projektille kokoama johtoryhmä toteutti työtehtävien ja projektin vastuualueiden delegoinnin yrityksen sisällä. Projektin alkuvaiheista jäljelle jäänyt kriittinen menestystekijä on minimaalinen ohjelmiston mukauttaminen. Kohdeyrityksen valitsema lähtökohta vanhan toiminnanohjausjärjestelmän toimintojen modernisoinnista antaa viitteitä laajasta ohjelmiston räätälöinnistä. Tällaisessa mittavassa ohjelmistoprojektissa on iso riski 44 kehittää viallisista ja ongelmallisista ydintoiminnoista riippuvia aliohjelmia, kuten viitekehyksessä on mainittu. Menestystekijää on kuitenkin vaikea arvioida tarkemmin sen vaikutuksien ollessa näkyvissä vasta ERP-järjestelmän käytössä ja ylläpidossa. Toisaalta, haastatteluista saadun näkemyksen mukaan kehitettävää ERP-järjestelmää ei ole kuitenkaan suunniteltu toteuttamaan uusia lisätoimintoja vanhan järjestelmän toteuttamiin operaatioihin verrattuna. Tämä saattaa vähentää ohjelmistomukauttamisesta aiheutuvia ongelmia. Ohjelmiston mukauttamista ei toteutettu uusien toimintojen kohdalla, sillä projektissa on keskitytty vain vanhan toiminnallisuuden yksinkertaistamiseen ja siirtämiseen uuteen teknologiaan. Samalla kehitysprojektissa ei ole käytössä pakettiratkaisuja, mikä myös vähentää mahdollisia ongelmia ohjelmistomukauttamisessa. Joka tapauksessa, menestystekijästä ilmenevien seurausten syvällisempi tarkastelu jää tutkimuksen rajausten ulkopuolelle. 4.2.2 ERP-järjestelmän toteutus Koska projektihallinta on toteutettu eräänlaisena yhdistelmänä vesiputousmallia ja ketterän kehityksen metodologiaa, osa sen elinkaarivaiheista on jakautunut toistettaviin jaksoihin. Projektin alussa hyödynnetty vesiputousmallin mukainen määrittely ja suunnittelu rakensivat pohjan toteutuksen ja testauksen iteraatiokierroksiin. Tässä toteutustavassa kohdeyrityksen toimintaa ohjasi suunnittelun alkuvaiheissa koottu johtoryhmä, joka koostui toimitusjohtajan lisäksi projektille oleellisista henkilöistä, muun muassa IT- ja taloushenkilöistä. Kohdeyrityksen koon takia yrityksessä ei ole erillistä asemaa prosessi- ja muutosjohtamiselle. Tämän seurauksena vastuu projektin edistymisestä ja sen seuraamisesta kohdeyrityksen sisällä lankesi kyseiselle johtoryhmälle. Olennaisin asema projektin hallinnassa oli kohdeyrityksen toimitusjohtajalla sekä haastatellulla IT- arkkitehdillä, joka toimi hankkeessa projektipäällikön virallisessa asemassa. Projektissa olivat mukana myös kehitysyrityksen puolelta toimi- ja päätösryhmät, jotka vastasivat 45 muun muassa projektin aikatauluttamisesta. Näiden kehitysyrityksen projektille nimittämien ryhmien tarkastelu tapahtuu kuitenkin tutkimuksessa vain haastateltujen avainhenkilöiden näkökulmasta. Muita projektille olennaisia sisäisiä sidosryhmiä johtoryhmän lisäksi olivat kohdeyrityksen erilliset osastot ja näissä toimiva henkilöstö. Kommunikointi projektista näiden sidosryhmien välillä tapahtui samalla tavalla kuin tavallinen, yritystoiminnalle oleellinen viestintä. Tiedonvälitys tapahtui muun muassa sähköpostien, intranetin, puheluiden ja digitaalisten viestien avulla sekä kokouksissa kasvotusten tai etänä. Havaittavia puutteita kohdeyrityksen informaationvälityksessä ei haastattelujen perusteella identifioitu. Kaikki vastaukset kommunikaatiosta antavat viitteitä onnistuneesta informaationkulusta. Johtoasemissa toimineet haastatellut avainhenkilöt kuvailivat kommunikointia projektista tavanomaiseksi. Sidosryhmien välisen tuloksellisen kommunikoinnin lisäksi kehitysprojektia ja sen toteutumista on tukenut sidosryhmien sitoutuminen projektiin. Projektin alkuvaiheissa huolellisesti toteutettu kommunikointi uuden järjestelmän tarpeellisuudesta vahvisti kohdeyrityksen henkilöstön omistautumista projektin onnistumiselle. Kohdeyrityksen sisäiset sidosryhmät mahdollistivat myös loppukäyttäjien sisällyttämisen osaksi kehitystyötä. Käyttäjiä otettiin mukaan kehitysprojektiin jo sen alkuvaiheilla monesta yrityksen osastosta. Työntekijät, jotka olivat olleet kauan asemissaan ja siten tunsivat hyvin työtehtävänsä sekä vanhan toiminnanohjausjärjestelmän toiminnot, olivat tärkeä osa niin vaatimusmäärittelyä, vanhan järjestelmän kartoittamista, kuin uuden ERP-järjestelmän myöhempää testaamista. Kaikkia kohdeyrityksen työntekijöitä ei ollut kuitenkaan mahdollista tai asianmukaista ottaa mukaan kehitystyöhön, vaan loppukäyttäjiä valittiin – kun mahdollista – kehitysprojektiin heidän kokemuksensa mukaan. Haastateltu ostopäällikkö kertoi, miten osastonsa henkilökunta oli toiminnassa mukana. Ostotiimin pienempi koko esimerkiksi myynnin henkilöstöön verrattuna mahdollisti 46 suuremman osan osaston osallistumisesta ja siten laaja-alaisen näkökantojen jakamisen vanhan ja uuden järjestelmän toiminnoista ja vaatimuksista. Yksi ostopäällikön jakama käytännön esimerkki liittyi vanhan toiminnanohjausjärjestelmän rajoituksiin. Ostossa oli aikaisemman järjestelmän käytössä ongelmia muun muassa näkyvyyden kanssa. Tässä tilanteessa esimerkiksi raaka-ainetietojen hakeminen vanhan järjestelmän tietokannasta ei onnistunut suoraan raaka-aineen nimellä. Tämä korjattiin uudessa ERP-järjestelmässä. Loppukäyttäjien esittämät samankaltaiset vaatimukset järjestelmän toiminnallisuudesta ohjasivatkin koko projektin kehitystä myös muiden osastojen kohdalla. Tämän lisäksi loppukäyttäjät olivat mukana ERP-järjestelmän testauksessa ja palautteenannossa. Uutta ERP-järjestelmää kehitettiin myös huomioimalla käyttäjäkokemus. Loppukäyttäjien sisällyttäminen kehitysprojektiin tuki huomattavasti tätä prosessia. Miltei kaikki haastatellut henkilöt nostivat esille järjestelmän käytettävyyden ja vasteajat järjestelmän vaatimuksissa käyttäjäkokemuksen kohdalla. Tapa käyttää vanhaa järjestelmää on hyvin erilainen nykyaikaisiin tietojärjestelmiin verrattuna ja tuki uusia toimintoja varten haluttiin sisällyttää osaksi uutta järjestelmää. Tämä lähestymistapa valittiin, koska vanhassa järjestelmässä tiedon syöttäminen ja käyttöliittymän navigointi oli erittäin ikääntynyt. Esimerkiksi navigointi järjestelmässä tapahtui kokonaan näppäimistöllä; ohjelmisto ei tukenut hiiren käyttöä. Jos käyttäjä halusi esimerkiksi hyödyntää jotain tiettyä aliohjelmaa, tuli hänen joko tietää ohjelman tunnistekoodi ja syöttää se valintaruutuun tai selata pitkä lista valikoita ohjelman manuaalista valintaa varten. Aliohjelman avautuessa käyttäjän ruutu oli täynnä toiminnon tarjoamia tietoja sekä mahdollisia syöttökenttiä, joiden välillä navigointi tapahtui ns. ”tabulaattorilla” (tab) ja enter-näppäimellä. Rajoittava käyttöliittymä haluttiinkin päivittää uusille työntekijöille lähestyttävämmäksi. Huomattavaa on se, että osa muutoksista käyttöliittymän ulkoasuun (UX) koettiin vaikeina muutaman pitkäaikaisen työntekijän kohdalla. He olivat tottuneet, että kaikki informaatio olisi esitetty ruudulla samanaikaisesti ja että tiedon syöttäminen olisi suoraviivaista. Yksi mallitapaus näiden työntekijöiden vaikeudesta sopeutua uuteen 47 UX:ään, oli pudotusvalikot eräiden syöttökenttien kohdalla. Esimerkiksi toimitustavan kirjaaminen järjestelmään asiakastilausta tallentaessa tapahtui syöttämällä sopiva numerokoodi vastaavaan kenttään, muun muassa koodi ”106” vastasi postilla toimitettavaa tilausta. Uudessa järjestelmässä nämä vaihtoehdot on sisälletty pudotusvalikoihin. Vaikka näiden vaihtoehtojen suora kirjoittaminen kenttään olisi onnistunut valikon käyttämisen lisäksi, asia koettiin siltikin ”hankalaksi”. Kyseinen havainto kuvastaa osittaista muutosvastarintaa, joka nähtiin muuten kohdeyrityksessä minimaalisena tekijänä. Suorituskykyä ja projektin edistymistä seurattiin hyödyntämällä Microsoftin ohjelmistoa, Azure DevOpsia. Kyseinen ohjelmisto soveltuu hyvin ketterän kehityksen metodologiaa seuraavaan ohjelmistotyöhön, minkä takia ohjelmisto valittiinkin osaksi kehitysprojektin toteutusta. Kohdeyritys käytti DevOpsia esimerkiksi käyttäjätarinoiden ja työtehtävien suunnittelussa, hajauttamisessa ja seuraamisessa. Kun uusi työtehtävä (bug/task) luotiin, siirrettiin se tehtävälle oleelliselle henkilölle. Esimerkiksi asiakkaan ostotilausta käsittelevän toiminnon tarkemman kuvauksen luonti annettiin kohdeyrityksen myyntihenkilöstölle suoritettavaksi. Kuvauksen valmistuessa tehtävä kuitattiin valmiiksi ja uusi tehtävä toiminnon toteuttamisesta luotiin kehitysyrityksen päässä. Näin projektin eri vaiheissa olevia tehtäviä voitiin seurata ja projektin suorituskyvyn arviointi oli mahdollista. Muita suorituskykymittareita (KPI) ei kohdeyrityksessä seurattu. Tiedonhallinta on toteutettu kohdeyrityksessä tiedonsyötössä ja -luonnissa. Vanha ja uusi toiminnanohjausjärjestelmä sisältävät tietotarkistuksia niiden jokapäiväisessä käytössä. Nämä tarkistukset varmistavat, että ERP-järjestelmän käyttämä informaatio on oikeassa muodossa sekä laadukasta ja luotettavaa. Kun järjestelmään syötetään informaatiota, annettu tieto tarkistetaan pakollisten kenttien olemassaolon, tietotyyppien tarkkuuden sekä vastaavien kriteereiden mukaan. Kohdeyrityksen käyttämä tietokanta sisältää muun muassa yritysprosesseissa hyödynnettäviä perus-, vertailu- ja tapahtumatietoja (master, reference ja transaction 48 data). Kyseistä dataa ei tarkisteta suoraan sen tietokannassa, vaan kaikki varmistusmenettelyt on toteutettu joko tiedon luonnissa tai sen käytössä, esimerkiksi raporttien luonnissa. Tarkempaa informaatiota kohdeyrityksen käyttämästä tietokannasta tai sen hyödyntämästä teknologiasta ei tässä tutkimuksessa mainita erikseen. Molemmat ovat erikoisia ja harvemmin käytettyjä ja kohdeyrityksen identifioiminen olisi täten helpompaa, mikä olisi tutkimuksen tavoitteiden vastaista. Tiedonhallinnan lisäksi kehitysprojektin toteutuksessa oli oleellista huomioida yrityksen muut tietojärjestelmät. Vaikka toiminnanohjausjärjestelmän päätarkoitus on yrityksen erilaisten liiketoimintaprosessien ja osastojen tuominen yhteen helposti hallittavaan kokonaisuuteen, yrityksillä saattaa olla käytössä myös muita tietojärjestelmiä. Kohdeyrityksessä tällaisia järjestelmiä ovat muun muassa raaka-aineiden sekä valmistuotteiden automaattiset varastointijärjestelmät. Näiden perinnejärjestelmien kohdalla kohdeyrityksessä haluttiin säilyttää järjestelmiä yhdistävät rajapinnat. Tiedonvälitys järjestelmien kesken pidettiin vanhan mallin mukaisena, jotta tiedonkulku ja järjestelmien toiminnallisuus voitiin testata ja uusi toiminnanohjausjärjestelmä ottaa käyttöön, toimitusjohtajan sanoin, ”jouhevasti”. Viimeinen toteutusvaiheen kriittinen menetystekijä, kulttuuriristiriita, ei ollut projektissa helposti tunnistettavissa. Vaikka molemmat yritykset toimivat kansainvälisillä markkinoilla, yrityksien työllistämät toimijat ymmärsivät toisiaan ja näiden osapuolten toimintatavat eivät olleet keskenään ristiriidassa. Koska kohdeyritys perustuu Suomeen, oli kehitysyrityksen kotimainen osasto suuri etu projektissa. Tästä huolimatta yritysten toiminnasta on mahdollista tunnistaa yksi huomattava ero, joka pohjautuu yritysten kokoon. Molemmat yritykset luokitellaan suuriksi yrityksiksi, mutta kehitysyrityksen varsinainen koko on moninkertainen kohdeyritykseen verrattuna. Tämän seurauksena yritysten työkulttuurien välillä esiintyi eroavaisuuksia liiketoimintaprosesseissa ja näitä prosesseja ohjaavissa organisatorisissa rakenteissa. 49 Yritysten työkulttuurien välinen ero on etupäässä tunnistettavissa haastateltujen, johtoryhmään kuuluvien henkilöiden vastauksista. Kohdeyrityksessä koettiin, että järjestelmän kehittävässä yrityksessä oli selvä siirtymä päätöksenteon ja toteuttavan tasojen välillä. Haastatellun talouspäällikön mukaan kohdeyrityksen omistajat ovat vahvasti mukana yrityksen jokapäiväisessä toiminnassa ja päätöksenteossa. Siten he ymmärtävät, mitä kohdeyrityksessä tavallisesti tapahtuu ja mihin suuntaan yrityksessä ollaan menossa. Kehitysyrityksen toiminta koettiin päinvastaisena. Kyseisen yrityksen ylin johto ei alun perin ymmärtänyt kehitettävän toiminnanohjausjärjestelmän laajuutta aiemmasta yhteistyöstä huolimatta, minkä seurauksena he lupasivat projektille turhan optimistisen aikataulun ja arvioivat kustannukset liian alhaisiksi. Tämä näkemys kuvastui myös kehitysyrityksen tarjoamassa sopimuksessa järjestelmän kehittämisestä. Kohdeyrityksen kommunikointi projektille luvatuista liian positiivisista tekijöistä ennen sopimuksen solmimista kohtasi taasen argumentointia kehitysyrityksen taustasta ja ammattitaidosta. Haastateltu kohdeyrityksen IT-arkkitehti kommentoi asiaa vastaavasti: ”Huolimatta aikaisemmasta yhteistyöstä vanhan järjestelmän parissa, syvällisempi vanhan järjestelmän tarkastelu hylättiin ennen sopimuksen tekoa. Toimittaja osoitti, että he ovat asiantuntija tällaisten järjestelmien kehittämisessä ja tietävät, mitä tekevät. Tämän seurauksena itsekin aloin kyseenalaistamaan vanhan järjestelmän monimutkaisuutta.” (parafraasi). Kehitysyrityksen vetoomus omaan ammattitaitoon ja kokemukseen vakuuttivat kohdeyrityksen ja sopimus solmittiin jälkeenpäin katsottuna projektille liian lyhyellä aikataululla ja liian alhaisella hinnalla. Tämä aiheutti myöhempää kädenvääntöä sopimuksen sisällöstä ja kehitysyrityksen vastuualueista, kun projektin kesto ja kustannukset kasvoivat. Kohdeyrityksen näkemys aiheesta kuvastaa, miten yritysten rakenteellinen ero, ja siten toiminnallinen kulttuuriristiriita, aiheutti kitkaa projektissa. Kehitysyrityksen organisatorinen rakenne eristää päätöksen- ja kaupanteon yrityksen tietojärjestelmiä kehittävästä tasosta, mikä todennäköisesti johti kommunikointivirheisiin ja väärinymmärryksiin kohdeyritykselle kehitettävän järjestelmän laajuudesta näiden 50 tasojen välillä. Projektille alussa solmittu problemaattinen sopimus aiheutti myöhempää näkemyseroa projektin skaalasta, kun kehitysyrityksen projektia toteuttava osasto koki painetta ylemmältä tasolta saada kehitysprojekti valmiiksi aikataulun pidentyessä ja kustannusten kasvaessa. Kohdeyrityksessä asiaa ei nähty positiivisena ja toiminnassa vahvasti mukana olleet omistajat vaativatkin järjestelmän perusteellista toteuttamista. Tämän seurauksena kulttuuriristiriita onkin ollut yksi projektin ongelmallisimmista menestystekijöistä, jonka perusteellinen tarkastelu ennen projektin alkua olisi mahdollisesti vähentänyt kohdeyrityksen kohtaamia ongelmia. 4.2.3 Projektin lopetus ja järjestelmän käyttöönotto Projektin ja toiminnanohjausjärjestelmän valmistuessa jäljelle jäi sen toimintojen testaus. Kuten edellisessä alakappaleessa on mainittu, on tämä elinkaarivaihe jakautunut moneen iteraatiokierrokseen toteutuksen tavoin. Ohjelmatestausta suoritettiin projektin aikana kohdeyrityksessä ketterän kehityksen iteraatiojaksojen lopussa jokaisen jaksossa kehitetyn toiminnon osalta. Kehitysyritys osoitti testitehtäviä (test plan) kohdeyrityksen henkilöstölle näiden vastuualueiden mukaan. Kohdeyrityksen toteuttamat testitehtävät koostuivat esimerkiksi arkipäiväisten toimintojen suorittamisesta uudella järjestelmällä. Jos ERP- järjestelmää testaava loppukäyttäjä kohtasi prosessin aikana ongelmia, kirjasi käyttäjä nämä huomiot testiraporttiin DevOpsissa. Testien perusteella kehitysyritys jatkoi joko kyseisen aliohjelman viimeistelyä tai muiden toimintojen kehittämistä. Kyseinen prosessi jatkui järjestelmän käyttöönottoon saakka. Näin projektissa minimoitiin ohjelmistovirheitä, mikä näkyi esimerkiksi ERP-järjestelmien vaihdossa ja uuden käyttöönotossa. Kuitenkin ennen toiminnanohjausjärjestelmien vaihtoa kohdeyrityksessä valmistauduttiin uuden järjestelmän tuloon kouluttamalla ERP-järjestelmää työssään hyödyntäviä henkilöitä. Osa näistä työntekijöistä oli jo tutustunut uuteen järjestelmään 51 kehitysprojektin edetessä. Esimerkiksi ne henkilöt, jotka olivat osana toimintojen testausta, saivat hyvän ymmärryksen uuden järjestelmän käytöstä. Nämä henkilöt tunnistettiinkin tehokäyttäjiksi, jotka kykenivät tarjoamaan apuaan muulle henkilökunnalle. Muut työntekijät, jotka eivät olleet mukana kehitysprojektissa missään muodossa, saivat ohjeistuksen ja läpikäynnin järjestelmän näille henkilöille oleellisista toiminnoista. Kaikki ERP-järjestelmän käyttäjät kävivät läpi myös oman työnsä vaatimat rutiinitoiminnot askel askeleelta ja täten varmistivat, että kykenivät toteuttamaan työtehtävänsä uudella järjestelmällä. Järjestelmän käyttöönotto ja sen toiminnallisuuden tarkistus suoritettiin kohdeyrityksessä neljän päivän aikana. Järjestelmien vaihto ajoitettiin pekkaspäivillä, eli työnajan lyhennysvapaan pitkittämälle viikonlopulle, jolloin järjestelmän seisokkiaika ei aiheuttanut yrityksessä ongelmia. Vanhan ERP-järjestelmän vaihtaminen uuteen järjestelmään onnistui ongelmitta ja yrityksen henkilökunta kykeni jatkamaan työtänsä uudella toiminnanohjausjärjestelmällä seuraavana päivänä. Tällä lailla kehitysprojekti saatiin päätökseen ja järjestelmän ylläpito sekä jatkokehitys voitiin aloittaa. 4.2.4 Monivaiheiset menestystekijät Projektista on havaittavissa myös kriittisiä menestystekijöitä, jotka voidaan luokitella aktiivisiksi jokaisessa projektin elinkaarivaiheessa. Esimerkiksi projektivisio on menestystekijä, jonka vaikutukset voidaan tunnistaa kaikista projektin työvaiheista. Kyseinen kriittinen menestystekijä näkyi kohdeyrityksen kehitysprojektissa selvästi. Kohdeyritys oli alusta alkaen tietoinen tarpeistaan ja siitä, mitä projekti edustaa näiden tarpeiden täyttämisessä. Haastateltu toimitusjohtaja kuvasi projektin tarkoitusta vanhan ERP-järjestelmän uudistamisesta muuttumattomana koko projektin ajan. Tämä visio rakensi selvän projektin määränpäästä ja sen tavoitteista. Näin projektissa voitiin keskittyä uuden toiminnanohjausjärjestelmän kehittämiseen eikä projektia tarvittu kohdistaa uudelleen. 52 Toinen monivaiheinen menestystekijä on muutosvastarinta. Tämä menestystekijä ei esiintynyt laaja-alaisesti kohdeyrityksessä. Projektin alussa määritelty projektin perustelu asetti vahvan kulmakiven kohdeyrityksen asenteille projektista ja esti virheellisten näkemysten ilmentymisen. Uuden järjestelmän tarpeellisuus vakuutti mahdolliset toisinsanojat tai projektin vastustajat. Tämä positiivinen näkemys järjestelmästä ja sen tarjoamista parannuksista työntekoon rajoitti muutosvastarinnan syntymistä. Ainoa seikka, joka aiheutti vastustusta, olikin käyttöliittymän muuttuminen uudenlaiseksi. Kun uuden järjestelmän esittämät ruudut sisälsivät informaatiota uudessa muodossa tai järjestyksessä, osa käyttäjistä reagoi negatiivisesti uuteen käyttöliittymään ja siihen perehtymiseen. Muuten haastatteluista saadun näkemyksen mukaan kohdeyrityksessä ei koettu muutosvastarintaa muissa muodoissa. Kohdeyrityksessä projektin toteuttaminen nähtiin erittäin tärkeänä, minkä seurauksena sille allokoitiin suuri osa käytettävissä olevista organisaation resursseista. Kohdeyrityksen koon takia yrityksessä ei kuitenkaan ollut käytännössä irrallisia resursseja, vaan projektin toteutus asettui käytössä olevien resurssien varaan. Tämä resurssien allokointi näkyi esimerkiksi henkilökunnan työtehtävien kasvamisella, kun ERP-järjestelmän vaativat työtehtävät tulivat normaalien tehtävien päälle. Yrityksen IT-palvelujen puolella projekti tarkoitti henkilöstöresurssien ohjaamista kokonaan projektin toteutukselle; vanhan järjestelmän kehitys ei ollut enää tarpeellista. Projektin toteutusta edistivät kohdeyrityksen ylimmän johdon tuki sekä sisäinen luottamus. Kohdeyrityksen johto on ollut projektissa mukana kehitystyötä lamauttavien ongelmatilanteiden ratkaisemisessa. He ovat ohjanneet toteutusta haittaavat hallinto- ja rakenneongelmat itselleen, kun nämä ovat hidastaneet projektia toteuttavaa henkilöstöä. Esimerkiksi kulttuuriristiriidan kohdalla mainittu ongelmatilanne yritysten erimielisyyksistä problemaattisen sopimuksen ja projektin laajuuden käsittelyssä uhkasi jumiuttaa projektin etenemisen. Tässä tilanteessa johto koki tarpeellisena tehdä tilaa työntekijöilleen ja otti ongelman ratkaisemisen vastuulleen kokonaisuudessaan, jolloin työntekijät kykenivät keskittymään kehitystyöhön. Luottamus esiintyi samalla tavalla; 53 mainittu ongelmatilanne aiheutti kitkaa yritysten välisessä luottamuksessa päätöstasolla, mutta luottamus toteuttavien tasojen välillä ei kariutunut. Osaa monivaiheisista menestystekijöistä ei kuitenkaan projektista voitu tunnistaa. Esimerkiksi kehitys- ja kohdeyrityksen ulkopuoliset konsultit eivät esiintyneet projektissa missään muodossa. Kohdeyritys luotti oman henkilökunnan sekä toimittajan toimintaan ja kokemukseen ja ei siten nähnyt tarpeelliseksi palkata ulkoista apua. Ainoa huomautus tämän menestystekijän osalta oli termin ”konsultti” käyttäminen osasta kehitysyrityksen toimihenkilöistä. Nämä henkilöt kuuluivat kehitysyrityksen henkilökuntaan ja tässä mielessä heitä ei voida pitää varsinaisina konsultteina viitekehyksen määritelmän mukaan. Toisien sanoen, nämä projektin konsultit eivät olleet organisaation ulkopuolisia neuvoja antavia asiantuntijoita. Nämä toimihenkilöt toimivat yhtenä siltana yritysten välisessä kommunikaatiossa ja työskentelivät vaatimusmäärittelyn parissa. Toinen osittain tunnistamaton monivaiheinen kriittinen menestystekijä oli projektin budjetti ja kustannukset. Tekijöistä vastasi kehitysprojektissa ERP-järjestelmän toteuttava osapuoli, eli kehitysyritys. Kohdeyrityksessä toimittiinkin pääasiassa kehitysyrityksen projektille antaman hintalapun varassa. Projektin kohtaama hinnankorotus ei kasvanut esteeksi projektin toteutumiselle. Kun kehitysyritys nosti toiminnanohjausjärjestelmän hintaa, oli kohdeyrityksen seurattava, jotta yritystoiminnalle oleellinen järjestelmä saatiin kehitettyä. Projektista on kuitenkin vaikea tunnistaa tarkemmin, mikä oikeastaan meni vikaan näiden menestystekijöiden osalta. Joka tapauksessa on selvää, että kustannusarvion laatiminen ei onnistunut projektin alussa kehitysyrityksen toimesta, mikä aiheutti budjetista ja sovitusta hinnasta poikkeamisen. Haastatteluista saadun näkemyksen mukaan yksi syy kustannusarvion poikkeamalle oli kehitysyrityksen päättävän ja toteuttavan tason näkemyserot projektin laajuudesta. Muita syitä kehitysyrityksen virheelliselle budjetoinnille ei haastatteluista saatu irti. Tarkempaa arviota aiheesta ei voidakaan toteuttaa tutkimukseen valitun 54 lähestymistavan takia. Kehitysyrityksen suora tutkiminen on tämän tutkimuksen rajoitteiden ulkopuolella. 4.3 Päivitetty viitekehys Haastatteluista tunnistettujen kriittisten menestystekijöiden ominaispiirteiden vuoksi osa viitekehyksestä on muokkauksen tarpeessa. Muun muassa kulttuuriristiriidan nähtiin olevan aktiivinen jokaisessa projektin elinkaarivaiheessa viitekehyksen listaamaan käyttöönottovaiheen sijaan. Sama tilanne on myös perinnejärjestelmien hallinnan kohdalla. Nämä muutokset on merkitty lihavoidulla fontilla alla olevaan päivitettyyn kriittisten menestystekijöiden viitekehykseen (ks. Taulukko 2). Taulukko 2. Päivitetty kriittisten menestystekijöiden viitekehys. Nro. Menestystekijä Englanniksi Osa-alue ERP- elinkaaren toimivaihe 1 Johdon tuki Top management support Organisaatio Kaikki 2 Kokonaisvaltainen yrityskuva ja järjestelmän soveltuvuus yrityksen prosesseihin Holistic enterprise view / System fit with business processes Organisaatio Esitutkimus, määrittely, suunnittelu 3 Konsultit Consultant support Organisaatio Kaikki 4 Koulutus ja pätevät työntekijät (sis. tehokäyttäjät) Training and retention of skilled workers Organisaatio Käyttöönotto 5 Kulttuuriristiriita Culture clash Organisaatio Kaikki 6 Ulkoinen toimittaja Supplier/vendor selection Organisaatio Esitutkimus 7 Pitkäaikaiset kumppanuudet Long-term partnerships Organisaatio Kaikki 8 Sidosryhmien sitoutuminen Stakeholder commitment Organisaatio Kaikki 9 Sidosryhmien kommunikaatio Stakeholder communication Organisaatio Kaikki 10 Sisäinen kommunikaatio Internal communication Organisaatio Kaikki 11 Luottamus sidosryhmien kesken Trust / Teamwork Organisaatio Kaikki 55 12 Minimaalinen ohjelmiston mukauttaminen Minimal software customisation Organisaatio Suunnittelu, toteutus 13 Organisaation resurssit Organisational resources Organisaatio Kaikki 14 Projektin perustelu Project justification Organisaatio Esitutkimus 15 Prosessi- ja muutosjohtaminen Business process re- engineering/management (BPR/BPM) Organisaatio Käyttöönotto 16 Muutosvastarinta Resistance to change / Organizational inertia Organisaatio Kaikki 17 Suorituskyvyn arviointi Performance evaluation Organisaatio Testaus, käyttöönotto 18 Vaatimusmäärittely System requirements Tekniikka Esitutkimus, määrittely 19 Käyttäjäkokemus User experience (UX) Tekniikka Suunnittelu, toteutus, käyttöönotto 20 Ohjelmatestaus Software testing Tekniikka Testaus 21 Perinnejärjestelmien hallinta Legacy system management Tekniikka Kaikki 22 Tiedonhallinta Data management Tekniikka Toteutus 23 Tietostandardit Data standards Tekniikka Toteutus 24 Tiedon laatu Data quality Tekniikka Toteutus 25 Tiedon tarkkuus Data accuracy Tekniikka Toteutus 26 Dokumentointi Documentation Tekniikka Kaikki 27 Projektinhallinta/-johto (sis. aikataulutus) Project management/ownership Projekti Kaikki 28 Suunnittelu Robust planning Projekti Suunnittelu 29 Budjetti / kustannukset Budget / Costs Projekti Kaikki 30 Loppukäyttäjän sisällyttäminen kehitysprojektiin End user involvement Projekti Esitutkimus, määrittely, suunnittelu, testaus 31 Selkeä ja realistinen projektivisio Clear and realistic project vision Projekti Kaikki 32 Projektin vaikutus yritystoimintaan ja liiketoimintaprosesseihin Effect on business activity and processes Projekti Kaikki Näiden muutosten lisäksi tutkimuksessa on nähty tarpeellisena lisätä kaksi uutta kriittistä menestystekijää viitekehyksen listaukseen. Näistä ensimmäinen on dokumentointi (documentation). Tämä menestystekijä näkyi projektissa vanhan toiminnanohjausjärjestelmän toiminnan kartoittamisessa. Kyseisen järjestelmän 56 dokumentaatio oli laadittu sen kehittämisen työvaiheissa vuosikymmeniä sitten, eikä sitä ollut päivitetty tai ylläpidetty laatimisen jälkeen. Vanhan järjestelmän myöhempien jatkokehitysvaiheiden dokumentointi oli tehty osittain suoraan koodiin tai erillisille määrittelydokumenteille, joita ei kuitenkaan ollut hallittu keskitetysti tai koottu yhteen. Tämä hidasti sen koodikannan tarkastelua ja ymmärtämistä. Samalla järjestelmän lähdekoodin sisältämät vanhat kommentit olivat usein käyttökelvottomia, kuten: ”toiminto X muutettu henkilön Y pyynnöstä päivämääränä Z”. Tällaiset kommentit eivät sisältäneet varsinaista tietoa siitä, mitä on muutettu tai miksi asia tehdäänkin nyt tällä uudella tavalla. Oikein toteutettu dokumentointi olisi ollut avuksi vanhan ERP-järjestelmän mekanismien selvittämisessä myös tilanteissa, joissa samasta toiminnosta tai aliohjelmasta oli tehty monia eri versioita. Näissä haastatellun IT-arkkitehdin nimittämissä ”virityksissä” saatettiin ajaa juuri samaa lähdekoodia, mutta hyvin pienillä eroilla eri käyttäjien tarpeisiin nähden. Pahimmassa tapauksessa esimerkiksi yhden raportin ajaminen voitiin toteuttaa 5–7 aliohjelman kautta riippuen ohjelmanajajan käyttöoikeuksista. Tämä ongelma pitkitti ja monimutkaisti toimintojen vertailua ja niiden perimmäisen käyttötarkoituksen selvittämistä ilman dokumentaatiota. Toteuttamisvaiheessa esimerkin ongelmasta päästiin eroon laatimalla yhden toiminnon suorittavia ohjelmia, joiden tuottamien tulosteiden variaatioita ohjattiin valintamahdollisuuksilla. Haastatteluista saatavien esimerkkien avulla vanhan järjestelmän dokumentoinnin voidaan nähdä olevan suuressa asemassa uuden järjestelmän kehitystyötä. Sen kokonaisuuden ja tarkkuuden tasot voivat vaikuttaa kehitysprojektiin joko positiivisesti tai negatiivisesti. Kohdeyrityksen ERP-järjestelmän kehitysprojektissa puuttunut ajantasainen dokumentaatio hidasti projektin etenemistä ja aiheutti ylimääräistä problematiikkaa toimintojen kartoittamisessa. Asiaan löytyy tämän tutkimuksen löydöksien lisäksi tukea myös muusta kirjallisuudesta. Aversano ja muut (2017) kuvailevat ohjelmiston dokumentointia erittäin tärkeäksi osaksi tietojärjestelmän elinkaarta – tämä koskee erityisesti monimutkaisia tietojärjestelmiä, kuten 57 toiminnanohjausjärjestelmiä. Heidän mukaansa dokumentointi on tärkeä niin ohjelmistokehittäjän näkökulmasta, kuin järjestelmän loppukäyttäjän. Tämän lisäksi dokumentointia tarvitaan järjestelmän ylläpidossa (Lopez & Salmeron, 2014). Näiden yksityiskohtien perusteella viitekehykseen lisätään dokumentointi osana teknistä osa- aluetta. Toinen päivitettyyn viitekehykseen lisätyistä kriittisistä menestystekijöistä on projektin vaikutus yritystoimintaan ja liiketoimintaprosesseihin (effect on business activity and processes). Tämä menestystekijä kuvastaa yksikertaisuudessaan projektin ja siihen siirrettyjen resurssien vaikutusta yrityksen normaaliin toimintaan. Kohdeyrityksessä nähtiin erittäin tärkeänä se seikka, että yritykselle ei tule ongelmia tai esteitä jatkaa tuotteiden valmistusta, raaka-aineiden ja valmistuotteiden käsittelyä sekä asiakastoimituksia. Haastatteluissa tämä tekijä tuli esille kolmen avainhenkilön näkökulmasta. Heidän mukaansa kohdeyritys onnistui hallitsemaan projektin tuottamaa työmäärää siinä määrin, että työtaakan lisäys ei hankaloittanut osastojen normaalia toimintaa. 58 5 Diskussio Tutkimuksessa tarkasteltiin toiminnanohjausjärjestelmien kehitysprojektien kriittisiä menestystekijöitä valmistavassa teollisuudessa. Tarkastelun painopisteenä oli ERP- järjestelmän tilaavan ja vastaanottavan yrityksen mielipiteet sekä näkemykset järjestelmän kehitysprojektin etenemisestä. Tutkimus toteutettiin case-tutkimuksena analysoimalla kansainvälisillä markkinoilla toimivaa suomalaista tevanake-teollisuuden yritystä. Kyseisen yrityksen ulkoistettu toiminnanohjausjärjestelmän kehitysprojekti mahdollisti tutkimusongelman tarkastelemisen kehitystyöhön vaikuttavien inhimillisten tekijöiden näkökulmasta. Tutkimusmenetelmänä käytettiin teemahaastattelua, jonka kohteena olivat tutkitun yrityksen avainhenkilöt. Haastattelut toteutettiin kahdessa haastattelukierroksessa, jotta tutkimusmateriaalia saatiin kerättyä yrityksestä mahdollisimman monipuolisesti. Ensimmäisessä kierroksessa haastateltujen henkilöiden annettiin kertoa kokemuksistaan ja mielipiteistään vapaasti. Toisessa kierroksessa haastattelut toteutettiin aiemmasta tutkimuksesta nostettua viitekehystä seuraamalla; kysymykset koskivat suoraan kehyksen menestystekijöitä. Molemmat haastattelukierrokset toteutettiin jokaisen avainhenkilön kohdalla yhden haastattelun aikana. Haastattelujen jälkeen kerätty tutkimusmateriaali litterointiin ja analysoitiin viitekehyksen elinkaarivaiheiden avulla. 5.1 Tulokset ja johtopäätökset Tutkimuksen aikana kohdeyrityksen kehitysprojektista onnistuttiin tunnistamaan suurin osa käytetyn viitekehyksen kriittisistä menestystekijöistä sekä muutama uusi tekijä, jotka sisällytettiin osaksi tutkimuksen tuloksissa tarkasteltua päivitettyä kehystä. Tarkastellun toiminnanohjausjärjestelmän kehitysprojekti oli edennyt viitekehyksessä tutkittujen tietojärjestelmien elinkaarivaiheiden tasolle ja soveltui täten hyvin tutkimuskohteeksi. Haastatteluista kerätty tutkimusmateriaali tarjosikin informatiivisia näkemyksiä kehitysprojektista ja sen menestystekijöistä monelta eri kannalta. Nämä havainnot olivat 59 viitekehystä tukevia näkökulmia sekä uusia, viitekehykselle aiemmin ulkopuolisia näkemyksiä projektille oleellisista menestystekijöistä. Kohdeyrityksessä kohdattujen menestystekijöiden vaikutukset projektityöhön olivat selväpiirteisiä avainhenkilöiden kertomuksista. Heidän kokemuksensa ilmaisivat, miten osa näistä kriittisistä menestystekijöistä oli yrityksen tiedossa etukäteen ja miten niitä oli ennakoitu. Esimerkiksi viitekehyksen toinen menestystekijä, kokonaisvaltainen yrityskuva ja järjestelmän soveltuvuus yrityksen prosesseihin, otettiin huomioon jo järjestelmän esitutkimuksessa, määrittelyssä ja suunnittelussa. Vastaavasti moni muu menestystekijä oli mukana kehitysprosessissa ja niiden vaikutukset kyettiin ennakoimaan ja hallitsemaan. Tutkimuksessa kuitenkin huomattiin, että vaikka suuri osa viitekehyksen menestystekijöistä oli huomioitu etukäteen, pieni osa menestystekijöistä aiheutti silti ongelmia kehitysprojektin aikana. Tärkein esimerkki tämäntyyppisistä kriittisistä menestystekijöistä oli kulttuuriristiriita. Kyseinen menestystekijä huomioitiin kohdeyrityksessä huolellisella alihankkijan valintaprosessilla. Tästä huolimatta kohde- ja kehitysyrityksen välillä vallitseva rakenteellinen ero mahdollisti toiminnallisen kulttuuriristiriidan, mikä aiheutti ongelmia alkuperäisen sopimuksen solminnassa ja erimielisyyksiä sopimuksen kattavista vastuualueista. 5.2 Rajoitteet ja tutkimuksen arviointi Tutkimuksessa on hyödynnetty kvalitatiivista lähestymistapaa ja case-tutkimusta. Käytetty tutkimusstrategia sopi tutkimusongelman selvittämiseen, mutta ei suoraisesti mahdollista tutkimustulosten yleistettävyyttä muihin tilanteisiin. Tutkimuksen tuloksia voidaan hyödyntää vastaavien toiminnanohjausjärjestelmien kehittämisessä teollisuuden toimialoilla, mutta ne eivät välttämättä sovellu jokaiseen kehitysprojektiin. On kuitenkin huomattava, että tämän tutkimuksen tavoitteena oli kehitysprojektin 60 läheinen tulkinta, eikä yleistää tutkimuksen havaintoja jokaiseen kehitysprojektiin. Tässä mielessä tutkimus on onnistunut sen tavoitteissa. Muita rajoituksia tutkimuksessa oli kehitysprojektin tarkastelun rajoittaminen teollisuuden yrityksiin. Suomalaisen tevanake-teollisuuden yrityksen tarkastelu on rajoittanut tutkimuksen löydöksiä ja niiden hyödyntäminen näistä raameista poikkeavissa muissa kehitysprojekteissa on osittain kyseenalaista. Esimerkiksi muulla toimialalla tai ulkomailla toimiva yritys ei välttämättä voi hyödyntää tutkimustuloksia suoraan. Samalla yritykset, joilla on tarve ja kyky toteuttaa toiminnanohjausjärjestelmän kehitysprojekti yrityksen sisällä, tulevat kohtamaan vain osan viitekehyksen menestystekijöistä. Näissä tapauksissa päivitetyn viitekehyksen ja muiden tulkintojen tulisi toimia vain suuntaa antavina määritelminä. 5.3 Jatkotutkimusaiheet Tutkimusta voidaan jatkaa tarkastelemalla muita toiminnanohjausjärjestelmien kehitysprojekteja muilla teollisuusaloilla. Esimerkiksi siirtyminen tuotteita loppukäyttäjille valmistavasta teollisuusyrityksestä vaikkapa muiden yrityksien tuotantoprosesseihin raaka-aineita tai välituotteita tuottavaan metalliteollisuuden yritykseen voi tuottaa uudenlaisia näkemyksiä viitekehyksen menestystekijöistä. Vastaavanlaista case-tutkimusta voitaisiin samalla hyödyntää vertailevassa tutkimuksessa, jonka avulla voitaisiin luoda laajempi ja mahdollisesti tarkempi näkemys tarkastelluista menestystekijöistä. Jatkotutkimusta tulisi myös tehdä toiminnanohjausjärjestelmän kehittävän yrityksen näkökulmasta. Nykyinen viitekehys on painottunut huomattavasti organisatorisiin kriittisiin menestystekijöihin. Järjestelmän toteuttavan toimijan näkemys voisi tarjota uusia mielipiteitä viitekehyksestä ja mahdollisesti jopa uusia menestystekijöitä erilaisen ajattelutavan kautta. Esimerkiksi ERP-järjestelmän ohjelmoija saattaisi nähdä kehitysprojektille tärkeitä teknisiä osa-alueita, joita tämänhetkinen viitekehys ei kata. 61 Samalla toiminnanohjausjärjestelmän kehitysprojektin syvällisempi tarkastelu projektinhallinnan perspektiivistä saattaisi kasvattaa menestystekijöiden listausta projektin osa-alueella. Näiden jatkotutkimusaiheiden lisäksi tutkimus tarjoaa hyvän lähtökohdan toiminnanohjausjärjestelmien kriittisten menestystekijöiden tarkasteluun järjestelmien myöhempien elinkaarivaiheiden näkökulmasta. Ylläpidon ja jatkokehityksen vaiheissa esiintyvät menestystekijät voivat tarjota aihetta edistävän perspektiivin. Vaikka tässä tutkimuksessa on nähty tarpeellisena analysoida järjestelmien kehitykselle ja toteutukselle ratkaisevia työvaiheita, ovat näitä työvaiheita seuraavat elinkaarivaiheet oleellisia ERP-järjestelmien käyttäjien näkökulmasta. Vastaavanlainen tutkimus tarjoaisi myös uusia tulkintoja viitekehyksen menestystekijöistä ja näiden vaikutuksista varsinaisen kehitystyön jälkeen. Esimerkiksi projektin alkuvaiheissa arvioidun menestystekijän, minimaalisen ohjelmiston mukauttamisen vaikutukset ovat näkyvissä vasta järjestelmän käyttöönoton jälkeen. 62 Lähteet Ahmed, A. (2011). Software Project Management. Auerbach Publishers, Incorporated. Al-Mashari, M., Al-Mudimigh, A., & Zairi, M. (2003). Enterprise resource planning: A taxonomy of critical factors. European journal of operational research, 146(2), 352– 364. https://doi.org/10.1016/S0377-2217(02)00554-4 Aston, B. (2022). The 9 Most Popular Project Management Methodologies Made Simple. DigitalProjectManager (DPM). https://thedigitalprojectmanager.com/projects/pm- methodology/project-management-methodologies-made-simple/ Aversano, L., Guardabascio, D., & Tortorella, M. (2017). Analysis of the Documentation of ERP Software Projects. Procedia Computer Science, 121, 423–430. https://doi.org/10.1016/j.procs.2017.11.057 Bernroider, E. W. N. (2013). Effective ERP adoption processes: the role of project activators and resource investments. European journal of information systems, 22(2), 235–250. https://doi.org/10.1057/ejis.2012.51 Bullen, C. V., & Rockart, J. F. (1981). A primer on critical success factors. IDEAS Working Paper Series/RePEc. https://www.researchgate.net/publication/5175561_A_primer_on_critical_succes s_factors Doherty, N. F., Ashurst, C., & Peppard, J. (2012). Factors Affecting the Successful Realisation of Benefits from Systems Development Projects: Findings from Three Case Studies. Journal of information technology, 27(1), 1–16. https://doi.org/10.1057/jit.2011.8 Elbanna, A. (2010). Rethinking IS project boundaries in practice: A multiple-projects perspective. The journal of strategic information systems, 19(1), 39–51. https://doi.org/10.1016/j.jsis.2010.02.005 Elbanna, A. (2013). Top management support in multiple-project environments: an in- practice view. European journal of information systems, 22(3), 278–294. https://doi.org/10.1057/ejis.2012.16 63 Escott, E. (2017). Waterfall vs Agile: Choosing The Right Fit. WorkingMouse. https://workingmouse.com.au/innovation/waterfall-vs-agile-choosing-the-right- fit/ Fui-Hoon Nah, F., Lee-Shang Lau, J., & Kuang, J. (2001). Critical factors for successful implementation of enterprise systems. Business process management journal, 7(3), 285–296. https://doi.org/10.1108/14637150110392782 GrandViewResearch. (2021). ERP Software Market Size, Share & Trend Report. https://www.grandviewresearch.com/industry-analysis/erp-software-market Greasley, Andrew. (2007). Operations Management. SAGE Publications Ltd. Haikala, I., & Mikkonen, T. (2011). Ohjelmistotuotannon käytännöt (12. uud. p.). Talentum. Haikala, Ilkka., & Märijärvi, Jukka. (2004). Ohjelmistotuotanto (10. uud. p.). Talentum. Hassenzahl, M., & Tractinsky, N. (2006). User experience - a research agenda. Behaviour & information technology, 25(2), 91–97. https://doi.org/10.1080/01449290500330331 Holcombe, W. M. L. (2008). Running an Agile Software Development Project. John Wiley & Sons, Incorporated. Ippolito, J. (2021). What is ERP? | Enterprise Resource Planning Explained. ProjectLine. https://www.projectline.ca/blog/what-is-erp-enterprise-resource-planning Jacobs, F. R., & Weston, F. C. (2007). Enterprise resource planning (ERP)—A brief history. Journal of Operations Management, 25(2), 357–363. https://doi.org/10.1016/J.JOM.2006.11.005 Jokinen, J. (2021). Toiminnanohjausjärjestelmien kehittäminen: Tarkastelussa kriittiset menestystekijät [Kandidaatintutkielma]. Vaasan yliopisto. Koh, S. C. L., Gunasekaran, A., & Goodman, T. (2011). Drivers, barriers and critical success factors for ERPII implementation in supply chains: A critical analysis. The journal of strategic information systems, 20(4), 385–402. https://doi.org/10.1016/j.jsis.2011.07.001 Kumar, S. A., & Suresh, N. (2009). Operations Management. New Age International. 64 Kumar, V., Loonam, J., Allen, J. P., & Sawyer, S. (2016). Exploring Enterprise Social Systems & Organisational Change: Implementation in a Digital Age. Journal of information technology, 31(2), 97–100. https://doi.org/10.1057/jit.2016.13 Laumer, S., Maier, C., Eckhardt, A., & Weitzel, T. (2016). Work routines as an object of resistance during information systems implementations: theoretical foundation and empirical evidence. European journal of information systems, 25(4), 317–343. https://doi.org/10.1057/ejis.2016.1 Lopez, C., & Salmeron, J. L. (2014). Dynamic risks modelling in ERP maintenance projects with FCM. Information sciences, 256, 25–45. https://doi.org/10.1016/j.ins.2012.05.026 Markus, M. L., Tanis, C., & van Fenema, P. C. (2000). Multisite ERP Implementations. Communications of the ACM, 43(4), 42–46. https://doi.org/10.1145/332051.332068 Meissonier, R., & Houzé, E. (2010). Toward an ”IT Conflict-Resistance Theory”: action research during IT pre-implementation. European journal of information systems, 19(5), 540–561. https://doi.org/10.1057/ejis.2010.35 Mueller, S. K., Mendling, J., & Bernroider, E. W. N. (2019). The roles of social identity and dynamic salient group formations for ERP program management success in a postmerger context. Information systems journal (Oxford, England), 29(3), 609–640. https://doi.org/10.1111/isj.12223 Nestell, J. G., & Olson, D. L. (2017). Successful ERP systems: a guide for businesses and executives. Business Expert Press. Ngai, E. W. T., Law, C. C. H., & Wat, F. K. T. (2008). Examining the critical success factors in the adoption of enterprise resource planning. Computers in industry, 59(6), 548– 564. https://doi.org/10.1016/j.compind.2007.12.001 O’Leary, D. E. (2000). Enterprise resource planning systems: systems, life cycle, electronic commerce, and risk. Cambridge University Press. Parthasarathy, S. (2007). Enterprise Resource Planning : A Managerial & Technical Perspective. New Age International. 65 Poba-Nzaou, P., & Raymond, L. (2011). Managing ERP system risk in SMEs: a multiple case study. Journal of information technology, 26(3), 170–192. https://doi.org/10.1057/jit.2010.34 Pollock, N., & Hyysalo, S. (2014). The Business of Being a User: The Role of the Reference Actor in Shaping Packaged Enterprise System Acquisition and Development. MIS quarterly, 38(2), 473–496. https://doi.org/10.25300/MISQ/2014/38.2.07 Rashid, Y., Rashid, A., Warraich, M. A., Sameen Sabir, S., & Waseem, A. (2019). Case Study Method: A Step-by-Step Guide for Business Researchers. https://doi.org/10.1177/1609406919862424 Rodov, A., & Teixidó, J. (2016). Blending Agile And Waterfall: Keys To Successful Implementation. Paper presented at PMI® Global Congress 2016—EMEA, Barcelona, Spain. Newtown Square, PA: Project Management Institute. Rootstock Software. (2019). 5 Signs You’ve Outgrown Your Old ERP System. https://www.rootstock.com/cloud-erp-blog/5-signs-youve-outgrown-your-old- erp-system/ Saaranen-Kauppinen, A., & Puusniekka, A. (2006). KvaliMOTV - Menetelmäopetuksen tietovaranto. Tampere: Yhteiskuntatieteellinen tietoarkisto. https://www.fsd.tuni.fi/menetelmaopetus/kvali/index.html Samara, Tarek. (2015). ERP and Information Systems : Integration or Disintegration. 114. https://www.wiley.com/en- us/ERP+and+Information+Systems%3A+Integration+or+Disintegration-p- 9781848218963 Schell, C. (1992). The Value of the Case Study as a Research Strategy. Schlichter, B. R., & Rose, J. (2013). Trust dynamics in a large system implementation: six theoretical propositions. European journal of information systems, 22(4), 455–474. https://doi.org/10.1057/ejis.2012.24 Schneider, S., Wollersheim, J., Krcmar, H., & Sunyaev, A. (2018). How do Requirements Evolve over Time? A Case Study Investigating the Role of Context and Experiences in the Evolution of Enterprise Software Requirements. Journal of information technology, 33(2), 151–170. https://doi.org/10.1057/s41265-016-0001-y 66 Shao, Z., Feng, Y., & Hu, Q. (2016). Effectiveness of top management support in enterprise systems success: a contingency perspective of fit between leadership style and system life-cycle. European journal of information systems, 25(2), 131– 153. https://doi.org/10.1057/ejis.2015.6 Shehab, E. M., Sharp, M. W., Supramaniam, L., & Spedding, T. A. (2004). Enterprise resource planning: An integrative review. Business Process Management Journal, 10(4), 359–386. https://doi.org/10.1108/14637150410548056/FULL/PDF SpiceWorks. (2016). How Long Should Your ERP System Last? - Enterprise Software. https://community.spiceworks.com/topic/2454579-how-long-should-your-erp- system-last Stare, A. (2013). Agile project management – a future approach to the management of projects? Dynamic relationships management journal, 2(1), 43–53. https://doi.org/10.17708/DRMJ.2013.v02n01a04 Sykes, T. A. (2015). Support Structures and Their Impacts on Employee Outcomes: A Longitudinal Field Study of an Enterprise System Implementation. MIS quarterly, 39(2), 473–496. https://doi.org/10.25300/MISQ/2015/39.2.09 Sykes, T. A., Venkatesh, V., & Johnson, J. L. (2014). Enterprise System Implementation and Employee Job Performance: Understanding the Role of Advice Networks. MIS quarterly, 38(1), 51–72. https://doi.org/10.25300/MISQ/2014/38.1.03 Tan, B., Pan, S. L., Chen, W., & Huang, L. J. (2020). Organizational sensemaking in erp implementation: The influence of sensemaking structure. MIS quarterly, 44(3), 1773–1810. https://doi.org/10.25300/misq/2020/11872 Trek Global. (2014). Managing the 5 Stages of an ERP Life Cycle. https://www.trekglobal.com/erp-resources/articles/managing-the-5-stages-of-an- erp-life-cycle Veiga, J. F., Keupp, M. M., Floyd, S. W., & Kellermanns, F. W. (2014). The longitudinal impact of enterprise system users’ pre-adoption expectations and organizational support on post-adoption proficient usage. European journal of information systems, 23(6), 691–707. https://doi.org/10.1057/ejis.2013.15 67 Winkelmann, A., & Leyh, C. (2010). Teaching ERP systems: a multi-perspective view on the ERP system market. Journal of information systems education, 21(2). Woo, H. S. (2007). Critical success factors for implementing ERP: the case of a Chinese electronics manufacturer. Journal of manufacturing technology management, 18(4), 431–442. https://doi.org/10.1108/17410380710743798 Zeng, Y., & Skibniewski, M. J. (2013). Risk assessment for enterprise resource planning (ERP) system implementations: a fault tree analysis approach. Enterprise information systems, 7(3), 332–353. https://doi.org/10.1080/17517575.2012.690049 68 Liitteet Liite 1. Haastattelun kysymykset Kohdeyritys = ERP-järjestelmän tilannut ja vastaanottava tevanake-teollisuuden yritys. Kehitysyritys = Järjestelmän kehittävä yritys, alihankkija. KIERROS I – Tausta ja omat näkemykset 1. Minkälainen asema teillä on kohdeyrityksessä? Mitkä ovat yleisimmät työtehtävät? 2. Kauanko olette olleet kohdeyrityksessä? Kauanko olette olleet työasemassanne? 3. Miten käytätte edellistä/uutta toiminnanohjausjärjestelmään työssänne? 4. Mitä vastuualueita teillä on ollut toiminnanohjausjärjestelmän kehitysprojektissa? 5. Miten kehitysprojekti on edennyt? Mitä tehtiin alussa ja mitä lopussa? 6. Mitä ongelmia kehitysprojektissa on kohdattu? 7. Mikä on onnistunut projektin aikana? 8. Kommentointi projektista vapaasti. KIERROS II – Viitekehyksen menestystekijät Huomautus: Seuraavat kysymykset eivät seuraa viitekehyksen kriittisten menestystekijöiden järjestystä. Kysymysten jäsentely on vaihdettu seuraamaan haastatteluille sopivampaa ja sujuvampaa järjestystä, minkä lisäksi osa menestystekijöistä on yhdistetty yhteen kysymykseen. Kysymykset seuraavat pääasiallisesti kehitystyön ja järjestelmän elinkaarivaiheita. Esimerkiksi kysymykset yrityksen resursseista ja budjetista on esitetty peräkkäin menestystekijöiden samankaltaisten aiheyhteyksien takia ja kysymykset tietojenhallinnasta, -standardeista, sekä informaation tarkkuudesta ja laadusta on yhdistetty yhdeksi kysymykseksi. 69 1. [PROJEKTIN PERUSTELU] Miksi uusi järjestelmä tuli kehittää? Miten projektia perusteltiin tarpeelliseksi ja miten se kommunikointiin kohdeyrityksessä? 2. [KOKONAISVALTAINEN YRITYSKUVA / MIN. OHJELMISTON MUKAUTTAMINEN] Miten kohdeyrityksen prosessit huomioitiin ERP-järjestelmän vaatimuksissa? Miten avaintoiminnot valittiin? Mitä jätettiin projektin ulkopuolelle? 3. [PROJEKTIVISIO] Miten projektin toteutus nähtiin alussa? Muuttuiko projektin visio kehitysprojektin edetessä? 4. [VAATIMUSMÄÄRITTELY] Miten järjestelmän vaatimukset määriteltiin? Mitä näkemyksiä järjestelmän toiminnoista kohdeyrityksellä ja kehitysyrityksellä oli projektin eri vaiheissa? 5. [SUUNNITTELU] Miten projektin suunnittelu toteutettiin? Mitä projektisuunnittelun työkaluja hyödynnettiin ja miksi? 6. [ULKOINEN TOIMITTAJA] Miten kehitysyritys valittiin / mitkä tekijät vaikuttivat valintaan? Olisiko valintaan tullut sisällyttää muita tekijöitä? Olisiko valinta ollut eri näin jälkikäteen? 7. [PITKÄAIKAISET KUMPPANUUDET] Tullaanko uuteen järjestelmään yhdistämään yrityksen kumppaneiden järjestelmiä? Miksi tai miksi ei? Miten tähän päätökseen päästiin? 8. [SIDOSRYHMIEN SITOUTUMINEN JA KOMMUNIKAATIO] Miten sidosryhmät ovat sitoutuneet projektin toteutumiseen? Miten projektista on kommunikoitu kohdeyrityksen ulkopuolisille sidosryhmille? Onko tässä esiintynyt ongelmia ja miksi? Onko projektissa ollut ongelmia viestinnässä kehitysyrityksen kanssa? 70 9. [SISÄINEN KOMMUNIKAATIO] Miten projektista keskusteltu kohdeyrityksen sisällä, esim. kokoukset, tiedonanto, sähköpostit jne.? Onko sisäisessä viestinnässä ollut puutteita? 10. [KULTTUURIRISTIRIITA] Miten kehitysyrityksen toiminta/työkulttuuri on vaikuttanut projektiin? Onko kehitysyrityksen kulttuuri ollut erilainen kohdeyrityksen toimintaan verrattuna? Mitä tämä on aiheuttanut? 11. [LUOTTAMUS SIDOSRYHMISSÄ] Onko kohdeyrityksessä ollut sisäistä luottamusta tai sen puutetta? Miten tämä on esiintynyt kehitysprojektissa? 12. [ORGANISAATION RESURSSIT] Onko projektille allokoitu tarpeeksi resursseja, esim. henkilöstöä? 13. [BUDJETTI / KUSTANNUKSET] Miten projektin kustannukset ovat kehittyneet kehitystyön eri vaiheissa? Ovatko kustannukset eronneet sille määritellystä budjetista, miten ja miksi? 14. [PROSESSI- JA MUUTOSJOHTAMINEN] Kuka on ollut vastuussa uuden järjestelmän tuomasta muutoksesta ja organisaation toimista sen suhteen? Mitä toimia on otettu käyttöön? 15. [MUUTOSVASTARINTA] Oletko huomannut kohdeyrityksessä tai sen henkilökunnassa muutosvastarintaa vanhan järjestelmän korvaamiselle? Miten tämä on esiintynyt ja miten siihen on vastattu esimerkiksi johdon toimesta? 16. [KÄYTTÄJÄKOKEMUS] Miten järjestelmän käyttäminen otettiin huomioon sen loppukäyttäjien näkökulmasta kehitysprojektissa? Mitkä tekijät nähtiin tärkeinä, mitä järjestelmän tuli sisältää käytön osalta, esim. käytettävyys, vasteajat, käyttöliittymä yms.? 71 17. [LOPPUKÄYTTÄJIEN SIS.] Miten järjestelmän loppukäyttäjiä on sisällytetty osaksi kehitysprojektia (suunnittelu, testaus ja käyttöönotto)? Mitä käyttäjät ovat tarjonneet osaksi kehitystyötä? 18. [PERINNEJÄRJESTELMÄT] Mitä perinnejärjestelmiä yrityksessä on käytössä? Miten nämä tulevat olemaan vuorovaikutuksessa uuden järjestelmän kanssa? Miten näiden perinnejärjestelmien hallinta ja ylläpito on toteutettu? 19. [TIEDONHALLINTA, TIETOSTANDARDIT, TIEDON TARKKUUS JA LAATU] Miten tiedon tarkkuus ja laatu varmistetaan uudessa järjestelmässä? Onko käytössä tiettyjä tietostandardeja? Onko vanhan toiminnanohjausjärjestelmän datan sisällyttäminen uuteen järjestelmään tuonut ongelmia, miten ne on ratkaistu? 20. [PROJEKTINHALLINTA / -JOHTO] Miten projektia on hallittu kohdeyrityksessä? Kuka on vastuussa projektin etenemisestä? Mitä työkaluja projektinhallinnassa on hyödynnetty? 21. [SUORITUSKYVYN ARVIOINTI] Miten projektin edistymistä on seurattu? 22. [OHJELMATESTAUS] Miten tulevaa järjestelmää on testattu? Miten testauksen tulokset on kommunikoitu kehitysyritykselle? 23. [KOULUTUS JA PÄTEVÄT TYÖNTEKIJÄT] Miten uuden järjestelmän käyttöönotto toteutettiin? Mitä ongelmia? Onko työntekijöitä koulutettu järjestelmän käytöstä ja miten? Onko henkilöstöstä tunnistettavissa tehokäyttäjiä ja onko heitä ohjattu tukemaan muuta henkilökuntaa? Onko henkilöstö vaihtunut kehitystyön aikana ja miten se on vaikuttanut kehitysprojektiin? 72 24. [JOHDON TUKI] Miten kohdeyrityksen johto on ollut kehityksessä mukana näkökulmastasi? Minkälaisia ongelmia johto on kohdannut ja miten ne on ratkaistu? Oliko johdon tuessa puutteita? 25. [KONSULTIT] Onko kehitystyössä ollut mukana kohdeyrityksen ja kehitysyrityksen ulkopuolisia konsultteja? Miten nämä konsultit ovat tukeneet kehitysprojektia? Onko heistä ollut apua/haittaa? 73 Liite 2. Saatekirje kohdeyritykselle Eettiset näkökohdat ovat erittäin tärkeitä kaikissa tutkimuksissa. Tämän seurauksena tälle tutkimukselle on välttämätöntä, että tutkimukseen osallistuvat osapuolet ovat täysin tietoisia osallistumisestaan ja roolistaan. Tutkimuksessa pyritään suojaamaan tapaustutkimuksen kohteen liikesalaisuuksia ja identiteettiä. Kohdeyrityksen henkilöstön haastatteluista kerättyä tutkimusmateriaalia hyödynnetään vain kohdeyrityksen johdon luvalla. Heillä on oikeus kieltäytyä tarjoamasta tietoa tekijöistä, jotka voivat aiheuttaa vahinkoa liiketoiminnalleen tai paljastaa yrityksen identiteetin, ja vaatia näiden tietojen muuttamista tai poistamista tutkimuksesta ennen sen julkaisua. Suojellakseen osallistujien oikeuksia ja yksityisiä tietoja, tutkimuksessa toteutetaan seuraavat toimet: 1. Tutkimukseen osallistunutta kohdeyritystä ei nimetä sen omasta tahdosta. 2. Kohdeyritystä kuvaillaan tutkimuksessa siinä tarkkuudessa, mikä oleellista tutkimukselle. Identiteetin paljastavia tietoja ei esitetä. 3. Kohdeyrityksen henkilöstön yksityisyys ja luottamuksellisuus suojataan tutkimuksen aikana ja sen jälkeen. 4. Haastatteluiden osallistujat on tehty tietoiseksi tutkimuksen tavoitteista ja toteutuksesta ennen haastatteluja. 5. Kohdeyritys käy tutkimuksen läpi ja täten hyväksyy sen sisällön ennen tutkimuksen julkaisua. Mahdolliset kysymykset tutkimuksen tavoitteista, toteutuksesta ja haastatteluista saatavan informaation käytöstä voidaan ohjata tutkimuksen tekijälle, Joonas Jokiselle.