P a g e 1. Yhteistoiminnallinen ohjelmistohankinta

P a g e 1 Yhteistoiminnallinen ohjelmistohankinta

P a g e 2 Sisällys Johdanto... 3 Organisationaalinen oppiminen... 4 Tiedon luomisen prosessi... 4 Yhteistoiminnallinen ohjelmistohankinta (Co-operative Software Acquisition, COSA)... 6 Vaihe 0: Tiimin muodostaminen... 7 Tutustumisvaihe... 7 Roolien ja tehtävien jako... 8 Vaiheen 0 tehtävät... 10 Vaihe 1: Tavoitteiden ja tarpeiden tunnistaminen (Externalization)... 10 Vaiheen 1 tehtävät... 11 Vaihe 2: Järjestelmähahmotelman muodostaminen (Combination)... 12 Vaatimusten määrittely... 12 Valintakriteerien määrittely... 13 Ohjelmistokandidaattien etsintä... 14 Vaiheen 2 tehtävät... 15 Vaihe 3: Testaus ja käyttöönotto (Internalization)... 16 Vertailu ja valinta... 16 Testaus... 17 Käyttöönotto... 17 Vaiheen 3 tehtävät... 17 Vaihe 4: Käytön levittäminen (Socialisation)... 18 Vaiheen 4 tehtävät... 18 Kirjallisuutta... 19

P a g e 3 Johdanto Valmisohjelmistojen hankinta on tullut yhä haasteellisemmaksi ja työläämmäksi osaksi yritysjohdon toimintaa. Pienten ja keskisuurten yritysten johdolla ei ole edes aikaa eikä resurssejakaan paneutua asiaan kunnolla. Hyvin usein turvaudutaan ohjelmistovalmistajien antamiin tietoihin ja lopulliset päätöksetkin tehdään luottaen järjestelmän toimittajan antamiin ehdotuksiin. Tietokoneohjelmistohankinta rinnastetaan usein perinteisiin investointiprojekteihin, jossa hankintahintaa verrataan kuviteltuihin tuottoihin ja kustannussäästöihin. Onnistunut osto ja käyttöönottoprosessi nähdään pelkästään tehtävien teknisenä hallintaongelmana. Projektin tekninen läpivienti ei yleensä olekaan ongelma, sillä ammattitaitoisen toimittajan avustuksella ohjelmisto saadaan kyllä asennettua ja teknisesti toimimaan. Varsinaiseksi haasteeksi ja yrityksen omalle vastuulle sitä vastoin jää hankitun ohjelmiston käyttöönotto ja uuteen toimintatapaan oppiminen. Tämä prosessi on vaativa ja aina tapauskohtainen riippuen yrityksen omasta toimintakulttuurista ja kokemushistoriasta. Näin ollen myös tulevien tuottojen ja kustannusten arviointi on osoittautunut melkein mahdottomaksi tehtäväksi, sillä niistäkään selviä perinteisillä investointilaskelmilla, vaan yrityksen oman toiminnan huolellisella arvioinnilla. Ohjelmistojen hankinta on ennen kaikkea liiketoiminnallinen päätös. Koska ohjelmistot noudattavat ennalta määriteltyjä prosesseja, olisi ohjelmistohankintakin aloitettava omien prosessien analyysista. Hankinta on suunniteltava huolellisesti ja siihen on otettava mukaan kaikki asianosaiset. Oikean ohjelmiston valinta ja tehokas käyttöönotto syntyy kun kaikki osapuolet - varsinkin tulevat käyttäjät - sitoutetaan prosessiin mahdollisimman aikaisessa vaiheessa. Ohjelmistojen hankinta on myös muutos- ja oppimisprosessi. Vaikka teknologia on tässä prosessissa vahvasti mukana, niin sen liiketoiminnalliset hyödyt syntyvät vasta sen käytöstä. Näin ajateltuna tämän prosessin keskeisinä toimijoina ja oppimisen subjektina ovat ne ihmiset, joita tämä muutos koskee, eli käyttäjät, yritysjohto, ICT-henkilöt ja usein myös asiakkaat ja yhteistyökumppanit. Jotta muutos tapahtuisi jouhevasti ja ihmiset myös sen hyväksyisivät, on se tehtävä yhteistoiminnassa kaikkien mukana olevien osapuolten kanssa. Yhteistoiminnallisen ohjelmistohankinnan (COSA) perusajatus on, että ohjelmistohankinnasta tehdään organisaation oppimistapahtuma, jossa käyttäjät valitsevat käyttämänsä ohjelmiston niin itsenäisesti kuin mahdollista. Työntekijöiden osallistuminen omaa työtään koskeviin päätöksiin myös sitouttaa käyttämään ohjelmistoa tehokkaammin. Keskeisintä tässä toiminnassa on kehittää organisaation voimavaroja yhteisöllistä luomalla toimintaa, joka sitouttaa työntekijät vapaaehtoisesti toimimaan yrityksen hyväksi sekä yksilönä että ryhmänä.

