Toiminnanohjausjärjestelmän teknisen vaatimusmäärittelyn laatiminen pk-yritysten käyttöön

Transkriptio

1 Toiminnanohjausjärjestelmän teknisen vaatimusmäärittelyn laatiminen pk-yritysten käyttöön TOMI raportti 2 Päivi Iskanius, Leena Klaavu, Timo Myllyoja

2 Toiminnanohjausjärjestelmän teknisen vaatimusmäärittelyn laatiminen pk-yritysten käyttöön TOMI raportti 2 Päivi Iskanius, Leena Klaavu & Timo Myllyoja Oulun yliopisto, Raahen toimintayksikkö, Raahe, 2009 ISBN

3 Tiivistelmä Pk-yrityksillä on suuria vaikeuksia toiminnanohjausjärjestelmäprojektin läpiviemisessä. Mitä laajemmasta ja kokonaisvaltaisemmasta järjestelmästä on kysymys, sitä haastavampi on järjestelmän suunnittelu-, hankinta- ja käyttöönotto. Pk-yrityksillä ei ole varaa epäonnistua järjestelmäprojektissa, sillä liikevaihtoon suhteutettuna järjestelmän käyttöönotto on huomattavan suuri, ja aiheutuneilla kustannuksilla on suoranainen vaikutus yrityksen tulokseen. Tässä raportissa tarkastellaan pk-yritysten toiminnanohjausjärjestelmien suunnitteluun, hankintaan ja käyttöönottoon liittyviä kriittisiä tekijöitä. Vaikka kaikki toiminnanohjausjärjestelmäprojektit ovat erilaisia ja esiin tulevat ongelmat vaihtelevat yritysten välillä, niissä on paljon samankaltaisia piirteitä ja ongelmien todennäköisiä aiheuttajia. Tärkeimpiä järjestelmäprojektin epäonnistumiseen vaikuttavia tekijöitä pk-yrityksissä on niiden krooninen resurssipula ja tietoteknisen osaamisen puute. Toiminnanohjausjärjestelmät on tyypillisesti suunniteltu suurten yritysten toimintaa ajatellen eikä järjestelmätoimittajat välttämättä tunne pk-yritysten erityispiirteitä, niiden toimintaprosesseja ja toimintatapoja. Pk-yritysten tietotaito ei välttämättä riitä arvioimaan järjestelmäprojektin todellista laajuutta, kustannuksia ja resurssitarvetta. Usein pk-yritykset ovat altavastaajina myyntineuvotteluissa. Myös projektipäälliköllä ei ole kovin vankkaa tuntemusta tietojärjestelmäprojekteista. Pk-yrityksissä ei tyypillisesti ymmärretä järjestelmän vaatimaa toimintatapojen muutostarvetta ja toiminta- ja työtapoja muutetaan sitä mukaa kun ongelmat tulevat vastaan. Pk-yrityksissä ei aina osaa kuvailla, minkälainen toiminnanohjausjärjestelmä heille parhaiten sopii. Niiltä puuttuu myös tietohallintastrategia ja johdonmukainen kehittämiskulttuuri. Toiminnanohjausjärjestelmän vaatimusmäärittely on onnistuneen järjestelmäprojektin edellytys. Tässä raportissa tarkastellaan vaatimusmäärittelyn laatimisprosessia kolmessa pk-yrityksessä. Tulokset ovat osittain salaisia, joten tässä raportissa esitetään ainoastaan ne tulokset, jotka eivät liity salassapitovelvoitteen piiriin. Vaatimusmäärittelyprosessi on toteutettu osittain C-CEI-menetelmän (Customer-Centered ERP Implementation) avulla keskittyen järjestelmäprojektin riskianalyysiin. Lisäksi yrityksille on laadittu järjestelmäprojektin haastavuusanalyysi ja luonneanalyysi riippuen siitä, missä vaiheessa case-yritykset ovat omaa järjestelmäprojektiaan. Case-yrityksien valinta on toteutettu siten, että mukana on toiminnanohjausjärjestelmää käyttävä yritys A, järjestelmän valintavaiheessa oleva yritys B, ja järjestelmän hankintaa suunnitteleva yritys C. Case-yritykset 3

4 ovat Raahen alueen metalli- ja puualan pk-yrityksiä. Käytännössä työ on tehty aikana. Case-yrityksillä ei ole järjestelmähankkeen läpiviemiseen vaadittavaa osaamista omassa organisaatiossaan. Osittain tätä osaamista on ostettu ulkopuolisilta konsulteilta sekä rekrytoitu yritykseen tietotekniikka-alan henkilöitä. Järjestelmätoimittajan kokemus ja referenssit toimialalta sekä pk-yritysten erityisvaatimusten tunnistaminen koettiin tärkeäksi valintakriteeriksi. Järjestelmän aiheuttamia toimintatapamuutoksia pidettiin haasteellisina. Pk-yritykset eivät ymmärtäneet niiden laajuutta ja tarvittavien resurssien määrää. Hyötyjen saaminen järjestelmähankkeesta kestää kauan. Järjestelmäprojektin onnistuminen riippuu siitä, miten hyvin pk-yrityksessä pystytään toimintatapamuutokset viemään läpi. Muutosprosessi on parhainta aloittaa jo paljon ennen järjestelmän hankintaa ja käyttöönottoa, sillä moniin järjestelmähankkeen riskeihin voidaan vaikuttaa ennen järjestelmän hankkimista. Yritys voi esimerkiksi hankkia tilapäistä työvoimaa tekemään avainhenkilöiden rutiiniluontoisia tehtäviä järjestelmän käyttöönoton ajaksi. Tällöin avainhenkilöillä on enemmän aikaa keskittyä järjestelmän ominaisuuksiin ja uusiin työkäytäntöihin. Toiminnanohjausjärjestelmän hankinta on pk-yritykselle suuri investointi. Ostohinnan lisäksi kokonaisbudjettiin on arvioitava välittömät käyttöönottoon ja koulutukseen liittyvät kustannukset. Järjestelmän ylläpitokustannukset muodostavat jopa 60 % koko järjestelmän elinkaarikustannuksista. Panostamalla aikaa ja resursseja järjestelmähankkeen alkuvaiheeseen ja käytön koulutuksen säästetään kustannuksia ja vähennetään riskejä. Tämä raportti on laadittu Pohjois-Pohjanmaan Liiton ja Raahen kaupungin rahoittaman TOMI Toiminnanohjausjärjestelmän kehittäminen Raahen alueen yrityksissä -hankkeen myötä. Kiitämme päärahoittajia ja case-yrityksiä saamastamme tuesta. 4

5 Sisällysluettelo Tiivistelmä Sisällysluettelo Johdanto Toiminnanohjausjärjestelmän hankinta pk-yrityksissä Toiminnanohjausjärjestelmät Toiminnanohjausjärjestelmän hankintastrategiat Toiminnanohjausjärjestelmät pk-yrityksissä Toiminnanohjausjärjestelmäprojekti Toiminnanohjasjärjestelmän vaatimusmäärittelyn laatiminen Kokemuksia case-yritysten vaatimusmäärittelyn luomisesta Tutkimuksen kulku Case 1: Yritys A Case 2: Yritys B Case 3: Yritys C Johtopäätökset Lähteet

