Loppukäyttäjän näkökulma toiminnanohjausjärjestelmän vaatimuksiin 1 Vaatimusmäärittely järjestelmän elinkaaressa

Kuten tämän julkaisun muissa artikkeleissa on tuotu esiin, yrityksen tietotek-niikkaa voidaan kehittää kolmella tasolla:

− strategian määrittelyllä

− yksittäiset tietotekniikkahankkeilla ja

− käytön aikaisella järjestelmien ja toimintatapojen parantamisella.

Tietojärjestelmätarpeen määrittelyä pk-yrityksessä käsitellään tässä artikkelissa yksittäisen tietojärjestelmähankkeen näkökulmasta, ts. lähtien tilanteesta, jossa

yrityksessä on tehty päätös tietojärjestelmän hankinnasta tukemaan toiminnan-ohjausta. Kohteena ei siis ole tätä päätöksentekoa edeltävä vaihe, esimerkiksi yleisen tietohallintostrategian kehittäminen tai koko tietojärjestelmä-arkkitehtuurin määrittely. Tällainen strategisen tason vaatimusmäärittely ohjaa koko tietojärjestelmiin kohdistuvaa kehittämistyötä yleisellä tasolla.

Tietojärjestelmähankkeen elinkaarimallissa (ks. I artikkeli) tarpeiden ja vaati-musten määrittely asettuu ennen kaikkea kahteen vaiheeseen:

1. Yrityksessä on tehty päätös tietojärjestelmähankinnasta, mutta toimittajaa tai tuotetta ei vielä ole valittu. Tällöin on yleensä tarkoituksenmukaista tunnistaa keskeisimmät tarpeet ja käydä läpi organisaation toimintatapojen kehittämistä tietojärjestelmän hankintaan liittyen, mutta ei määritellä yksityiskohtaisesti, miten systeemin tulisi toimia. Tämän vaiheen tulisi antaa riittävästi tietoa toi-mittajan (ja kenties ratkaisun) valintaa varten. Lopputuloksena voi olla esim.

toiminnallinen kuvaus, jonka pohjalta toimittajilta voidaan pyytää tarjous järjes-telmästä ja selvittää tarjolla olevien tuotteiden soveltuvuutta. Jos tarpeiden kar-toitus jää tässä vaiheessa tekemättä ja hypätään suoraan toimittajan valintaan, voi tästä aiheutua jatkossa lisätyötä ja ongelmia sekä hankintaprojektin aikana että varsinaisessa käyttövaiheessa.

2. Toimittajan ja ohjelmistotuotteen (-tuotteiden) valinnan jälkeen tehdään tarkempi määrittely siitä, miten uuden järjestelmän kanssa toimitaan, esim.

miten valittu tuote sovitetaan (parametroidaan) yrityksen toimintaan. Käyttäjä-roolien, -tehtävien ja prosessien tunnistaminen ja keskeisten käyttäjien henki-löinti auttaa ymmärtämään tavoiteltua tulosta. Tämä vaihe on jo lähempänä jär-jestelmän suunnittelua, mutta siihen voi liittyä myös läpikäyntiä vaatimusten tasolla. Varsinainen vaatimusmäärittely pitäisi olla kuitenkin tehty jo ennen tuot-teen hankintaa.

3.2 Järjestelmätyypit ja niiden vaikutus vaatimusten määrittelyyn

Vaatimusten määrittelyn suoritustapaan ja sisältöön vaikuttaa paitsi suorittaja ja ympäristö myös tapa, jolla yrityksen tietojärjestelmä rakennetaan. Toiminnan-ohjausjärjestelmät voidaan jakaa toteutustavaltaan kolmeen luokkaan:

1. Räätälöidyt järjestelmät kehitetään kokonaan asiakkaan tarpeiden mukaan.