P a g e 4 Organisationaalinen oppiminen Organisationaalinen oppiminen on japanilaisen tutkijan, Ikujiro Nonakan kehittämä teoria organisaation toiminnan perusteista. Hänen näkemyksensä mukaan organisaatiot ovat viime kädessä tietoa käsitteleviä ja tietoa tuottavia yksiköitä. Yrityksen menestys riippuu siitä, miten hyvin se oppii kokemuksistaan ja muuntaa saadun tiedon uusiksi toimintamalleiksi. Organisaatiossa tapahtuva muutos on ymmärrettävä siis oppimisprosessina. Organisaation muutokset ovat ongelmakeskeisiä oppimistilanteita, jossa ihmiset systemaattisesti tuottavat ja jalostavat sitä tietoa, jonka ohjaamana he toimivat ongelmia ratkaisseissaan. Tieto on kuin energiaa: se varastoituu erilaisiin organisaation toimijoihin ja jalostuessaan muuttaa jatkuvasti muotoaan. Yritysten pyrkimyksenä on yleensä esittää tiedot eksplisiittisessä eli näkyvässä muodossa, jotta ne olisivat helpommin varastoitavissa, kehitettävissä ja siirrettävissä. Näkyvä tieto muodostuu kaikista kirjoitetusta ja muusta sellaisesta tiedosta, joka on helposti siirrettävissä muodossa kuten dokumentteina, web-sivustoina, tietokantoina ja työohjeina sekä tietokoneohjelmistoina. Yrityksen jokapäiväisessä toiminnassa syntyy myös valtava määrä hiljaista tietoa, joka ei ole niin helposti siirrettävissä eikä tunnistettavissakaan. Hiljaista tietoa on esimerkiksi kokemus, taidot, asenteet, arvot ja työtavat. Hiljainen tieto on sisäistettyä ja sidottua siihen tilanteeseen, missä sitä käytetään. Jotta yrityksen eksplisiittiset tietovarat muuttuisivat tuottavaksi toiminnaksi, ne on saatava tiedot hiljaiseen muotoon. Tiedon alkuperä ja varastoitumispaikka on viime kädessä yksilö. Ilman yksilöitä ei tieto muuttuisi toiminnaksi. Toiminnassaan yksilö toteuttaa omaa yksilöllistä tietoaan. Toimiessaan yhteisön jäsenenä, yksilöt kuitenkin sopeuttavat toimintansa osaksi organisaation toimintaa. Yhdessä omaksuttu asia muuttuu yhdessä toimimisen tietoperustaksi eli organisationaaliseksi tiedoksi. Tiedon luomisen prosessi Organisaation oppiminen perustuu yksilön ja yhteisön väliseen dynaamiseen vuorovaikutukseen. Vaikka oppiminen tapahtuu yksilöissä, niin yksilöt levittävät oppimaansa toisille ja valikoivat opittavat asiat organisaation käytänteistä. Uusia asioita opiskellaan usein tietoisesti, mutta yksilöt omaksuvat niitä myös suoraan työn kautta. Kokemus synnyttää uutta tietoa, jota voidaan jalostaa uuteen systemaattisempaan ja organisaatiolle käyttökelpoisempaan muotoon. Organisaation oppimisprosessi (kuva alla) on tiedon jatkuvaa muuntumista eri muodosta toiseen ja leviämistä organisaation eri tasoilla. Tiedon alkuperä on yksilöissä ja tavallisesti se on luonteeltaan myös hiljaista. Jotta tätä tietoa voitaisiin jalostaa ja saada organisaation käyttöön, on se ensin ulkoisotettava luovassa dialogissa näkyvään muotoon. Tämä tiedon muuntaminen on avaintekijä organisaation tiedonmuodostuksessa. Näkyväksi muunnettua tietoa voidaan sitten kehittää yhdistelemällä sitä muun näkyvän tiedon kanssa. Jalostettu uusi tieto on sisäistettävä hiljaiseksi tiedoksi eli käytännölliseksi osaamiseksi työssä oppimisen avulla. Hiljainen tieto siirtyy sen jälkeen yksilöltä toiselle sosialisaatiossa eli yrityksen arkikäytännössä kokemuksia jakamalla.