6 1. Johdanto Yritysten toimintaympäristö on kokenut suuria muutoksia. Tiedon ja osaamisen merkitys kilpailukykytekijänä on kasvanut ja tietojärjestelmien käyttö yrityksen liiketoiminnassa on yleistynyt voimakkaasti. Yritysten toiminnot ovat muuttuneet tietotekniikalla tuetuiksi ja samalla niitä on pyritty integroimaan yrityksen sisäisinä ja yritysten välisinä prosesseina. Viimeisen kymmenen vuoden aikana on yritysten yhdeksi merkittävimmäksi haasteeksi noussut toiminnanohjausjärjestelmän hankinta ja käyttöönotto. Laajat toiminnanohjausjärjestelmät muodostavat monimutkaisen kokonaisuuden ja niiden vaikutukset ulottuvat yrityksen liiketoimintaprosesseihin ja toimintaympäristöön. Tällaisen järjestelmän hankinta vaatii huolellista paneutumista suunnittelu- ja käyttöönottovaiheessa. Vielä 1990-luvulla toiminnanohjausjärjestelmiä ottivat käyttöön lähinnä suuret, kansainväliset yritykset. Nämä markkinat ovat kuitenkin jo lähellä kyllästymispistettään, ja järjestelmätoimittajat hakevat kasvua lähinnä keskisuurista, mutta myös pienistä yrityksistä, ja tarjoavat niiden tarpeisiin sopivia järjestelmiä ja toimintokohtaisia järjestelmämoduuleita (Everdingen ym., 2000). Mitä laajempaa ja kokonaisvaltaisempaa toiminnanohjausjärjestelmää ollaan hankkimassa, sitä haastavampi on sen suunnittelu-, käyttöönotto- ja ylläpitoprosessi (Vilpola ja Kouri, 2006). Monet järjestelmäprojektit ovat aikojen saatossa keskeytyneet ja epäonnistuneet. Standish Groupin tutkimuksen mukaan jopa 90 % tietojärjestelmän käyttöönottoprojekteista myöhästyy aikataulustaan tai ylittää budjettinsa (Umble ym., 2002). Epäonnistuminen käyttöönottoprojektissa aiheuttaa yritykselle huomattavia taloudellisia menetyksiä ja estää järjestelmän täysimittaisen hyödyntämisen. Käyttöönottoprojekti sitoo myös voimavaroja, joita tarvittaisiin kipeästi päivittäisessä perusliiketoiminnassa. Toiminnanohjausjärjestelmän hankinnan takana on monia syitä ja yritysten lähtökohdat ovat erilaisia. Jokainen järjestelmäprojekti on luonteeltaan erilainen ja vaatii ymmärrystä yksitäisen yrityksen liiketoiminnasta ja kulttuurista. Järjestelmän käyttöönottoprojekti on oppimisprosessi, jossa tulee huomioida liiketoiminnan tarpeet, järjestelmän tuleva toimintaympäristö, käyttäjien vaatimukset ja valmiudet, sekä koko käyttäjäorganisaation toiminnan kehittäminen (Kettunen ja Simons, 2001) Käyttöönotto voi tapahtua kertaponnistuksena tai pitempiaikaisena jatkuvana toimintatapojen ja järjestelmän ominaisuuksien parempaan hyödyntämiseen tähtäävänä kehittämisprojektina. 6

7 Pk-yritysten toiminnanohjausjärjestelmän hankinta- ja käyttöönottoprojekti on osoittautunut varsin ongelmalliseksi (Kettunen ja Simons, 2001). Pk-yrityksiltä puuttuu usein tietotekniikka- ja tietohallintastrategia, jonka pohjalta yritys johdonmukaisesti toimii esim. tietoteknisten laitteiden hankintoja tehdessään ja tietoja käsitellessään. Niiltä puuttuu myös järjestelmän vaatimusmäärittelyssä ja käyttöönotossa tarvittavaa tietotaitoa. Järjestelmätoimittajien käyttämät mallinnusmenetelmät ovat vieraita, yhteinen kieli puuttuu ja kommunikointitapa on erilainen. Järjestelmätoimittajilla on näin ollen suuri valta järjestelmän myyntitilanteessa ja käyttöönottoprosessin aikana. Tuloksena saattaa olla yrityksen toimintaa huonosti tukeva toiminnanohjausjärjestelmä, johon upotetut resurssit ylittävät huomattavasti järjestelmästä saatavat hyödyt. (Tölli, 2002) Pk-yrityksillä ei ole varaa epäonnistua toiminnanohjausjärjestelmän hankinta- ja käyttöönottoprojektissa, sillä liikevaihtoon suhteutettuna järjestelmän käyttöönotto on huomattavan suuri ja aiheutuneilla kustannuksilla on suoranainen vaikutus yrityksen tulokseen. Tämän raportin tarkoituksena on tarkastella pk-yritysten toiminnanohjausjärjestelmien suunnitteluun, hankintaan ja käyttöönottoon liittyviä kriittisiä tekijöitä. Vaikka kaikki käyttöönottoprojektit ovat erilaisia ja esiin tulevat ongelmat vaihtelevat yritysten välillä, niissä on paljon samankaltaisia piirteitä ja ongelmien todennäköisiä aiheuttajia. Toiminnanohjausjärjestelmän vaatimusmäärittely on onnistuneen järjestelmäprojektin edellytys. Tässä raportissa tarkastellaan vaatimusmäärittelyn laatimisprosessia kolmessa pk-yrityksessä. Tulokset ovat osittain salaisia, joten tässä raportissa esitetään ainoastaan ne tulokset, jotka eivät liity salassapitovelvoitteen piiriin. Vaatimusmäärittelyprosessi on toteutettu osittain C-CEI-menetelmän (Customer-Centered ERP Implementation) avulla keskittyen riskianalyysin laatimiseen. Lisäksi yrityksille on laadittu järjestelmäprojektin haastavuusanalyysi ja luonneanalyysi riippuen siitä, missä vaiheessa case-yritykset ovat omaa järjestelmäprojektiaan. Case-yrityksien valinta on toteutettu siten, että mukana on toiminnanohjausjärjestelmää käyttävä yritys A, järjestelmän valintavaiheessa oleva yritys B, ja järjestelmän hankintaa suunnitteleva yritys C. 7

8 2. Toiminnanohjausjärjestelmän hankinta pk-yrityksissä 2.1. Toiminnanohjausjärjestelmät Toiminnanohjausjärjestelmä (ERP Enterprise Resource Planning) on koko organisaation kattava integroitu tietojärjestelmä, joka pyrkii yhdistämään yrityksen eri toiminnot, kuten osto- ja myyntitoiminta, tuotannon suunnittelu ja seuranta, varastotoiminnot, laadunohjaus, henkilöstö- ja taloushallinto (Kettunen ja Simons, 2001). Englanninkielisen lyhenteen ERP mukaan toiminnanohjaus on yrityksen voimavarojen; työn ja resurssien ohjausta ja suunnittelua (Laudon ja Laudon, 2000). Toiminnanohjauksen näkökulmasta tarkasteltuna organisaation työntekijät muodostavat erilaisia resurssiyksiköitä, ryhmiä, tiimejä ja osastoja. Yrityksen resursseihin sisältyvät myös mm. koneet, tuotantotilat, ja muut fyysiset puitteet. (Kettunen ja Simons, 2001) Toiminnanohjausjärjestelmän tarkoituksena on tehostaa yrityksen liiketoimintoja integroimalla liiketoimintaprosessit tehokkaammin toimiviksi kokonaisuuksiksi sekä yrityksen sisällä että myös yritysten välillä (Kettunen ja Simons, 2001). Järjestelmän tavoitteena on tukea yrityksen strategian toteutumista ja auttaa seuraamaan ja ohjaamaan kilpailukyvyn kannalta oleellisia mittareita. Asiakastyytyväisyyteen vaikuttavia mittareita ovat mm. tuotteiden ja palveluiden laatu; eri aikatekijät kuten läpäisyaika, toimitusaika ja toimitusvarmuus; ja hintakilpailukyky. Yrityksen kannalta tärkeitä menestystekijöitä ovat mm. kustannusten hallinta, varastojen hallinta, tuottavuus, kapasiteetti, koneiden ja laitteiden käytettävyys jne. Toiminnanohjausjärjestelmä voi välittää myös yrityksen asiakkaille heitä koskevaa informaatiota. (Kettunen ja Simons, 2001) Viime vuosina kehitetyt toiminnanohjausjärjestelmät ovat rakenteeltaan modulaarisia. Ne muodostuvat yksittäisistä toiminnallisista moduuleista, joita on mahdollista liittää yhteen suuremmiksi kokonaisuuksiksi asiakkaan tarpeen mukaan. Moduulien kehityksessä on keskitytty pitkälti yrityksen sisäisiin järjestelmiin, toiminnallisuuden parantamiseen ja uuden toiminnallisuuden esittelemiseen. Tänä päivänä toimittajat pyrkivät myös vastaamaan sähköisen liiketoiminnan ja verkostoituneen yritysympäristön asettamiin haasteisiin (Shields, 2001). Nykyiset toiminnanohjausjärjestelmät perustuvat pääsääntöisesti nk. client-server-arkkitehtuuriin, jolloin yrityksessä on käytössä yrityksen oma palvelin sekä erillisiä työasemia järjestelmän käyttöä varten. Toiminnanohjausjärjestelmän eri moduulit kommunikoivat suoraan keskenään tai tekemällä päivityksiä yhteiseen tai keskitettyyn tietokantaan (Luoma ym., 1999). 8