Tällöin vaatimusmäärittelyn rooli korostuu, kun ei lähdetä liikkeelle mistään valmiista ratkaisusta. Räätälöinnin hyvänä puolena on, että voidaan saada juuri sellainen järjestelmä kuin halutaan. Haittana on tietysti kehittämisen ja ylläpidon vaatimat suuret resurssit sekä ohjelmistotoimittajalta että asiakkaalta. Samoin riskit hankkeen viivästymiselle ja epäonnistumiselle ovat suuret. Käytännössä täysin räätälöityjä järjestelmiä ei voida pk-sektorilla toteuttaa kuin hyvin rajat-tuihin tehtäviin. Osittainenkin räätälöinti on usein liian kallista. Toisaalta räätä-löidytkin tuotteet perustuvat yleensä aiemmin toteutettujen moduulien tai kom-ponenttien osittaiseen uudelleenkäyttöön. Räätälöidyssä toimituksessa luodaan kuitenkin myös uutta ohjelmistokoodia tai muokataan aikaisempaa.

2. Esikonfiguroidut ja parametroitavat järjestelmät. Toiminnanohjausjärjestel-mien toteutuksessa yleisin menettelytapa ovat standardituotteet, joista asiakasso-vellus luodaan konfiguroimalla. Konfigurointi tarkoittaa tyypillisesti modulaari-sen tuotteen toimitettavien moduulien valintaa sekä sovellukmodulaari-sen virittämistä asiakkaan tarpeisiin parametroinnin avulla. Parametreillä voidaan valita esim.

tarjolla olevista toimintatavoista asiakkaalle sopivin, asettaa laskenta- ja rapor-tointitapoja tai muokata käyttöliittymää.

3. Täysin standardit tuotteet edustavat toista ääripäätä, joissa joka kerta toimite-taan täsmälleen sama järjestelmä. Koska nämäkin tuotteet usein vaativat yrityk-sen perusdatan syötön, ei ole mahdollista tehdä tarkkaa rajaa parametroitavan ja standardituotteen välillä. Standardituotteet sopivat parhaiten tukemaan määrät-tyjen, melko tarkasti rajattujen toimialojen tai toimintojen tarpeita.

Tuotteiden jakoa näihin kolmeen ryhmään hämärtää vielä se, että useissa tapauk-sissa toimitettava järjestelmä joudutaan liittämään muihin, jo olemassaoleviin yrityksen tai yhteistyökumppaneiden (asiakkaiden, alihankkijoiden) järjestel-miin, mikä usein vaatii standardisysteemin rinnallekin räätälöityjä ratkaisuja.

Ohjelmistotuotteen ja -toimituksen tyyppi vaikuttaa siihen, miten vaatimusmää-rittelyä tehdään ennen toimittajan valintaa ja toteutusprojektissa ja mikä rooli siinä on asiakkaalla ja toimittajalla. Realistisia ratkaisuja pk-yrityksille ovat yleensä vain paketoidut tuotteet (luokat 2 ja 3), jolloin toimittajan valintaa edel-tävä vaatimusmäärittely voi olla tehokasta jakaa kahteen vaiheeseen:

− tavoitteiden ja tarpeiden kartoitus ja keskeisten ja ehdottomien vaatimusten määrittely

− toiminnanohjausjärjestelmätuotteiden soveltuvuusanalyysi: miten tarjolla olevat tuotteet palvelevat yrityksen tarpeita.

Molemmissa vaiheissa on tarpeellista käydä läpi yrityksen toiminnan ja sen ohjauksen kokonaisprosesseja sekä luoda pohjaa järjestelmän organisatoriselle käyttöönotolle mm. henkilöstön motivoinnin ja osallistumisen avulla.

Jos loppukäyttäjällä on ennestään luottamukselliset suhteet johonkin tietotek-niikkatoimittajaan, voi ko. toimittaja olla mukana hankintaprosessissa jo varsin varhaisessa vaiheessa. Näin on, kun yrityksessä on jo käytössä jokin toiminnan-ohjausjärjestelmä, jota halutaan laajentaa tai päivittää. Tällöin vaatimusmäärit-tely jää helposti suppeaksi, ja olemassa oleviin ongelmiin haetaan ratkaisua niistä tuotteista, joita toimittaja tarjoaa. Tämä ei ole keveydessään välttämättä huono ratkaisu, mutta toisaalta yrityksen pidemmän tähtäimen tarpeet ja suunnat voivat jäädä siinä pohtimatta.