P a g e 5 KUVA: Tiedon luomisen prosessimalli, SECI malli Tieto jalostuu muuntumalla muodosta toiseen neljässä eri vaiheessa (kuva yllä): Ulkoistaminen (Externalisation): Hiljaisesta tiedosta näkyväksi Yhdistely (Combination): Näkyvästä tiedosta näkyväksi Sisäistäminen (Internalization): Näkyvästä tiedosta hiljaiseksi Sosialisaatio (Socialization): Hiljaisesta tiedosta hiljaiseksi Hankittaessa ohjelmistoja, on yrityksen ensin paljastettava nykytilanteessa ilmeneviä ongelmia ja pohdittava tulevaisuuden mahdollisuuksia. Tässä toiminnassa syntyvä tieto on kokemusperäistä ja jäsentymätöntä hiljaista tietoa. Käyttäjät ilmaisevat käsityksensä nykyisestä järjestelmästä ja asettavat toiveita uudelle järjestelmälle. Nämä kirjataan eli ulkoistelaan mahdollisimman kattavasti näkyvässä muodossa. Tiedot yhdistellään valmiiksi hankittavaa ohjelmistoa koskeviksi vaatimusmäärittelyiksi, jolloin saadaan kokonaiskuva hankittavasta ohjelmistosta. Yhdistelyvaihe jatkuu, kun markkinoilta etsitään vaatimuksia vastaava ohjelmisto. Käytännön opiskelun ja testauksen kautta tiedot sisäistetään, harjoittelemalla ohjelman käyttöä ja testaamalla sen toimintaa käyttöympäristössään. Lopullisesti ohjelman käyttö leviää ja tehostuu käyttäjien välisessä yhteistyössä eli sosialisaatiossa. Yhteistoiminnassa opitut työkäytännöt muodostavat perustan sille, miten hyvin opitusta saadaan

P a g e 6 toivotut hyödyt. Ohjelmiston käytön syvyys ja laajuus riippuva niistä ihmisistä, jotka ohjelmistoa käyttävät. Yhteistoiminnallinen ohjelmistohankinta (Co-operative Software Acquisition, COSA) Yhteistoiminnallinen tietojärjestelmän hankinta (COSA) on malli, joka soveltaa organisaation oppimisen teoriaa tietojärjestelmän hankintaan. Mallin ydinajatuksena on, että koko hankintaprosessi viedään mahdollisimman lähelle käyttäjää. Parhaiten mallin soveltaminen onnistuu, kun yrityksessä on jo valmiiksi avoin ilmapiiri ja henkilökunnalla on kokemusta tietotekniikasta ja yhteistoiminnallisista työmenetelmistä. Malli soveltuu pienille ja keskisuurille yrityksille, jotka toimivat tietointensiivisellä ja/tai palvelualalla. Malli ei sovellu puhtaasti teknisille ICT-hankinnoille, joissa hankittavalla ohjelmistoilla ei ole vaikutusta loppukäyttäjien työhön. Mallia ei tule myöskään soveltaa laajamittaisiin, koko organisaatiota koskeviin muutoshankkeisiin, jossa muutos ei aiheudu tietotekniikasta. Keskeisenä toimijana COSA prosessissa on kehitystiimi, jonka johdolla koko hankinta viedään läpi. Hankintatiimin muodostamisen lisäksi mallissa on neljä vaihetta, jotka perustuvat neljään tiedon muunnosprosessiin: ulkoistaminen, yhdistely, sisäistäminen ja sosialisaatio.

P a g e 7 KUVA: Yhteistoiminnallinen tietojärjestelmän hankinta Vaihe 0: Tiimin muodostaminen Tutustumisvaihe Tiimin ensimmäinen tehtävä on tutustuttaa jäsenet toisiinsa. Tavoitteena on keskinäisen arvostuksen luominen ja kaikenlaisten jännitteiden kuten kilpailun, pelon, salailun ja muun sellaisen poistaminen. On myös äärimmäisen tärkeää, että yrityksen ylempi johto osoittaa sitoutumisensa tiimin työlle. Tiimin kokoonpanossa on varmistuttava seuraavista asioista: 1. Selkeä visio ja tavoite (Intention) Ihmisen toiminta on luonteeltaan tarkoitettua ja tavoitteellista. Siksi on varmistettava, että tiimin jäsenillä on käsitys siitä, mihin ohjelmiston hankinnalla pyritään. Tärkeintä ei vielä ole tavoitetilan tarkka kirjaaminen vaan tiimin yhteinen tahto ja sitoutuminen. 2. Autonomia (Autonomy)