9 Tyypillisiä toiminnanohjausjärjestelmän moduuleja ovat (Brady, 2001): o Myynti ja jakelu (mm. myyntitilaukset ja toimitusaikataulut, asiakastiedot kuten hinnoittelu, laskutus- ja toimitustavat) o Materiaalinhallinta/varastonhallinta (mm. raaka-aineiden tilaukset ja niiden varastotiedot, keskeneräisen tuotannon varastojen ja lopputuotevarastojen saldot) o Valmistus/tuotannonsuunnittelu (mm. valmistuksen suunnittelu ja aikataulutus, sen hetkinen tuotannon tila, kapasiteetin hallinta) o Laadunhallinta (mm. laatusertifikaattien, laaduntarkastuksien ja laatutyökalujen hallinta) o Huolto (mm. ennaltaehkäisevän huollon suunnittelu, huoltoon liittyvät resurssit) o Henkilöstöhallinta (mm. työntekijöiden rekrytointiin, palkkaukseen ja koulutukseen liittyviä toimintoja, palkanmaksu, työsuhde-edut) o Kirjanpito/Taloushallinta (mm. tilitapahtumat, ulkoiseen raportointiin tarvittavat luvut ja lakisääteiset tunnusluvut) o Projektinhallinta (mm. projektien suunnittelu ja budjetointi, etenemisen seuranta ja projektibudjetissa pysyminen) o Seuranta (mm. kustannusanalyysit) o Omaisuuden hallinta (mm. kiinteiden kustannusten hallinta) 2.2. Toiminnanohjausjärjestelmän hankintastrategiat Toiminnanohjausjärjestelmän valinta on lähes aina kompromissi yrityksen tarpeiden ja järjestelmän ominaisuuksien välillä. Keskeisiä järjestelmän hankintaan liittyviä ongelmia ovat mm. järjestelmään kohdistuvat epärealistiset odotukset; järjestelmäntoimittajan ja loppuasiakkaan väliset kommunikointiongelmat; sekä teknologiapainotteinen suunnittelu- ja käyttöönottoprosessi, jossa asiakkaan liiketoiminnan haasteet ja toiminnan kehittämissuunnitelmat jäävät helposti järjestelmän teknisen määrittelyn, toteutuksen ja käyttöönoton jalkoihin (Kettunen ja Simons, 2001). Lisäksi ongelmia aiheuttavat riittämätön budjetti ja resurssien puute; henkilökohtaiset ristiriidat projektiryhmässä; näkemyserot eri osapuolten välillä; ja avainhenkilöiden siirtyminen muualle kesken projektin (Kale, 2000). Toiminnanohjausjärjestelmät ovat rakenteeltaan usein joustamattomia. Ne toimivat omalla logiikallaan ja periaatteellaan, ja organisaatioiden on muutettava toimintojaan ja prosessejaan niiden mukaiseksi, sillä järjestelmän muuttaminen on kallista. Järjestelmän käyttöönottoprojekti voi kestää 3-5 vuotta suurissa yrityksissä. Järjestelmän käyttöönotto pk-yrityksissä on jonkin verran 9

10 nopeampaa, mutta kestää niissäkin kuitenkin 6 kk ylöspäin. Toiminnanohjausjärjestelmillä on hierarkkinen käsitys organisaatiosta. Keskittynyt valvonta on vanhentunut tapa nykypäivän matalissa organisaatioissa, jossa valtaa on jaettu ja työntekijöillä on päätäntävaltaa oman työnsä tekemisessä. Toiminnanohjausjärjestelmää valittaessa, on huomioitava mm. seuraavia tekijöitä (Yongjean ja Ki-Heung, 2001): o Sopivuus yrityksen liiketoimintaprosesseihin o Eri moduuleiden vaatima integrointi o Joustavuus ja skaalautuvuus o Käyttäjäystävällisyys vs. kompleksisuus. o Hyötyjen realisoitumisaika Toiminnanohjausjärjestelmät voidaan jakaa kolmeen eri luokkaan (Kettunen ja Simons, 2001): 1) Räätälöidyt järjestelmät 2) Esikonfiguroidut ja parametroitavat järjestelmät 3) Standardoidut järjestelmät Räätälöidyt järjestelmät kehitetään asiakkaan omien tarpeiden pohjalta, joten tässä ratkaisussa vaatimusmäärittelyn rooli korostuu. Räätälöinnin myötä yritys saa juuri sellaisen järjestelmän kuin haluaa, mutta järjestelmän kehittäminen ja järjestelmän ylläpito vaatii paljon resursseja. Samoin riskit hankkeen viivästymiselle ja epäonnistumiselle ovat suuret. Pk-yritykset hankkivat yleensä valmiin standardoidun järjestelmän, joista asiakassovellus luodaan konfiguroimalla. Konfigurointi tarkoittaa toimitettavien moduulien valintaa sekä sovellusten muokkaamista asiakkaan tarpeisiin parametroinnin avulla. Parametreilla voidaan muokata käyttöliittymää, asettaa laskenta- ja raportointitapoja sekä valita toimintavoista asiakkaalle sopivin. Täysin standardoidut järjestelmät ovat täsmälleen samanlaisina kaikille asiakkaille. Standardituotteen ja parametroitavan tuotteen välillä on vaikeaa tehdä tarkkaa rajaa, koska standardoidut järjestelmätkin vaativat usein yrityksen perusdatan syötön. (Kettunen ja Simons, 2001) Toiminnanohjausjärjestelmän hankinta voi tapahtua eri tavoilla (Shields, 2001): 1) Yritykset voivat kehittää itse omia räätälöityjä ratkaisuja ja integroida ne muihin järjestelmiin 2) Yritykset voivat ostaa valmiita järjestelmäsovelluksia ja tehdä liittymät olemassa oleviin järjestelmiinsä 10

11 3) Yritykset voivat ostaa valmiita moduuleita eri toimittajien järjestelmäpaketeista ja rakentaa nk. best-of-breed -toimintamallin, jossa toiminnanohjausjärjestelmä toteutetaan integroimalla 2-5 tuotteen ja /tai räätälöidyn ratkaisun parhaat komponentit. Pk-yritykset suosivat eri moduuleista koostuneita valmispakettiratkaisuja, koska niillä ei ole resursseja räätälöidä ohjelmistoa, joka kattaisi kaikki niiden esittämät vaatimukset. Siksi ne tyytyvät ohjelmiston räätälöintiin vain kriittisimmillä alueilla. Pakettiratkaisut ovat huomattavasti räätälöityjä ohjelmistoja halvempia. Best-of-Breed-lähestymistapa jakaa mielipiteet. Eri toimittajilta ostettujen moduulien yhdistäminen vaatii hyvät kuvaukset moduulien liittymäpinnoista. Moduulien kehitystyö tapahtuu eri toimittajien toimesta ja uusien versioiden käyttöönotto voi tässä tapauksessa olla työläs. Liitännät muihin moduuleihin täytyy testata ja pahimmassa tapauksessa integrointityö pitää tehdä uudelleen. Erillisissä valmissovelluksissa järjestelmätoimittaja voi vastata sopimuksesta riippuen järjestelmän jatkokehittämisestä ja uusien versioiden ylläpidosta, muta räätälöidyn ratkaisun tapauksessa yritys joutuu itse vastaamaan järjestelmän jatkokehityksestä, mikä tuo yllättäviä lisäkustannuksia. Nykyään yritysten ei tarvitse ostaa ohjelmiston käyttölisenssiä, vaan ne voivat myös vuokrata järjestelmän järjestelmätoimittajalta tai vastaavalta palveluyritykseltä. Erityisesti pienet yritykset hyötyvät tästä sovellusvuokrauksesta, koska tällä tavalla he voivat hyödyntää paremmin pitkälle kehitettyjä ohjelmistotuotteita. (Karjalainen 2001) Nykyisten järjestelmien modulaarinen rakenne antaa yrityksille mahdollisuuden edetä järjestelmän käyttöönotossa asteittain ja hankkia vain ne toimintamoduulit, joita se kulloinkin tarvitsee. Yritys voi ottaa kaikki moduulit käyttöön samanaikaisesti (ns. Big-Bang ) tai tietyn joukon moduuleita kerrallaan (ns. Mini Big-Bang ). Yritys voi myös ottaa käyttöön vain yhden tai muutaman moduulin samanaikaisesti tai ottaa tietyn yksikön, tehtaan tms. moduulit kerrallaan käyttöön. Isommat yritykset suosivat enemmän jälkimmäisiä vaiheittaisia - ja samalla vähemmän riskialtista strategiaa, kun taas pienemmät yritykset suosivat Big-Bang strategiaa (Soni, 2003). Vaiheistetun käyttöönoton etuna on, että niin hyvät kuin huonotkin kokemukset voidaan ottaa huomioon myöhemmissä kohteissa. Tällainen tapa on kuitenkin luonnollisesti hitaampi toteuttaa Toiminnanohjausjärjestelmät pk-yrityksissä Pienet ja keskisuuret yritykset (pk-yritykset) ovat yrityksiä, joiden palveluksessa on alle 250 työntekijää ja vuosittainen liikevaihto on enintään 50 milj. tai taseen loppusumma enintään 43 milj.. Lisäksi toinen yritys (ei pk-yritys) voi omistaa korkeintaan 25 % pk-yrityksen pääomasta tai 11