Jos yritys ei koe käytössä olevien järjestelmien voivan toimia pohjana uudelle järjestelmälle, tai jos yrityksessä ei ole ennestään mitään riittävän kattavaa jär-jestelmää, on loppukäyttäjän käynnistettävä hankintaprojekti, mm. tarpeiden määrittely, omin voimin. Tyypilliselle pk-yritykselle hanke on usein vaativa ja yritykset voivatkin helposti joutua ”toimittajien vietäviksi”. Saadakseen realisti-sen kuvan tuotteista pk-yritys voi esim. kokeilla tai testata ohjelmistoja omalla aineistollaan ja tutustua muissa yrityksissä käytössä oleviin sovelluksiin ja yri-tyksen käyttökokemuksiin. Myös toimittajan referenssien ja laatujärjestelmän arviointi voi olla tarpeen.

Etenkin suurilla ohjelmistotoimittajilla voivat tarjolla olevat ratkaisut, asiakas-toimitusprosessi ja sen työkalut olla varsin pitkälle määritellyt. Konfiguroitavista ratkaisuista voi olla olemassa prosessimallikirjastot, joista voidaan valita yrityk-selle sopivin toimintatapa. Mallikirjastojen kasvaessa ja monimutkaistuessa pk-yritysten ongelma selviytyä hankkeesta ei ole kuitenkaan poistunut. Lisäksi käytettävät välineet soveltuvat usein vain tietotekniikkaa syvällisemmin ym-märtävien osapuolien keskustelun tueksi. HANSKA-projektin haasteena onkin

kehittää nimenomaan pk-yrityksille soveltuvia tehokkaita menettelytapoja myös vaatimusmäärittelyvaiheeseen.

3.3 Toiminnan kehittäminen vai tietojärjestelmän hankinta?

Tietotekniikkahanketta tulisi tarkastella kokonaisuutena, ei vain teknisenä muu-toksena. Vaatimuksia määriteltäessä tulisi lähteä liikkeelle liiketoiminnan ja käyttäjien tarpeista. Nämä on toivottavasti kuvattu yleisellä tasolla teknologia-strategiassa.

Yritysten tietojärjestelmähankkeiden laajuus ja vaikuttavuus organisaatiossa vaihtelee laajoista organisaatioiden uudelleenjärjestelyistä lähes puhtaisiin tie-tojärjestelmäostoihin. Ei ole olemassa yhtä sääntöä, miten laajasti ja syvällisesti vaatimuksia tulisi kartoittaa – vaatimusmäärittelyn tarve riippuu mm. hankkeen tavoitteista. Molemmissa ääripäissä väijyy mahdollisuuksia epäonnistumiselle:

− Liian laaja tarpeiden kartoitus ja toimintojen läpikäynti voivat johtaa loput-tomaan pohdintaan, joka voi tulla kalliiksi ja joka voi viivästyttää hanketta merkittävästi (ns. ”analysis paralysis”). Organisaation eri osien ja toimijoi-den liittäminen projektiin on välttämätöntä erilaisten käyttäjäryhmien tarpei-den huomioon ottamiseksi mutta se ei takaa hankkeen onnistumista. Kartoi-tusvaiheessa tarvitaan myös kokonaisnäkemystä yrityksen prosesseista, eri osien yhteensovittamista ja päätöksentekopisteitä.

− Epäonnistumisen mahdollisuudet ovat suuret, jos vain ostetaan systeemi

”kaupan hyllyltä” pohtimatta lainkaan sitä, mihin sitä tarvitaan ja miten sen tukemana tulisi toimia. Näissä tapauksissa käyttöönotto ei välttämättä ai-noastaan viivästy ja niele ylimääräisiä resursseja, vaan tuloksena voi myös olla, että järjestelmää ei saada lainkaan käyttöön tai vain vajaakäyttöön.

Toimintatapojen ja -prosessien muuttaminen on yleensä vaikeaa. Joskus se onnistuu nopeasti ja joskus taas vaatii asteittaista etenemistä. Samoin on tieto-järjestelmän käyttöönoton laita. Vaikuttavia tekijöitä ovat ainakin hankkeen luonne ja tavoitteet, organisaation koko, osaaminen, yrityskulttuuri ja käyttöön-ottoon käytettävissä olevat resurssit. Pk-yritysten yhteinen piirre on resurssien rajallisuus; osaamistaso ja yrityskulttuuri sen sijaan vaihtelevat.

Yrityksen toiminnan kehittämistä on käsitelty enemmän mm. tämän julkaisun III artikkelissa.

4. Vaatimusmäärittelyn vaiheet