P a g e 8 Tiimi toimii itseohjautuvana. Työhön osallistuvien jäsenten on voitava ilmaista vapaasti käsityksensä. Yksittäiset jäsenet ovat toiminnassaan autonomisia, mutta jakavat saman informaation ja mukautuvat yhdessä muodostettuun tietoon yhteisen päämäärän hyväksi. Jäsenet eivät toimi varsinaisesti taustaryhmiensä edustajina. 3. Vaihtelu ja luova kaaos (Fluctuation and creative chaos) Tiimissä tulee olla erilaisia asiantuntijoita. Luovuus syntyy vaihtelun ja epäjärjestyksen ympäristössä. Vaihtelua ja uusia ideoita voidaan edistää myös keinotekoisesti järjestämällä irrottamalla työntekijät arkirutiineista ja tiimityön työolosuhteisiin vaihtelua ja ulkoisia kaaosta aiheuttavia virikkeitä. 4. Ylimäärä (Redundancy) Tiedot muodostus ei saisi jäädä kenenkään yksittäisen asiantuntemuksen varaan, vaan sen pitäisi syntyä erilaisten näkemysten synteesinä. Tiimiin voidaan valita useampia henkilöitä, joilla on saman bisnesalueen tuntemusta, sekä henkilöitä, jotka ymmärtävät muidenkin tarpeita. Samalla tiimin jäsenille tulisi jakaa tietoa yrityksen toimista, johdon vastuualueista ja koko yrityksestä kokonaisuutena. 5. Riittävä moninaisuus (Requisite variety) Tiimin jäsenissä tulisi olla edustaja riittävän monesta osapuolesta. Mikään näkemys ei saisi dominoida. On varmistettava myös, että tiimillä on pääsy tarvittaviin tietolähteisiin ja monipuoliset tiedot tehtäväalueesta. Roolien ja tehtävien jako Tiimin jäsenet osallistuvat työhön eri rooleissa, jolloin kullakin on oma asiantuntijuusalueensa. Samalla alueella voi olla myös useampia asiantuntijoita. Roolit ovat luoteeltaan tehtävien jakamista, jonka suhteen jäsenet ovat tasa-arvoisia. 1) Yritysjohto (Knowledge officer) Yritysjohdon roolina on asettaa reunaehdot, suunta ja tavoitteet, mutta se ei osallistu aktiivisesti tiimin varsinaiseen toimintaan. On kuitenkin tärkeää, että yritysjohto sitoutuu asettamaansa työhön. Resursseja on varattava riittävästi, jotta henkilöillä on aikaa paneutua työhön kunnolla. 2) Tiimin vetäjä (Knowledge engineer) Tiimin vetäjän tärkeimpänä tehtävänä on koota ja yhdistellä tiimin työssä syntyvää luovan kaaoksen tuloksia järkeviksi kokonaisuuksiksi. Samalla hän toimii yritysjohdon asiamiehenä ohjaamalla ryhmää kohti yritysjohdon visiota, mutta myös välittämällä yritysjohdolle kokemusperäistä tietoa. Hän toimii myös välittäjänä tiimin ulkoisiin intressiryhmiin. 3) Loppukäyttäjät (Knowledge operators)

P a g e 9 Loppukäyttäjillä tarkoitetaan sitä ryhmää, joilla on konkreettisin suhde hankittavaan ohjelmistoon. Heidän kokemuksensa antaa arvokasta tietoa nykyisistä ongelmista ja asetettavista järjestelmävaatimuksista. Heidän tieto on pääosin hiljaista tietoa ja heistä viime kädessä riippuu tulevan järjestelmän hyödyt. 4) Toimialan ja tietojärjestelmien asiantuntijat (Knowledge specialists) Asiantuntijat toimivat pääasiallisesti eksplisiittisen tiedon tasolla. Heiksi luetaan sekä alan asiantuntijat että ICT-asiantuntijat. Heidän tietämyksensä on käytössä lähinnä silloin kun yhdistellään eksplisiittistä tietoa järjestelmävaatimuksiksi. Tiimin varsinainen työ alkaa kun jäsenet tutustuvat toisiinsa ja jakavat hiljaista arvoistaan ja asenteistaan. Tavoitteena on saavuttaa myönteinen työvire ja löytää työlle yhteinen tavoite. On tärkeää, että tiimi samalla kun sen jäsenet tuovat oman kokemuksensa ja näkemyksensä esille, myös löytää yhteisen kentän jossa näkemyksiä voi vaihtaa.