12 äänimäärästä (Euroopan Unioni, 2008). Pk-yritysten toiminnanohjausjärjestelmän hankintaprojekti poikkeaa suurten yritysten järjestelmäprojekteista. Pk-yritykselle toiminnanohjausjärjestelmän käyttöönotto on suuri investointi ja sen vaikutukset ovat pitkäaikaisia. Pienelle yritykselle investointi voi olla merkittävä suhteessa liikevaihtoon. Järjestelmän hintahaarukka pk-yrityksille vaihtelee välillä , sisältäen ohjelmiston ja sen asennuksen sekä koulutuksen ja konsultoinnin. Pk-yritysten päätökseen hankkia toiminnanohjausjärjestelmä liittyy usein yrityksen ulkopuolisia paineita. Suuret asiakkaat vaativat jonkin tietojärjestelmän käyttöönottoa liikekumppanuuden edellytyksenä, ja tietty järjestelmä on joskus otettava käyttöön, vaikka se ei sopisi yrityksen omiin suunnitelmiin. Järjestelmä hankitaan usein siinä tarkoituksessa, että ne palvelevat 5-10 vuotta (Hyötyläinen ja Kalliokoski, 2001). Pk-yrityksillä on vaikeuksia pysyä jatkuvasti tietoteknisen muutoksen vauhdissa, koska niillä ei ole resursseja uusia järjestelmiä ja ATK-laitteitaan näin nopeasti. Viimeaikainen nopea teknologinen kehitys asettaa paineita uusia järjestelmä useammin. Tällöin järjestelmän elinkaari lyhenee tarpeettoman lyhyeksi, eikä tietotekniikkainvestoinneista ehditä saamaan haettuja hyötyjä. Teknologisen kehityksen mukanaan tuomille paineille vaihtaa järjestelmä uuteen nopealla tahdilla on myös vastavoimansa. Järjestelmiä kehitetään avoimen standardin suuntaan, joustavaksi ja helpommin muokattavaksi. Järjestelmän käyttöikää pyritään pidentämään. Näin järjestelmäprojektista saadaan paremmin hyödyt irti. Pk-yrityksillä on ominaispiirteitä, jotka ovat osoittautuneet kriittisiksi tekijöiksi koko järjestelmäprojektin onnistumisen kannalta. Pk-yritysten omistuspohja on yleensä kapea ja monet pk-yritykset ovat perheyrityksiä, joissa osakkaiden enemmistö tai äänivalta on yhden perheen tai suvun hallussa. Pk-yritysten organisaatiorakenne on matala eikä niillä ole suuryrityksille ominaisia organisaation hierarkkisuuteen liittyviä ongelmia. Ylin johto on usein myös omistaja, jolloin päätöksenteko on nopeaa ja joustavaa. Pienissä yrityksissä työntekijät tuntevat toisensa ja tiedonvaihto voi olla hyvinkin tehokasta myös ilman tietojärjestelmän apua. Matalan organisaation ansiosta tiedonkulku on nopeaa ja informaatio välittyy nopeasti tuotantoon ja reagointiaika on monissa tilanteissa lyhyt. Pienissä mikroyrityksissä ei tietojärjestelmä olekaan välttämättä ensimmäisenä kehittämislistalla. Toiminnan sähköistymisen vaatimukset tulevat kuitenkin niillekin yleensä suurilta asiakkailta. (Kalliokoski ym., 2001) Pk-yritysten johdon koulutustaso on yleensä matala ja yrityksistä puuttuu lähes täysin akateemiset työntekijät, jotka ovat erityisesti strategisen suunnittelun osaajia. Lähtökohta siis 12

13 toiminnanohjausjärjestelmän vaatimalle strategiselle suunnittelulle on heikko. Yrityksen resurssit ohjautuvat pääasiassa operatiiviseen toimintaan. Tietohallinnon tehtävät hoidetaan usein oman toiminnan ohessa ja tietohallinnon hoitaminen on ongelmakeskeistä: Ongelmat pyritään selvittämään sitä mukaa kun ne ilmaantuvat, mutta jos ongelmia ei ilmene, niin keskitytään päivittäiseen työhön (Siira 2001). Pk-yritysten päätöksiä ohjaavat käytännön sanelemat pakkoratkaisut, ei tarkasti harkitut toimintasuunnitelmat.. Monet päätökset ovat nopeasti tehtyjä ja vastuu tietojärjestelmähankkeesta annetaan sellaiselle henkilölle, joka ymmärtää tietotekniikasta eniten. Ylimmän johdon henkilökohtainen kiinnostus edistää tietotekniikan käyttöä yrityksessä. Pkyritykset eivät osaa käyttää ulkopuolisia asiantuntijapalveluita, vaikka ne voisivat toimia väliaikaisena kehittämisresurssina ja tulkkina järjestelmätoimittajan ja yrityksen välillä. Yritysten liiketoimintaprosessien ja toimintatavan muutokset toiminnanohjausjärjestelmän käyttöönoton myötä pakottavat henkilöstön muutoksiin ja aiheuttavat erilaisia valta- ja resurssijakoja. Siksi järjestelmän käyttöönotto laukaisee erilaisten ryhmien avoimen ja piilevän vastustuksen (Hong ja Kim, 2002) On tyypillistä, että järjestelmän käyttöönottovaiheissa kohdataan muutosvastarintaa. Työntekijöiden on vaikeaa muuttaa työtapoja, jotka he osaavat hyvin. Joskus työntekijät jatkavat vanhaa toimintatapaansa vaikka järjestelmä on otettu käyttöön. Muutosvastarintaa voidaan vähentää avoimuudella, keskusteluilla ja koulutuksella (Ross, 1999). Pk-yritysten on valmistauduttava käyttämään riittävä määrä rahaa koulutukseen osana toiminnanohjasjärjestelmän käyttöönottobudjettia. On arvioitu, että toiminnanohjausjärjestelmäprojektin budjetista % osuuden varaaminen koulutukseen johtaa 80 %:n todennäköisyydellä onnistuneeseen järjestelmän käyttöönottoon. Työntekijöiden pitää päästä itse kokeilemaan järjestelmän toimintaa omien jokapäiväisten toimintojensa kautta. Myös käyttöönoton jälkeinen koulutus on tärkeää, jotta voidaan käsitellä järjestelmässä esiintyneitä seikkoja ja vertailla eri käyttäjien kokemuksia. Yrityksen on myös valmistauduttava siihen, että vaativan käyttöönottoprojektin jälkeen yrityksen tuottavuus laskee hieman, ja nousee vasta kun järjestelmä on kunnolla saatu käyttöön. (Umble ym., 2002) 2.4. Toiminnanohjausjärjestelmäprojekti Toiminnanohjausjärjestelmän hankinta on useimmiten kertaluonteinen tapahtuma, projekti 1. Järjestelmän suunnittelu, hankinta ja käyttöönotto toteutetaan projektityönä, jonka osapuolet ovat järjestelmän hankkinut yritys ja järjestelmän toimittanut järjestelmätoimittaja. Järjestelmän 1 Projekti on kertaluonteinen työsuoritus ainutlaatuisen tuotteen, palvelun tai muun tuloksen tuottamiseksi (Forselius ym., 2005). 13

14 hankkiva yritys varaa hankintaprojektia varten tietyt resurssit, joiden tukemana hankinta ja käyttöönotto tullaan toteuttamaan. Projektia varten perustetaan tilapäinen organisaatio. Projektia valvoo johtoryhmä, jonka tehtäviin kuuluu projektin ajallisten ja teknisten seikkojen määrittäminen ja kustannustavoitteiden asettaminen. Johtoryhmä koostuu asiakasyrityksen ja järjestelmätoimittajan edustajista. Projektin vetäjä eli projektipäällikkö on kokonaisvastuussa projektista, sen suunnittelusta, toimeenpanosta, työn ohjauksesta ja päättämisen valmistelusta. Projektiryhmän jäsenten tehtäviin kuuluu ensisijaisesti osallistuminen projektipäällikön määräämien tehtävien suorittamiseen. (Tölli, 2002) Jos yrityksen johto ei ole kehitystyön takana, niin sen eteenpäin vieminen on mahdotonta. Ylimmän johdon lisäksi myös projektipäällikön ja koko henkilöstön sitoutuminen käyttöönottoprojektiin on tärkeää. Teknisten taitojen lisäksi projektipäällikön johtamistaito ja muutoksenhallintakyky edesauttavat projektin onnistumista. Tietojärjestelmäprojektia voidaan kuvata kuvan 1 elinkaarimallin avulla. Kuva 1. Tietojärjestelmäprojektin elinkaarimalli (Kettunen ja Simons, 2001) Kuvan e elinkaarimalli jaetaan neljään osaan (Kettunen ja Simons, 2001): o Systemaattinen strateginen suunnittelu ja strateginen näkökulma. Strategiasta voidaan erotella varsinainen liiketoimintastrategia ja tietotekniikkastrategia. Jälkimmäisessä täsmennetään tietotekniikan rooli ja asetetaan tavoitteet sen hyödyntämiselle yrityksen strategiassa. o Tietojärjestelmähankkeen suunnittelu, järjestelmän valinta sekä vaatimusmäärittely. Nämä ovat eräänlaisia esisuunnittelutoimenpiteitä itse käyttöönottoa varten. Oleellisia toimenpiteitä ovat toimintaan ja sen kehittämiseen perustuva vaatimusmäärittely valittavalle 14

15 järjestelmälle, neuvottelut ja tarjouspyyntökierrokset ohjelmistotoimittajille tai järjestelmäintegraattoreille sekä itse järjestelmän valinta. Kunnollisella, yrityksen eri toiminnot ja prosessit huomioivalla vaatimusmäärittelyllä päästään loppukäyttäjän ja toimittajan väliseen ymmärrykseen ja tätä kautta haluttuun lopputulokseen. o Tietojärjestelmän käyttöönotto, joka tarkoittaa valitun tietojärjestelmän implementointia, parametrointia ja mahdollisia uusia tietojärjestelmäversioita. Käyttöönottovaihe käsittää myös järjestelmän tuotantokäyttöön ottamisen, joka tarkoittaa toiminnan suunnittelua ja ohjausta uuden tietojärjestelmän avulla. Tähän vaiheeseen voi kuulua lisäksi mahdolliset tietojärjestelmän räätälöinnit, koulutukset ja tarpeelliset harjoituskäytöt. o Tietojärjestelmän jatkuva kehittäminen, joka tarkoittaa tietoteknisten valmiuksien ylläpitämistä ja kehittämistä sekä tietoteknisestä että liiketoiminnallisesta näkökulmasta käsin. Henkilöstön osaamisen kehittäminen kuuluu myös jatkuvaan kehittämiseen. Tietojärjestelmien jatkuva kehittäminen tarkoittaa järjestelmäpäivityksiä sekä käytössä olevan järjestelmän laajuuden kasvattamista. Jatkuva kehittäminen tulisi nähdä myös osana yrityksen normaalia toimintaa, koska siihen liittyy läheisesti myös yrityksen tai organisaation omien toimintaprosessien ja toiminnanohjauksen kehittäminen. Tietojärjestelmäprojektissa on kysymys mutkikkaista strategisista kysymyksistä, teknisistä, taloudellisista ja organisatorisista ongelmista sekä niihin liittyvien ratkaisujen hakemisesta. Järjestelmäprojektin onnistumiseen vaikuttavat keskeisesti omaksutut suunnittelu- ja käyttöönottomallit ja niihin liittyvät menetelmät. Tietojärjestelmäprojektin onnistumiseen vaikuttavat (Forsman, 1995; Umble ym., 2002): o Strategisten tavoitteiden ymmärtäminen - Selkeät odotukset ja tavoitteet o Liiketoiminnan tasolta lähtevä sitoutuminen ja johdonmukainen projektin ohjaus - Ylimmän johdon sitoutuminen o Organisaation muutoksenhallinta - Organisaatiorakenteiden ja avainprosessien yhteensovittaminen järjestelmän rakenteen, työkalujen ja informaatiotyyppien kanssa perimmäisenä tavoitteena yrityksen ja liiketoiminnan kehittäminen ei ohjelmistojen käyttöönotto o Aito tarpeiden ymmärtäminen ja jäädyttäminen toteutuksen pohjaksi - Tulevien käyttäjien tarpeet, nykytila ja muutostarpeet o Hyvä projektinhallinta - Selkeät, määritellyt tavoitteet, työtehtävät ja resurssit sekä jatkuva seuranta 15

16 o Hallittu toteutus tarvemäärityksestä tuotannolliseen käyttöön - Kokonaisuuden hallinta, riskien hallinta o Riittävän ja ammattitaitoisten resurssien osoittaminen projektiin - Asiantunteva ja kykenevä projektitiimi yrityksen sisältä ja myös ulkopuolelta o Toimiva kommunikaatio eri osapuolten välillä - Avoin ja rehellinen vuoropuhelu osapuolten kesken o Tiedon oikeellisuus - Vanhojen järjestelmien poistaminen käytöstä välittömästi uuden järjestelmän tultua käyttöön. Kaikkien on siirryttävä siihen yhtä aikaa. o Koulutus ja harjoittelu - Kaikkien työntekijöiden on osattava käyttää järjestelmää oikein. o Järjestelmän suorituskykymittareiden laatiminen - Seurataan uuden järjestelmän vaikutusta yrityksen toimintoihin ja suorituskykyyn, esim. toimitukset pysyminen aikataulussa, aika tilauksesta toimitukseen, varaston kiertonopeus, toimittajien kyvykkyys Toiminnanohjasjärjestelmän vaatimusmäärittelyn laatiminen Toiminnanohjausjärjestelmän vaatimusmäärittely luo pohjan järjestelmäprojektille ja sen läpivienti on projektin onnistumisen kannalta merkittävä. Vaatimusmäärittelyksi kutsutaan vaihetta, jossa tunnistetaan tavoitteet, tarpeet ja odotukset kehitettävänä olevalle järjestelmälle (Kettunen ja Simons, 2001). Vaatimusmäärittelyä tarvitaan ennen toiminnanohjausjärjestelmän hankintaa, jotta käyttäjä-, tilaaja- ja toteuttajaosapuolet kaikki ymmärtäisivät samalla tavoin ja riittävän kattavasti ja täsmällisesti, miten toteutettavan/hankittavan järjestelmän on tarkoitus toimia, ja mitä erityisominaisuuksia siltä odotetaan. Jos tähän vaiheeseen ei kiinnitetä riittävästi huomiota, seurauksena voi olla järjestelmä, joka ei sovellu käyttötarkoitukseensa, tai joka sisältää paljon virheitä. Vaatimusmäärittelyn aikana syntyneet virheet kostautuvat usein järjestelmän käyttövaiheessa aiheuttaen lisäkustannuksia, eikä odotettuja hyötyjä saavuteta (Alvarez ja Urla, 2002). Vaatimusmäärittelyn tarkoituksena ei ole kehittää täydellisiä liiketoimintavaatimuksia vaan dokumentoida selkeästi esitetyt vaatimukset, joiden avulla järjestelmän suunnittelun ja konfiguroinnin voidaan antaa edetä hyväksyttävällä riskillä. Vaatimusmäärittelydokumentti ei ole suunnitteludokumentti, vaan vaatimusmäärittelyssä kerrotaan mitä järjestelmän pitää tehdä - ei sitä, miten se tehdään (Kettunen ja Simons, 2001). Vaatimusmäärittely on hyvä dokumentoida siten, että vaatimusten toteutumista voidaan seurata läpi koko projektin. Yleensä vaatimusmäärittely 16