P a g e 10 Vaiheen 0 tehtävät Tehtävä Kuvaus 1 Tiimin tutustuminen Sosiaalistaminen Tiimin dynamiikan oppiminen 2 Roolien ja tehtävien jako Yritysjohto Tiimin vetäjä Loppukäyttäjät Toimialan ja tietojärjestelmien asiantuntijat Vaihe 1: Tavoitteiden ja tarpeiden tunnistaminen (Externalization) Tämän vaiheen tehtävänä on selvittää nykyinen tilanne ja siihen liittyvät ongelmat. Tiimin jäsenten olisi löydettävä yhteinen näkemys siitä miksi vanha järjestelmä korvataan uudella ja mitä uudella ohjelmistolla tavoitellaan. Keskustelun painopiste pidetään mahdollisimman käytännön läheisenä. Käyttäjät keskustelevat työstään ja siihen liittyvistä ongelmista. Jotta tarpeet tunnistettaisiin oikein, on selvitettävä tarpeiden taustalla olevaa liiketoimintaa ja työprosesseja. Keskustelun aluksi käydään läpi keskeiset käsitteet ja varmistetaan, että käsitteiden merkitys on kaikille sama. Tavoitteena on tunnistaa mahdollisimman paljon tarpeita ja saada jäsenten hiljainen tieto eksplisiittiseen muotoon. Niiden tarpeellisuus arvioidaan myöhemmin. Aluksi määritellään se mihin liiketoiminnalliseen tavoitteeseen järjestelmällä pyritään. Tavoitteena voi olla joko poistaa havaittu ongelma tai tarttua johonkin mahdollisuuteen. Ongelmista pidetään kirjaa ja kuvataan sitä tilannetta jossa se ilmenee, sekä sen seurauksia. Havaitun ongelman poisto tai mahdollisuuden käyttö on perustuttavat yrityksen strategiaan. Työhön liittyviä ongelmia ovat esimerkiksi puutteellinen tieto, kohtuuton työkuorma, ajan vienti, turhat manuaaliset työt, jne. Mahdollisuus liittyy siihen tapaa, jolla tehtävä voitaisiin hoitaa uudella tavalla. Uusi ohjelmisto yleensä tarjoaa tällaisia mahdollisuuksia. Mahdollisuuksien löytäminen riippuu käyttäjien motivaatiosta, asiaan liittyvästä yleisestä tiedosta ja yhtiön ulkopuolelta saaduista virikkeistä. Vaikka ongelmien tunnistaminenkin on tärkeä vaihe, vie mahdollisuuksien etsiminen työtä enemmän eteenpäin. Työ jatkuu työprosessien analyysillä, missä kuvataan käytännön läheisesti, mitä kussakin tehtävässä tapahtuu, millä tavalla tietokone siinä avustaa ihmistä ja miten tehtävän eri osat on jaettu tietokoneen

P a g e 11 ja ihmisen välillä. Tärkeää on kuvata tehtävään liittyviä tietoja eli mitä tietoja tehtävässä tarvitaan ja mitä tietoja siinä syntyy. Kuvaus tehdään tehtävien, ei suorittajien, mukaisesti. Käyttäjien tarpeet ja muut ohjelmistovaatimukset ovat keskeisin tunnistettava asia. Ohjelmistolle asetettavien vaatimusten haussa lähdetään yleensä juuri määritellyistä tehtävien kuvauksista ja luetellaan vaatimukset niiden pohjata. Toinen tapa on kokonaisuutta korostava. Tässä tavassa tehtyjen tehtäväkuvaisten perusteella määritellään ensin ohjelmiston yleiskuvaus, jonka perusteella johdetaan yksittäiset tarpeet. On mahdollista käyttää myös niiden yhdistelmää. Yhdistetyssä menetelmässä, voidaan käyttää kielikuvia ja metaforia, joilla ilmaistaan toivotut piirteet. Esimerkki dokumenttienhallintajärjestelmän vaatimusmäärittely: Tehtävän kuvauksesta lähtevä: Järjestelmän tulisi löytää annetun projektin dokumentit ryhmiteltynä asiasisällön mukaan. Kokonaisuutta korostava: Järjestelmään tulee voida tallettaa ja sieltä pitää olla joustavasti haettavissa kaikki dokumentit ennalta määriteltyjen avainsanojen mukaisesti. Kielikuvia käyttävä: Järjestelmän tulee avustaa käyttäjää kuin informaatikko kirjastossa, jonka vuoksi mennään kun tarvitsee jotain dokumenttia, mutta ei ole aavistustakaan edes avainsanoista, joilla sitä voisi hakea. Toiminnallisten tarpeiden lisäksi on myös ns. ei-toiminnallisia ja puhtaasti teknisiä tarpeita. Näitä ovat esimerkiksi helppokäyttöisyys, opittavuus, ylläpidettävyys, yhteensopivuus, käytetyt standardit, jne. Myös muut valintaan hiljaisesti vaikuttavat tekijät, kuten esimerkiksi arvot (esim. avoin koodi), imago, maine jne. olisi listattava. Tässä vaiheessa ei kuitenkaan pidä arvioida tai verrata tarpeita keskenään. Ohjelmiston toimittajille on asetettava etukäteen myös selkeät kriteerit. Näitä ovat esim. palvelun määrä ja laatu, koko, paikallisuus, jne. Päätöksentekoon saattaa vaikuttaa myös sellainen kokemusperäinen tieto, jota ei voi ilmaista eksplisiittisesti. Tällaisiin kuuluvat sellaiset tekijät kuten maine, arvot, imago, omakohtaiset kokemukset ja sidokset, jne. Tämän tyyppiset asiat saattavat vaikuttaa vaarallisen paljon ellei niitä tunnisteta ajoissa. Vaiheen 1 tehtävät Tehtävä Kuvaus 1 Tavoitteiden kuvaus Havaitut ongelmat Mahdollisuudet 2 Tehtävien kuvaus Mitä kussakin tehtävässä tapahtuu