17 suoritetaan järjestelmän toimittajan tai toimittajaa konsultoivan yhteistyökumppanin toimesta. Tällöin vaatimusmäärittelytekniikat, työkalut ja prosessimetodit auttavat projektiryhmää suorittamaan tarpeelliset toimenpiteet ajallaan ja kustannustehokkaasti. Standardoituja vaatimusmäärittelyprosesseja käytetään teollisuudessa runsaasti, mutta harva pkyritys ymmärtää prosessia syvällisesti (Daneva, 2002). Vaatimusmäärittelyyn kehitetyt menetelmät ja mallit eivät yleensä sovellu suoraan pk-yrityksille. Pk-yritykset voivat kuitenkin osallistua standardoituun vaatimusmäärittelyprosessiin esim. ulkopuolisen konsultin ohjaamana. Standardoidun vaatimusmäärittelyprosessin myötä saavutetaan seuraavia hyötyjä (Daneva, 2002): o Ajan optimointi o Taattu laatu o Projektin resurssien tehokas käyttö o Tarkat projektin kustannusarviot o Tehokkaampi jäljitettävyys o Vaatimusten muutostenhallintaprosessi. Vaatimusmäärittelyn alussa tehdään usein markkinakartoitus, jonka tarkoituksena on selvittää, löytyykö markkinoilta sopiva ratkaisu tarpeiden täyttämiseksi. Jos niitä on olemassa, hankinta kohdistuu valmisjärjestelmään; muussa tapauksessa hankitaan räätälöity järjestelmä. Markkinakartoitus tapahtuu esim. pyytämällä sopivilta toimittajilta tuote-esittelyä, tutustumalla kirjalliseen ja verkossa olevaan materiaaliin, sekä kysymällä vastaavia järjestelmiä käyttäviltä yrityksiltä niiden kokemuksia. Näiden selvitysten kautta selviää samalla hankittavalle järjestelmälle asetettavia vaatimuksia. Ne ominaisuudet, jotka toiminnanohjausjärjestelmään ehdottomasti halutaan, tulee esittää täsmällisinä ehdottomina vaatimuksina. Vaatimukset perustuvat yrityksen tavoitteisiin ja eri käyttäjäryhmien eteenpäin jalostettuihin tarpeisiin. Vaatimusmäärittelyvaiheessa on tarpeen tunnistaa, koota, ryhmitellä, muokata ja karsia tarpeet sekä asettaa ne tärkeysjärjestykseen esim. taloudellisten ja teknisten tekijöiden perusteella. Näistä tarpeista muodostuu järjestelmään kohdistuvia vaatimuksia. Järjestelmävaatimukset voivat olla ehdottomia tai toivottavia. Ehdottomien vaatimusten asettamisessa tulee olla huolellinen, jotta markkinoilta löytyy ratkaisuja jotka täyttävät kaikki asetetut vaatimukset. Käytännössä vaatimusten toteuttaminen on yleensä kompromissi. (Kettunen ja Simons, 2001) Vaatimukset voidaan jakaa kahteen luokkaan (Sagheb-Tehrani ja Ghazarian, 2002): 1) toiminnalliset ja 2) ei-toiminnalliset vaatimukset Toiminnalliset vaatimukset kuvaavat millaisia toimintoja tai palveluja järjestelmältä 17

18 halutaan. Ei-toiminnalliset vaatimukset liittyvät yleensä järjestelmän suorituskykyyn (Sagheb- Tehrani ja Ghazarian, 2002). Toiminnallinen vaatimusmäärittely sisältää yleensä valitun toimintamallin graafisen kuvauksen. Siinä kuvataan tavoiteltavat hyödyt, järjestelmän toiminnot, tulevat käyttäjät, järjestelmän sisältämät raportit, keskeisimmät käsitteet sekä muut toiminnalliset vaatimukset. Tekniset vaatimukset sisältävät järjestelmän teknisen ympäristön vaatimukset, ohjelmiston tekniset laatuvaatimukset, tietoturvavaatimukset sekä käytettävyysvaatimukset. Vaatimusmäärittelyn lisäksi on tarpeen määritellä sen kehittämiseen, käyttöönottoon ja ylläpitoon liittyviä vaatimuksia. Vaatimusmäärittelyssä on tärkeää tunnistaa eri järjestelmien rajoitteet. Rajoitteet voivat olla peräisin esim. yrityksen tietotekniikkastrategiasta, suunnittelustandardeista tai lakivelvoitteista. Vaatimusmäärittelyn taso riippuu siitä, ollaanko hankkimassa valmisohjelmistoa vai räätälöitävää ohjelmistoa. Valmisohjelmiston osalta tärkeintä on kuvata järjestelmän käytön kautta tavoitellut hyödyt ja järjestelmän toteuttama lopputulos. Lisäksi määritellään ne toimintojen ehdottomat minimivaatimukset, joita hankintayksiköllä on järjestelmälle sekä lisäominaisuuksia, joista annetaan lisäpisteitä tarjousten vertailussa. Tarjouspyynnössä voidaan myös sallia vaihtoehtoisten ratkaisujen esittäminen. Räätälöidyn ohjelmiston osalta tulee kuvata järjestelmän tukema prosessi sekä sen sisältämät toiminnot kokonaisuudessaan siten, että toimittaja pystyy arvioimaan niiden toteutuksen vaatiman työmäärän. (Kettunen ja Simons, 2001) Toiminnanohjausjärjestelmän käyttö integroituu laajasti yrityksen eri henkilöiden sekä toimintojen käyttöön. Tarpeiden tunnistuksessa pitää tämä seikka ottaa huomioon, eli ainakin taloushallinnon, tuotannon ja varastotoimintojen tulisi pystyä vaikuttamaan tarpeiden kartoitukseen. Jos järjestelmää käytetään eri toimipisteissä, on hyvä selvittää erilaisten toimintatapojen ja -kulttuurien eroja, jotta järjestelmän käyttö olisi mahdollisimman helppoa. Työryhmät, keskustelut, haastattelut sekä kyselyt ovat hyviä keinoja erojen selvittämiseen. Järjestelmäprojektiin kannattaa ottaa mukaan myös järjestelmän loppukäyttäjät, jotta käyttöönotto olisi yksinkertaista sekä henkilöstö olisi sitoutunut tähän järjestelmään. (Kettunen ja Simons, 2001) 18

19 3. Kokemuksia case-yritysten vaatimusmäärittelyn luomisesta 3.1. Tutkimuksen kulku Case-yritykset ovat Raahen alueen metalli- ja puualan pk-yrityksiä. Yritykset on valittu siten, että yhdellä yrityksellä on - vaillinaisesti - toimiva järjestelmä, toinen yritys on järjestelmävalinnan edessä ja kolmas yritys suunnittelee järjestelmän hankkimista. Kaikki yritykset tiedostavat toiminnanohjausjärjestelmän merkityksen oman liiketoimintansa tehostamisessa ja kilpailukykynsä parantamisessa. Toiminnanohjausjärjestelmän valintaa (ja tehostamista) varten laadittiin case-yrityksille tekninen vaatimusmäärittely (tai muutosvaatimusmäärittely) osittain noudattaen C-CEI-menetelmää. Käytännössä työ on tehty aikana. C-CEI-menetelmä (Customer-Centered ERP Implementation) on Tampereen teknillisessä yliopistossa kehitetty menetelmä yritysten toiminnanohjausjärjestelmäprojektien tueksi. C-CEI-menetelmä jakautuu kolmeen vaiheeseen: 1) toimintoanalyysi (kriittisten toimintojen tunnistaminen yrityksen nykyisessä toimintamallissa), 2) toimintaympäristöanalyysi (toimintojen analysoiminen työympäristössä käyttäjäkeskeisen menetelmän avulla) ja 3) riskianalyysi (toiminnanohjausjärjestelmän valintaan, käyttöönottoon ja käyttöön liittyvien riskien tunnistaminen ja analysoiminen). (Vilpola ja Kouri, 2006) Tässä tutkimuksen vaiheessa on keskitytty riskianalyysivaiheeseen. Kuvassa 2 on esitetty C-CEImenetelmän vaiheet ja niiden keskinäiset suhteet. 1. Toimintoanalyysi Potentiaaliset riskit 2. Riskianalyysi ERP-logiikasta eroavat käytännöt Organisaation yrityskohtaiset käytännöt Priorisoidut vaatimukset järjestelmälle Potentiaaliset riskit Arvioidut riskit 2. Toimintaympäristö- analyysi Toimintaympäristön vaatimukset käyttöönotolle Toiminnanohjausjärjestelmän käyttö Kuva 2. C-CEI-menetelmän vaiheet (Vilpola ja Kouri, 2006) 19

20 C-CEI-menetelmä keskittyy yrityskohtaisiin kriittisiin toimintoihin yleisellä tasolla tapahtuvien prosessikuvausten sijaan sekä toimintaympäristön (käyttäjät, tehtävät, laitteet ja fyysinen sekä sosiaalinen ympäristö) analysoimiseen osana toiminnanohjausjärjestelmän vaatimusmäärittelyä ja käyttöönoton suunnittelua. Kriittiset toiminnot ovat niitä kohtia, joissa yrityksellä on suurin muutostarve siirryttäessä uuteen toiminnanohjausjärjestelmään, yrityksen tietojenkäsittelytarve korostuu tai on havaittavissa organisatorisia erityispiirteitä. Perinteiset menetelmät eivät anna kattavaa kuvaa yrityksen organisaatiosta, kulttuurista ja fyysisestä ympäristöstä. Näitä tietoja varten C-CEI-menetelmässä sovelletaan käyttäjäkeskeistä suunnittelumenetelmää toimintaympäristön analysointiin. Tavoitteena on käyttäjätarpeiden ymmärtäminen. Käyttäjäkeskeisen suunnittelun on tarkoitus pienentää toiminnanohjausjärjestelmän kehitys-, ylläpito- ja käyttökustannuksia ja parantaa järjestelmän laatua. Tämä tarkoittaa 1) toiminnanohjausjärjestelmän valintakriteerien määrittelyä ja priorisointia parhaiten yritykselle soveltuvan järjestelmän valitsemiseksi, 2) käyttöönoton suunnittelua ja riskienhallintaa käyttöönottoajan lyhentämiseksi ja käyttöönoton tehokkuuden kasvattamiseksi ja 3) käyttöönoton koulutusresurssien kohdistamista kriittisiin toimintoihin yrityksen toiminnan turvaamiseksi ja järjestelmän kohdistuvien investointien hyödyntämiseksi. (Vilpola ja Kouri, 2006) C-CEI-menetelmän mukainen riskianalyysi muodostuu 63 toiminnanohjausjärjestelmän hankintaan, käyttöönottoon ja käyttöön liittyvästä kysymyksestä tai väittämästä, joiden laukeamisen vaikutusta yrityksen toimintaan arvioidaan asteikolla 1-5 ja toteutumisen todennäköisyyttä asteikolla 1 5. Jokaiselle case-yritykselle laadittiin riskianalyysi, yrityskohtainen raportti, jossa kuvattiin tärkeimmät ja vaikutuksiltaan suurimmat riskit. Lisäksi esitettiin muutamia ehkäisykeinoja näille riskeille. Useat riskit pienenevät mm. tarkalla vaatimusten määrittelyllä, kehittämällä muutosjohtamiskykyä ja kiinnittämällä enemmän huomiota järjestelmäsopimuksen pykäliin. Järjestelmän suunnittelu- ja valintavaiheessa sekä sopimuksen laatimisvaiheessa pk-yritysten on parasta käyttää asiantuntijaa. Toiminnanohjausjärjestelmäprojektin käynnistämispäätösvaiheessa on tärkeää tietää, mitä tavoitellaan ja mitä konkreettisesti aiotaan tehdä, ja miten ja millaisena kokonaisuutena järjestelmäprojekti aiotaan toteuttaa. Mikäli esiselvitystyötä ei ole tehty, on projektiryhmä haastavassa tilanteessa. Projektiryhmän avuksi on luotu erityinen työkalu, nk. projektin luonneanalyysi, jonka avulla voidaan varmistaa, että projekti on tavoitteidensa, sisältönsä ja toteuttamistapansa suhteen hallittavissa. Luonneanalyysin perusteella saadaan tietoa projektin osittamisesta ja vaiheistamisesta. Luonneanalyysi muodostuu 30 kysymyksestä, joihin vastatessa 20

21 projektiryhmän jäsenet joutuvat pohtimaan projektin lopputulosta, kontekstia ja muita erityispiirteitä. Kysymykset ovat positiivisia ja negatiivisia väittämiä, joiden oikeellisuutta projektin yhteydessä pohditaan. Luonneanalyysi tulos voidaan esittää graafisena tuloksena (Forselius ym., 2005) (vrt. kuva 7). Haastavuusanalyysi on luonneanalyysia laajempi analyysi, joka tuottaa tuloksena suosituksen siitä, minkä johtamisen osa-alueiden hallintaan tulee kiinnittää erityistä huomiota tarkasteltavassa tietojärjestelmäprojektissa (organisointi, ohjeistus, menetelmät ja työkalut). Lisäksi haastavuusanalyysi nostaa esille ne kysymykset, jotka erityisesti vaikuttavat ko. osa-alueiden haasteellisuuteen. Haastavuusanalyysi kertoo myös kriittisistä tekijöistä, riskeistä ja osoittaa puutteita johtamisessa, joita toiminnanohjausjärjestelmän, tai minkä tahansa muun suuren tietojärjestelmän, käyttöönotto aiheuttaa yrityksessä. Analyysi muodostuu järjestelmäprojektiin liittyvistä 90 kysymyksestä, joihin vastatessaan yrityksen henkilöstö joutuu pohtimaan perusteellisesti projektin toteuttamistilannetta ja toimintaympäristöä sekä johtamisen osa-alueiden vaatimuksia. Analyysin kysymykset ovat luonteeltaan positiivisia tai negatiivisia väittämiä, joiden oikeellisuutta pohditaan järjestelmäprojektin yhteydessä. Kysymyspatteristo on toteutettu Exceltyökalulla, joka käsittelee vastaukset automaattisesti annettujen laskentasääntöjen mukaisesti. Neliöillä ja sinisellä värillä piirretty käyrä kuvaa ko. projektia koskevien, kuhunkin tietämysalueeseen liittyneiden vastausten keskiarvoa. Sitä voidaan pitää varsinaisena haastavuusprofiilina. Toinen, vinoneliöillä ja punaisella värillä tehty, laajemman alueen kattava käyrä kuvaa kutakin tietämysaluetta koskevien yksittäisten vastausten korkeinta arvoa. Sen tehtävänä on lähinnä avustaa haastavuusprofiilin tulkinnassa ja nostaa esiin poikkeuksellisen haasteellisia yksityiskohtia projektista (vrt. kuva 6) Case 1: Yritys A Yritys A on Raahen alueella toimiva noin 20 työntekijän yritys. Yrityksen A suunnitelmissa on toiminnanohjausjärjestelmän hankinta. Järjestelmäprojektia ei ole vielä perustettu, dokumentoitua esiselvitystä mahdollisista sopivista järjestelmistä ei ole vielä tehty, eikä neuvotteluja järjestelmätoimittajien kanssa ole aloitettu. Kuvassa 3 on esitetty yrityksen A nykyinen järjestelmä. Yrityksen tietokoneet ovat yhteydessä toisiinsa langattoman verkon kautta. Dokumenttikone sisältää kaikki yrityksen dokumentit, mutta dokumentteja on talletettuna myös muille koneille. 21