P a g e 12 Tarvittavat tiedot Syntyvät tiedot 4 Tarpeet Järjestelmään toimintaan liittyvät tarpeet Muut tarpeet 4 Järjestelmän rajaus Mitä kuuluu järjestelmän piiriin Mikä ei kuulu järjestelmän piiriin Vaihe 2: Järjestelmähahmotelman muodostaminen (Combination) Tämän vaiheen tehtävänä on käydä läpi esitetyt tarpeet ja päättää mitkä niistä otetaan mukaan hankittavan järjestelmän vaatimusmäärittelyyn. Edellisessä vaiheessa tuotettua näkyvää tietoa arvioidaan, yhdistellään ja kootaan kokonaisvaltaisemmaksi hahmotelmaksi. Tässä vaiheessa päätetään myös arviointikriteereistä sekä ohjelmiston että ohjelmistotoimittajan osalta. Arviointikriteereissä määritellään kunkin vaatimuksen painoarvo eli kuinka paljon kyseistä ominaisuutta painotetaan lopullisessa valinnassa. Samalla sovitaan se miten ja mitä tietoa arvioinnin pohjaksi kerätään. Kun ohjelmiston vaatimukset ja arviointikriteerit tiedetään, voidaan aloittaa ohjelmistokandidaattien etsintä. Työ tapahtuu pääasiallisesti näkyvän tiedon varassa. Vaatimusten määrittely Tehtävä alkaa käyttäjien toiveiden luokittelulla ja niiden asettamisella tärkeysjärjestykseen. Kustakin toiveesta päätetään onko se realistinen ja asetetaanko se mukaan hankittavan järjestelmän vaatimusmäärittelyjen listalle. Kustakin ominaisuudesta muodostetaan mahdollisimman konkreettinen kuva, jotta sen laatu olisi helposti testattavissa. Kuvauksesta voi tuoda esille myös mahdolliset muutokset henkilöiden työhön ja liiketoimintaan. Vaatimukset luokitellaan neljään ryhmään: 1) Toiminnalliset ominaisuudet: Toiminnot, jotka ohjelmistolla voidaan suorittaa. 2) Ei-toiminnalliset ja tekniset ominaisuudet: Muut ominaisuudet, jotka vaikuttavat käytettävyyteen, toimivuuteen tai muuhun vastaavaan. Tällaisia ominaisuuksia ovat esimerkiksi: käyttöliittymä, luotettavuus, ylläpidettävyys, siirrettävyys, vaatimukset muulta ohjelmistolta ja koneelta, yms.

P a g e 13 3) Toimittajan ominaisuudet: Minkä tyyppisen yhtiön kanssa haluamme luoda kumppanuuden. Tulevalta ohjelmistotoimittajalta voimme arvioida esim. seuraavia asioita: Kokemus, pysyvyys, maine, koulutus, ohjelmistotuki ja markkinaosuus. Tulevaan vaikuttaa myös se, onko yritys asiakas- vai tuoteorientoitunut. Myös yhtiön koolla ja paikallisuudella on oma arvonsa. 4) Hinta ja kustannukset: Ohjelmiston hankintahinta on vain jäävuoren huippu todellisista kustannuksista. Tulevien tuottojen ja kustannussäästöjen määrä ei riipu hankittavasta ohjelmistosta vaan siitä miten sitä tulevaisuudessa käytetään. Valintakriteerien määrittely Ennen numeraalista arviointia, vaatimukset on syytä listata tärkeysjärjestykseen. Kustakin vaatimuksesta päätetään onko se pakollinen (ns. avain eli diskriminoiviin ominaisuus), suotava vai ainoastaan hyvä lisäominaisuus. Jos pakollinen ominaisuus puuttuu tai se ei täytä minimivaatimuksia pudotetaan ehdokas. Muussa tapauksessa ominaisuus painaa lopullisessa valinnassa sen mukaan minkä arvion se saa lopullisessa vertailussa. Ryhmille ja niiden ominaisuuksille määritellään painokertoimet välillä 0 100 %. Ominaisuuksien summa on ryhmän painokerroin ja ryhmien painokertoimien summa on 100 %. Alla oleva esimerkki kuvaa asiaa: Ryhmä Ominaisuus Paino Pakollisuus Toiminnalliset 50 % Dokumenttien hakuominaisuudet Eri tiedostotyyppien tuki 20 % pakoll. 30 % pakoll. Ei-toiminnalliset ominaisuudet 20 % Käyttöliittymä 20% pakoll. Tekniikka 10 % MS yhteensopivuus 10 % suotava Toimttaja 10 % Ohjelmistotuki 7 % Koulutus 3 % Hinta 10 % Yhteensä 100 %

P a g e 14 Tiedot vertailua varten voidaan saada esimerkiksi seuraavilla tavoilla: Eksplisiittiset lähteet: 1) Kyselyt toimittajan referenssiyrityksistä 2) Kirjalliset lähteet kuten käyttöoppaat, tutkimukset, kirjallisuus, web-sivut, yms. 3) Muodollinen tarjouspyyntö (RFP) Hiljaista tietoa sisältävät tietolähteet: 4) Konferenssit 5) Demo toimittajan tiloissa 6) Demo omissa tiloissa 7) Tutustuminen ohjelmistoon toimittajan asiakkaan luona 8) Pilotointi Tiedonhankintatavat ovat listattu siinä järjestyksessä, kun ne vievät aikaa. Ohjelmistokandidaattien etsintä Ohjelmistokandidaattien etsintä kannattaa aloittaa eksplisiittisillä tietolähteillä. Tiedon lähteinä käytetään mahdollisimman objektiivisia ja riippumattomia lähteitä kuten käyttöoppaita, kolmannen osapuolen raportteja ja tutustumiskäyntejä. Helpoin ja nopein tapa ohjelmistokandidaattien etsinnässä on Internet. Toimittajien web-sivustolta löytyy yleensä hyviä kuvauksia ja demoja ohjelmiston toiminnallisuuksista ja sieltä voi yleensä ladata ilmaisen kokeiluversion. Toimittajiakin voidaan käyttää, mutta tässä vaiheessa heitä ei pidä päästää dominoimaan päätöksentekoa. Muodollinen tarjouspyyntö on luonnollisin tapa etsiä selvittää sekä ohjelmiston, että toimittajan ominaisuudet. Se on syytä valmistella huolella. Se sisältää ainakin seuraavat asiat 1. oman toiminnan lyhyt kuvaus 2. hankittavan ohjelmiston tarkoitus 3. toimittajan ohjeet ja aikataulu 4. ohjelmiston yleiskuvaus 5. ohjelmiston toiminnalliset vaatimukset 6. ei toiminnalliset vaatimukset 7. vaatimukset toimittajasta Jos tarjouspyyntö on kirjoitettu huolellisesti ja siinä ohjeistetaan tarjoajat hyvin, saadaan samanmuotoisia tarjouksia, joiden perusteella on helppo pisteyttää ominaisuudetkin. Samalla tarjous toimii pohjana tuleville sopimusneuvotteluille. Tässä vaiheessa huomio voidaan kiinnittää pelkästään siihen onko ohjelmistokandidaatilla kaikki vaaditut ominaisuudet. Huomio on ehdokkaiden karsinnassa eikä vertailussa. Jos avainominaisuudeksi

P a g e 15 ominaisuus puuttuu, voidaan kandidaatti jättää pois lopullisesta vertailusta. Mitä pitemmälle vertailu etenee, sitä enemmän painotetaan hiljaiseen tietoon perustuvia tietolähteitä. Vaiheen lopussa tehdään päätös koekäyttöön otettavasta järjestelmästä ja sen toimittajasta. Loppusuoralle on syytä ottaa 2 3 ehdokasta. Valinta tulee tehdä mahdollisimman läpinäkyväksi ja sen tulee perustua asetettuihin kriteereihin. Henkilökunnalle tulisi varata mahdollisuus vielä tässäkin vaiheessa vaikuttaa tehtyyn kokeilupäätökseen. Vaiheen 2 tehtävät Tehtävä Kuvaus 1 Vaatimusten määrittely Toiminnalliset ominaisuudet: Ei-toiminnalliset Tekniset ominaisuudet Toimittajan ominaisuudet Hinta ja kustannukset 2 Valintaperusteiden määrittely Avainominaisuuksien määrittely Ryhmittely Painokerrointen määrittely Tiedonhankintamenettelyt 3 Ohjelmistokandidaattien etsintä Kyselyt toimittajan referenssiyrityksistä Kirjalliset lähteet kuten käyttöoppaat, tutkimukset, kirjallisuus, web-sivut, yms. Muodollinen tarjouspyyntö (RFP) Konferenssit