22 Nykyinen järjestelmä sisältää seuraavat toiminnot: yrityksen asiakashallinta, tuotetiedon ja tuoterakenteen hallinta, projektinhallinta, osto- ja myyntitilausten hallinta sekä tuotteen elinkaaren hallinta. Nykyisen järjestelmän ongelmana on monien (> 100) erilaisten Excel-, Word- ja AutoCaddokumenttien variaatioiden ja versioiden hallinta. Ongelmia aiheuttavat myös tuotannon karkeakuormitus ja hienokuormituksen puuttuminen, tarjoussuunnittelun ja projektien aikataulun epätarkka laatiminen, varaston hallinnan puuttuminen ja ostotilausten hallinta. Yrityksen A tarkoituksena on hankkia toiminnanohjausjärjestelmä, jonka tarjoaa apua tuotannon karkea- ja hienokuormitukseen siten, että projektin aikataulutus ja resurssien jakaminen voidaan suunnitella tarkasti ennen projektin aloittamista. Lisäksi uudelta järjestelmältä vaaditaan, että se tukee varastonhallintaa ja ostotilausten tekemistä. Kuva 3. Yrityksen A nykyinen järjestelmä 22

23 Yrityksen A kriittiset toiminnot tunnistettiin läpikäymällä yrityksen toiminnot pienryhmissä. Yrityksen A toiminnan kuvaaminen aloitettiin muodostamalla yrityksen liiketoimintaprosesseista rakennekaaviot 2. Rakennekaavio laadittiin yrityksen johdon kanssa. Tavoitteena oli selvittää, mitkä ovat yrityksen kriittiset toiminnot, joiden tiedonsiirrosta tulevan toiminnanohjausjärjestelmän pitää kyetä selviytymään. Lisäksi mallinnettiin liiketoimintaa ja toimintoihin liittyvää tiedonkulkua pohjautuen johdon ja työntekijöiden haastatteluihin. Kukin pääprosessi (Markkinointi, Suunnittelu, Tuotanto, Huolto, Johdon prosessit, Talousprosessit) kuvattiin tarkemmalla tasolla (esim. Tuotanto jaettiin Tuotannonohjaukseen, Työnsuunnitteluun, Materiaalitoimintoihin, Valmistukseen ja Kunnossapitoon). Sen jälkeen kuvattiin järjestelmään liittyviä oleellisia prosesseja vielä tarkemmalla tasolla. Ensimmäisessä vaiheessa kaaviot tehtiin PostIt -lapuilla yrityksen neuvotteluhuoneen seinälle, jossa sitä voitiin helposti muutella. Sen jälkeen niitä analysoitiin ja koottiin prosessien rakennekaavio. Kuvassa 4 on esitetty yrityksen A pääprosessien rakennekaavio. YRITYS A Markkinointi Suunnittelu Tuotanto Huolto Johdon Talous prosessit prosessit Myynti Tuotekehitys Tuotannon- Varaosat Yrityksen Palkanlaskenta 111 (uusi tuote) ohjaus 141 kehittäminen 161 Mainostaminen Piirustukset Työnsuunnittelu Huoltokeikat Laatu Maksuliikenne Tuotteet Konetoimitusten Materiaali- Reklamaatiot Henkilöstö Osto- ja 113 dokumentointi toiminnot myyntireskontra Valmistus Huolto ja Dokumentin- Rahoitus 134 varaosamyynti hallinta 164 Kunnossapito Projektinohjaus Kuva 4. Yrityksen A toiminnan rakennekaavio 2 Rakennekaavio on graafinen kuvaus rakenteesta, prosesseista tai kokonaisuudesta jonka avulla voidaan rajata ja hahmottaa niitä. 23

24 Seuraavassa vaiheessa pyrittiin havainnoimalla seuraamaan työntekijöiden työtä kriittisissä prosessivaiheissa. Näin pyrittiin selvittämään millaisia työvaiheita kriittiseen työprosesseihin kuuluu ja miten tieto liikkuu vaiheesta toiseen. Tällainen havainnointi antaa hyvän kuvan siitä, miten yrityksessä toimitaan ja millaisia ongelmia tarkasteltavassa prosessissa nousee esille. Havainnoinnin tavoitteena oli löytää tiedonkulkuun liittyvät tekijät, joihin tulevan järjestelmän pitää kyetä vastaamaan. Havainnoinnin aikana tapahtuvat poikkeukset, virheet ja poikkeamat normaalista prosessista, antoivat tietoa erilaisista prosessin ongelmakohdista. Apukeinona havainnoinnissa käytettiin digitaalikameraa sekä sanelinta, jotta havainnoinnin aikana käytyä keskustelua voitiin analysoida myöhemmin. Tämän lisäksi kriittisessä prosessissa työskentelevä henkilö kertoi omin sanoin, miten prosessi etenee yrityksessä. Haastatteluiden ja työprosessien havainnoinnin pohjalta laadittiin erilaisia prosessikaavioita, joiden avulla pyrittiin kuvaamaan, miten prosessit etenevät yrityksessä ja miten tieto kulkee eri rajapintojen välillä (kuva 5). Kuva 5. Yrityksen A suunnitteluvaiheen sekvenssikaavio 24

25 Yrityksen A suurimmat tuotannon ongelmat löytyivät kuormituksessa ja varaston hallinnassa. Varastonhallinta ei ollut ajan tasalla, sillä varastokirjanpito oli pääasiassa työntekijöiden muistin ja silmämääräisen tarkistuksen varassa. Yrityksen A kriittisimmäksi prosessiksi nousi suunnitteluprsessi. Sitä varten on tarkoitus hankkia erillinen PDM-järjestelmä (Product Development Management), koska monet toiminnanohjausjärjestelmät tukevat huonosti tuoterakenteen hallintaa. Vaatimusmäärittelyn laatiminen aloitettiin pohjautuen toimitusjohtajan kanssa käytyihin keskusteluihin, työntekijöiden haastatteluihin ja prosessimallinnuksen tuloksiin. Havainnoinnin ja keskustelujen pohjalta löydetyt ongelmat muokattiin vaatimuksiksi. Johdon kanssa käydyissä palavereissa vaatimuksia yhä edelleen tarkennettiin. Lopuksi yrityksessä tehtiin toiminnanohjausjärjestelmän haastavuus- ja riskianalyysi. Yrityksessä on vähän työntekijöitä ja järjestelmäprojektin käyttöönottoon tarvittavan resurssin puute todettiin suureksi riskiksi. Lisäksi satojen Excel-tiedostojen siirtäminen uuteen järjestelmään ei välttämättä suju helposti, koska tietoja ei voi muokkaamatta siirtää uuteen järjestelmään. Yrityksen A kanssa käytiin läpi riskilista, jossa arvioitiin riskin vaikutusta ja todennäköisyyttä järjestelmäprojektin onnistumiseksi. Analyysin mukaan suurimmat riskit järjestelmähankkeessa syntyvät, kun valitaan väärä järjestelmätoimittaja; tai joka ei ymmärrä yrityksen tarpeita oikein; tai joka ei sitoudu riittävästi järjestelmäprojektin läpiviemiseen; tai joka ei kehitä järjestelmää tulevaisuudessa; tai lopettaa kokonaan järjestelmätuen. Lisäksi suurena riskinä yritys A pitää tilannetta, jossa ERP valitaan yrityksen toimintaan epäsopiva järjestelmä; tai järjestelmä, joka ei huomioi yrityksen erityistarpeita, tässä tapauksessa riski on lähinnä tuotetiedon hallinnan osalta. Suuri riski syntyy myös jos ylin johto ei tue järjestelmäprojektia, tai ei anna tarpeeksi resursseja. Myös järjestelmäprojektin ohjausryhmän/projektiryhmän mahdollinen kompetenssipuute on pienessä yrityksessä suuri riski. Analysoitaessa, mitkä riskit todennäköisesti laukeavat yrityksessä A, esille nousi suurimpina riskeinä projektipäällikön osa-aikaisuus järjestelmäprojektissa sekä järjestelmän integrointivaikeudet muihin olemassa oleviin järjestelmiin. Lisäksi jos toimittaja ei sitoudu riittävästi järjestelmään käyttöönottoon; tai ei ymmärrä asiakkaan tarpeita oikein, voi koko hanke epäonnistua. Yrityksessä A on vähän työntekijöitä (alle 20), joten resurssin puute on todennäköinen riski. Järjestelmän integrointi muihin järjestelmiin tuottaa ongelmia ja tietojen siirtäminen vanhasta 25