P a g e 16 Vaihe 3: Testaus ja käyttöönotto (Internalization) Vertailu ja valinta Lopullisessa arvioinnissa käydään läpi jokainen ohjelmistokandidaatti ja arvioidaan sen kykyä vastata esitettyyn vaatimusmäärittelyn ominaisuuteen asteikolla 1-10. Ominaisuudet pitäisi pystyä arvioimaan ensikäden kokemuksen kautta eli näkemällä toimivuus demossa tai kokeilemalla itse. Vain siten voidaan arvioida miten ja missä laajuudessa toiminnallisuus on ohjelmistossa toteutettu. Paras arvio saadaan siten, että kukin arvioitsija arvioi ominaisuuden täysin itsenäisesti tietämättä muiden antamista arvioista. Lopullinen arviointi otetaan joko keskiarvona tai mediaanina. Kun pisteet on annettu, lasketaan painotetut pisteet ottamalla painon ilmoittaman prosenttimäärä toimittajan pisteistä (esim. Ostotarjouksen teko: 20 % x 8 = 1,6). Ohjelmistojen vertailuun kannattaa käyttää valmista Excel laskenta-alustaa: Toimittaja 1: Ohjelmisto A Toimittaja 2: Ohjelmisto B Ryhmä Ominaisuus Paino Pisteet Painotetut pisteet Pisteet Painotetut pisteet Toiminnalliset 50 % Dokumenttien hakuominaisuudet 20 % 8 1,6 8 1,6 Eri tiedostotyyppien tuki 30 % 10 3,0 8 2,4 Eri tietostotyyppien tuki 20 % Käyttöliittymä 20 % 5 1,0 9 1,8 Teknologia 10 % MS yhteensopivuus 10 % 8 0,8 10 1,0 Toimittaja 10 % 1,0 0,7 Koulutus 2 % 5 0,1 0 0 Ohjelmistotuki 8 % 5 0,4 1 0,1 Hinta 10 % 6 0,6 10 1,0 Yhteensä 100 % 8,5 7,9

P a g e 17 Testaus Kokeiluvaiheen tehtävänä on saada konkreettinen kuva ohjelmiston sopivuudesta. Tässä vaiheessa toimitaan hiljaisen tiedon tasolla, jossa huomio kiinnitetään käyttöliittymän toimivuuteen, opittavuuteen ja muihin käyttäjien kokemuksiin ja asenteisiin. Tiimin jäsenet ovat edelleen avainasemassa testaajina. Testauksen aikana pidetään kirjaa käytöstä ja kerätään kokemuksia. Tulevan käytön kannalta on tärkeää, että ihmiset voivat sanoa kokemuksensa jo käyttöönottovaiheessa. Samaan aikaan kerätään myös toimittajan asiantuntemusta ja palvelukykyä. Testauksen kohteena voi olla myös sopivuus yhtiön strategiaan, innovatiivisuus, realistisuus, teknologinen sopivuus sekä kustannukset ja tuotot. Käyttöönotto Lopullinen ostopäätöksen tekemiseksi kerätään kaikki kokemuksellinen tieto. Ohjelmiston varsinainen käyttöönotto organisaatiossa voidaan tehdä kahdella tavalla: levittämällä käyttöä asteittain henkilöltä henkilölle tai kaikki ottavat ohjelmiston käyttöön samanaikaisesti kertarysäyksellä. Jos ohjelmistoa ei voi ottaa käyttöön asteittain, on siirtymisvaiheen kertarysäys suunniteltava huolellisesti. Ihmisten on voitava valmistautua huolella työssä tapahtuviin muutoksiin. Tiimin jäsenet ovat avainasemassa ensimmäisinä käyttäjinä ja muutosagentteina. Vaiheen 3 tehtävät Tehtävä Kuvaus 1 Valinta Demo toimittajan tiloissa Demo omissa tiloissa Tutustuminen ohjelmistoon toimittajan asiakkaan luona Pilotointi Arviointipisteiden antaminen Painotettujen keskiarvojen laskeminen ja valinta 2 Testaus Pilotointi omassa yrityksessä 3 Käyttöönottosuunnitelma Asteittain Kertarysäyksenä

P a g e 18 Vaihe 4: Käytön levittäminen (Socialisation) Käyttöönotto onnistuu parhaiten työn yhteydessä ja sen kautta työntekijältä toiselle. Sen onnistuminen riippuu siitä miten vallitsevaa asenneilmastoa ja työssä oppimisen tilanteita pystytään hallitsemaan. Käyttöönotto voidaan tehdä myös kertarysäyksenä, jolloin uuden järjestelmän käyttöön siirrytään nopealla aikataululla ja kaikki yhtä aikaa. Kultakin osastolta ja työpisteistä valitaan avainhenkilöt, jotka opettavat järjestelmän käyttöä työtovereilleen. Käyttöönotto tulisi järjestää yksilöllisenä työssä oppimisena. Myös muut tukitoimet olisi suunniteltava yhdistettynä ohjelmiston työssä käyttöön. Järjestelmän käytöstä on hyvä kerätä kokemuspäiväkirjaa ohjelmiston luotettavuuden seuraamiseksi mutta myös käyttökokemusten vaihtamista varten. Vaiheen 4 tehtävät Tehtävä Kuvaus 1 Siirtymä Tiedotus Asennukset Työssä oppiminen 2 Tukitoimenpiteet Koulutus Lähituki

P a g e 19 Kirjallisuutta Eskelin Allen: Technology Acquisition: Buying the Future of Your Business, Addison-Wesley Professional, 2001 Nonaka Ikujiro: A Dynamic Theory of Organisational Knowledge Creation, Organisation Science, Vol 5, No 2, 14-37, 1994 Nonaka, Ikujiro & Takeuchi, Hirotaka: The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York: Oxford University Press, 1995.