käyttöönotto pk-yrityksessä Toiminnanohjausjärjestelmän · 2020-02-18 · 3 Toiminnanohjausjärjestelmän käyttöönotto pk-yrityksessä. Teknologialähtöisestä ajattelusta

V T T J U L K A I S U J A

Jari Kettunen & Magnus Simons

Toiminnanohjausjärjestelmänkäyttöönotto pk-yrityksessäTeknologialähtöisestä ajattelustakohti tiedon ja osaamisen hallintaa

8 5 4

VTT JU

LKAISU

JA 854

Toiminnanohjausjärjestelm

än käyttöönotto pk-yrityksessä

VTT JULKAISUJA – PUBLIKATIONER

837 Meinander, Harriet & Österlund, Ralf. Suojakäsineiden käyttömukavuus. Tutkimus hikoilevallakädellä. HIKKÄSI-pojektin loppuraportti. 1999. 22 s. + liitt. 6 s.

838 Suomen merikuljetusten turvallisuus. Tutkimusohjelma 1996–1998. Toim. Juhani Sukselainen &Risto Jalonen. 1999. 123 s.

839 Suomi-Lindberg, Leena, Viitaniemi, Pertti, Häkkä-Rönnholm, Eva & Ritschkoff, Anne.Metalliliittimien korroosio puurakenteissa. Biokorroosio. 1999. 50 s. + liitt. 9 s.

840 Pingoud, Kim & Perälä, Anna-Leena. Arvioita puurakentamisen kasvihuonevaikutuksesta. 1.Skenaariotarkastelu potentiaalisesta puunkäytöstä ja sen kasvihuonevaikutuksesta vuosien 1990ja 1994 uudisrakentamisessa. 2. Rakennuskannan puutuotteiden hiilivaranto Suomessa: inven-taariot vuosilta 1980, 1990 ja 1995. 2000. 58 s. + liitt. 14 s.

841 Pipatti, Riitta, Tuhkanen, Sami, Mälkiä, Pirjo & Pietilä, Riitta. Maatalouden kasvihuonekaasu-päästöt sekä päästöjen vähentämisen mahdollisuudet ja kustannustehokkuus. 2000. 72 s.

842 Hienonen, Risto & Lahtinen, Reima. Korroosio ja ilmastolliset vaikutukset elektroniikassa. 2000.231 s. + liitt. 164 s.

843 Laasonen, Juha. Saastuneiden sedimenttien käsittelymahdollisuudet Kymijoessa ja kenttä-kokeiden suunnittelu. 2000. 115 s. + liitt. 4 s.

844 Sipari, Pekka & Parmanen, Juhani. Teräsvälipohjien askelääneneristävyys. 2000. 51 s. + liitt.12 s.

845 Karttunen, Mikko, Österlund, Ralf, Rounioja, Vuokko, Avellan, Pekka, Jussila, Marjo & Ruus-kanen, Pekka. Kiinteän tilan prosessointi ja metalli-, polymeeri-, keraami-yhdistelmämateriaalit.2000. 85 s. + liitt. 12 s.

846 Nurmilaakso, Juha-Miikka. Yritysverkostojen taloustieteellinen tarkastelu. 2000. 95 s. + liitt.12 s.

847 Riihimäki, Markku, Lehtinen, Erkki, Muroma, Martti, Häme, Taneli & Näkyvä, Tapio.Brandiajattelu kiinteistöalalla. 2001. 86 s. + liitt. 18 s.

848 Häkkinen, Tarja, Vares, Sirje, Vesikari, Erkki & Karhu, Vesa. Rakennusten elinkaaritekniikka.Tuoteinformaatio käyttöikäsuunnittelun tueksi. 2001. 79 s.

849 Hemmilä, Pasi, Usenius, Arto, Welling, Irma, Olllila, Tapani & Rautio, Sari. Ympäristöystä-vällinen puuntyöstö. 2001. 104 s.

850 Vesikari, Erkki, Rautiainen, Liisa, Häkkä-Rönnholm, Eva, Silvennoinen, Kari, Salonvaara,Mikael & Viitanen, Hannu. Julkisivujen ja katteiden käyttöiän ennakointi. 2001. 158 s.

851 Itävaara, Merja. Jätevirtojen hallinta USA:ssa. 2001. 65 s. + liitt. 10 s.852 Liukkonen, Sauli. Moniakselisten kuormitusten mittaus ja tallennus. 2001. 97 s.853 Reiman, Teemu. Organisaatiokulttuuri Säteilyturvakeskuksen Ydinvoimalaitosten valvonta

-osastolla. Kvalitatiivinen ja kvantitatiivinen tapaustutkimus henkilöstön käsityksistä organisaa-tion kulttuurista. 2001. 89 s. + liitt. 6 s.

854 Toiminnanohjausjärjestelmän käyttöönotto pk-yrityksessä. Teknologialähtöisestä ajattelustakohti tiedon ja osaamisen hallintaa. Toim. Jari Kettunen & Magnus Simons. 2001. 232 s.

Tätä julkaisua myy Denna publikation säljs av This publication is available from

VTT TIETOPALVELU VTT INFORMATIONSTJÄNST VTT INFORMATION SERVICEPL 2000 PB 2000 P.O.Box 2000

02044 VTT 02044 VTT FIN–02044 VTT, FinlandPuh. (09) 456 4404 Tel. (09) 456 4404 Phone internat. + 358 9 456 4404Faksi (09) 456 4374 Fax (09) 456 4374 Fax + 358 9 456 4374

ISBN 951–38–5881–2 (nid.) ISBN 951–38–5882–0 (URL: http://www.inf.vtt.fi/pdf/)ISSN 1235–0613 (nid.) ISSN 1455–0857 (URL: http://www.inf.vtt.fi/pdf/) VALTION TEKNILLINEN TUTKIMUSKESKUS ESPOO 2001

VTT JULKAISUJA - PUBLIKATIONER 854

VALTION TEKNILLINEN TUTKIMUSKESKUSESPOO 2001

Toiminnanohjausjärjestelmänkäyttöönotto pk-yrityksessä

Teknologialähtöisestä ajattelustakohti tiedon ja osaamisen hallintaa

ToimittajatJari Kettunen & Magnus Simons

VTT Automaatio

ISBN 951–38–5881–2 (nid.)ISSN 1235–0613 (nid.)

ISBN 951–38–5882–0 (URL: http://www.inf.vtt.fi/pdf/)ISSN 1455–0857 (URL: http://www.inf.vtt.fi/pdf/)

Copyright © Valtion teknillinen tutkimuskeskus (VTT) 2001

JULKAISIJA – UTGIVARE – PUBLISHER

Valtion teknillinen tutkimuskeskus (VTT), Vuorimiehentie 5, PL 2000, 02044 VTTpuh. vaihde (09) 4561, faksi (09) 456 4374

Statens tekniska forskningscentral (VTT), Bergsmansvägen 5, PB 2000, 02044 VTTtel. växel (09) 4561, fax (09) 456 4374

Technical Research Centre of Finland (VTT), Vuorimiehentie 5, P.O.Box 2000, FIN–02044 VTT, Finlandphone internat. + 358 9 4561, fax + 358 9 456 4374

VTT Automaatio, Teollisuusautomaatio, Tekniikantie 12, PL 1301, 02044 VTTpuh. vaihde (09) 4561, faksi (09) 456 6752

VTT Automation, Industriautomation, Teknikvägen 12, PB 1301, 02044 VTTtel. växel (09) 4561, fax (09) 456 6752

VTT Automation, Industrial Automation, Tekniikantie 12, P.O.Box 1301, FIN–02044 VTT, Finlandphone internat. + 358 9 4561, fax + 358 9 456 6752

Toimitus Leena Ukskoski

Tummavuoren Kirjapaino Oy, Vantaa 2001

3

Toiminnanohjausjärjestelmän käyttöönotto pk-yrityksessä. Teknologialähtöisestä ajattelusta kohtitiedon ja osaamisen hallintaa [ERP implementation in small and medium-sized enterprises. Fromtechnology push to the management of knowledge and expertise]. Toim. Jari Kettunen & MagnusSimons. Espoo 2001. Valtion teknillinen tutkimuskeskus, VTT Julkaisuja – Publikationer 854.232 s.

Avainsanat enterprices, SMEs, resource planning, organizational learning, ERP, implemen-tation, information systems, processes

TiivistelmäJulkaisussa luodaan laaja-alainen katsaus tietojärjestelmien käyttöönoton prob-lematiikkaan. Keskeisellä sijalla ovat pk-yritysten toiminta ja toiminnanohjaus,tietojärjestelmien määrittely- ja käyttöönottoprosessit sekä erityisesti toiminnan-ohjausjärjestelmät. Aihepiiriä lähestytään sekä menetelmälähtöisesti että toimin-nan kehittämisen näkökulmasta. Julkaisu koostuu kahdeksasta itsenäisestä artik-kelista. Artikkeleissa kuvataan, mitä em. aihealueista tällä hetkellä tiedetään,millaisia haasteita ja ongelmia pk-yritysten tietojärjestelmähankkeisiin tyypilli-sesti liittyy ja mitä näiden haasteiden voittaminen käytännössä edellyttää. Useis-sa artikkeleissa painotetaan, että pk-yritykset tarvitsevat yksinkertaisia ja help-pokäyttöisiä menetelmiä järjestelmien määrittely- ja käyttöönottoprosessientueksi. Lisäksi artikkeleissa todetaan, että tietojärjestelmiä tulee kehittää yrityk-sen liiketoiminnan tavoitteista lähtien ja että tietojärjestelmähankkeeseen kuuluumyös organisaation toiminnan kehittäminen. Julkaisun keskeinen johtopäätös on,että tietojärjestelmän käyttöönotto on luonteeltaan organisatorinen oppimispro-sessi, jota tulee systemaattisesti tukea ja vahvistaa.

4

Toiminnanohjausjärjestelmän käyttöönotto pk-yrityksessä. Teknologialähtöisestä ajattelusta kohtitiedon ja osaamisen hallintaa [ERP implementation in small and medium-sized enterprises. Fromtechnology push to the management of knowledge and expertise]. Ed. by Jari Kettunen & MagnusSimons. Espoo 2001. Technical Research Centre of Finland, VTT Julkaisuja – Publikationer 854.232 p.

Keywords enterprices, SMEs, resource planning, organizational learning, ERP, implemen-tation, information systems, processes

AbstractThis publication is about the challenges and problems of informationsystems (IS) implementation. The main topics of the publication are smalland medium-sized enterprises (SMEs) and their production and operationmanagement practices, IS specification and implementation processes,and especially enterprise resource planning systems (ERPs). Those issuesare approached from both systems engineering and organisational deve-lopment points of view. The publication comprises eight independentarticles. The articles concern themselves with the problems that SMEstypically encounter in IS implementation projects. In addition, the poten-tial causes of identified problems are analysed and a number of remedialactions are proposed in the articles. Many authors underline the importan-ce of having simple and easy-to-use methods to support systems specifi-cation and implementation in the SME context. They also state that sys-tems should be developed on the basis of the (business) objectives of theorganisation concerned and that development of the functioning of theorganisation is an integral part of any IS project. The main conclusion ofthe publication is that an IS implementation project is essentially an or-ganisational learning process that needs to be systematically supportedand reinforced.

5

Sisällysluettelo

Tiivistelmä ............................................................................................................ 3

Abstract ................................................................................................................. 4

Johdanto ................................................................................................................ 7

I Tietojärjestelmien käyttöönottoprosessi ........................................................... 17

II Pk-yrityksen toiminnanohjaus ja sen järjestelmät ........................................... 40

III Toiminnan muutos ja työssä oppiminen tietojärjestelmähankkeissa ............. 65

IV Pk-yrityksen tietohallintostrategian määrittely .............................................. 98

V Toiminnanohjausjärjestelmän vaatimusten määrittely pk-yrityksessä.......... 124

VI Tietojärjestelmän kehittämistä tukevat menetelmät pk-yrityksessä............. 138

VII Prosessiajattelun voima ja rajat .................................................................. 169

VIII Tietojärjestelmien tuottavuus ja vaikuttavuus........................................... 190

Johtopäätökset................................................................................................... 219

6

7

JohdantoTietojärjestelmien kehityksen ja yritysten tarpeiden muutoksen tuloksena yrityk-set ovat vähitellen ottaneet käyttöön yhä laajempia tietojärjestelmäkokonaisuuk-sia. Kehityskulun yhteinen nimittäjä on järjestelmien, tietokantojen ja sovellus-ten kasvava integraatio. Toiminnanohjausjärjestelmät edustavat omalta osaltaantällaisia kokonaisratkaisuja.

Viime vuosikymmenen kuluessa monen organisaation – myös pk-yrityksen –keskeiseksi haasteeksi nousikin toiminnanohjausjärjestelmän käyttöönotto.Nämä järjestelmät tarjoavat integroidun ratkaisun yritysten tietomassojen jaliiketoimintaprosessien hallintaan. Toisaalta niistä on muodostunut monimutkai-sia kokonaisuuksia, joiden tarjoamia ominaisuuksia ja mahdollisuuksia on vai-kea hahmottaa. Mitä laajempaa ja kokonaisvaltaisemmin organisaation toimin-taan vaikuttavaa tietojärjestelmää ollaan hankkimassa, sitä haastavampi on jär-jestelmän suunnittelu- ja käyttöönottoprosessi. Epäonnistuminen käyttöönotto-prosessissa voi johtaa suuriin taloudellisiin menetyksiin ja estää toiminnanoh-jausjärjestelmään sisältyvien potentiaalien hyödyntämisen.

Epäonnistumisten syyt ovat moninaisia. Keskeisiä syitä ovat mm. epärealistisetodotukset, järjestelmätoimittajan ja loppuasiakkaan väliset kommunikointion-gelmat sekä teknologiapainotteinen suunnittelu- ja käyttöönottoprosessi, jossaasiakkaan liiketoiminnan haasteet ja toiminnan kehittämissuunnitelmat jääväthelposti teknisen järjestelmän määrittelyn, toteutuksen ja käyttöönoton jalkoihin(esim. Kanerva 1999; Seppälä 1999; Checkland ja Holwell 1998; Hyötyläinen1998). Keskeisenä haasteena on siten yrityksen toiminnanohjauksen ja organi-saation toimintatapojen kehittämisen yhdistäminen niitä tukeviin tietojärjestel-mähankkeisiin. Toiminnanohjausjärjestelmää suunniteltaessa ja käyttöönotet-taessa huomiota tulisikin kiinnittää liiketoiminnan tarpeisiin, järjestelmän tule-vaan käyttökontekstiin, käyttäjien vaatimuksiin ja valmiuksiin sekä käyttäjäor-ganisaation toiminnan – kuten oppimisen ja johtamismallien – kehittämiseen.

Toiminannanohjausjärjestelmän käyttöönotolla pyritään luonnollisesti tukemaanja edistämään yrityksen liiketoimintaa. Hankkeen onnistumisen kannalta huolel-linen konseptisuunnittelu ja vaatimusmäärittely ovat keskeisessä asemassa.Kuitenkin tietojärjestelmä konkretisoituu vasta käyttöönotossa. Tietojärjestel-män käyttöönotto voidaan nähdä joko kertaponnistuksena tai vaihtoehtoisesti

8

jatkuvana toimintatapojen ja järjestelmän ominaisuuksien parempaan hyödyntä-miseen tähtäävänä kehittämisprosessina. Tutkimukset viittaavat siihen, ettäjärjestelmän potentiaalien realisoiminen on organisatorisen kehitystyön takana(Lyytinen 1986; Checkland ja Holwell 1998; Hyötyläinen 1998).

Laajojen ja monia sovelluksia integroivien järjestelmien kasvava kysyntä avaamahdollisuuksia ohjelmistotaloille. Toistaiseksi alaa ovat hallinneet suuret toi-mijat kansainvälisillä, suuryritysten tarpeisiin kehitetyillä ohjelmistoillaan. Pk-yritykset ovat kuitenkin vaikeassa asemassa tietojärjestelmien käyttöönotonosalta. Raskaat ja kalliit järjestelmät eivät sovellu parhaalla mahdollisella tavallapk-yritysten tarpeisiin. Tarvittaisiin joustavuutta ja toimialakohtaisia ratkaisuja,mieluiten kohtuulliseen hintaan. Näin ollen erityisesti pk-kenttä ja sen moninai-set tarpeet luovat mahdollisuuksia suomalaiselle ohjelmistotuotannolle. Yritys-ten verkostoituminen on myös luomassa ohjausjärjestelmille uusia vaatimuksia,joihin ei ainakaan tällä hetkellä ole vielä olemassa patenttiratkaisuja (ks. Kuiva-nen ja Hyötyläinen 1997; Kuitunen et al. 1999). Näillä alueilla suomalaisillaohjelmistotaloilla on edellytyksiä suuntautua myös kansainvälisille markkinoille(Nukari ja Forsell 1999).

Myös ohjelmistotalojen ja järjestelmätoimittajien palvelukonseptit ovatmuuttumassa integroitujen järjestelmien toimittamisen myötä. Asiakasyrityksilletoiminnanohjausjärjestelmien käyttöönotto on monimutkainen ja usein sangentuskallinenkin prosessi, joka täytyy jotenkin huomioida palvelukokonaisuuksiasuunniteltaessa. Uusista palvelukonsepteista voi tulevaisuudessa hyvinkin muo-dostua keskeinen kilpailutekijä alan toimijoille. Kysymys on siitä, miten tässäkannattaa edetä.

Toiminnanohjausjärjestelmän käyttöönottoprosessin kehityskysymykset

Toiminnanohjausjärjestelmien käyttöönottoprosesseista on suhteellisen vähäntutkittua tietoa. Tämä pätee erityisesti pk-sektoriin. Lisätietoa tarvittaisiin mm.pk-yritysten toiminnanohjauksen tarpeista, järjestelmien käyttöönottoproses-seista sekä niiden tukemiseen soveltuvista menetelmistä ja välineistä (Currie jaGalliers [toim.] 1999).

Toiminnanohjausjärjestelmien käyttöönotot ovat suuria investointeja, suuryri-tyksissä kooltaan jopa satoja miljoonia markkoja. Pienissä ja keskisuurissa yri-

9

tyksissäkin kyse on usein huomattavista summista, kun järjestelmien hankinta-kustannuksia verrataan yritysten liikevaihtoon. Lisäksi käyttöönottoprosessisitoo tärkeitä voimavaroja, joita tarvittaisiin perusliiketoiminnan pyörittämiseen.Näin ollen on luonnollista, että asiakkaat kohdistavat järjestelmähankkeisiinsuuria odotuksia.

Erityisesti pk-yrityksissä toiminnanohjausjärjestelmien käyttöönotto ja käyttö onkuitenkin ongelmallista. Tähän on olemassa ainakin kolme syytä. Ensinnäkinkaupalliset toiminnanohjausjärjestelmät on ensisijaisesti rakennettu suurtenyritysten tarpeisiin. Tällaiset järjestelmät soveltuvat harvoin sellaisenaan pk-yrityksen epämuodolliseen toimintaympäristöön. Lisäksi pk-yritysten toiminta-ympäristöt ovat keskenään kovin erilaisia ja nopeasti muuttuvia, mikä asettaaerityisvaatimuksia tietojärjestelmien ylläpidettävyydelle ja joustavuudelle.

Toiseksi pk-yrityksillä on harvoin omaa tietotekniikkastrategiaa, joka muodos-taisi luontevan pohjan suurten järjestelmähankkeiden suunnittelun ja hankinnantueksi. Strategisen ajattelun puute heikentää yritysten asemaa suhteessa aggres-siivisesti ja ammattitaitoisesti omia tuotteitaan markkinoiviin järjestelmätoimit-tajiin ja konsultteihin.

Kolmanneksi pk-yrityksillä ei ole useinkaan järjestelmien määrittelyssä ja käyt-töönotossa tarvittavaa tietotaitoa. Yrityksillä ei ole käytössään malleja, mene-telmiä tai työkaluja, jotka auttaisivat kehitysongelmien jäsentämisessä, tavoittei-den asetannassa, järjestelmien määrittelyssä tai käyttöönottoprosessin hallinnas-sa. Tämä sama ongelma koskee myös toiminnanohjausjärjestelmien toimittajia.Ohjelmistotalojen ja järjestelmätoimittajien tapa mallintaa tietojärjestelmiä onhelposti vieras pk-yritykselle. Erityisen ongelmallista on yhteisten mallien jamenetelmien luominen tietojärjestelmien määrittelyn ja käyttöönottoprosessintarpeisiin. Tuloksena saattaa olla yrityksen toimintaa huonosti tukeva järjestel-mä, johon upotetut resurssit ylittävät moninkertaisesti järjestelmästä saatavanhyödyn.

Pk-yritysten toiminnanohjausjärjestelmien suunnittelu- ja käyttöönottoprosessienkeskeisiä kysymyksiä tulisi pystyä lähestymään nimenomaan käyttäjäyrityksennäkökulmasta. Tämä asettaa kehityspaineita ohjelmistotaloille ja järjestelmätoi-mittajille, jotka haluavat vallata uusia markkinoita pk-sektorilta. Tuotteita ja

10

palvelukonsepteja kehittämällä voidaan samalla palvella pk-yrityksiä ja luodapohjaa tyytyväisen asiakaskunnan kartuttamiselle.

Toiminnanohjausjärjestelmien suunnittelu- ja käyttöönottotoiminnan tarkasteluorganisatoristen oppimisprosessien näkökulmasta on osoittautunut lupaavaksilähestymistavaksi. Lähtökohtana on ajatus, että viime kädessä toiminnanohjaus-järjestelmät ovat ”potentiaalista” teknologiaa. Potentiaalien realisoituminenkäytännössä tapahtuu vasta ja ainoastaan loppukäyttäjäyrityksissä. Ilman tietoi-sia organisatorisia oppimisprosesseja uusien järjestelmien potentiaaleja ei voidahyödyntää kovinkaan tehokkaasti. Oppimisprosessit voivat myös ulottua organi-saatiorajojen yli. Esimerkiksi järjestelmätoimittaja voi oppia uutta jokaisestaprojektista ja kehittää edelleen omaa toimintansa ja tuotekonseptejaan (vrt. No-naka ja Takeuchi 1995; Dixon 1999).

Edellä hahmotettu problematiikka nostaa esiin joukon vastausta odottavia kysy-myksiä. Ne liittyvät ensisijaisesti pk-yritysten toiminnanohjauksen, toimintata-pojen ja tietojärjestelmien kehittämiseen sekä niitä tukeviin malleihin, menetel-miin ja välineisiin. Haluamme nostaa esiin erityisesti seuraavat neljä tutkimus- jakehitysongelmaa:

1. Tietotekniikkatarpeiden määrittely liiketoiminnan näkökulmasta. Keskeisiäkysymyksiä: miten järjestelmähankkeelle asetettavat tavoitteet johdetaan yrityk-sen liiketoimintatavoitteista, miten nykytila ja nykyiset järjestelmät vaikuttavatvaatimuksiin, miten verkostoitumisen haasteet huomioidaan, millaiset menetel-mät sopivat pk-yritysten käyttöön, miten laaditaan yrityksen liiketoimintastrate-giaa tukeva tietotekniikkastrategia?

2. Tietojärjestelmien käyttöönoton toimintaja oppimismallit. Keskeisiä kysy-myksiä: miten vaatimusmäärittelystä edetään kohti järjestelmän käyttöönottoa jakäyttöä, millainen on tyypillinen toiminnanohjausjärjestelmän käyttöönottopro-sessi käytännössä ja millainen se voisi pk-yrityksessä olla, mitkä ovat keskeisethaasteet ja ongelmat ja kuinka ne voitetaan, miten käyttöönotossa syntyvä tietä-mys saadaan talteen ja edelleen hyötykäyttöön, miten organisoidaan käytönai-kainen kehittäminen, miten tuetaan ihmisten, organisaation ja organisaatioidenvälistä oppimista?

11

3. Tietojärjestelmien vaikuttavuuden ja tuottavuuden arviointi. Keskeisiäkysymyksiä: mitä ovat tietojärjestelmien ”tuottavuus” ja ”vaikuttavuus”, kuinkaniitä voidaan arvioida tai mitata, miten arviointimenetelmiä voidaan käyttääjärjestelmien hankinnan, käyttöönoton ja käytön tukena?

4. Toiminnanohjausjärjestelmien toimittajien rooli. Keskeisiä kysymyksiä:millaisilla menetelmillä ja toimintatavoilla ohjelmistotalot ja järjestelmätoimit-tajat voivat parhaiten tukea pk-yritysten toiminnanohjausjärjestelmien käyttöön-ottoprosesseja, miten asiakkailta saatua palautetta ja hankkeista saatuja koke-muksia voidaan parhaiten hyödyntää oman toiminnan ja tuotteiden kehittämi-seen?

Voidaan nähdä, että kysymysten käsittely ja niitä koskevan tiedon lisääminenpalvelee sekä akateemisia että yritysten käytännön tarpeita. Tässä julkaisussaem. kysymyksiä pyritään valaisemaan eri näkökulmista. Kaikkiin kysymyksiinei luonnollisesti voida antaa tyydyttävää vastausta: onhan joukossa ns. ikuisuus-kysymyksiä, jotka luonteensa johdosta tulevat todennäköisesti kiusaamaan vielätuleviakin sukupolvia. Toivomme kuitenkin, että julkaisusta on hyötyä henki-löille, jotka ovat vastuussa esimerkiksi pk-yritysten toiminnanohjausjärjestel-mien suunnittelu- ja käyttöönottoprosesseista ja/tai uusien toiminnanohjauksenratkaisujen ja palvelukonseptien kehittämistä.

Julkaisun sisältö ja taustat

Pk-yritysten toiminnanohjausjärjestelmien suunnittelu- ja käyttöönottoprosessejakoskeva tutkimus- ja kehitystyö on vaativa haaste, joka edellyttää moniosaa-mista. Tässä julkaisussa yhdistää voimansa kolme eri tutkimusorganisaatiota,jotka ovat tehneet vuosia informaatio- ja tietojärjestelmien suunnitteluun jakäyttöön kohdistuvaa tutkimus- ja kehitystyötä. Organisaatiot ovat VTT Auto-maatio, Jyväskylän yliopiston Tietotekniikan tutkimusinstituutti (TITU) sekäTurun yliopiston Matemaattisten tieteiden laitoksen Laboris-yksikkö.

VTT Automaation teollisuusautomaation tutkimusalueella tekniikan ja tietojär-jestelmien tutkimus- ja kehitystyöllä on keskeinen asema. Myös järjestelmienkäyttöönottoprosessit ovat olleet tutkimuksen kohteena. Jyväskylän yliopistonTietotekniikan tutkimusinstituutissa (TITU) erityisenä huomion kohteena ovatolleet pk-yritykset ja pk-yritysten tietojärjestelmät. Turun yliopiston Laboris-

12

yksikkö lähestyy tietojärjestelmien suunnittelua ja käyttöä erityisesti ihmisten jaorganisaatioiden toiminnan näkökulmasta.

Tämä julkaisu koostuu kahdeksasta itsenäisestä artikkelista. Julkaisu on luon-teeltaan state of the art -tyyppinen katsaus tietojärjestelmähankkeiden, erityisestitoiminnanohjausjärjestelmien suunnittelun ja käyttöönoton problematiikkaan.Artikkeleissa esitellään mm. erilaisia malleja, menetelmiä ja teorioita yritystentoiminnan, toiminnanohjauksen ja tietojärjestelmähankkeiden analysoimiseen jatukemiseen. Useimmissa artikkeleissa näitä asioita tarkastellaan erityisesti pk-yrityksen näkökulmasta. Seuraavassa artikkelien tematiikan esittely:

− I artikkelissa Hyötyläinen ja Kalliokoski (VTT Automaatio) tarkastelevattietojärjestelmien käyttöönottoprosessia useista eri näkökulmista. Tavoittee-na on eri näkökulmien käsittelyn avulla jäsentää tietojärjestelmien käyttöön-ottoprosessia ja siihen vaikuttavat tekijöitä sekä osoittaa organisatoristen op-pimisprosessien ja tietämyksen hallinnan mahdollisuus ja välttämättömyysonnistuneen käyttöönottoprosessin edellytyksenä.

− II artikkelissa Kalliokoski, Simons ja Mikkola (VTT Automaatio) käsittele-vät pk-yrityksen toiminnanohjauksen erityispiirteitä, kuten toiminnan mo-nimuotoisuutta, sekä toiminnan suunnitteluun ja ohjaukseen tarkoitettujatoiminnanohjausjärjestelmiä. Artikkelissa esitetään lyhyesti myös ajatuksiatoiminnanohjausjärjestelmien tulevaisuuden kehitysnäkymistä. Edellisiin pe-rustuen artikkelissa arvioidaan nykyisten toiminnanohjausjärjestelmien so-veltuvuutta pk-yritysten tarpeisiin sekä toiminta- että järjestelmälähtöisesti.Artikkelissa esitetään myös pk-yritysten kokemuksia toiminnanohjausjär-jestelmien käyttöönotosta ja käytöstä.

− III artikkelissa Reijonen, Reiman ja Airola (VTT Automaatio) lähestyvät pk-yritysten toiminnanohjausjärjestelmän käyttöönottoa ja käytön aikaista ke-hittämistä käyttäytymistieteellisestä näkökulmasta. Tarkastelun kohteena ontietojärjestelmän käyttöönotto sosiaalisena oppimis- ja muutosprosessina.Taustaa hahmottavan johdannon jälkeen artikkeli jakaantuu kahteen osaan.Ensimmäisessä osassa esitellään kolme organisatorisen oppimisen näkökul-maa, joiden kautta tarkastellaan kriittisesti dynaamisen toimintaympäristönaikaansaamia muutospaineita organisaatioiden toiminnan jatkuvalle kehit-tämiselle ja henkilöstön työssä oppimiselle. Huomiota kiinnitetään myös sii-

13

hen, kuinka organisaatioiden monimuotoista osaamista, tiedon luontia, le-vittämistä ja hyödyntämistä voidaan tukea. Artikkelin toisessa osassa orga-nisatorisen oppimisen näkökulmat liitetään tiiviimmin tietojärjestelmähank-keisiin tarkastelemalla hankkeiden problematiikkaa pk-yrityksissä mm. tie-tojärjestelmien eri käyttäjäryhmien oppimisen edellytysten ja toimintatapo-jen kehittämisen kannalta. Lisäksi kuvataan joitain pk-yrityksille soveltuviamenettelyitä ja työkaluja, joiden avulla voitaisiin entistä paremmin ottaahuomioon yksittäisen käyttäjän ja työyhteisön näkökulmat tietojärjestelmä-hankkeissa.

− IV artikkelissa Siira (TITU, Jyväskylän yliopisto) tarkastelee tietohallinto-strategian laadintaa pk-yrityksen näkökulmasta. Aihealueeseen liittyy paljonkäsitteitä, joiden käyttöä erilaisissa tilanteissa pyritään selvittämään. Artik-kelissa käydään läpi tietojenkäsittelyyn liittyvien strategioiden taustoja, joi-den perusteella tietohallintostrategian suunnittelun lähestymistapoja on laa-dittu. Tietohallintostrategian laadintaan on suunniteltuja malleja, joita artik-kelissa esitellään kaksi. Näiden mallien pohjalta arvioidaan sitä, mitä tieto-hallintostrategian tulisi sisältää ja kuinka kattava sen tulisi olla. Artikkelissaerityisen tarkastelun kohteena on pk-yritysten erityispiirteiden huomioimi-nen tietohallintostrategian laadinnassa.

− V artikkelissa Karvonen ja Tommila (VTT Automaatio) tarkastelevat vaati-musten määrittelyä toiminnanohjausjärjestelmän käyttöönotossa pk-yrityksessä. Vaatimusmäärittelyn todetaan luovan pohjan tietojärjestelmä-hankkeille, minkä johdosta sen läpivienti on hankkeiden onnistumisen kan-nalta merkittävä. Pk-yrityksissä keskeisen haasteen aiheuttavat yhtäältä ra-jalliset resurssit ja toisaalta vaatimusmäärittelyn rooli loppukäyttäjien ja tie-tojärjestelmäammattilaisten vuorovaikutuksen välineenä. Artikkelissa kuva-taan vaatimusmäärittelyn näkökulmia, sijoittumista toiminnanohjaushank-keeseen, vaiheita sekä kehitystarpeita.

− VI artikkelissa Halttunen, Lehtinen ja Lyytinen (TITU, Jyväskylän yliopisto)pohtivat, mitkä ovat keskeiset tietojärjestelmien kehittämismenetelmät jamiten ne soveltuvat pk-yrityksissä tehtävään kehittämistyöhön. Perusprob-leemiksi todetaan se, että laaja järjestelmä, kuten toiminnanohjausjärjestel-mä, voi sisältää samat ominaisuudet niin pk-yrityksessä kuin suuryritykses-säkin. Tämän johdosta järjestelmien kehittäminen on vähäiset resurssit

14

omaavalle pk-yrityksille vaativa tehtävä, johon voi sisältyä merkittäviä ris-kejä. Pk-yrityksille sopivien menetelmien kehittäminen on siten tärkeää japerusteltua. Artikkelin tavoitteena on luoda kokonaiskuva tietojärjestelmä-tieteen menetelmistä ja kuvaustavoista sekä arvioida niiden lähtökohtia, ta-voitteita ja sisältöä. Artikkelissa esitetään myös viitekehys, jonka avulla me-netelmiä voidaan arvioida.

− VII artikkelissa Nurminen ja Järvinen (Laboris, Turun yliopisto) tarkastele-vat prosessiajattelua ja sen käyttöön sisältyviä vahvuuksia ja rajoituksia. Ar-tikkelissa paneudutaan mm. prosessin käsitteeseen, prosessiajattelun juuriin,prosessien kuvaamistekniikoihin sekä prosessiajattelun käyttöön osana tie-tojärjestelmien suunnittelua. Esimerkkinä käytetään perusterveydenhuollontietojärjestelmiä, joiden suunnittelu- ja käyttöönottoprosesseihin kirjoittajatovat aktiivisesti osallistuneet. Prosessiajattelun rajoituksina tuodaan esiinmm. satunnaisten ja kestoltaan määrittelemättömien työtehtävien kuvaami-seen liittyvät vaikeudet sekä sellaiset organisaatioiden toiminnan tehosta-mispyrkimykset, joissa yltiöpäinen prosessien virtaviivaistaminen johtaa or-ganisaation joustavuuden ja kehityskyvyn menettämiseen. Lopuksi pohdi-taan, millä tavalla prosessiajattelun viitekehystä voitaisiin laajentaa ja yleis-tää.

− VIII artikkelissa Kettunen, Simons ja Mikkola (VTT Automaatio) luovatkatsauksen tietotekniikan (erityisesti tietojärjestelmien) tuottavuuden ja vai-kuttavuuden mittaamiseen liittyviin haasteisiin. Artikkelissa kuvataan tieto-järjestelmien tuottavuuden ja vaikuttavuuden arvioimiseen kehitettyjä lä-hestymistapoja, pohditaan eri lähestymistapojen käyttöön liittyviä rajoituksiaja vaikeuksia sekä esitellään viitekehys tietotekniikkainvestoinnin potentiaa-listen hyötyjen ja kustannusten tunnistamiseen. Lopuksi pohditaan, millai-nen rooli tuottavuuden ja vaikuttavuuden arvioinnilla voisi olla toiminnan-ohjausjärjestelmän käyttöönottoprosessissa. Aihetta pidetään tärkeänä, koskajärjestelmäprojektien koon ja hinnan kasvaessa myös niiden merkitys yri-tysten toiminnan luotettavuuden ja taloudellisen tuloksen kannalta kasvaa.

Yhteenveto ja johtopäätökset esitetään julkaisun lopussa omassa erillisessäkohdassa.

15

Tämä julkaisu on osa HANSKA -tutkimus- ja kehityshanketta, jonka kantavanaajatuksena on lähestyä toiminnanohjausjärjestelmien käyttöönottoa organisatori-sen oppimisen viitekehyksestä. HANSKA on kolmivuotinen tutkimus- ja kehi-tyshanke, jonka toteutuksesta vastaavat edellä mainitut tutkimusorganisaatiot.HANSKA-hanke käynnistyi keväällä 2000. Hanke koostuu kuudesta osaprojek-tista, joista viisi on yrityksiin kohdistuvia kehitysprojekteja. Yritysprojekteissakeskitytään yhtäältä ohjelmistotalojen ja järjestelmätoimittajien toiminnan japalvelukonseptien kehittämiseen, ja toisaalta loppukäyttäjäyritysten tarpeisiin janiiden tarvitsemien mallien, menetelmien ja työvälineiden kehittämiseen. Kuu-des projekti on luonteeltaan menetelmähanke, jossa luodaan kehitysprojekteilleyhteiset perusteet, tutkimusorganisaatioiden yhteinen oppimis- ja kehitysympä-ristö sekä uutta tietoa toiminnanohjausjärjestelmien käyttöönottoprosessienonnistumiseen vaikuttavista tekijöistä. Hankkeen tavoitteisiin kuuluu myösosaprojekteissa kehitettyjen ja toimiviksi osoittautuneiden mallien, menetelmienja työvälineiden tuotteistaminen sekä julkaisutoiminta. Jos haluat lisätietojaHANSKA-hankkeesta, käy kotisivuillamme osoitteessahttp://www.vtt.fi/aut/tau/hanska/.

Lopuksi haluamme esittää kiitoksemme professori Jukka Heikkilälle Jyväskylänyliopistoon lukuisista kommenteista ja parannusehdotuksista. Olemme yrittäneetottaa ne huomioon parhaan kykymme mukaan. Toivomme, että lopputulos täyt-tää myös kriittisemmän lukijan odotukset ja avaa uusia näkökulmia toiminnan-ohjausjärjestelmien ja käyttöönottoprosessien kiehtovaan maailmaan. Miellyttä-viä lukuhetkiä!

Espoossa 13. elokuuta 2001

Tekijät

Johdannon lähteet

Checkland, P. & Holwell, S. 1998. Information, Systems and Information Sys-tems. Making Sense of the Field. Chichester: John Wiley and Sons.

Currie, W. L. & Galliers, B. (Eds.) 1999. Rethinking Management InformationSystems. Oxford: Oxford University Press.

16

Dixon, N. M. 1999. The Organizational Learning Cycle. How We Learn Collec-tively. Cambridge: Gower.

Hyötyläinen, R. 1998. Implementation of Technical Change as OrganizationalProblem-Solving Process. Management and User Activities. Espoo: VTT Publica-tions 337. 238 s. + liitt. 12 s.

Kanerva, O. 1999. Kriittiset pisteet toiminnanohjausjärjestelmän hankintapro-jektissa. Metallitekniikka (5/1999).

Kuitunen, K., Räsänen, P., Mikkola, M. & Kuivanen, R. 1999. Kehittyvä yritys-verkosto. Toimittajaverkostot kilpailukyvyn ja osaamisen lähteenä. Espoo: VTTTiedotteita 1976. 148 s.

Kuivanen, R. & Hyötyläinen, R. (toim.) 1997. Kohti uudenlaisia yritysverkostoja.Monenkeskisen verkostoyhteistyön kehittäminen. Espoo: VTT Tiedotteita 1830.116 s.+ liitt. 3 s.

Lyytinen, K. 1986. Information Systems Development as Social Action: Frame-work and Critical Implications. Jyväskylä Studies In Computer Science,Economics and Statistics, No 8.

Nonaka, I. & Takeuchi, H. 1995. The Knowledge-Creating Company. HowJapanese Companies Create the Dynamics of Innovation. New York – London:Oxford University.

Nukari, J. & Forsell, M. 1999. Suomen ohjelmistotuotannon kasvun strategia jahaasteet. Haasteina pk-yritysten kansainvälistyminen ja koulutetun henkilöstönsaatavuus. Helsinki: Tekes, Teknologiakatsaus 67/99.

Seppälä, M. 1999. Finnish ERP Research 1999. Pro gradu -työ Åbo Akademissa.

17

I Tietojärjestelmien käyttöönottoprosessiRaimo Hyötyläinen, Petri Kalliokoski

VTT Automaatio

1. Lähtökohdat

Tässä artikkelissa peruskysymyksinä ovat kysymys tietojärjestelmien soveltami-sesta organisaatiossa ja kysymys niistä näkökulmista, joista tätä ilmiötä voidaantarkastella ja arvioida. Keskeisenä tavoitteena on tietojärjestelmien käyttöönot-toprosessin jäsentäminen.

Tietojärjestelmien käyttöönottoprosessi on osoittautunut yrityksissä hankalaksikysymykseksi. Tietojärjestelmien käyttöönottoon liitettyjen tavoitteiden saavut-taminen ei ole itsestään selvää. Tietojärjestelmien tarkastelussa onkin yhdeksikeskeiseksi teemaksi muodostunut tuottavuusvaikutukset ja niiden riippuvuus-mekanismit (Willcocks ja Lester [toim.] 1999). Tietojärjestelmien käyttöönotois-sa lähtökohtana on yleensä ajattelu, että muuttamalla radikaalisti tietojärjestel-mien avulla toiminnan edellytyksiä, organisaatio ja toimintatavat sopeutuvatuusiin olosuhteisiin, jolloin tavoitteet on saavutettavissa. Tässä lähestymistavas-sa on kuitenkin ilmeiset ongelmansa. Onko mitään takeita, että järjestelmätsaadaan käyttöön suunnitellusti? Tulos voi olla puolinainen, ja jos huonosti käy,jopa lähtötilannetta huonompi (Kortteinen et al. 1996). Tähän on vaikuttamassase, että järjestelmien käyttöönottoprosessit kestävät useita vuosia ja että proses-siin osallistuu useita tahoja erilaisin intressein, näkökulmin ja menetelmin(Checkland ja Howell 1998; Hyötyläinen 1998; Mumford 1999).

Artikkelissa tarkastellaan tietojärjestelmien käyttöönottoprosessia useista erinäkökulmista. Tavoitteena on eri näkökulmien käsittelyn avulla jäsentää tieto-järjestelmien käyttöönottoprosessi ja siihen vaikuttavat tekijät ja osoittaa organi-satoristen oppimisprosessien ja tietämyksen hallinnan mahdollisuus ja välttä-mättömyys onnistuneen käyttöönottoprosessin edellytyksenä. Aluksi kohdassa 2tarkastellaan tietojärjestelmien soveltamista tiedonalana ja siinä tapahtuneitamuutoksia. Kohdassa 3 käsitellään tietojärjestelmien käyttöönoton prosessimal-linnusta. Tarkoitus on osoittaa tietojärjestelmien käyttöönottoprosessin moni-mutkaisuus ja tarve uudenlaisiin suunnittelu- ja käyttöönottoprosessia koskeviinajattelumalleihin. Kohdassa 4 käsitellään tietojärjestelmien elinkaarimallinnusta.

18

Kohdassa luodaan tietojärjestelmien elinkaarimallit sekä loppukäyttäjäyritykses-sä tapahtuvalle käyttöönottoprosessille että ohjelmistotoimittajan kehitys- jatoimitusprosesseille. Kohdassa 5 tarkastellaan tietojärjestelmien käyttöönotto-prosessia toimintana ja siihen liittyvien organisatoristen oppimisprosessienedellytyksiä. Lopuksi kohdassa 6 vedetään johtopäätökset artikkelista ja arvioi-daan tietojärjestelmien käyttöönottoprosessiin kohdistuvia kehityskysymyksiä.

2. Tietojärjestelmien soveltaminen tiedonalana

Tietojärjestelmien soveltaminen organisaatiossa, tämän soveltamisprosessinjohtaminen ja niihin liittyvät menettelyt ovat muodostuneet omaksi tutkimusalu-eekseen (the management of information systems within organizations) (Currieja Galliers [toim.] 1999; Checkland ja Holwell 1998). Tutkimustoiminta ontuottanut suuren määrän tutkimusjulkaisuja ja tietoa tietojärjestelmien suunnit-telusta, käyttöönotosta ja käytöstä.

Erityisesti parin viime vuosikymmenen aikana on ilmestynyt lukuisia kirjoja jaartikkeleita tietojärjestelmien hallinnasta ja johtamiskysymyksistä. Keskeisetteemat ovat liittyneet strategian muodostamiseen ja vaatimusmäärittelyihin,tietojärjestelmien käyttöönottoon ja kyvykkyyksien ja osaamisen kehittämiseensekä suorituksen mittaamiseen. Esillä ovat olleet myös tietojärjestelmien käyt-töönottoon liittyen liiketoimintaprosessien uudistaminen ja yritysverkostojakoskevat kysymykset sekä projektihallinnan menetelmät. Lisäksi huomiota onkiinnitetty muutoksen organisatorisiin ja inhimillisiin vaikutuksiin (Currie jaGalliers [toim.] 1999).

Tietojärjestelmiin ja niiden käyttöön liittyvä tutkimus voidaan nähdä olemuk-seltaan tietojärjestelmien rakentamista ja hyödyntämistä koskevaksi ongelman-ratkaisuksi ja menetelmälliseksi kehitystyöksi. Tietojärjestelmiin kohdistuvatutkimustoiminta on kuitenkin saman ongelman edessä kuin tutkimustoimintayleensäkin. Informaatiojärjestelmät ovat monimutkaisia järjestelmiä ja niidensuunnittelu ja käyttö tapahtuu monimutkaisissa organisaatioissa. Käytännöntasolla on aina kyse mutkikkaista strategisista kysymyksistä, teknisistä ja talou-dellisista ongelmista ja organisatorista ratkaisuista, joiden käsitteellistäminen eionnistu pelkästään empiirisellä havaintotasolla (Currie ja Galliers [toim.] 1999;ks. Laudan 1977; Sayer 1992).

19

Yleisesti on tiedostettu, että käsityksillä tutkimuskohteista ja tutkimusongelmistaon merkitystä valittaville menetelmille (ks. esim. Rosenberg 1995; Easterby-Smith et al. 1991; Uusitalo 1999). On nähtävissä, että tietojärjestelmien käyt-töönottoprosessiin kohdistuvaan tutkimus- ja kehitystoimintaan ja sovellettaviinmenetelmiin on vaikuttamassa se, mitkä asiat koetaan tärkeiksi tutkimuskysy-myksiksi, millaisina tutkimuskohteet ja niiden ympäristö nähdään ja mitkä ovattutkimustoiminnan keskeiset tavoitteet (Checkland ja Holwell 1998; Kuutti1994; vrt. Rosenberg 1995; Kusch 1993).

Tietojärjestelmien soveltamiseen kohdistuvassa tutkimus- ja kehitystoiminnassaon tapahtunut ajan myötä muutoksia, jotka ovat koskeneet erityisesti suunnittelu-ja käyttöönottomalleja ja niihin liittyviä menetelmiä. Aikaisemmin tietojärjes-telmät on nähty enemmän teknisestä ja suunnittelumenetelmiin painottuvastanäkökulmasta. Huomiota ovat saaneet vahvasti tietojärjestelmän tekniset valin-nat ja niiden suunnittelu, järjestelmän toteutus sekä näihin liittyvät suunnittelu-tavat (Currie ja Galliers [toim.] 1999; Avison ja Fitzgerald 1999; Iivari ja Lyyti-nen 1999).

Painotukset tietojärjestelmien ja tietoteknologian kehittämisen ja soveltamisenosalta ovat siirtyneet pelkän kovan teknologian ja menetelmäpuolen korostami-sesta enemmän pehmeiden asioiden esille nostamiseen viime vuosikymmenenalusta alkaen (Mumford 1999; Checkland ja Holwell 1998). Tietoteknologiannähdään olevan luonteeltaan intellektuaalista ja potentiaalista teknologiaa. Tämäsisältää ajatuksen siitä, että tietoteknologian potentiaaliset hyödyt realisoituvatvasta toteutuksessa ja käytössä. Tietoteknologian toteuttajat ja käyttäjät muovaa-vat tietojärjestelmät toimiviksi toimintajärjestelmän tukivälineiksi. Tietojärjes-telmän potentiaalisten hyötyjen realisoituminen on kiinni ihmisistä ja organisaa-tioista, jotka ottavat käyttöön ja käyttävät tietojärjestelmää. Tästä johtuen samaatietoteknologiaa voidaan ottaa käyttöön ja käyttää eri tavoin, koska tietojärjes-telmän käyttöön, johtamiseen, ylläpitoon ja muuttamiseen on vaikuttamassamonia tekijöitä ja prosesseja (Lee 1999; Davenport 1997; Hyötyläinen 1998).

Tästä näkökulmasta voidaan nostaa keskeinen kysymys, joka liittyy tietojärjes-telmien käyttöönottoprosessin tutkimus- ja kehitysongelmiin. Kysymys on siitä,mikä on tietojärjestelmien käyttöönottoprosessi ilmiönä ja mitkä näkökulmat jaulottuvuudet määrittävät tietojärjestelmien suunnittelu- ja käyttöönottoprosessia.Voidaan katsoa, että tietojärjestelmien suunnittelu- ja käyttöönottoprosessiin

20

liittyvien eri näkökulmien ja ulottuvuuksien käsittely ja niitä koskevan tiedonlisääminen palvelee yhtäältä tietojärjestelmien soveltamista tiedonalana ja toi-saalta yritysten käytännön tarpeita. Tässä artikkelissa lähestytään tietojärjestel-mien suunnittelu- ja käyttöönottoprosessia keskeisten näkökulmien ja ulottu-vuuksien jäsentämisen ja määrittelyn kautta.

3. Tietojärjestelmien käyttöönoton prosessimalli

Kuva tietojärjestelmien käyttöönotosta on yleensä suoraviivaisen ”ruusuinen”.Yrityksillä on ollut vahva usko teknologian mahdollisuuksiin liiketoimintapro-sessien ja yritystoiminnan kehittämisessä (Davenport 1993). Kuitenkin koke-mukset ja tutkimukset viittaavat siihen, että liiketoimintaprosessien uudistami-seen liittyvät laajat tietotekniikkahankkeet epäonnistuvat usein. Kansainvälisestiarvioiden vain noin kolmannes hankkeista onnistuu (Davenport 1997; Mac-Donald 1998; Fichman ja Moses 1999).

Tutkimusten mukaan tietojärjestelmien käyttöönotolla saavutettavien tulostenkatsotaan riippuvan keskeisesti järjestelmien toteutus- ja käyttöönottoprosessistasekä niiden muodoista ja menetelmistä (Willcocks ja Lester [toim.] 1999;Checkland ja Holwell 1998). Tietojärjestelmän suunnittelu- ja käyttöönottopro-sessi voidaan nähdä monivaiheisena ja monimutkaisena prosessina, mikä eietene suoraviivaisesti tavoitteista toteutukseen ja normaaliin käyttöön. Kuvassa 1on esitetty periaatteellinen prosessimalli teknisen järjestelmän käyttöönottopro-sessista (Hyötyläinen 1998).

Aika

Innovaatio

Kehittäminen

SUUNNITTELU-TOIMINTA KÄYTTÖÖNOTTO-

TOIMINTA KÄYTTÖ- JA KEHITTÄMIS-TOIMINTA

Käyttöönotto- vaihe

Kuva 1. Teknisen järjestelmän käyttöönoton prosessimalli.

Yleisesti katsotaan, että tekninen kehitys tapahtuu portaittaisina hyppäyksinätasolta toiselle. Tätä voidaan kutsua teknistä muutosta koskevaksi ideaalimallik-

21

si. Tämän on osoitettu olevan epärealistinen malli (Fichman ja Moses 1999).Tilalle on tarjottu mallia, jonka mukaan teknologinen hyppäys alkaa pian ”ra-pautua”, jolloin seuraava teknologinen hyppäys alkaa alemmalta tasolta kuinmihin edellinen päättyi (Imai 1986, s. 26). Tältä voidaan välttyä vain sillä, ettäinnovaatiohyppäykseen liittyy jatkuva kehitys- ja parannustyö (Imai 1986, s.27). Yhdistämällä innovaatiot ja jatkuva kehitys on mahdollista päästä jatkuvastietenevään kehitykseen.

On kuitenkin perusteltu syy olettaa, että edellä kuvatut mallit eivät kuvaa oi-kealla tavalla prosessi-innovaation etenemistä. Tekninen muutos on luonteeltaansosiaalinen prosessi, mikä viittaa siihen, että tekniikka- ja innovaatiokeskeinenajattelu ei kykene yksin selittämään teknisten järjestelmien käyttöönottoproses-sia (Hyötyläinen 1998; Fichman ja Moses 1999). On tutkimuksia, joiden mukaanalkuperäinen tekninen muutos – riippumatta siitä kuinka radikaali se on – alittaaaina suorituskyvyltään järjestelmän, jonka se korvaa. Vasta sitkeällä kehitys-työllä uusi järjestelmä saavuttaa entisen järjestelmän tason ja voi ylittää sen.Näin vasta uuteen järjestelmään sisältyvät potentiaalit saadaan käyttöön (Yin1994).

Tätäkin kuvaa voidaan tarkentaa. Kuva 1 esittää tarkennettua mallia (Hyötyläi-nen 1998). Ensimmäinen tarkennus koskee suunnittelutoimintaa. Suunnitteluakuvaava katkoviiva viittaa siihen, että suunnittelutoiminta ei ole suoraviivaistajärjestelmän määrittelyä ja suunnittelua. Innovaatio ei ole valmiina eikä synnykerralla. Kyse on pikemminkin monista pienistä askeleista ja inkrementaalisistainnovaatioista sekä improvisoinnista (Ciborra 1999; Sahal 1981). Tämä tapahtuusosiaalisten prosessien kautta, joihin osallistuu monia organisaation tahoja erilai-sin tavoittein ja intressein (Torvinen 1999). On myös näyttöä siitä, että tietojär-jestelmien suunnittelussa ei käytetä kovinkaan systemaattisia menetelmiä (Rossi1998; Hyötyläinen 1998). Joka tapauksessa tietojärjestelmien suunnittelutoimin-nassa on kyse pitkästä prosessista, joka voi viedä organisaatiolta useita vuosia.Lisäksi suunnittelutoiminnalla on läheiset linkit järjestelmätoimittajiin ja mah-dollisiin järjestelmäkonsultteihin, mikä voi edelleen mutkistaa suunnittelutoi-mintaa, koska suunnittelutoiminnassa törmäävät erilaiset lähestymistavat, ta-voitteet, menetelmät ja organisatoriset toimintatavat (Tolvanen 1998; S.A.M.I.Ernst ja Young 1999).

22

Toinen tarkennus koskee käyttöönottotoimintaa. Kuva 1 osoittaa, että uusi jär-jestelmä alittaa käyttöönoton aluksi edellisen järjestelmän tason. Käyttöönotto-toiminnassa on kyse monista muutoksista ja innovaatiosta, joiden avulla järjes-telmä ja organisaatio sopeutetaan toisiinsa. Kyse on samalla uuden osaamisen jayhteistoimintatavan kehittämisestä ja omaksumisesta. Tästä toiminnasta onkäytetty termiä ”re-invention”, millä viitataan innovaatioon tehtäviin muutoksiinkäyttöönottovaiheessa (Rogers 1995, s. 172–180). Käyttöönottotoiminnassatörmätään lukuisiin ongelmiin ja häiriöihin, jotka edellyttävät uusia ratkaisuja jamuutoksia järjestelmään. Tässä mielessä on syytä nähdä suunnittelun ja käyt-töönoton raja vähemmän selkeänä. Voidaan nähdä, että suunnittelu jatkuu käyt-töönottovaiheessa (Ehn 1988; Brown 1991; Winter 1996). Ei nimittäin riitä, ettäkäyttäjä osaa käyttää järjestelmää. Hänen pitää myös osata liittää se osaksi omaatyötänsä, tunnistaa sen välittämä organisatorinen yhteistyö sekä pystyä toimi-maan sen avulla poikkeustilanteessa ja kehittämään työtänsä. Tällä on vaikutustaniin suunnittelussa kuin käyttöönotossakin käytettäviin lähestymistapoihin jamenetelmiin sekä sovellettaviin organisatorisiin muotoihin (Corbett et al. 1991;Boedker ja Gronbaek 1996; Kalela 1996).

Kolmas tarkennus koskee jatkuvaa kehitystoimintaa järjestelmän käytössä. Jär-jestelmän potentiaalien hyödyntäminen edellyttää järjestelmän toiminnan jatku-vaa kehitystyötä. Käytössä eteen tulevien ongelmien poistaminen sekä uusienavautuvien mahdollisuuksien hyödyntäminen onnistuu vain jatkuvalla kehitys-työllä. Tämä kehitystyö onnistuu parhaiten, kun se perustuu pitkäaikaiseenkäyttäjien kokemukseen. Tällöin puhutaan ”käyttämällä oppimisesta” (Rosen-berg 1985, s. 120–140; Zuboff 1988; Kalela 1996). Mielenkiintoisen kysymyk-sen muodostaa se, kuinka järjestelmän suunnittelutietämys ja -mallit voisivatolla käytettävissä käytön aikaisessa kehitystyössä.

Neljäs tarkennus koskee käyttö- ja kehittämistoimintaa. Peruskäsitys on se, ettäjärjestelmien kehittyminen tapahtuu vähittäin etenevänä toimintana oppimiskäy-rän periaatteiden mukaan. Tämä kuva ei ehkä pidä paikkaansa. Järjestelmänkäytössä on havaittavissa käyttöönottovaiheita (Hyötyläinen 1998). Syyt näihinkäyttöönottovaiheisiin voivat olla moninaiset. Keskeisiä ovat järjestelmien tek-niikassa, tuotteissa tai organisaatiossa tapahtuvat muutokset. Näyttää siltä, ettäkäytön aikana toteutuvat käyttöönottovaiheet johtavat järjestelmän suoritustasonväliaikaiseen laskuun samalla tavalla kuin varsinaisessa (ensimmäisessä) käyt-töönottovaiheessa. Tällä on vaikutusta organisaation järjestelmälle asettamiin

23

tavoitteisiin, toimintatapoihin ja menetelmiin. Kehittämisen ja innovaation sekäkäytön ja suunnittelun rajat hämärtyvät. Käytössä esiintyvät käyttöönottovaiheetedellyttävät kehittämisen lisäksi uusia innovatiivisia ratkaisuja.

4. Tietojärjestelmien käyttöönoton elinkaarimallit

Teknisen järjestelmän käyttöönoton prosessimalli avaa mahdollisuuden tarkas-tella tietojärjestelmien käyttöönottoprosessia eri toimijoiden näkökulmasta.Tietojärjestelmien käyttöönotto voidaan nähdä sosiaalisena prosessina, missä eritoimijat (johto, suunnittelijat, työnjohto, työntekijät ja organisaation eri toimin-tojen henkilöt sekä toimittajan edustajat ja konsultit) osallistuvat osaltaan eritavalla ongelmanratkaisuprosesseihin tietojärjestelmän suunnittelu- ja käyttöön-ottovaiheissa (Hyötyläinen 1998; Kuutti 1994; Fichman ja Moses 1999; ks.Argyris ja Schön 1978; Engeström 1987; Blackler 1993).

Samalla teknisen järjestelmän käyttöönoton prosessimalli tukee tietojärjestelmänsuunnittelu- ja käyttöönottoprosessin tarkastelemista elinkaarimallin (lifecyclemodel) kautta. Tietojärjestelmän suunnittelu- ja käyttöönottoprosessi voidaannähdä eri vaiheista eli sykleistä koostuvana elinkaarena. Tietojärjestelmiensuunnittelu- ja käyttöönottoprosessiin eri vaiheissa osallistuvien toimijoidentoimintaa ja toimenpiteitä voidaan vastaavasti arvioida suhteessa elinkaarimalliinja sen sykleihin. Tietojärjestelmien suunnittelu- ja käyttöönottoprosessiin liittyyyleensä kaksi päätoimijaa. Luonnollisesti keskeisenä on loppukäyttäjäyritys,joka ottaa tietojärjestelmän käyttöön. Toisena päätoimijana on tietojärjestelmäntoimittaja. Tämä voi olla ohjelmistotalo tai ns. järjestelmäintegraattori. Järjes-telmäintegraattorilla tarkoitetaan yleensä eräänlaista jälleenmyynti- ja imple-mentointiorganisaatiota, joka toimittaa yhden tai useamman ohjelmistovalmis-tajan ohjelmistotuotteita (Laudon ja Laudon 2000).

Nämä kaksi päätoimijaa muodostavat kaksi perustavanlaatuista näkökulmaatietojärjestelmän suunnittelu- ja käyttöönottoprosessiin. Nämä näkökulmat eroa-vat toisistaan, sillä kummallakin osapuolella on yleensä omat, toisistaan eroavatmenettelyt ja tavoitteet tietojärjestelmän käyttöönotolle. Tämä muodostaa yhdensyyn tietojärjestelmien käyttöönoton vaikeuksille.

Tässä kohdassa esitetään eräänlaisena hypoteesimallina elinkaarimallit tietojär-jestelmän käyttöönotolle sekä loppukäyttäjäyrityksen että ohjelmisto- tai järjes-

24

telmätoimittajan näkökulmasta. Tämän julkaisun seuraavissa artikkeleissa tul-laan käsittelemään tietojärjestelmien ja erityisesti toiminnanohjausjärjestelmienkäyttöönoton problematiikkaa osittain elinkaarimalliajatteluun nojautuen.

4.1 Loppukäyttäjäyrityksen näkökulma tietojärjestelmän käyttöönottoon

Loppukäyttäjäyrityksen tai vastaavan organisaation osalta tietojärjestelmänkäyttöönoton elinkaarimalli kattaa syklit aina yrityksen strategiasuunnittelustatietojärjestelmän ja sen käytön jatkuvaan kehittämiseen (STO 1999, Cassidy1998, Laudon ja Laudon 2000). Kaikkiaan elinkaarimalliin voidaan hahmottaaneljä eri sykliä, jotka voidaan jakaa edelleen tarkemmalle tarkkuustasolle. Kuva2 esittää loppukäyttäjäyrityksen elinkaarimallia.

Strategiasuunnittelu(liiketoiminnan tavoitteet

ja edellytykset tieto- järjestelmälle)

Tietojärjestelmän käyttöönottovaihe

Tietojärjestelmänkehittäminen

Tietojärjestelmänsuunnittelu ja järjestelmänvalinta, vaatimusmäärittely

1. 2. 3. 4.

Kuva 2. Loppukäyttäjäyrityksen tietojärjestelmän käyttöönottoprosessin elinkaa-rimalli.

Strategiasuunnittelun voidaan katsoa olevan yrityksen liiketoiminnan perusta.Strategiasuunnittelu muodostaa ensimmäisen syklin elinkaarimallissa. Strategianosalta voidaan erottaa varsinainen liiketoimintastrategia ja tietotekniikkastrate-gia, jossa täsmennetään yrityksen tietotekniikan rooli yrityksen strategiassa jaasetetaan tavoitteet tietotekniikan hyödyntämiselle (Mintzberg 1994; Luoma etal. 1999, Kamensky 2000, ks. myös tämän julkaisun IV artikkeli). Strategianluonti ja toteutus on nähty yhdeksi liikkeenjohdon keskeiseksi tavaksi toimia janivoa päivittäiset toimet osaksi yrityksen yhteistä tavoitteistoa ja strategistalinjausta. Tietojärjestelmän hankinnan katsotaan oleellisesti edellyttävän strate-

25

gian täsmentämistä ja strategisten tavoitteiden huomioimista järjestelmän han-kinnan yhteydessä (Cassidy 1998). Tietojärjestelmien elinkaari on yleensä suh-teellisen pitkä, mistä johtuen systemaattinen strateginen suunnittelu ja strategi-sen näkökulman huomioonottaminen ovat välttämättömiä tekijöitä, jotka ovatmahdollistamassa liiketoiminnan tavoitteita tukevan tietojärjestelmän valintaa.

Tietojärjestelmähankkeen suunnittelu, järjestelmän valinta sekä vaatimusmää-rittely sijoittuvat strategiasuunnittelun jälkeisiin vaiheisiin. Nämä toimenpiteetmuodostavat toisen syklin elinkaarimallissa. Toimenpiteet voidaan nähdäeräänlaisena esisuunnitteluna itse käyttöönottoa varten. Keskeisiä toimenpiteitäelinkaarimallin toisessa syklissä ovat toimintaan ja sen kehittämiseen perustuvavaatimusmäärittely valittavalle järjestelmälle, neuvottelut ja tarjouspyyntökier-rokset ohjelmistotoimittajille tai järjestelmäintegraattoreille sekä itse järjestel-män valinta. Yrityksen tai organisaation tekemä vaatimusmäärittely on perustajärjestelmän valinnalle. Kunnollisella, yrityksen eri toiminnot ja prosessit huo-mioivalla vaatimusmäärittelyllä päästään haluttuun lopputulokseen (STO 1999).Kunnolliset vaatimusmäärittelyt auttavat myös yritystä ja toimittajaa keskuste-lemaan ja ymmärtämään toisiaan.

Tietojärjestelmän käyttöönotolla tarkoitetaan valitun tietojärjestelmän imple-mentointia, parametrointia ja mahdollisia tietokonversioita vanhasta tietojärjes-telmästä uuteen. Tämä muodostaa kolmannen syklin elinkaarimallissa. Käyt-töönottovaiheeseen sisältyy lisäksi mahdolliset tietojärjestelmän räätälöinnit,koulutukset ja tarpeelliset harjoituskäytöt. Käyttöönoton kannalta tärkeää onsaada koko organisaatio ja henkilöstö mukaan, jolloin käyttöönotto helpottuu(Kalela 1996). Käyttöönottovaihe käsittää myös järjestelmän tuotantokäyttöönottamisen, jolla taas tarkoitetaan toiminnan suunnittelua ja ohjausta uuden tieto-järjestelmän avulla. Tuotantokäyttöön siirtyminen on usein kriittinen vaihetietojärjestelmähankkeissa, ja sen sujuminen kivuttomasti vaatii melkoisia pon-nistuksia organisaatiolta ja ohjelmistotoimittajilta (Hyötyläinen 1998).

Tietojärjestelmän jatkuvan kehittämisen voidaan katsoa olevan tietoteknistenvalmiuksien ylläpitämistä ja kehittämistä sekä tietoteknisestä että liiketoimin-nallisesta näkökulmasta käsin. Tämä muodostaa elinkaarimallin neljännen vai-heen. Jatkuva kehittäminen kattaa myös yrityksen tai organisaation henkilöstönosaamisen kehittämisen. Tietojärjestelmien jatkuva kehittäminen tarkoittaa uusiajärjestelmäpäivityksiä sekä käytettävän järjestelmän laajuuden kasvattamista.

26

Itse järjestelmän lisäksi yritys tai organisaatio voi kehittää omia toimintaproses-sejaan sekä itse yrityksen toiminnanohjausta, jolloin olemassa olevasta järjes-telmästä saadaan uutta potentiaalia irti. Jatkuva kehittäminen tulisi nähdä myösosana yrityksen normaalia toimintaa (Hyötyläinen 1998; Hyötyläinen ja Karvo-nen 2000; Imai 1986; Lillrank 1990).

4.2 Ohjelmistotoimittajan tai järjestelmäintegraattorin näkökulma tietojär-jestelmän käyttöönottoon

Ohjelmistotoimittajalla ja järjestelmäintegraattorilla on omanlaisensa näkökulmaedustamansa tai toimittamansa tietojärjestelmän käyttöönottoon. Ohjelmistotoi-mittajan elinkaarimallin voidaan katsoa alkavan tuotekehitysprosesseista jajärjestelmän strategisista tavoitteista. Tuotekehitysprosessit ja tuotekonseptienmäärittelyt ovat erittäin tärkeitä, sillä niiden varaan rakentuu pitkälti yrityksenliiketoiminta ja ydintuotteet. Seuraavana vaiheena toimittajan elinkaarimallissavoidaan nähdä myynti- ja markkinointitoiminnot, jotka taas vastaavat loppu-käyttäjäyrityksen mallissa järjestelmän hankinta- ja esisuunnitteluvaihetta. Myö-hemmin seuraavat sitten itse tietojärjestelmän toteutusprojekti (yhtenevä käyt-töönoton kanssa) sekä järjestelmän käytönaikainen tuki ja kehittäminen (jatkuvakehittäminen). Kuvaan 3 on hahmoteltu tietojärjestelmän elinkaarimallia ainatuotekehityksestä ylläpitopalvelujen järjestämiseen.

Tietojärjestelmäntuotekehitysprosessit

Tietojärjestelmän käyttöönottovaihe(implementointi ja

koulutus)

Käytönaikanen tukija päivitykset

Myynti ja markkinointi

1. 2. 3. 4.

Kuva 3. Järjestelmäintegraattorin tai ohjelmistotoimittajan näkökulman mukai-nen elinkaarimalli.

27

Tuotekehitysprosessit ja strategiasuunnittelu on pohja ohjelmistoja tietojärjes-telmätoimittajien toiminnalle. Tuotekehityksen kautta yritykset pyrkivät vastaa-maan asiakkaidensa tarpeisiin. Viime vuosina erityisesti toiminnanohjausjärjes-telmien kehittäjät ja toimittajat ovat fokusoituneet yrityksen sisäiseen ohjauk-seen. Suomalaisessa pk-teollisuudessa on kuitenkin omat erityispiirteensä, joitaei ole täysimittaisesti otettu huomioon ohjelmistokehityksessä.

Viime aikoina erityisesti ohjelmistojen tuotekehityksen puolella ovat nousseetesiin uudet teknologiat, esim. komponenttiteknologia, joka parantaa erilaistenohjelmistojen liityntöjen toteutusta (Niemelä et al. 2000). Tuotekehityksessä onviime vuosina noussut myös esille myös yritysten verkostoituminen ja sen mu-kaan tuomat tarpeet yritysverkostojen toiminnan suunnittelulle ja ohjaukselle(Hyötyläinen 2000). Tuotekehitys näyttelee erityisesti ohjelmistotoimittajannäkökulmasta erityisen tärkeää osaa, sillä yhden tuotesukupolven elinkaari ontavallisesti 5–10 vuotta. Ohjelmistotoimittajien ja järjestelmäintegraattoreidenstrategisia kysymyksiä ovat tuotekehityksen lisäksi erilaiset toimintakonseptit,kuten ASP-palvelut (Application Service Provider) ja niiden toteuttaminen.Keskeisen kysymyksen toiminnalle muodostaa tuotekehityksen suhteen myössuhtautuminen ohjelmistojen räätälöintiin ja modulointiin.

Myynti ja markkinointi on ohjelmistotoimittajan tai järjestelmäintegraattorinelinkaarimallissa yhtenevä loppukäyttäjäyrityksen hankinnan ja esisuunnittelunkanssa. Myynti ja markkinointi on tärkeä osa elinkaarimallia, sillä siinä luodaankontakteja loppukäyttäjäyrityksiin, ja sitä kautta pystytään myös hahmottamaanyritysten ja organisaatioiden tarpeita. Ohjelmistotoimittajille ja järjestelmäinte-graattoreille onkin erityisen keskeistä huomioida yritysten tarpeet ja realistisestikertoa omien tuotteiden tukemat mahdollisuudet sekä järjestelmän tuki yrityksentoiminnalle ja prosesseille. Tärkeää on myös asettua asiakkaan rooliin, silläusein ongelmia aiheuttaa yhteisen kommunikointisanaston ja -kielen puuttumi-nen.

Tietojärjestelmän implementoinnilla tarkoitetaan tietojärjestelmän toimituksenprojektointia, eli tietojärjestelmän toteuttamista kaikkine konversioineen jaliityntöineen muihin järjestelmiin sekä itse ohjelmistojen asennusta. Usein oh-jelmistojen toimittaja järjestää myös yrityksen henkilöstön koulutuksen sekäkäyttöönoton opastuksen. Tässä elinkaaren vaiheessa toimittajan ja loppukäyt-

28

täjäyrityksen yhteistoiminta on keskeistä, sillä se muodostaa pohjan järjestelmäntuotantokäytölle ja yleensäkin käytölle yrityksessä.

Käytönaikainen tuki ja kehittäminen liittyy olemassa oleviin järjestelmiin sekäniiden käytön aikaisen tuen järjestämiseen. Usein tietojärjestelmän toimittajatarjoaa tukipalveluita muun muassa ongelmia varten. Lisäksi toimittaja useintekee parannuksia ohjelmistoon, mikä tarkoittaa käytännössä ohjelmistopäivityk-siä. Yrityksillä on usein myös mahdollisuus osallistua ohjelmiston kehittämiseenja antaa ehdotuksia esimerkiksi uusista toiminnallisista ominaisuuksista, joitaohjelmistoon voitaisiin lisätä.

5. Näkökulmana organisatoriset oppimisprosessit

Tietojärjestelmien soveltaminen tapahtuu usean organisaation yhteistyönä javuorovaikutuksen kautta. Tietojärjestelmien suunnittelu- ja käyttöönottoprosessitovat monivaiheisia ja monimutkaisia prosesseja, joissa organisaatiot joutuvatyhdessä ja erikseen ratkomaan lukuisia toimintaan ja sen kehittämiseen samoinkuin järjestelmään liittyviä kysymyksiä. Näissä prosesseissa törmätään moniinyllättäviin ongelmiin. Organisaatiot joutuvatkin käytännössä omaksumaan uusiatoimintatapoja näiden ongelmien ratkaisemiseksi. Tietojärjestelmien suunnittelu-ja käyttöönottoprosesseja voidaankin tarkastella kehittyvän toiminnan näkökul-masta (ks. Argyris ja Schön 1978; Engeström 1987; Blackler 1993; Kuutti 1994;Fichman ja Moses 1999).

Tietojärjestelmien suunnittelu- ja käyttöönottoprosessien näkeminen kehittyvänätoimintana tuo näkökenttään sen, että organisaatiot oppivat ja luovat uusia käy-täntöjä ja niitä tukevia menetelmiä prosessien kuluessa. Tietojärjestelmien suun-nittelu- ja käyttöönottoprosesseja voidaan täten lähestyä organisatoristen oppi-misprosessien näkökulmasta. Lähtökohtana on ajatus, että viime kädessä tieto-järjestelmät ovat potentiaalista teknologiaa. Potentiaali realisoituu vasta käytän-nössä loppukäyttäjäyrityksissä. Ilman tietoisia organisatorisia oppimisprosessejauusien järjestelmien potentiaaleja ei voida hyödyntää täydellisesti. Oppimispro-sessit voivat ulottua organisaatiorajojen yli. Ohjelmistotoimittaja voi oppia uuttajokaisesta toimituksesta oman toimintansa sekä asiakasprosessinsa ja tuotekon-septinsa kehittämiseksi (vrt. Nonaka ja Takeuchi 1995; Dixon 1999 ja 2000).

29

Ongelma on siinä, että oppimisprosessit eivät tapahdu automaattisesti. Vaikkaorganisaatiot törmäävät ongelmiin ja vaikeuksiin, ei tämä johda välttämättätietoisiin oppimistapahtumiin edes yksittäisessä yrityksessä – puhumattakaanorganisaatiorajojen yli tapahtuvista oppimisprosesseista. Oppimisprosessit edel-lyttävät tietoisia organisatorisia käytäntöjä, yhteistyötapoja ja kommunikointi-välineitä (Krogh et al. 2000; Hyötyläinen 2000).

Usein ihmiset eivät ole tottuneet esittämään asioita selkeästi malliajatteluunperustuen. Asioista kerrotaan monisanaisesti ja epäyhtenäisesti (ks. Hyötyläinen1998 ja 2000). On ymmärrettävää, että näin eri toimijoiden ja toimintojen onvaikeaa ja hidasta oppia ymmärtämään toistensa toimintalogiikkaa ja alkaayhdessä rakentamaan uutta toimintamallia uuden tietojärjestelmän tehokkaankäyttöönoton ja käytön tueksi. Kysymys on siitä, että tietoa on organisaatiossapaljon, vaikka se on enimmäkseen sitoutunut yksilöihin ja heidän erilaisiinnäkemyksiinsä sekä eri toimintojen rutiineihin (ks. Polanyi 1983; Nonaka jaTakeuchi 1995; March ja Simon 1958).

Uuden tietojärjestelmän käyttöönotto ja toimintatavan kehittäminen edellyttävätriittävää yhteistyötä ja keskustelua toiminnasta ja sen kehittämisestä organisaa-tion sisällä (ks. Nonaka ja Takeuchi 1995; Dixon 1999; Hyötyläinen 1998).Tämä ei onnistu, ellei eri toimijoilla ja toiminnoilla ole riittävän yhtenäistä ku-vaa organisaation toiminnasta. Tässä suhteessa keskijohdolla voidaan nähdäolevan organisaatiossa keskeinen asema (ks. Nonaka ja Takeuchi 1995). Yleensäylin johto operoi visio- ja tavoitemalleilla, jotka kuvaavat strategisia pyrkimyk-siä liiketoiminnan kehittämiseksi. Osin johdon visiot ja tavoitteet ovat jäsenty-mättömiä ja vailla konkreettisia malleja etenemiselle tavoitteiden suuntaan.Toisaalta perustasolla toimijoiden mallit koskevat välittömiä työtehtäviä japrosesseja. Sen sijaan keskijohto asemansa puolesta pystyy toimimaan johdon japerustason välissä. Se kykenee ymmärtämään yhtäältä johdon ajattelumaailmaaja tahtotilaa, minkä johto usein ilmaisee vertauksin, analogioin ja tavoittein (ks.Nonaka 1991; Prange 1999). Toisaalta keskijohdolla on riittävän tarkka kuvaorganisaation jokapäiväisestä toiminnasta ja sen kehitysongelmista. Keskijohtopystyy välittävänä linkkinä esittämään johdon visiot ja tavoitteet operatiivisellatasolla toimintoja ja niiden toimijoita varten. Keskijohto kykenee myös viesti-mään johdolle toimintojen ja toiminnan reaalisista mahdollisuuksista ja rajoit-teista.

30

Useat yritykset ovat karsineet keskijohtoaan kovalla kädellä viime vuosien aika-na. Nähtäväksi jää, osoittautuuko tämä säästötoimenpide sittenkin virheliikkeek-si pidemmällä aikajänteellä. Varsinkin suurten yritysten toiminta on sen luon-teista, että hyvin toimivan keskijohdon merkitystä esimerkiksi strategisen jaoperatiivisen toiminnan koordinoijana ei voi aliarvioida.

Vuoropuhelu ja kehitystoimintaan liittyvä keskustelu ovat osa organisaationtietojärjestelmää (Checkland ja Holwell 1998; Macdonald 1998; Simons jaHyötyläinen 1998). Tällä tarkoitetaan kaikkea kommunikointia, muun muassatiedonsiirtoa ja -hallintaa, jolla organisaatio tukee toimintaansa. Tietojärjestelmäkokonaisuutena on luonteeltaan joustava ja muuttuu tilanteen mukaan. Tämä onmahdollista, koska käytössä on joukko erilaisia menetelmiä. Yksinkertaisin jaluonnollinen osa järjestelmää on spontaani, jokapäiväinen henkilöiden välinenkeskustelu. Muita tietojärjestelmään kuuluvia menetelmiä ja menettelytapojaovat muun muassa etukäteen suunnitellut ja valmistellut palaverit, erilaiset do-kumentit ja formaalit työkalut. Kasvava osa yrityksen tietojärjestelmästä perus-tuu tietoteknisten välineiden käyttöön.

6. Johtopäätökset

Tietojärjestelmien käyttöönottoprosessin ja siihen vaikuttavien kehitysmekanis-mien ymmärtäminen edesauttaa tietojärjestelmien soveltamista organisaatiossaja käyttöönottoon asetettujen tavoitteiden saavuttamisessa. Tietojärjestelmienkäyttöönottoprosessi on kuitenkin vaikeasti käsitteellistettävä ilmiö. Käytännöntasolla tietojärjestelmien käyttöönotossa on aina kyse mutkikkaista strategisistakysymyksistä, teknisistä, taloudellisista ja organisatorisista ongelmista sekäniihin liittyvien ratkaisujen hakemisesta. Artikkelissa tietojärjestelmien käyt-töönottoprosessia on lähestytty määrittelemällä ja käsittelemällä ilmiötä viidestäeri näkökulmasta. Nämä näkökulmat ovat: tiedonalan näkökulma, käyttöönotonprosessimallin näkökulma, loppukäyttäjäorganisaation elinkaarimallin näkökul-ma, ohjelmisto- tai järjestelmätoimittajan elinkaarimallin näkökulma sekä orga-nisatoristen oppimisprosessien näkökulma.

Johtopäätöksenä näkökulmien käsittelystä voidaan esittää, että tietojärjestelmienkäyttöönottoprosessiin ja sen onnistumiseen ovat keskeisesti vaikuttamassaomaksutut suunnittelu- ja käyttöönottomallit ja niihin liittyvät menetelmät. Ar-tikkelissa on nostettu esiin uudenlainen ajattelumalli tietojärjestelmien käyttöön-

31

ottoprosessista. Tietojärjestelmien käyttöönottoprosessi nähdään monimutkaise-na ja monivaiheisena prosessina, joka toteutuu ja määräytyy organisatoristentoimenpiteiden kautta. Viime kädessä kyse on organisatorisista tiedonluonti- jaoppimisprosesseista. Näiden prosessien kautta vasta tietoteknologian ”potentiaa-lit” voidaan saada täyteen käyttöön. Käyttöönottoprosessiin osallistuu useitatahoja erilaisin intressein, tavoittein ja menetelmin, mikä voi edesauttaa oppi-misprosesseja. Kuitenkin eri toimijoiden ja näkökulmien olemassaolo ei takaasellaisenaan tiedonluonti- ja oppimisprosessien käynnistymistä organisaatioissa(loppukäyttäjäorganisaatio ja ohjelmistotoimittaja) ja niiden välisessä yhteis-työssä.

Tiedonluonti- ja oppimisprosessit edellyttävät tietoisia toimia ja menettelyjenluontia. Nämä toimet ja menettelyt on sidottava elinkaarimalleihin. Oleellista onluoda menettelyt tiedon siirrolle ja oppimisprosesseille elinkaarimallien erisyklien välille ja koko elinkaarimallin ylitse.

Artikkelissa tehty tietojärjestelmien käyttöönottoprosessin jäsennys kytkeytyyinnovaation, tiedonluonnin ja oppivan organisaation käsitteisiin, joista on tullut1990-luvulta alkaen yleisesti käytettyjä käsitteitä (ks. Senge 1990; Argyris 1992;Garvin 1993; Leonard 1995; Nonaka ja Takeuchi 1995; Krogh et al. 1998 ja2000). Tietojärjestelmien käyttöönottoprosessia ei ole laajemmin tarkasteltutiedonluonnin ja organisatoristen oppimisprosessien näkökulmista (Currie jaGalliers [toim.] 1999; vrt. Nonaka ja Takeuchi 1995). Elinkaarimalleja on käsi-telty eri tavoin useissa lähteissä (Laudon ja Laudon 2000; Cassidy 1998). Kui-tenkin malleja on käytetty enimmäkseen joko projektinhallinnan välineinä tieto-järjestelmäprojekteissa tai apuna erillisten menetelmien kehittämissä. Artikkelis-sa elinkaarimallit sidotaan yhtäältä tietojärjestelmien käyttöönoton prosessimal-liin ja toisaalta organisaatioiden ja niiden välisiin yhteistyö- ja oppimisproses-seihin.

Artikkeli nostaa monia kysymyksiä jatkotutkimukselle. Mielenkiintoinen kysy-mys on tiedonluonnin- ja oppimisprosessien mikrokosmos eli kuinka uudentiedon luonti ja oppiminen tapahtuu konkreettisten toimien kautta organisaatios-sa ja organisaatioiden välisessä yhteistyössä (vrt. Krogh et al. 2000). Yhtä kiin-nostavia kysymyksiä ovat käyttöönoton prosessimallin selitysvoima ja elinkaa-rimallien ja niiden syklien merkitys uudenlaisten suunnittelu- ja käyttöönotto-mallien ja menetelmien kehitystyössä. Näihin kysymyksiin vastaaminen onnis-

32

tuu parhaiten tietojärjestelmien käyttöönottoprosesseihin kohdistuvalla konst-ruktiivisella tutkimus- ja kehitystyöllä (Lee 1999; Fryer ja Feather 1994; Kuula1999). Mikäli tähän tutkimus- ja kehitystyöhön liittyy riittävä teoreettinen työs-kentely, voidaan tällä työllä palvella myös tietojärjestelmien soveltamista koske-vaa tiedonalaa uusilla käsitteillä ja kysymyksenasetteluilla.

Artikkelin pohjalta voidaan nostaa esiin joitakin suosituksia menettelyiksi tieto-järjestelmien käyttöönottoprosessia varten. Pääsanoma on, että tietojärjestelmänkäyttöönotto ja toimintatavan kehittäminen perustuu osallistuvien organisaatioi-den ja henkilöiden oppimiseen ja tiedon luontiin tietojärjestelmän käyttöönotonelinkaarimalleissa ja niiden eri syklien välillä. Kussakin organisaatiossa yksilötoppivat, mutta samalla voi muodostua koko organisaatiolle yhteistä osaamista.Tietojärjestelmien suunnittelu- ja käyttöönottoprosessiin ja sen eri sykleihintulee järjestää kommunikointi- ja vuoropuheluprosessi organisaation sisällä jaosallistuvien organisaatioiden välillä. Tämän prosessin kautta syntyy ja välittyytietoa, joka tukee yhteisen käsityksen muodostamista tietojärjestelmän määritte-lystä, käyttöönotosta ja toimintatapojen kehittämisestä. Tämä kommunikointi- javuoropuheluprosessi on ratkaisevassa asemassa uuden tiedon luonnissa ja orga-nisatorisessa oppimisessa, mitkä mahdollistavat uuden tietojärjestelmän tehok-kaan käyttöönoton organisaatiossa (ks. Stacy 1996, Checkland ja Holwell 1998;Dixon 1999; Hyötyläinen 1998 ja 2000).

Suosituksena voidaan todeta lisäksi, että tietojärjestelmien käyttöönottoprosessinedistäminen ja tähän liittyvän suunnittelu- ja kehitystoiminnan järjestäminenosallistuvissa organisaatioissa edellyttää sitä, että toimintojen ja erityisesti niidenavainhenkilöiden täytyy alkaa tarkastella toimintaa eri näkökulmista eli ”metata-solla”, mikä merkitsee toiminnan ja sen perusteiden reflektiivistä ajattelua jasille perustuvaa mallintamista (ks. Schön 1983; Engeström 1994). Tämä ei on-nistu ilman toimivaa kommunikointi- ja vuoropuheluprosessia ja siihen soveltu-via menettelyjä ja välineitä.

33

Lähdeluettelo

Argyris, C. 1992. On Organizational Learning. Oxford: Blackwell Business.

Argyris, C. & Schön, D. A. 1978. Organizational Learning: A Theory of ActionPerspective. Reading, Massachusets – Menlo Park, California – London –Amsterdam – Don Mills, Ontario – Sydney: Addison-Wesley.

Avison, D. E. & Fitzgerald, G. 1999. Information Systems Development. In:Currie, W. L. & Galliers, B. (Eds.), Rethinking Management InformationSystems. Oxford: Oxford University Press. S. 250–278.

Blackler, F. 1993. Knowledge and the Theory of Organizations: Organizationsof Activity Systems and the Reframing of Management. Journal of ManagementStudies, 30:6, November, s. 863–884.

Boedker, S. & Gronbaek, K. 1996. Users and Designers in Mutual Activity: AnAnalysis of Cooperative Activities in Systems Design: In: Engeström, Y. &Middleton, D. (Eds.), Cognition and Communication at Work. New York:Cambridge University Press. S. 130–158.

Brown, J. 1991. Research that Reinvents the Corporation. Harvard BusinessReview, January-February, s.102–111.

Cassidy, A. 1998. A Practical Guide to Information Systems Strategic Planning.London: St. Lucie Press.

Checkland, P. & Holwell, S. 1998. Information, Systems and InformationSystems. Making Sense of the Field. Chichester: John Wiley and Sons.

Ciborra, C. U. 1999. A Theory of Information Systems Based on Improvisation.In: Currie, W. L. & Galliers, B. (Eds.), Rethinking Management InformationSystems. Oxford: Oxford University Press. S. 136–155.

34

Corbett, J. M., Rasmussen, L. B. & Rauner, F. 1991. Crossing the Border. TheSocial and Engineering Design of Computer Integrated Manufacturing Systems.London – Berlin – Heidelberg – New York – Paris – Tokyo – Hong Kong:Springer-Verlag.


Davenport, T. H. 1993. Process Innovation. Reengineering Work throughInformation Technology. Boston: Harvard University Press.

Davenport, T. H. 1997. Information Ecology. Why Technology is not Enoughfor Success in the Information Age. Oxford: Oxford University Press.

Dixon, N. M. 1999. The Organizational Learning Cycle. How We LearnCollectively. Cambridge: Gower.

Dixon, N. M. 2000. Common Knowledge. How Companies Thrive by SharingWhat They Know. Boston, Mass.: Harvard Business School Press.

Easterby-Smith, M., Thorpe, R. & Lowe, A. 1991. Management Research. AnIntroduction. London: Sage Publications.

Ehn, P. 1988. Work-Oriented Design of Computer Artifacts. Stockholm:Arbetslivcentrum.

Engeström, Y. 1994. Training for Change: New Approach to Instruction andLearning in Working Life. Geneva: International Labour Office.

Engeström, Y. 1987. Learning by Expanding. An Activity-Theoretical Approachto Developmental Research. Helsinki: Orienta-Konsultit Oy.

Fichman, R. G. & Moses, S. A. 1999. An Incremental Processes for SoftwareImplementation. Sloan Management Review, Winter, s. 39–52.

35

Fryer, D. & Feather, N. T.1994. Intervention Techniques. In: Cassell, C. &Symon, G. (Eds.), Qualitative Methods in Organizational Research. A PracticalGuide. London – Thousands Oak – New Delhi: Sage Publications. S. 230–247.

Garvin, D. A. 1993. Building a Learning Organization. Harvard Business Review,July-August, s. 78–91.

Hyötyläinen, R. 1998. Implementation of Technical Change as OrganizationalProblem-Solving Process. Management and User Activities. Espoo: VTTPublications 337. 238 s. + liitt. 12 s.

Hyötyläinen, R. 2000. Development Mechanisms of Strategic Enterprise Networks.Learning and Innovation in Networks. Espoo: VTT Publications 417. 142 s.

Hyötyläinen, R. & Karvonen, I. 2000. Häiriönseurannan organisointi- jaanalysointimenetelmät. Espoo: VTT Tiedotteita 2035. 91 s. + liitt. 5 s.

Iivari, J. & Lyytinen, K. 1999. Research on Information Systems Developmentin Scandinavia. Unity in Plurality. In: Currie, W. L. & Galliers, B. (Eds.),Rethinking Management Information Systems. Oxford: Oxford University Press.S. 57–102.

Imai, M. 1986. Kaizen. The Key to Japan´s Competitive Success. New York:McGraw-Hill Publishing Company.

Kalela, J. 1996. Automaation paradigmat. Käyttäjien osallistuminen automaationsuunnitteluun. Espoo: VTT Julkaisuja 817. 148 s. + liitt. 74 s.

Kamensky, M. 2000. Strateginen johtaminen. Jyväskylä: Kauppakaari.

Kortteinen, B., Nurminen, M. I., Reijonen, P. & Torvinen, V. 1996. ImprovingIS deployment through evaluation: Application of the ONION model. In:Brown, A. & Remenyi, D. (Eds), Proceedings of the 3rd European Conferenceon the Evaluation of IT. S. 175–181.

36

Krogh, G. von, Roos, J. & Kleine, D. (Eds.) 1998. Knowing in Firms.Understanding, Managing and Measuring Knowledge. London: SAGEPublications.

Krogh, G. von, Ichijo, K. & Nonaka, I. 2000. Enabling Knowledge Creation.How to Unlock the Mystery of Tacit Knowledge and Release the Power ofInnovation. Oxford: Oxford University Press.

Kusch, M. 1993. Tiedon kentät ja kerrostumat. Oulu: Kustannus Pohjoinen.

Kuula, A. 1999. Toimintatutkimus. Kenttätyötä ja muutospyrkimyksiä.Tampere: Vastapaino.

Kuutti, K. 1994. Information Systems, Cooperative Work and Active Subjects:The Activity-Theoretical Perspective. University of Oulu, Department ofInformation Processing Science, Research Papers, Series A 23.

Laudan, L. 1977. Progress and Its Problems. Towards a Theory of ScientificGrowth. Berkeley: University of California Press.

Laudon, K. & Laudon, J. 2000. Management Information Systems –Organization and Technology in The Networked Enterprise. New York: PrenticeHall, Sixth Edition.

Lee, A. S. 1999. Researching MIS. In Currie, W. L. & Galliers, B. (Eds.)Rethinking Management Information Systems. Oxford: Oxford University Press.S. 7–27.

Leonard, D. 1995. Wellsprings of Knowledge. Building and Sustaining theSources of Innovation. Boston: Harvard Business School Press.

Lillrank, P. 1990. Laatumaa. Johdatus Japanin talouselämään laatujohtamisennäkökulmasta. Jyväskylä: Gaudeamus.

Luoma, J., Muhonen, T. & Huomo, T. 1999. Uudistuva tietotekniikka-arkkitehtuuri. Helsinki: HM&V Research Oy.

37

Macdonald, S. 1998. Information for Innovation. Managing Change from anInformation Perspective. Oxford: Oxford University Press.

March, J. G. & Simon, H. 1958. Organizations. New York - London - Sidney:John Wiley & Sons, Inc.

Mintzberg, H. 1994. The Rise and Fall of Strategic Planning. New York:Prentice Hall.

Mumford, E. 1999. Routinisation, Re-engineering, and Socio-technical Design.Changing Ideas on the Organisation of Work. In: Currie, W. L. & Galliers, B.(Eds.), Rethinking Management Information Systems. Oxford: OxfordUniversity Press. S. 28–44.

Niemelä, E., Kuikka, S., Vilkuna, K., Lampola, M., Ahonen, J., Forssel, M.,Korhonen, R., Seppänen, V. & Ventä, O. 2000. Teolliset komponenttiohjel-mistot. Kehittämistarpeet ja toimenpide-ehdotukset. Helsinki: Tekes, Tekno-logiakatsaus 89/00.

Nonaka, I. 1991. The Knowledge-Creating Company. Harvard Business Review,November-December, s. 96–104.


Polanyi, M. 1983. The Tacit Dimension. Gloucester, MA: Peter Smith(published originally 1966).

Prange, C. 1999. Organizational Learning – Despetately Seeking Theory? In:Easterby-Smith, M, Burgoyne, J. & Arajujo, L. (Eds.), Organizational Learningand the Learning Organization. Developments in Theory and Practice. London:SAGE Publications. S. 23–43.

Rogers, E. M. 1995. Diffusion of Innovations. New York – London – Toronto –Sydney – Tokyo – Singapore: The Free Press, Fourth Edition (first edition in1962).

38

Rosenberg, A. 1995. Philosophy of Social Science. Boulder, Colorado: WestvievPress, Second Edition.

Rosenberg, N. 1985. Inside Black Box: Technology and Economics. Cambridge– London – New York – New Rochelle – Melbourne – Sydney: CambridgeUniversity Press.

Rossi, M. 1998. Advanced Computer Support for Method Engineering.Implementation of CAME Environment in MetaEdit+. Jyväskylä: University ofJyväskylä, Jyväskylä Studies in Computer Science, Economics and Statistics 42.

Sahal, D. 1981. Patterns of Technological Innovation. London – Amsterdam –Don Mills, Ontario – Sydney – Tokyo: Addison-Wesley Publishing Company.

S.A.M.I. Ernst & Young 1999. Liike – toiminta – prosessi. Vuosikirja 1999.

Sayer, A. 1992. Method in Social Science. A Realistic Approach. SecondEdition. London and New York: Routledge.

Schön, D. A. 1983. The Reflective Practitioner. New York: Basic Books.

Senge, P. 1990. The Fifth Discipline. The Art and Practice of the LearningOrganization. New York: Doubleday.

Simons, M. & Hyötyläinen, R. 1998. Monenkeskisen verkostotoiminnankehittämisen menetelmät ja välineet. In: Ollus, M., Ranta, J. & Ylä-Anttila, P.(toim.), Verkostojen vallankumous. Miten johtaa verkostoyritystä? Vantaa:Taloustieto Oy. S. 132–149.

Stacy, R. 1996. Complexity and Creativity in Organizations. San Francisco:BerretKoehler Publishers.

STO. 1999. Toiminnanohjausohjelmiston hankinta ja markkinoiden nykytilanne.STO-työryhmäraportti. Suomen Tuotannonohjausyhdistys ry.

39

Tolvanen, J.-P. 1998. Incremental Method Engineering with Modeling Tools.Jyväskylä: University of Jyväskylä, Jyväskylä Studies in Computer Science,Economics and Statistics 47.

Torvinen, V. 1999. Construction and evaluation of the Labour Game method,Doctoral Dissertation, Turku Centre for Computer Science, No. 17.

Uusitalo, H. 1999. Tiede, tutkimus ja tutkielma. Johdatus tutkielman maailmaan.Juva: WSOY, 6. painos.

Willcocks, L. P. & Lester, S. (Eds.) 1999. Beyond the IT Productivity Paradox.Chichester: Wiley.

Winter, S. G. 1996. Organizing for Continuous Improvement. EvolutionaryTheory Meets the Quality Revolution. In: Cohen, M. D. & Sproull, L. S. (Eds.),Organizational Learning. Thousands Oak – London – New Delhi: SagePublications. S. 460–483.

Yin, J. Z. 1994. Managing Process Innovation through Incremental Improve-ments: Empirical Evidence in the Petroleum Refining Industry. TechnologicalForecasting and Social Change 47, s. 265–276.

Zuboff, S. 1988. In the Age of the Smart Machine. The Future of Work andPower. New York: Basic Books.

40

II Pk-yrityksen toiminnanohjaus ja senjärjestelmät

Petri Kalliokoski, Magnus Simons, Markku MikkolaVTT Automaatio

1. Johdanto

Kehittyvässä ja globalisoituvassa taloudessa tiedon hallinnan, jalostuksen jahyödyntämisen tehokkuus määrää pitkälle yritysten menestymisen. 1990-luvunaikana yritysten liiketoiminnan tueksi on kehitetty toiminnanohjausjärjestelmiä(Enterprise Resourse Planning systems, ERP), joiden tarkoitus on integroidayritysten liiketoimintaprosessit tehokkaammin toimiviksi kokonaisuuksiksi sekäyritysten sisällä että yhä enenevissä määrin myös yritysten välillä (ks. Luoma etal. 1999). Alun pitäen kyseisiä järjestelmiä on kehitetty lähinnä suurten yritystenja organisaatioiden tarpeisiin. Viimeaikainen kehitys on kuitenkin johtanut sii-hen, että toiminnanohjausjärjestelmiä on otettu ja otetaan käyttöön myös pk-yrityksissä. Pk-yritysympäristö taas asettaa järjestelmille sekä teknisesti ettätoiminnallisesti erilaisia vaatimuksia kuin mihin suuremmissa ja jo perusval-miuksiltaan kehittyneemmissä organisaatioissa törmätään.

Pk-yritysten toiminnanohjauksen järjestelmätarpeista, järjestelmien käyttöönot-toprosesseista ja niitä tukevista menetelmistä on toistaiseksi melko vähän tietoa(ks. Iivari ja Lyytinen 1999). Tämän artikkelin tarkoituksena on selventää pk-yrityksen toiminnanohjauksen erityispiirteitä, hahmottaa nykyisten toiminnan-ohjausjärjestelmien rakennetta ja ominaisuuksia sekä esittää ajatuksia toimin-nanohjauksen ja toiminnanohjausjärjestelmien kehitystrendeistä. Lisäksi artik-kelissa analysoidaan nykyisten toiminnanohjausjärjestelmien soveltuvuutta pk-yrityksiin ja esitetään kokemuksia toiminnanohjausjärjestelmien käyttöönotostaja käytöstä pk-sektorin yrityksissä.

Pk-yritysten toiminnanohjaus on tutkimuksellisesti mielenkiintoinen osa-alue.Koska pk-yritysten toiminta on monessa yrityksessä hyvinkin erilaista, on niillemyös vaikea kehittää toiminnanohjausjärjestelmiä. Mielenkiintoisen lisän tähänongelmakenttään tuo yritysten lisääntyvä verkostoituminen (ks. Hyötyläinen2000; Kuitunen et al. 1999). Yritysten verkostoituminen luo myös tarpeita ja

41

haasteita erilaisten järjestelmien integroinnille sekä kokonaisten yritysverkosto-jen toiminnanohjauksen kehittämiselle.

2. Pk-yrityksen toiminnanohjaus

Toiminnanohjausjärjestelmien kehittäminen on lähtenyt liikkeelle suurten yri-tysten ja organisaatioiden tarpeista, ja siirtynyt siitä vähitellen kohti entistäpienempiä yrityksiä. Voidaankin melko perustellusti olettaa, että nykyisin pk-yrityksille suunnattujen toiminnanohjauksen ratkaisujen pohjana on toimintapro-sessiajattelu, joka juontaa juurensa erilaisesta toiminnallisesta kontekstista kuinminkä pk-sektori muodostaa. Tämä taas tuo mukanaan tarpeen pk-yrityksillesuunnattujen toiminnanohjausjärjestelmien ja toiminnanohjauksen ratkaisujenkehittämiselle. Tässä kohdassa on tarkoitus hahmotella lyhyesti pk-yrityksentoiminnanohjausta ja sen erityispiirteitä.

2.1 Toiminnanohjauksen malli

Toiminnanohjaus on viime vuosina saanut paljon huomiota ns. toiminnanoh-jausjärjestelmien ansiosta. Näiden järjestelmien lähtökohtina ovat mm. materi-aalinhallinnan ja taloushallinnan järjestelmät, joita on laajennettu tukemaanyrityksen muita toimintoja. Tällä tavalla käsite toiminnanohjaus on tullut kytke-tyksi yrityksen liiketoiminnan eri osa-alueisiin. Tässä haluamme määritellätoiminnanohjausta yrityksen liiketoiminnan näkökulmasta. Tarkastelemmetoiminnanohjausta kokonaisuutena, jolla tavoitteellisesti ohjataan yrityksentoimintaa eri toiminnoissa ja eri tasoilla.

Toiminnanohjauksella ohjataan yrityksen työtä ja resursseja. Työn tulosten tuleeolla asiakkaan vaatimusten mukaisia ja valmistua asiakkaalle luvatussa ajassa.Työ voi liittyä yhtäältä selkeästi eroteltavien fyysisten tuotteiden ja/tai kompo-nenttien (tilausten) valmistamiseen, tai vaihtoehtoisesti monimutkaisempienkokonaisuuksien kuten laajojen toimitus- tai tuotekehitysprojektien läpiviemi-seen. Resurssien tehokas käyttö muodostaa perustan taloudellisesti kannattavalletoiminnalle. Yrityksen perusresurssi on työntekijä. Organisaatiossa työntekijätmuodostavat ohjausmielessä erilaisia resurssiyksiköitä, kuten ryhmiä, tiimejä jaosastoja. Myös koneet, tuotantotilat ja muut fyysiset puitteet ovat yrityksenresursseja.

42

Yrityksen (liike)toiminnan ohjaus voidaan jakaa kolmeen tasoon: strategiseenohjaukseen, kehitystoiminnan ohjaukseen ja operatiiviseen ohjaukseen. Strategi-sessa toiminnassa asetetaan tavoitteita, seurataan tuloksia ja suunnitellaan toi-menpiteitä. Kehitystoiminnalla pyritään luomaan edellytyksiä strategiassa ase-tettujen tavoitteiden saavuttamiseksi. Operatiivinen toiminta tuottaa yritykselletuloa. Sen ohjaus on yrityksen tärkeimpiä tehtäviä.

Toiminnanohjausta voidaan tarkastella eräänlaisena loogisena säätöpiirinä, jossavoidaan eritellä neljänlaisia tehtäviä: suunnittelu, toimenpano, seuranta ja säätö.Yhdessä nämä muodostavat ohjausmekanismin, jolla tuetaan tavoitteellistatoimintaa. Loogisen säätöpiirin malliin perustuva yritystoiminnan analyysi onrakenteeltaan selkeä ja siksi houkutteleva. Tiedämme kuitenkin, että toimintayrityksissä perustuu epätäydelliseen tietoon ja rajoitettuihin resursseihin, ja sitäkautta myös ”rajattuun logiikkaan” (mm. March ja Simon 1966). Tämä johtaaohjausmekanismiin, missä suunnitelma on abstrakti ja yksinkertaistettu kuvaustavoiteltavasta toiminnasta, toimeenpano on joukko tulkintoja suunnitelmasta, jaseuranta tarkoittaa tietojen keräämistä ja analysointia siinä mitassa, mihin re-surssit antavat myöten. Ongelmaksi muodostuu yhtäältä tiedonhallinta ja toi-saalta tavoitteiden hallinta organisaatiossa, jossa jokainen tekijä tuo omat näke-myksensä, toivomuksensa ja tavoitteensa mukaan ohjausprosessiin (March jaSimon 1966, Cyert ja March 1992).

2.2 Toiminnanohjaus pk-yrityksessä

Toiminta pienessä organisaatiossa hahmotetaan henkilöiden tai keskeisten ko-neiden suorittamien työvaiheiden kautta. Käytännössä strategisia tehtäviä eierotella kehitystoiminnan tai operatiivisista tehtävistä. Kaikki ovat tehtäviä, joitatehdään tarpeen vaatiessa. Pääpaino on operatiivisissa tehtävissä, koska nämätuottavat niitä lopputuloksia, joiden myynnistä yritys elää.

Pienessä organisaatiossa sama henkilö suorittaa tehtäviä monella tasolla ja mo-nen funktion alueelta. Esim. tuotetta kehitetään toimitusprojektien yhteydessä,tuotesuunnittelija ostaa materiaalia ja ohjaa tuotantoa, ja johtajat käärivät hihan-sa kun työkuorma tuotannossa nousee korkealle. Pienessä organisaatiossa tämäon luonteva tapa toimia, koska mikään yksittäinen funktio tai toiminnan taso eitavallisesti pysty kokonaan työllistämään työntekijää. Ja vaikka yrityksellä olisi-kin selkeä kuva työvaiheista, materiaalivirroistaan ja toimitusprosessin vaiheista,

43

niin kehittämistoiminta – esim. tuotekehitys tai toiminnankehitys – on tyypilli-sesti vähemmän systemaattista. Tällöin näiden prosessien vaatimat panokset jaeteneminen jäävät helposti erittelemättä ja toiminta kokonaisuutena ohjaamatta.

Toiminnan kasvaessa työntekijöille syntyy enemmän mahdollisuuksia erikoistua,mutta organisaation koon lisäksi myös monet muut tekijät vaikuttavat siihen,miten yritys rakentaa ja ohjaa toimintansa. Näitä ovat mm. tuote- ja palvelusor-timentti, asiakaskunta ja markkinat sekä yrityksen yhteistyöverkostot. Kaikkinämä vaikuttavat organisaation rakenteeseen ja sen keskeisiin toimintaproses-seihin. Myös yrityksen johtamistapa ja tekninen infrastruktuuri ovat tärkeitätoiminnan luonteeseen vaikuttavia tekijöitä.

Moni pieni valmistava organisaatio toimii varsinkin elinkaarensa alussa alihank-kijana. Tällöin keskitytään valmistamaan asiakkaan suunnittelemia ja tilaamiatuotteita. Yrityksen osaaminen liittyy valmistustehtäviin muiden toimintojenollessa vähemmän kehittyneitä. Toiminnan ohjaaminenkin keskittyy tuotannonoperatiivisen ohjaamiseen. Strateginen ohjaus on käytännössä rajattu töidenriittävyyden varmistamiseen ja potentiaalisten asiakkaiden kartoittamiseen.Erityisesti pienemmän kokoluokan pk-yrityksissä strategisen ajattelun taso onusein melko vaatimatonta. Toiminnassa korostuu dynamiikka ja nopeus, jolloinpitkäjänteistä toimintaa ei kovin paljoa suunnitella.

Alihankkijana toimiva yritys voi myös alkaa kehittää omia tuotteitaan ja brändi-ään (kuva 1). Tällöin täytyy panostaa tuotteiden suunnittelussa tarvittavien re-surssien ja osaamisen kehittämiseen. Alihankkijan tapauksessa on tyypillistä,että yritys elää lyhyemmän tai pitemmän ajan jonkinlaisessa siirtymävaiheessa,jossa toimitaan sekä alihankkijana että oman tuotteen tuottajana. Alussa kunuuden toiminnan volyymit ovat pieniä, alihankintaa ja oman tuotteen valmistustaei toiminnassa välttämättä erotella toisistaan, vaan samoja resursseja käytetäänmolempiin tehtäviin.

44

Alihankinta: valmistus

Alihankinta: valmistus + suun.

Oma tuote

Tuotelinjat

Kuva 1. Pk-yrityksen tuote- ja palvelukonseptit.

Ensimmäisestä omasta tuotteesta kehitetään uusia versioita ja kasvua tavoitel-taessa luodaan eri tarkoitukseen soveltuvia variaatioita. Tai sitten osaamistahyödynnetään aivan uusien tuotteiden kehittämiseen. Tällöin pk-yrityksen joutuupäättämään, hallitaanko kaikkia tuotteita samalla organisaatiolla vai erikoistuukoosa yrityksestä tietyn tuotteen tai tuoteperheen myyntiin ja tuottamiseen.

Mikäli tuotteiden tai palvelujen tuottaminen on luonteeltaan toistuvaa, voidaanhahmottaa selkeitä työrutiineja ja -vaiheita, materiaali- ja informaatiovirtojasekä toimintaprosesseja. Työtä voidaan ohjata ja seurata näiden vaiheiden kaut-ta. Toistuvuuteen vaikuttaa luonnollisesti erilaisten tuotteiden tai palvelujenmäärä suhteessa toiminnan kokonaisvolyymiin. Mikäli toistuvuus on pientä, eityövaiheita, materiaalivirtoja tai prosesseja voida hyödyntää resurssien allokoin-nissa. Tällöin resurssit tyypillisesti organisoidaan funktioiden perusteella. Näinmenetellään mm. pienissä alihankintayrityksissä.

Pk-yrityksen asiakasrajapinnan rakenne vaikuttaa myös toiminnan luonteeseen.Yrityksellä voi olla suurempi tai pienempi määrä asiakkaita. Joskus yritykselläon vain yksi keskeinen asiakas, joka ostaa lähes kaikki yrityksen tuotteet taipalvelut. Tällöin asiakasrajapinta on selkeä. Toisaalta keskeisen asiakkaan rin-nalla voi olla suuri määrä pienempiä asiakkaita, joiden yhteinen ostovolyymi onyritykselle merkittävä. Tässä tilanteessa asiakasrajapinnan epämääräisyys saattaavaikeuttaa selkeiden toiminnan linjausten tekoa sekä erikoistumista.

Organisaation koko vaikuttaa myös organisaation rakenteeseen ja sen ohjauk-seen. Hyvin pienessä organisaatiossa saatetaan toimia ilman virallista johtajaa,mutta yritystoimintaa harjoittavassa organisaatiossa joudutaan sen koosta riip-pumatta määrittelemään vastuuhenkilöitä. Tyypillisesti muutaman henkilön

45

yrityksessä ei ole muita esimiesasemassa olevia henkilöitä kuin toimitusjohtaja.Kun yrityksessä on 10–15 henkilöä, on yleensä jo syntynyt jonkinlaista toimin-nallista erikoistumista. Esimerkiksi myynnillä ja tuotannolla on perinteisestiomat erikoistuneet työntekijänsä ja toimihenkilönsä. Ja mitä suuremmaksi orga-nisaatio kasvaa, sitä enemmän erikoistumista tapahtuu – sekä toiminnallisestiettä johtamishierarkioiden suhteen. 50–60 henkilön teollisuusorganisaatiostalöytyy mm. sellaisia nimikkeitä kun toimitusjohtaja, myyntipäällikkö, tuotanto-päällikkö, työnjohtaja ja työntekijät. Tämänkin kokoisessa organisaatiossa samahenkilö saattaa edelleen suorittaa eri toimintojen tehtäviä.

Perinteisten linjaorganisaatioiden ja johtamishierarkioiden tilalle on viime vuo-sina noussut solu- ja tiimiorganisaatioita, joissa samaan tiimiin yhdistetäänmonen toiminnon osaajia. Tiimillä tai solulla on vapauksia päättää oman toimin-nan ohjauksesta ja kehittämisestä (Alasoini et al. 1995). Tiimi- ja soluorganisaa-tio perustuu erilaiseen johtamisfilosofiaan kuin perinteinen linjaorganisaatio.Tässä odotetaan, että tekijät itse kantavat vastuun oman toiminnan ohjauksesta jakehittämisestä. Tekijöillä on tähän parhaimmat mahdollisuudet, koska he tunte-vat oman toimintansa parhaiten. Linjaorganisaation tehtävä on tukea ja mahdol-listaa tiimien toimintaa. Ohjausmielessä tämä tarkoittaa esimerkiksi sitä, ettälinjaorganisaation jalostaa ja tuottaa tiimeille tietoa päätöksenteon tueksi.

Pk-yrityksen toiminnan luonteelle on siis ominaista, että erikoistumisen taso onalhainen. Käänteisesti tämä tarkoittaa, että tekijät ovat monitaitoisia ja pystyvätjoustavasti siirtymään tehtävästä toiseen tarpeen mukaan. Tässä on pienen orga-nisaation voima. Resurssien käyttöaste on korkea, ja erikoistumisesta johtuvatodotusajat ja iteraatiokierrokset puuttuvat. Toimintatavat ovat joustavia ja yksi-löllisiä. Toiminnan kasvaessa tehokkuutta haetaan mm. erikoistumalla ja mää-rittelemällä selkeitä prosesseja, tehtäviä ja rakenteita. Yksilöllisistä ratkaisuistapyritään organisaation yhteisiin toimintatapoihin. Tämä on muutosprosessi, jokavaatii osaamista ja resursseja, joita pienen yrityksen on usein hankittava proses-sin aikana. Koska kehitysresursseja on niukasti, kohdistetaan muutokset siihen,missä kehitystarpeet ovat suurimmat. Esimerkiksi toiminnanohjausjärjestelmänkäyttöönotto on pienelle yritykselle vaativa tehtävä, koska useimpien toiminnan-ohjausjärjestelmien rakenne heijastelee yrityksen toimintojen eriyttämiseen jahierarkkiseen johtamismalliin perustuvaa ajattelutapaa.

46

3. Toiminnanohjausjärjestelmät

Tässä kohdassa käsitellään toiminnanohjauksen järjestelmiä sekä niiden kehitys-näkymiä ja -trendejä. Aluksi esitetään katsaus yritystoiminnan ohjaukseen tar-koitettujen järjestelmien kehittymiseen aina materiaalinohjauksesta kokonais-valtaiseen toiminnanohjausjärjestelmään. Sen jälkeen esitellään lyhyesti toimin-nanohjausjärjestelmien toiminnallisuutta ja teknistä toteutusta. Lopuksi hahmo-tellaan toiminnanohjausjärjestelmien tulevaisuutta, verkoston toiminnanohjaustasekä esitellään ASP-konsepti.

3.1 Tietojärjestelmät toiminnanohjauksen tukena, historiallinen perspektiivi

ERP-järjestelmien (Enterprise Resource Planning) kehityksen voidaan katsoaalkaneen 1960-luvulla, jolloin varastonseuraan aloitettiin kehittämään ohjelmis-toja. Ohjelmistot olivat nykymittapuun mukaan arvioituna melko yksinkertaisiaja lähinnä in-house-käyttöön (yritykselle kehitettyjä, räätälöityjä järjestelmiä)tarkoitettuja. Ohjelmistokehityksestä vastasivat joko yritykset itse tai ohjelmis-tojen räätälöintiin erikoistuneet ohjelmistotalot. Järjestelmiä käytettiin lähinnävarastomäärien seurantaan (Ptak ja Schragenheim 2000).

Seuraavan sukupolven yritystoimintaa (nimenomaan tuotantoa) tukevien tieto-järjestelmien kehityksen voidaan katsoa alkaneen 1970-luvun alussa, jolloinalettiin kehittämään MRP-järjestelmiä (Materials Resource Planning). Ohjel-mistojen tarkoituksena oli tuottaa materiaalitarvelaskentoja varasto- ja hankin-tatoimintoja varten, eli ohjata ostotoimintaa sekä automatisoida tilausten teke-mistä mm. erilaisten hälytysten muodossa (ReOrder Point). MRP-ohjelmistojentoiminnallisuuteen kuului myös taloudellisen eräkoon määrittäminen tuotannon-suunnittelua varten. Kaiken kaikkiaan MRP-järjestelmät olivat melko kankeita jatoiminnallisesti vaatimattomia verrattuna nykypäivän kehittyneisiin ERP-järjestelmiin. 1970-luvun loppupuolella kaupallisten standardiohjelmistojenvalmistus alkoi lisääntyä. Kaikkia ohjelmistoja ei enää räätälöity pelkästään yhdenyrityksen käyttöön vaan ajatukseksi muodostui ohjelmistojen ”paketointi”.

1980-luvulla varaston- ja tuotannonhallintaan alettiin kehittelemään MRP II-konseptia, joka perustui aikaisempaan MRP-järjestelmään mutta sisälsi uusiatoimintoja mm. lattiatason toiminnanohjauksen sekä jakelunhallinnan osa-

47

alueilla. MRP II -ohjelmistojen kehittymistä ja levinneisyyttä lisäsi myös PC-koneiden yleistyminen ja kehittyminen.

1990-luvun alussa MRP II -ohjelmistoihin lisättiin entistä enemmän tuotannon-ohjaustason toiminnallisuutta. Lisäksi MRP-konseptien päälle alettiin liittäämuiden osa-alueiden ohjelmistoja, joiden kehittäminen oli tähän asti kulkenutmelko erillään. Tällaisia ohjelmistoteollisuuden osa-alueita olivat mm. projek-tinhallinnan-, taloushallinnon- sekä henkilöstöhallinnan osa-alueet. Näin pää-dyttiin nykyiseen ERP-konseptiin. Pääasiallisena ERP-kehitystyön lähtökohtanavoidaankin pitää MRP- ja MRP II -ohjelmistoja, mutta vastaavanlaista laajene-mista on tapahtunut myös päinvastaiseen suuntaan (taloushallinnasta tuotannon-ohjaukseen, vrt. SAP). Kuva 2 kuvaa, miten ohjelmistojen ominaisuudet jatuotesukupolvet liittyvät toisiinsa.

Toiminnallisuus

Järjestelmä ja aika

Räätälöityvarastonhallinta

1960–1970

Varaston-hallinta

MRP1970–1980

Kehittynytvaraston- jamateriaalin-

hallinta

Varaston- ja materiaalin-

hallinta,tarvelaskenta

MRP II1980–1990

ERP1990–2000

Toiminnan-ohjaus

ERP +Internet

E-liiketoiminta,verkoston

ohjaus

Kuva 2. Toiminnanohjausjärjestelmien kehityshistoria ja toiminnallisuudenkehittyminen.

48

1990-luvun loppupuolella toiminnanohjausjärjestelmien kehittymisen myötätoiminnanohjaukseen liitettiin myös ajatus sähköisestä kaupankäynnistä ja li-sääntyvästä tiedonsiirrosta yritysten tietojärjestelmien välillä. Yritystason tie-donsiirtoa on toki ollut aikaisemminkin (vrt. EDI) mutta uusien tiedonsiirtotek-niikoiden ja Internetin mahdollisuuksien myötä siirtokustannusten uskotaanpienenevän ja sovellusalueiden laajenevan. Tällä hetkellä puhutaankin verkos-tojen toiminnanohjauksesta ja sitä kautta toimintojen optimoinnista yritystenvälillä. Yritysten viimeaikainen, voimakas ja osittain myös strateginen verkos-toituminen tarjoaakin melkoisen kentän (ja haasteita) toiminnanohjausjärjestel-miä valmistaville ja integrointipalveluja tarjoaville yrityksille (Hyötyläinen2000, Ollus et al. 1998).

3.2 ERP-järjestelmä toiminnanohjauksessa

ERP-järjestelmät ovat viime vuosina yleistyneet sekä suurissa että pk-sektorinteollisuusyrityksissä. ERP-järjestelmän tarkoituksena on integroida eri yritys-toiminnan osa-alueita, joita ovat mm. toiminnan suunnittelu, valmistus, myynti-toiminnot, taloushallinto ja projektinhallinta (Laudon ja Laudon 2000, Ptak jaSchragenheim 2000, Shtub 1999). Viime vuosina kehitellyt toiminnanohjausjär-jestelmät ovat rakenteeltaan modulaarisia, ja näin ollen tietystä kokonaisuudestavastaa usein tietty toiminnallinen moduuli. Kuvassa 3 on eritelty SAP R/3:ntoiminnallisia moduuleja. SAP on tällä hetkellä maailman johtava toiminnanoh-jausjärjestelmien valmistaja.

ERP-järjestelmä

Valmistus

Jakelunhallinta

Varastonhallinta

Hankintatoiminta

Taloushallinta

Henkilöstöhallinto

Myyntitoiminnot

Asiakashallinta

Laadunvarmistus

”Shop-floor”

Kuva 3. ERP-järjestelmän (SAP R/3) toiminnallisia moduuleja.

49

Tämänhetkiset, yrityksissä käytössä olevat toiminnanohjausjärjestelmät perustu-vat pääsääntöisesti client-server -arkkitehtuuriin, jolloin yrityksessä on käytössäyritystason palvelin sekä tarvittava määrä työasemia järjestelmän käyttöä varten(Luoma et al. 1999). Modulaarisen toiminnanohjausjärjestelmän moduulit kom-munikoivat suoraan keskenään tai tekemällä päivityksiä yhteiseen ja keskitet-tyyn tietokantaan. ERP-järjestelmät on pääasiassa tarkoitettu yrityksen sisäisentoiminnan suunnitteluun ja hallintaan, mutta monissa järjestelmissä on myösEDI (Electronic Data Interchance) valmius yritystenvälistä tiedonsiirtoa varten.Nämä liittyvät lähinnä sähköisiin tilaus- ja laskutusrutiineihin.

4. Toiminnanohjausjärjestelmän soveltuvuus pk-yritysympäristöön

Toiminnanohjausjärjestelmien toiminnallisuudesta ja kehittymisestä ollaanmontaa eri mieltä. Viime aikoina monet eri tahot ja tutkimukset ovat arvostelleettoiminnanohjausjärjestelmien mammuttimaisuutta (Davenport 2000). Toimin-nanohjausjärjestelmät, niiden erilaiset moduulit ja raskaat, prosessimaiset toi-mintamallit voidaankin nähdä liian joustamattomina yritysten muuttuvaan toi-mintaan ja toimintaympäristöön. Tämä pätee erityisesti moniin pk-yrityksiin.Oman ongelmansa tuo mukanaan myös järjestelmien keskinäinen integrointi,joka nykyään on väistämätön kehitystrendi yritysten verkostoituessa (Laudon jaLaudon 2000, Hyötyläinen 2000). Tässä kohdassa hahmotellaan toiminnanoh-jausjärjestelmien tämänhetkistä soveltuvuutta erityisesti pk-yritysten tarpeisiin.Asiaa pohditaan sekä toiminta- että järjestelmälähtöisesti. Kappaleiden sisältöperustuu pitkälti kokemusperäiseen tietoon ja suurempien yritysten kokemuk-siin, sillä pk-kontekstissa ko. asioista on melko vähän tutkimustietoa (Iivari jaLyytinen 1999).

4.1 Toimintalähtöinen analyysi

Pk-yritysten toiminnan kannalta kriittiset kysymykset, jotka koskevat nykyistentoiminnanohjausjärjestelmien soveltuvuutta pk-yritysten toiminnanohjaukseen,voidaan jakaa neljään pääryhmään (Davenport 2000, Holopainen et al. 1999).Pääryhmät on kuvattu alla olevassa luettelossa.

Toiminnanohjausjärjestelmien joustamattomuus on keskeinen ongelma pk-yrityksen näkökulmasta. Toiminnanohjausjärjestelmät on tavallisesti rakennettuyritysten tyypillisiä toimintaprosesseja kuvaaviin prosessimalleihin perustuen.

50

Prosessimallinnuksen heikkoutena voidaan nähdä joustamattomuus ja mukautu-mattomuus muuttuvaan toimintaympäristöön. Muuttuva toimintaympäristö onsen sijaan tunnusomaista nimenomaan pk-yritysten toiminnalle. Yritystoiminnanlainalaisuuksia ja toimintaympäristön dynamiikkaa on vaikea mallintaa niin, ettäniiden pohjalta voitaisiin suunnitella dynaamiseen toimintaympäristöön soveltu-via ja kohtuu ponnistuksin konfiguroitavia tietojärjestelmiä. Joustamattomuudenseurauksena yritys joutuu usein mukautumaan tietojärjestelmän logiikkaan, eikänäin ollen voi toimia optimaalisella, oman ansaintalogiikkansa vaatimalla tavalla.

Toiminnanohjausjärjestelmien pitkä käyttöönottoprosessi voidaan nähdä toi-minnanohjausta ja uuteen järjestelmään mukautumista vaikeuttavana tekijänä.Tyypillisesti pk-yritysympäristössä järjestelmän ja suunnittelu- ja käyttöönotto-vaihe kestää noin vuoden (vaihteluväli on luonnollisesti suuri aina muutamastakuukaudesta useampaan vuoteen). Kalenteriajassa vuosi on pitkä jakso, ja senaikana usein myös yrityksen toiminta ja järjestelmälle asetetut toiveet ja vaati-mukset muuttuvat. Tämän seurauksena uusi järjestelmä voi olla ”vanha” jotuotantokäytön alkaessa. Ongelma koskettaa tietysti myös suuryrityksiä, joissamittava käyttöönottoprosessi vie tavallisesti vuosia.

Toiminnanohjausjärjestelmän hierarkkisuus voi myös aiheuttaa ylimääräisiäongelmia. Toiminnanohjausjärjestelmien mukanaan tuoma tiedon keskitettyhallinta ja tämän mahdollistama ”kontrollointi” voidaan nähdä yritystoimintaarasittavina tekijöinä. Tarkka kontrollointi ja raportointi voivat tuntua esimerkiksityöntekijöistä liialliselta valvonnalta, joka herkästi tulkitaan epäluottamuksenosoitukseksi. Tämä taas sotii nykyaikana korostettuja organisaation avoimuudenja vapauden periaatteita vastaan.

Organisaation osaaminen ja suhtautuminen tietojärjestelmähankkeisiin onkriittinen tekijä erityisesti järjestelmän hankinta- ja käyttöönottovaiheessa. Useinpk-yrityksissä tietojärjestelmäosaaminen on suhteellisen heikkoa. Tämä vai-keuttaa järjestelmien määrittelyä ja lisää epäonnistuneiden valintojen riskiä.Toisaalta järjestelmähankkeet mielletään usein korostetun tietoteknisiksi hank-keiksi, jolloin liiketoiminnan kehittäminen jää helposti vähemmälle (STO 1999).Lisäksi monissa yrityksissä järjestelmien mukanaan tuomiin mahdollisuuksiinsuhtaudutaan liiankin optimistisesti.

51

Pk-yritysten toiminnalliset piirteet ja monimuotoinen toiminta ovat haaste toi-minnanohjausjärjestelmille ja niiden toimittajille. Viime aikoina yritykset ovatinvestoineet järjestelmiin monista eri syistä, eivätkä nämä päätökset ole ainaolleet viisaita. Toiminnanohjausjärjestelmiä on usein hankittu miettimättä yri-tyksen todellisia tarpeita ja hankinnan moninaisia seurauksia. Hankinnan ajurinaon saattanut olla jokin yksittäinen ongelma, jonka ratkaisemiseksi olisi useinollut erilaisia vaihtoehtoja. Esimerkkejä tällaisista ongelmista ovat mm. Y2K(vuosi 2000) ja euro. Tämä on taas johtanut tilanteeseen, jossa yritykset eivät oletyytyväisiä järjestelmien tarjoamaan tukeen kokonaisuutena.

4.2 Järjestelmä- ja teknologialähtöinen analyysi

Toiminnanohjaus- ja tietojärjestelmien soveltuvuutta voidaan lähestyä toimin-nallisuuden ja organisatorisen näkökulman lisäksi myös järjestelmä- ja teknolo-gialähtöisesti. Tietojärjestelmät kehittyvät koko ajan, mutta erityisesti toimin-nanohjausjärjestelmiä on kritisoitu vanhanaikaisesta teknologiasta (Davenport2000). Tällä tarkoitetaan erityisesti modulaarisuutta ja client-server-arkkitehtuuria (Luoma et al. 1999). Toinen merkittävä ongelma on tietojärjes-telmien integrointi, jonka merkitys kasvaa yritysten verkostoituessa ja sähköisenliiketoiminnan muotojen lisääntyessä. Seuraavassa on purettu auki tarkemmallatasolla toiminnanohjausjärjestelmien soveltuvuutta ja mahdollisia ongelmakohtiapk-yritysympäristössä teknologia- ja järjestelmälähtöisesti.

Teknologinen kehitys voidaan nähdä sekä heikkoutena että mahdollisuutenamuuttuvassa toimintaympäristössä. Yhtäältä nopea teknologinen kehitys vai-keuttaa yritysten ja erityisesti pk-yritysten mahdollisuuksia pysyä kehityksenmukana. Uusien teknologioiden soveltaminen ja hyötykäyttö vaativat sekä tie-tämystä että resursseja (aikaa ja rahaa), jotka usein ovat kummatkin rajallisia pk-yrityksissä. Toisaalta uusi teknologia mahdollistaa uudenlaisia toimintamallejaja avaa yrityksille uusia markkinoita. Uusilla toimintamalleilla voidaan tarkoittaaesim. sähköistä kaupankäyntiä, toimintojen automatisointia (esim. laskutus) sekäerilaisia asiakkuudenhallinnan ratkaisuja (CRM = Customer Relationship Ma-nagement) (Laudon ja Laudon 2000, Luoma et al. 1999, Barnes 2000).

Järjestelmien integrointivaikeudet ja tietojärjestelmäarkkitehtuuri on yksimerkittävä tekijä yritystoiminnan muuttuvassa kentässä. Teknologioiden kehit-tyminen korostaa järjestelmien arkkitehtuurisuunnittelun merkitystä. Onnistunut

52

järjestelmäarkkitehtuuri muodostaa hyvät edellytykset tietojärjestelmien kehit-tämiselle, mm. uusien liityntöjen ja laajennusten tekemiselle. Näiden merkityskorostuu erityisesti tilanteessa, joissa yritysten verkostoitumista halutaan tukeatietoteknisin välinein. Muutos on pysyvä olotila sekä liiketoiminnan että tieto-tekniikan suhteen, ja tämä vaatii paljon myös yritysten tietojärjestelmäratkai-suilta. Nykyisten toiminnanohjausjärjestelmien ongelmana onkin toiminnallisenjoustamattomuuden lisäksi tekninen joustamattomuus ja järjestelmien integroin-tihaasteet. Uudessa taloudessa juuri edellä mainittujen asioiden merkitys koros-tuu entisestään, myös pk-yrityskentässä (Luoma et al. 1999, Tapscott 1996).

Tietoteknisillä välineillä on ollut merkittävä rooli yritystoiminnassa jo vuosi-kymmeniä. Pk-sektorilla eletään kuitenkin vielä kasvun aikakautta, ja uusiajärjestelmiä ja sovelluksia - kuten toiminnanohjausjärjestelmiä ja e-businessratkaisuja – otetaan käyttöön yhä pienemmissä yrityksissä. Kehityskulku koros-taa osaamisen ja tietämyksen hallinnan merkitystä erityisesti teknologisessamielessä. Yrityksissä osaajien määrä on vähäinen, ja nykyisessä yhteiskunnankehitystilanteessa osaajien saaminen pieniin yrityksiin on erityisen vaikeaa.Tämä voidaankin nähdä pk-yritysten keskeisenä tulevaisuuden haasteena.

5. Kokemuksia toiminnanohjausjärjestelmistä

Tähän kappaleeseen on kerätty yritysten kokemuksia toiminnanohjausjärjestel-mien käyttöönottoprosessista, tuotantokäytöstä ja käytön aikaisesta kehittämi-sestä. HANSKA-tutkimushankkeen puitteissa järjestettiin kysely suomalaisillepk-yrityksille koskien järjestelmien käyttöönottoa ja käyttöä (Tietoykkönen2000). Kyselyn otoskoko oli 120 suomalaista pk-yritystä, joiden henkilökunnanmäärä vaihteli muutamasta kymmenestä useaan sataan. Yleisesti ottaen monetyritykset ovat kokeneet toiminnanohjausjärjestelmien käyttöönotot suhteellisenhankalina. Lisäksi yritykset eivät ole kovin tyytyväisiä järjestelmien tarjoamaantukeen liiketoiminnalle. Monet yritykset olivat järjestelmiinsä kuitenkin suhteel-lisen tyytyväisiä kokonaisuutena. Seuraavassa esitellään mainitussa kyselyssäsekä muutamissa muissa tutkimuksissa saatuja tuloksia.

5.1 Kokemuksia toiminnanohjausjärjestelmien käyttöönotosta

Useat yritykset kokevat toiminnanohjausjärjestelmän käyttöönoton suhteellisenraskaana prosessina. Toiminnanohjausjärjestelmän hankkiminen ja käyttöönotto

53

koskettaa usein suurta osaa organisaation toiminnoista ja henkilöstöryhmiä. Pk-yritykselle tällainen menettelytapa ja henkilöstön laaja osallistuminen kehitys-hankkeisiin on usein uutta. Monille työntekijäryhmille ja yksittäisille työnteki-jöille myös tietokoneen käyttö on usein vierasta ja aiheuttaa näin ollen raskaitaoppimisprosesseja järjestelmään tutustuttaessa ja sitä käytettäessä.

Toiminnanohjausjärjestelmän vaatimusmäärittely ja sen kunnollinen organisointion onnistuneen toiminnanohjausjärjestelmän hankinnan perusedellytys (STO1999). Pk-yrityksille tietojärjestelmän vaatimusmäärittely ja järjestelmäprojektintavoitteiden asettaminen on vaikeaa. Tämä johtuu monestikin yrityksen ”sokeu-desta” omia toimintaprosessejaan kohtaan, mutta usein on kysymys myös pro-sessi- ja vaatimusmäärittelyosaamisen puutteesta. Epäonnistunut vaatimusmää-rittely johtaa usein tilanteeseen, jossa järjestelmä hankintaan enemmänkin arpa-pelillä kuin huolellisen suunnittelun kautta. Tällainen menettely vaikeuttaa myöstoimittajan työtä ja projektin toteuttamista.

Toiminnanohjausjärjestelmän implementointi ja räätälöinti riippuu pitkältikäyttöönotettavan järjestelmän rakenteesta ja laajuudesta. Implementointi voiolla hyvinkin kevyt prosessi tapauksissa, joissa yritys ottaa käyttöönsä ns. stan-dardipaketin. Standardipaketti perustuu ennalta määritettyyn tapaan toimia, jayrityskohtaiset muutokset tehdään pienimuotoisen parametroinnin kautta. Toi-sessa ääripäässä ovat ns. räätälöidyt järjestelmät jotka sovitetaan suoraan yrityk-sen toimintatapaan ja liiketoimintaprosesseihin. Tällaisen toiminnanohjausjärjes-telmän implementointi ja käyttöönotto on yleensä melko pitkäjänteistä puuhaa.

Projektin hallinta ja resurssointi on usein hankalaa, erityisestikin loppukäyttäjä-yrityksen puolelta. Uuden ja kokonaan integroidun tietojärjestelmän käyttöön-otto on monissa organisaatioissa uusi asia, ja siihen ei useinkaan osata suhtautualiiketoiminnan kehittämisprojektina. Sen sijaan hankkeet suunnitellaan ja resur-soidaan korostetun tietoteknisestä näkökulmasta (Holopainen et al. 1999). Puut-teet resurssoinnissa ja projektin hallinnassa voivat aiheuttaa epäselvyyksiä vas-tuualueista ja työtehtävistä toimittajan ja loppukäyttäjäyrityksen välillä.

Yrityksen ja toimittajan yhteistoiminta on jo luonteeltaankin monesti ongelmal-lista. Loppukäyttäjäyrityksen tavoitteena on saada parhaiten liiketoimintaansatukeva järjestelmä, kun taas toimittajayrityksen tavoitteena on kustannustehokastoimitusprojekti. Tämä voi johtaa tavoitteiden ja toteutuksen ristiriitaan eri osa-

54

puolten välillä. Usein loppukäyttäjäyritykseltä ja toimittajalta puuttuu myösyhteinen ”kieli”, mikä vaikeuttaa ajatusten vaihtoa ja yhteisen ”maailmankuvan”rakentamista.

Organisaation toimijat ovat uudessa tilanteessa, kun toimintaa suunnitellaan,ohjataan ja raportoidaan tietoteknisten välineiden avulla. Järjestelmän sisältä-mien tietojen oikeellisuus edellyttää, että sitä myös käytetään suunnitellullatavalla ja systemaattisesti. Tällaisen systemaattisuuden vaaliminen on useinvaikeaa pk-yrityksissä, joissa on tavallisesti yhtä monta toimintatapaa kuinavainhenkilöäkin. Tyypillisiä ongelmia ovat esimerkiksi virheelliset materiaali-kirjaukset, jotka vaikuttavat suoraan liiketoimintaprosessien seuraavien vaihei-den ohjaukseen ja seurantaan (mm. tuotannonohjaukseen ja taloushallintoon).Koska tietojärjestelmä on edelleen suhteellisen uusi asia monille työntekijöille,ongelmia on aiheuttanut mm. ”pelko” tietokoneita kohtaan. Tämän seurauksenamoni työasema ja sovellus onkin jäänyt käyttämättä.

5.2 Kokemuksia toiminnanohjausjärjestelmän käytöstä ja käytönaikaisestakehittämisestä

Tietojärjestelmän yrityksen liiketoiminnalle tarjoamalla tuella tarkoitetaan sitätapaa, jolla tietojärjestelmä käytännössä palvelee yrityksen toimintoja ja liike-toimintaprosesseja sekä tukee henkilökunnan työtä. Usein yritykset ovat tyyty-mättömiä toiminnanohjausjärjestelmiin, koska ne eivät jäykistävät yrityksen jasen henkilökunnan toimintaa. Tämä on ilmeistä erityisesti pk-sektorilla, jossamonimuotoiset toimintatavat ovat ennemminkin sääntö kuin poikkeus. Toimintasovitetaan usein kysyntään ja markkinoiden vaateisiin, ja nämä saattavat muut-tua hyvinkin nopeasti. Sama yritys saattaa esimerkiksi toimia osittain tilausoh-jatusti ja tehdä samanaikaisesti joitain tuotteita varastoon, valmistaa toisinaanasiakaskohtaisesti räätälöityjä erikoistuotteita ja toisinaan massatuotteita jaharjoittaa vieläpä projektitoimintaakin. Tällaisille, erityylisille toimintatavoilleon vaikea sovittaa yhtenäistä, kokonaisvaltaista tukea tarjoavaa järjestelmää.Tilanteen tekee hankalaksi se, että monet pk-yritykset päätyvät kustannussyistäpitkälle esikonfiguroituihin pakettiratkaisuihin.

Useat pk-yritykset ovat loppujen lopuksi kuitenkin suhteellisen tyytyväisiä itsejärjestelmän tuotantokäyttöön (Tietoykkönen 2000). Pk-yrityksissä opitaan useinajan myötä käyttämään ja hyödyntämään toiminnanohjausjärjestelmän poten-

55

tiaalia. Joissakin yrityksissä potentiaalin löytäminen on suhteellisen nopea toi-menpide, kun taas joissakin se on erittäin hidas prosessi (Hyötyläinen 1998).Yrityksille kertyy ajan myötä osaamista hallita omaa järjestelmäänsä mm. eri-laisten päivitysten kautta.

6. Toiminnanohjausjärjestelmien tulevaisuus

Toiminnanohjausjärjestelmien kehitys on ollut aina melkoisen vauhdikasta, jatälläkin hetkellä ohjelmistovalmistajat etsivät uusia ratkaisuja yritysten toimin-nanohjausten ongelmiin ja kehitystarpeisiin. Tässä kohdassa tutkitaan kahtamahdollista kehityssuuntaa: tietojärjestelmien integrointia ja yritysverkostontoiminnanohjausta sekä ASP-toimintamallia.

6.1 Järjestelmien integrointi ja verkoston toiminnanohjaus

Viime vuosina Internet on monella tavalla mullistanut liiketoiminnan kehitys-mahdollisuuksia. Internet jo sinällään tarjoaa mielenkiintoisen toimintaympäris-tön sekä monenlaisia mahdollisuuksia. Internet ja erilaiset internet-tekniikatvoidaan nähdä mahdollisuutena myös yritysten välisen toiminnanohjauksen jatoimintatapojen kehittämiseen. Yritysten välinen sähköinen liiketoiminta voi-daan tulkita uudeksi toimintamalliksi, vaikka kyse onkin periaatteessa siitä, ettätuttuja asioita tehdään uusilla välineillä (alussa kysymys oli lähinnä sähköisestäkaupankäynnistä, mutta viime aikoina järjestelmien toiminnallisuus ja sovellus-kohteet ovat laajenneet logistiikan ja tuotannon hallinnan suuntaan) (Järvelä jaTinnilä 2000, TT 2000). Tulevaisuudessa ERP-järjestelmien voidaan odottaamuodostavan eräänlaisen perusinfrastruktuurin, joka palvelee yrityksen sisäisiätoimintaprosesseja ja sisäisen tehokkuuden optimointia, kun taas uudet kehitys-suunnat keskittyvät ulkoisen tehokkuuden lisäämiseen yrityksen ja sen sidos-ryhmien välillä (Fakta 4/2000). Kuva 4 kuvaa toiminnanohjauksen kehiä sisäisenja ulkoisen tehokkuuden suhteen.

56

Logistiikka Taloushallinto

Tuotanto

Johto

Henkilöstö

AsiakkaatToimittajat

Perinteinen ERP-järjestelmä

”Extended ERP”

Kuva 4. Perinteinen ERP-ajattelu suhteutettuna järjestelmien integrointiin (Mu-kailtu lähteestä Fakta 4/2000).

Informaatioteknologian ja välineiden viimeaikainen kehitys mahdollistaa yri-tystoiminnan tehostamisen ja kehittämisen monin eri tavoin. Aikaisemmin tie-totekniikka ja siihen liittyvät sovellukset on nähty enemmänkin toteuttajina kuinmahdollistajina. Tällä hetkellä tilanne on hiukan muuttunut, sillä kehittynytinformaatioteknologia mahdollistaa yrityksille uudenlaisia toimintamalleja jasitä kautta myös uudenlaisia palvelukonsepteja. Uudet palvelukonseptit voivatpitää sisällään mm. logistiikkaratkaisuja, sujuvampia ja nopeampia tilauskäy-täntöjä, reaaliaikaisen tuotanto- ja toimitustilanteen seurannan sekä tehostuneentuotetiedonhallinnan.

Yksi merkittävä tekijä, jonka avulla voidaan tehostaa verkostojen ja toimitus-ketjujen toimintaa, on toiminnanohjauksen ja toimintaprosessien verkostonlaa-juinen integrointi. Yrityksen ovat viimevuosina investoineet merkittäviä summiasisäisten prosessien ja toimintatapojen kehittämiseen ERP-järjestelmien avulla.Tämä muodostaa hyvän pohjan ja kehitysalustan myös toimitusketjujen ja ver-kostojen toiminnanohjauksen kehittämiselle. Yritysten välinen toiminnanohjaustarkoittaa käytännössä entistä tehokkaampaa ja tarkempaa tiedonvaihtoa esim.toiminnanohjausjärjestelmien välillä. Tällöin voidaankin puhua sähköisestäbusiness to business -liiketoiminnasta. Viime vuosina sähköisestä liiketoimin-nasta puhuttaessa on useimmiten viitattu yrityksen ja loppuasiakkaan väliseen

57

kaupankäyntiin (mm. Amazon verkkokirjakauppa), mutta todellinen potentiaalion ennusteiden mukaan erityisesti business to business puolella. Kuva 5 havain-nollistaa tilannetta Forrester Researchin ennusteiden mukaan.

Business trade outweights consumer trade

300,000

600,000

900,000

1,200,000

1,500,000

200420032002200120001999

Mill

ions

of $

US

Kuva 5. Sähköisen kaupankäynnin ennustettu kasvu. Alaosa kuvaa ns. businessto business -toiminnan kasvua (Torris 1999).

Sähköinen liiketoiminta tarkoittaa entistä tehokkaampaa tiedonsiirtoa yritystenvälillä, joka mahdollistaa esim. ennusteiden ja resurssien läpinäkyvyyden toi-mitusketjussa tai yritysverkostossa. Tämä tuo mukanaan entistä paremman poh-jan tuotannon ja toiminnan suunnittelulle. Sähköinen tiedonsiirto yritysten tieto-järjestelmien välillä mahdollistuu myös pienempien yritysten välillä, sillä tie-donsiirtokustannukset laskevat (vrt. EDI) ja tekniikat kehittyvät koko ajan (vrt.XML). Sähköisen yritysten välisen tiedonsiirron kautta voidaan myös karsiamanuaalisia toimenpiteitä sekä liittää mukaan toimintaketjuun sähköisesti useitaosapuolia (esim. kuljetuspalveluja tarjoavat toimijat). Näin ollen tulevaisuudessavoidaankin puhua enemmänkin palvelukonsepteista kuin yksittäisistä tuotteista.Keskeisen haaste on järjestelmien monimutkaistuminen ja teknologioiden jatku-va kehitys, mistä johtuen integroitujen järjestelmien kehitys, käyttöönotto jaylläpito muodostuvat yhä enemmän erityisosaamista vaativiksi toiminnoiksi.

58

Edellä kuvatun kehityssuunnan luomat mahdollisuudet ovat kuitenkin erittäinvarteenotettavia ja tärkeitä erityisesti nopeasti muuttuvilla toimialoilla kuteninformaatioteknologia ja elektroniikka. Dynaamisilla toimialoilla tuotesukupol-vet ovat lyhyitä. Tehokas toiminta ja tuotetiedon hallinta ovat tekijöitä, jotkatakaavat kilpailukyvyn. Nopeasti muuttuvilla aloilla informaatioteknologiaa onhyödynnetty jo pitkään, ja usein impulssi teknologian kehittämiseen ja käyttöön-ottoon tulee asiakasrajapinnasta. Asiakkaat vaativat kehittyneitä järjestelmiä jasähköistä tiedonsiirtoa. Esim. elektroniikka-alalla merkittävät asiakkaat ovatglobaaleja toimijoita, jotka toimivat kehittynein välinein. Toimialalla kilpailumarkkinoista on kovaa ja näin ollen erilaisten lisäarvopalveluiden merkityskilpailutekijöinä korostuu.

6.2 ASP-toimintamalli

Application Service Provider (ASP) on yritys, joka tarjoaa asiakkaidensa käyt-töön tietotekniikka- ja ohjelmistopalveluja vuokrausperiaatteella. Asiakas mak-saa palveluista käytön mukaan. Palvelut sisältävät yleensä järjestelmähallinnan,ohjelmistot, päivitykset ja käytön tuen.

International Data Corporation (IDC 1999) on määritellyt ASP:n ominaisuuksiaseuraavasti:

− Sovelluskeskeisyys. ASP ylläpitää kytkentä- ja hallintapalveluja kaupalli-sesti saatavilla oleviin sovellusohjelmistoihin.

− Myydään pääsyoikeutta sovelluksiin. ASP tarjoaa asiakkaille pääsyn uusiinsovelluksiin ilman suuria etupainotteisia kustannuksia (ohjelmistolisenssit,palvelinkoneet, ihmiset ja muut resurssit). Asiakas maksaa käyttömääränsämukaisesti.

− Keskitetty hallinta. Asiakkaat kytkeytyvät ASP:n keskitettyihin palveluihintietoverkkojen (Internet) välityksellä.

− Yksi monelle -palvelu. ASP tarjoaa yhdessä partneriensa kanssa standar-doituja, hyvin vähän räätälöitäviä palveluita, joita monet yritykset voivatkäyttää. Perinteinen tietojärjestelmien ulkoistaminen on toiminut yksi yh-delle -periaatteella.

59

− Vastaa toimituksesta. ASP toimii yleensä yhdessä useiden partnereidenkanssa. Ongelmatilanteissa ASP kuitenkin vastaa loppuasiakkaille palveluntoimivuudesta.

ASP-toimintamallissa erotetaan yleensä kuvan 6 mukaiset toimijat (perusmalli).ASP-yrityksen tehtävänä on laajojen asiakasjoukkojen kytkeminen palveluihin-sa, joiden perustana on eri ohjelmistotoimittajien ohjelmat. ASP-yrityksen jaohjelmistotoimittajien välillä on yleensä tiivis partnerisuhde.

Teknologia- jaohjelmisto-toimittajat Application Service Providers Loppukäyttäjät

ASP perusmalli

Kuva 6. ASP perusmalli (Sonera Juxto -esittelykalvot 13.6.2000).

ASP-malli voidaan nähdä yhtenä ratkaisumallina tietojärjestelmien ulkoistami-seen. Tietojärjestelmien ulkoistaminen ei ole uusi asia. Jo 1970-luvulla keskitet-tiin järjestelmien ylläpitoa palveluyrityksiin. Tällöin kyseessä olivat kuitenkinpääasiassa asiakaskohtaisesti räätälöidyt järjestelmät ja sovellukset, joka siirret-tiin ulkopuolisen palveluyrityksen hoidettavaksi. Nykyisessä ASP-mallissakeskeistä on standardoitujen ratkaisujen tarjoaminen laajalle asiakaskunnallekevyesti toteutettavalla räätälöinnillä. Tässäkin tosin räätälöinnin taso vaihteleerunsaasti tarjottavasta ohjelmistosta riippuen.

ASP-mallissa kyse ei ole välttämättä olemassa olevien järjestelmien ulkoistami-sesta, vaan ainakin palvelun tarjoajien tavoitteena on usein mahdollistaa laajem-

60

pi käyttäjäkunta sovelluksilleen. Yhä useammat yritykset voivat ottaa sovelluk-sia taloudellisesti käyttöön, koska tavanomaisen järjestelmäprojektin etukäteenmaksettavien kustannusten sijasta yritykset maksavat järjestelmistä käyttömää-ränsä mukaisesti.

Soneran ASP- ja ulkoistamispalveluihin erikoistunut tytäryhtiö Sonerajuxtonäkee ASP-mallin keskeisenä kehityssuuntana jatkossa langattoman ASP:n(Wireless ASP) (kuva 7). Tietoliikenneteknologioiden kehittyessä yhä useampiasovelluksia voidaan käyttää langattomien päätelaitteiden avulla paikasta riippu-matta.

IT servicesIT services•• customer-specific apps customer-specific apps

•• SW licensing SW licensing•• IT outsourcing IT outsourcing

Net computingNet computing•• fixed access fixed access•• net net sourcing sourcing•• apps rental apps rental

Wireless ASPWireless ASP•• fixed & wireless access fixed & wireless access

•• security security •• availability availability1970-951970-951970-95

1990-20001990-20001990-2000

2000 ---> 2000 ---> 2000 ---> ASP:n kehitys

Kuva 7. ASP:n kehityskaari Soneran mukaan (Sonera Juxto -esittelykalvot13.6.2000).

Monet toiminnanohjausjärjestelmiä tarjoavat yritykset näkevät ASP-palvelunkautta tarjottavan toiminnanohjauspalvelun yhtenä kehitystrendinä. ASP:n kauttatarjottava toiminnanohjauspalvelu voi helpottaa erilaisten järjestelmien ylläpitoaja integrointia, mutta tuo mukanaan monenlaisia ongelmia. Eräänä keskeisenäkysymyksenä onkin se, että haluavatko yrityksen luovuttaa oman ydinosaami-sensa, eli toimintaprosessit ja niiden ohjauksen kolmannen osapuolen haltuun.Lisäksi mukaan tulee mahdollisesti muitakin toimijoita, jolloin toimintaympä-ristö monimutkaistuu. Toisaalta Internetin luotettavuus on vielä suhteellisen

61

kyseenalainen, jolloin esim. verkkokatkot voivat aiheuttaa ongelmia yrityksentoiminnanohjauksessa.

7. Yhteenveto

Artikkelin tarkoituksena oli hahmottaa pk-yrityksen monimuotoista toimintaa jatoiminnanohjausta sekä luoda katsaus toiminnanohjausjärjestelmiin ja niidenkehitysnäkymiin. Lisäksi artikkelissa käsiteltiin perinteisen toiminnanohjausjär-jestelmän sopivuutta pk-yrityksen toiminnanohjauksen välineeksi. Edellisiinpohjautuen artikkelissa esitettiin myös pk-yritysten kokemuksia toiminnanoh-jausjärjestelmien käyttöönotosta ja käytöstä.

Pk-yrityksen toiminnanohjauksen keskeisenä hankaluutena on yleensä moni-muotoinen toiminta, jota yritys harjoittaa (mm. projektitoiminta, sarjatuotantosekä yksittäiset alihankintapalvelut). Tämä muodostaa myös haasteen toimin-nanohjausjärjestelmien kehittämiselle. Perinteisen ajattelun mukaan toiminnan-ohjausjärjestelmät on pääsääntöisesti suunniteltu vastaamaan tiettyä toimintata-paa. Tämän vuoksi monilla pk-yrityksillä on ollut ongelmia ohjata toimintaansakokonaisvaltaisesti. Lisäksi toiminnanohjausjärjestelmien logiikka ja toiminta onusein peräisin suurten yritysten toimintatavoista ja liiketoimintaprosesseista,jolloin parasta yhteensopivuutta on vaikea saavuttaa. Monissa pk-yrityksissämyös toiminnanohjausjärjestelmien käyttöönotto on koettu melko raskaaksi.Tähän on useita syitä, joita ovat mm. kommunikointivaikeudet loppukäyttäjä-yrityksen ja järjestelmätoimittajan välillä, puutteellinen tietojärjestelmän vaati-musmäärittely, projektin hallinnan ongelmat sekä riittämättömät resurssit.

Toiminnanohjausjärjestelmät kehittyvät koko ajan. Kehitykselle toiminnallistapohjaa luovat yritysten verkostoituminen ja tarve sähköiseen tiedonsiirtoon. Tätäkautta myös toiminnanohjausjärjestelmät ja niiden käyttöönotto monimutkaistu-vat, jolloin mm. vaatimusmäärittelyn merkitys korostuu. Ongelmia verkostontoiminnanohjaukselle ja järjestelmien integroinnille aiheuttavat monimuotoisettekniset ratkaisut ja tiedonsiirtostandardit. Yhtenä merkittävänä kehitystrendinävoidaan tunnistaa ASP-palvelutarjonnan kehittyminen. Nähtäväksi jää kyseisenajattelun sopivuus pk-yritysten toiminnanohjaukseen.

Tulevaisuuden toiminnanohjausjärjestelmiä kehitettäessä keskeisessä roolissatulisi olla pk-sektorin suhteen juuri yritysten monimuotoinen toiminta ja toisaalta

62

yritysten verkostoprosessit. Huomiota tulisi myös kiinnittää järjestelmien vaati-musmäärittelyyn järjestelmää valittaessa ja käyttöönotettaessa. Mielenkiintoisentutkimus- ja kehityskysymyksen muodostaa toiminnanohjausjärjestelmien käyt-töönottomalli yritysverkostoissa ja ASP-palveluissa.

Lähdeluettelo

Alasoini, T., Hyötyläinen, R., Klemola, S., Seppälä, P., Toikka, K. & Kiviniitty, J.1995. Verkostosolu – uusi näkökulma solutuotantoon. Tampere: Metalliteollisuu-den Kustannus Oy.

Barnes, J. G. 2000. Secrets of Customer Realtionship Management: It’s Allabout How You Make Them Feel. New York: McGraw-Hill. 317 s. ISBN0-07-136253-3.

Cyert, R.M. & March, J.G. 1992. A Behavioral Theory of the Firm. SecondEdition. Massachusets: Blackwell Publishers.

Davenport, T. H. 2000. Mission Critical – Realizing the Promise of EnterpriseSystems. Boston: Harvard Business School Press. 335 s. ISBN 0-87584-906-7.

Fakta 4/2000. Kohti seuraavaa vaihetta – Toiminnanohjaus (Fakta Bonus).

Holopainen, S., Lillrank, P. & Paavola, T. 1999. Tietotekniikan linkki liiketoi-mintaan. Keuruu: Kustannusosakeyhtiö Otava. 183 s. ISBN 951-1-16510-0.

Hyötyläinen, R. 1998. Implementation of Technical Chance as OrganisationalProblem-Solving Process. Espoo: VTT Publications 337. 238 s. + liitt. 12 s.ISBN 951-38-5216-4.

Hyötyläinen, R. 2000. Development Mechanisms of Strategic Enterprise Net-works – Learning and Innovation in Networks. Espoo: VTT Publications 417.142 s. ISBN 951-38-5575-9.

International Data Corporation IDC 1999. The ASPs’ Impact on the IT Industry:An IDC-Wide Opinion. Bulletin #W20323. September 1999.

63

Iivari, J. & Lyytinen, K. 1999. Research on Information Systems Development inScandinavia. Unity in Plurality. In: Currie, W. L. & Galliers, B. (Eds.), RethinkingManagement Information Systems. Oxford: Oxford University Press. S. 57–102.

Järvelä, P. & Tinnilä M. 2000. Elektronisesta kaupankäynnistä eLiiketoimintaan.Digitaalisen median raportti 01/00. Tekes.

Kuitunen, K., Räsänen, P., Mikkola, M. & Kuivanen, R. 1999. Kehittyvä yritys-verkosto – Toimittajaverkostot kilpailukyvyn ja osaamisen lähteenä. Espoo:VTT Tiedotteita 1976. 148 s. ISBN 951-38-5469-8.

Laudon, K. & Laudon, J. 2000. Sixth Edition. Management Information Systems– Organization and Theory

Luoma, J., Muhonen, T. & Huomo, T. 1999. Uudistuva tietotekniikka-arkki-tehtuuri. Helsinki: HM&V Research Oy. 296 s. ISBN 951-98059-2-3.

March, J.G. & Simon, H.A. 1966. Organizations. USA: John Wiley & Sons.

Mintzberg, H. 1994. The Rise and Fall of Strategic Planning. New York:Prentice Hall. 484 s. ISBN 0-13-781824-6.

Ollus, M., Ranta, J. & Ylä-Anttila, P. (Eds.). 1998. Yritysverkostot – kilpailuatiedolla, nopeudella ja joustavuudella. Vantaa: Sitra. 133 s. ISBN 951-628-281-4.

Ptak, C. A. & Schragenheim, E. 2000. ERP Tools, Techniques and Applicationsfor Integrating the Supply Chain. CRC Press – St. Lucie Press. 456 s. ISBN157-4442-708.

Shtub, A. 1999. Enterprise Resource Planning (ERP) – The Dynamics of Opera-tions Management. Kluwer Academic Publishers. 148 s. ISBN 0-7923-8438-5.

STO. 1999. Toiminnanohjausohjelmiston hankinta ja markkinoiden nykytilanne.STO-työryhmäraportti. Suomen Tuotannonohjausyhdistys ry.

64

Sääksjärvi, M. 1991. Outsourcing: tietohallinnon tehokkuus ja palvelevuuspalvelujen ulkoistamisen valossa: case-tutkimus seitsemässä suuressa suomalai-sessa liiketoimintayksikössä. Helsinki: Helsingin kauppakorkeakoulun julkaisu-ja, D 147. 66 s. ISBN 951-702-016-3.

Tapscott, D. 1996. The Digital Economy – Promise and Peril in the Age ofNetworked Intelligence. New York: McGraw-Hill. 342 s. ISBN 0-07-063342-8.

Tietoykkönen Oy (Research Information Center). 2000. Toiminnanohjausjärjes-telmät-kysely / HANSKA-tutkimushanke.

Torris, T. 1999. European Internet Commerce. Forrester Research. Presentationon the IST Conference in Helsinki on November 24, 1999.

TT. 2000. Tehoa tietoverkoista, elektroninen liiketoiminta pkt-teollisuudessa jakoko teollisuudessa. Teollisuuden ja Työnantajien Keskusliiton julkaisu.

Sonera Juxto -esittelykalvot 13.6.2000.http://www.sonerajuxto.com/finnish/index.html

65

III Toiminnan muutos ja työssä oppiminentietojärjestelmähankkeissa

Inka Reijonen, Teemu Reiman, Merja AirolaVTT Automaatio

1. Johdanto

Tässä artikkelissa toiminnanohjausjärjestelmän käyttöönottoa ja käytön aikaistakehittämistä pk-yrityskontekstissa lähestytään käyttäytymistieteellisestä näkö-kulmasta. Toiminnanohjausjärjestelmähanke nähdään organisaation oppimispro-sessina, jossa painottuvat sosiaaliset muutosprosessit. Artikkeli rakentuu seuraa-vasti. Johdannossa esitetään lyhyt johdatus jälkiteollisen yhteiskunnan kehitys-suuntiin, pohjustus toiminnanohjausjärjestelmän (ERP) yhä kasvavasta merki-tyksestä yrityksille sekä järjestelmähankkeisiin liittyvästä problematiikastatarkastelun kohteena olevalla pk-sektorilla. Kohdassa 2 tarkastellaan kolmenorganisatorisen oppimisen näkökulman kautta dynaamisen liiketoimintaympä-ristön aikaansaamia muutospaineita ja toisaalta uusia mahdollisuuksia työtoi-minnan kehittämiseksi ja työssä oppimisen edistämiseksi. Kohdassa 2.4 esitetäänko. näkökulmien herättämiä ajatuksia ja kritiikkiä. Kohdassa 3 kuvaillaan tieto-järjestelmähankkeisiin liittyvää problematiikkaa organisatorisen oppimisennäkökulmista. Lisäksi esitetään joitain pk-yrityksille soveltuvia kehitysideoita,menettelyjä ja työkaluja, joiden avulla tavoitettaisiin entistä paremmin yksilön jaryhmän näkökulmat tietojärjestelmähankkeissa.

1.1 Jälkiteollisen yhteiskunnan kehityssuuntia

Monimutkaisuus, epävarmuus ja ennustamattomuus ovat jälkiteollista yhteis-kuntaa kuvaavia tunnuspiirteitä. Globaalien markkinoiden muutokset heijastuvatyhä voimakkaammin pk-sektorin yritystenkin toimintaan mm. suurten asiakkai-den tai kansainvälisten yhteistyökumppaneiden globaalien markkinoiden kautta.Markkinoiden muutokset sekä tuotanto- ja informaatioteknologioiden kehitysedellyttävät ja toisaalta myös mahdollistavat yhä tehokkaampia ja markkinoidenmuuttuviin vaatimuksiin joustavasti reagoivia tuotantoprosesseja sekä markki-nointi- ja myyntikanavia. Yritysten on keskityttävä ydinosaamiseensa ja ydin-

66

prosessiensa kehittämiseen, ja samalla luomaan jatkuvasti uusia tuotteita sekähankkimaan uusia asiakas- ja kumppanuussuhteita.

Niinikään toiminnan tehokkuutta ja joustavuutta on haettu erilaisten solutuotan-toja tiimiorganisaatioratkaisujen kautta sekä verkostoyhteistyötä kehittämällä.Nämä muutokset ovat puolestaan johtaneet uudenlaisiin kvalifikaatiovaatimuk-siin, kuten monitaitoisuuden, itseohjautuvuuden, vastuullisuuden, yhteistyötai-tojen kasvavaan tarpeeseen sekä suunnittelu- ja kehittämistoiminnan yleistymi-seen organisaatiotasosta riippumatta (Kasvio 1994, s. 20).

Jälkiteollisessa yhteiskunnassa kilpailu perustuu tietoja osaamisperusteiselletaloudelliselle kasvulle ja sitä tukeville rekrytointi- ja henkilöstön kehittämis-strategioille. Tämä ilmenee mm. tietoja asiantuntijatyön jatkuvana kasvuna jasitä tukevan teknologian mahdollisimman monipuolisena hyödyntämisenä sekäyrityksen ydinosaamiseen panostamisena. Tiedon luomisesta, hankkimisesta,käsittelystä ja levittämisestä on tullut yhä hallitsevampi rooli työtoiminnassa.Näin ollen työ muuttuu paljolti käsityöstä ajattelutyöksi, eli työn luonne ja sitämyötä työssä vaadittavat päättely- ja päätöksentekoprosessit muuttuvat. Tämäasettaa työntekijöille uusia kvalifikaatiovaatimuksia. Päivittäiset selviytymis-strategiat ja -keinot on ratkaistava organisaatiokohtaisesti, jolloin välittöminävaikuttimina ovat yritysten strategiat, johtamisjärjestelmät ja -kulttuuri sekähenkilöstö itse. (Warhurst ja Thompson 1998, s. 1–24; Järvinen et al. 2000, s.37–58 ja 72–75.)

Myös perinteiset hierarkkiset organisaatiorakenteet ja niihin perustuva käsky- jaarvovalta menettävät vähitellen merkitystään. Vertikaalinen työnjako on kor-vautumassa horisontaalisella, eli organisaation eri toimintojen ja ammatillistentyöryhmien vaakasuoralla yhteistoiminnalla – myös yli organisaatiorajojen.Samalla johtamisen luonne ja painopiste siirtyy työnjohdollisesta roolista ”in-formaatiota ja vastuuta jakavaan sekä monensuuntaista kommunikaatiota tuke-vaan”. (Warhurst ja Thompson 1998, s. 1–24; Järvinen et al. 2000, s. 37–58.)

Kriittisemmät pyrkivät kiinnittämään huomion kiihkeän kasvun ja tehokkuus-ajattelun varjopuoliin, kuten hyperfordismiin, stressillä johtamiseen, henkilöstönäärimmäisiin joustovaateisiin (Järvinen et al. 2000, s. 37–44) sekä teknologianosaamista ja työn mielekkyyttä köyhdyttäviin seuraamuksiin. Esimerkiksi tuo-tantoympäristössä vastuun ja autonomian lisääntyminen saattaa olla näennäistä

67

tai ainakaan niiden siirtyminen organisaatiossa alaspäin ei suinkaan vähennäkontrollin tarvetta ja määrää. Tietojärjestelmien leviäminen kaikille liike- jatuotantotoiminnan alueille ja tasoille onkin tehnyt prosesseista läpinäkyviä, mikämahdollistaa prosessien ja niihin sisältyvien toimintojen laaja-alaisen, jatkuvanja siten hyvin tehokkaan valvonnan ja ohjauksen. Informaatioteknologian seu-rauksena yksilön vuorovaikutus työympäristönsä kanssa muuttuu välilliseksi jaentistä käsitteellisemmäksi (ks. Zuboff 1988). Näin ollen kontrolli ja ohjaus ovatvain muuttaneet muotoaan; automaatio- ja informaatiojärjestelmät tekevät pro-sesseista ja siten niitä suorittavista ihmisistä helpommin ja tehokkaammin kont-rolloitavia (Vrt. Zuboff 1988; Järvinen et al. 2000, s. 50).

Tutkimuksissa (Leppänen 1999, s. 56–60) onkin havaittu stressin ja uupumusoi-reilun lisääntyneen toimihenkilötasolla, mikä vaikuttaa olevan yhteydessä liike-toiminta-ympäristön edellyttämiin monensuuntaisiin toiminnan kehitystarpeisiinja muuttuviin ammattitaitovaatimuksiin. Toimihenkilötehtävissä työskentelevätkokevat työnsä muuttuneen liian raskaaksi ja vaativaksi. Tietotekniikan myötärutiinityöt ovat vähentyneet, mikä on merkinnyt suunnittelu- ja päätöksenteko-prosessien lisääntymistä ja siten työtehtävien sekä niissä vaadittavan tietämyk-sen ja prosessien hallinnan abstraktiuden kasvua. Lisäksi toimihenkilöresurssiensupistukset ja työtahdin kiristyminen ilmenevät lisääntyvänä työmääränä. Tämäyhdistettynä epävakaisiin ja muuttuviin olosuhteisiin ja muutosten aiheuttamiinjousto- ja oppimisvaateisiin saattaa ajaa toimihenkilöt suorituskykynsä äärira-joille. (Leppänen 1999, s. 56–60.) Toisaalta toisena informaatioteknologianaiheuttamana kehitystrendinä on tutkimuksin osoitettu toimistotyön muuttumi-nen yksitoikkoisemmaksi, standardoidummaksi ja osaamisvaatimuksiltaan vä-häisemmäksi (Zuboff 1988).

1.2 Toiminnanohjausjärjestelmien merkitys pk-yrityksille

Pk-yritysten kilpailukyky yhä kansainvälistyvillä ja nopeasti muuttuvilla mark-kinoilla on riippuvainen siitä, kuinka nopeasti ne pystyvät tunnistamaan liike-toiminta-ympäristössään ilmenevät osittain ristiriitaiset muutospaineet ja kehi-tyssuunnat sekä löytämään niihin omaa liiketoimintaansa hyödyttävät ja kehittä-vät selviytymiskeinot ja innovatiiviset ratkaisut. Samaa valppautta ja muutos-valmiutta edellytetään yhä enenevässä määrin myös henkilöstöltä, kultakinyksittäiseltä työn tekijältä.

68

Organisaatioiden kehittämistoiminnan tyypillisenä epäkohtana on turvautuminensenhetkisiin trendeihin ja pikaratkaisuihin pohtimatta tarkemmin uudistustenasettamien vaatimusten ja organisaation nykyisten menettelytapojen ja rakentei-den yhteensopivuutta. Kenties konkreettisimmin tämä tulee esille yritysten tek-nologisissa investoinneissa, esimerkiksi kone- ja laitekantaa tai tietojärjestelmiäuusittaessa. Hankintojen suunnitteluun ja selvitystyöhön (vaatimusmäärittelytyms.) käytetty aika ja muut resurssit jäävät lähes poikkeuksetta liian vähäisiksi.Teknologisia uudistuksia, kuten tässä toiminnanohjausjärjestelmän käyttöönot-toa, tulee kuitenkin tarkastella laajana ja monitahoisena koko organisaatiota jasen toimintatapoja koskevana uudistuksena.

Tietojärjestelmähankkeita ja yritysten tietohallintoa käsittelevässä kirjallisuudes-sa on jäsennetty seikkaperäisesti tietojärjestelmähankkeen läpivientiin liittyväämonitahoista problematiikkaa ensisijaisesti käyttäjäorganisaation näkökulmasta.Kirjallisuudessa painottuvat liike- ja tuotantotaloudelliset sekä prosessi- ja tek-nologiakeskeiset näkökulmat. (ks. Kempis ja Ringbeck 1999; Holopainen et al.1999 jne.) Toisaalta yritysten tietojärjestelmähankkeita on tarkasteltu verrattainlaajalti myös organisatorisen muutoksen näkökulmasta. Tällöin painotetaannäkemystä hankkeen monitahoisuudesta usein koko organisaatiota koskettavanauudistuksena, organisatoristen muutosten monimutkaisuutta ja hitautta sekäkäyttäjien aktivoimisen ja toimintatapojen kehittämisen merkitystä eräänä kriitti-senä hankkeen onnistumisen tekijänä. (ks. esim. Keen 1981; Sachs 1995; Fors-man 1995; Roukala 1998; Ruohonen ja Salmela 1999). Erityisesti toiminnanoh-jausjärjestelmien kohdalla tarkastelun kohteena ovat kuitenkin olleet lähes yk-sinomaan suuryritykset. Pk-yrityksille tyypillisistä ongelmista ja erityispiirteistäkoskien Erp-järjestelmien käyttöönottoa ja kehittämistä löytyy sen sijaan varsinvähän tutkimustietoa.

Pk-yrityksissä päätöksenteolle on tyypillistä keskittyminen yhdelle tai muuta-malle avainhenkilölle ja siten epämuodollisuus, verrattain lyhyt liiketoiminnansuunnitteluperspektiivi ja strategisten linjausten yleisluonteisuus. Tästä etuinausein nähdään joustava ja nopea päätöksentekovalmius dynaamisessa toiminta-ympäristössä. Toisaalta strategiatyöskentelyn laiminlyönnistä usein johtuvapäätöksenteon systemaattisuuden puute heijastuu organisaation toiminnan ly-hytjännitteisyytenä ja suunnittelemattomuutena. Tällöin toiminnan johdonmu-kainen ja tehokas ohjaus on vaikeaa, puhumattakaan toiminnan pitkäjänteisestäkehittämisestä.

69

Yritykset joutuvat kuitenkin jatkuvasti tehostamaan ja kehittämään toiminnan-ohjaustaan ja prosessejaan, mikä usein edellyttää myös tietojärjestelmien kehit-tämistä. Yrityksen toiminnanohjaus ja sitä tukevat tietojärjestelmät ovat sekästrategisesti että operatiivisesti merkittäviä, sillä ne integroivat yrityksen ydin-prosessit. Näin ollen yritystä, sen toiminnanohjausta sekä sen alaisia prosesseja,toimintoja ja tietojärjestelmiä tulisi tarkastella kompleksisena, dynaamisena sekäsisäisesti ristiriitaisena systeeminä tai toimintajärjestelmänä (vrt. Senge 1990;Engeström 1995).

Päivittäisessä toiminnassa toiminnanohjausjärjestelmän tulisi olla sisäänraken-nettuna yrityksen muuhun toimintajärjestelmään ja samalla tavoin myös senkehittäminen tulisi nähdä osana organisaation jatkuvaa toiminnan kehittämistä.Käytännössä toiminnanohjausjärjestelmän käyttöönotto nähdään usein yhtenäprojektina muiden joukossa, eikä tarpeita sen yhteensovittamiseen ja kehittämi-seen organisaation toiminnanohjausperiaatteiden, prosessien, johtamistapojen,muiden tietojärjestelmien sekä henkilöstön toimintatapojen kanssa tiedosteta.Toisin sanoen laajan toiminnanohjausjärjestelmän kokonaisvaikutuksia yritykseneri toimintoihin ja kokonaisohjattavuuteen ei ymmärretä. Pk-yritysten investoin-tiresurssien rajallisuuden ja räätälöityjen ratkaisujen kalleuden vuoksi yrityksetmyös tyytyvät pitkälle standardoituihin ratkaisuihin, joiden käyttöönotossajoudutaan tekemään monia kompromisseja. Käytännössä nämä ilmenevät pro-sessien kankeutena ja joustamattomuutena sekä tietojärjestelmiin sisältyvienpotentiaalien käyttämättä jättämisenä ja toiminnan ohjaamisena perinteisin kei-noin.

Ymmärtämättömyys toiminnanohjausjärjestelmän moninaisista vaikutuksistaorganisaation toimintaan liittyy Pk-yrityksille tyypilliseen it-alan osaamisenpuutteeseen (ks. Holopainen et al. 1999; Ruohonen ja Salmela 1999). Yritysjoh-don tuleekin tiedostaa se tosiasia, että yritysten tietojärjestelmien monimutkais-tumisen ja käyttäjäkunnan laajentumisen myötä tietohallintoon ja järjestelmätu-keen on panostettava aiempaa enemmän. Toiminnanohjausjärjestelmän häiriötöntoiminta, sen optimaalinen soveltaminen liiketoiminnan tukena ja käyttäjienvalmiudet hyödyntää järjestelmää mahdollisimman tehokkaasti ja vaivattomastimuodostavat erään keskeisen tekijän yrityksen liiketoiminnan tuloksellisuudenkannalta.

70

Yrityksen johdon keskeinen tehtävä on integroida tietojärjestelmien kehittämi-nen kiinteästi yrityksen liiketoiminnan kehittämiseen, mikä on toteutettava ainastrategiatasolta jokapäiväiseen operatiiviseen toimintaan. Liiketoiminnan tasoltaalkava sitoutuminen ja johdonmukainen projektin ohjaus edellyttää johdolta

1. seisomista hankkeen takana – eli sen on pystyttävä perustelemaan henkilös-tölle projektin merkitys yrityksen (liike)toiminnan kehittämisen kannalta

2. riittävien ja tarkoituksenmukaisten resurssien kohdentamista

3. määrätietoista ja kannustavaa henkilöjohtajuutta.

Tietojärjestelmähankkeiden onnistumista määrittävät olennaisesti (Forsman1995, s. 48–50; ks. Ruohonen ja Salmela 1999; Airaksinen 2000)

1. (tulevien) käyttäjien tarpeiden ymmärtäminen ja heidän asteittainen sitout-taminen hankkeeseen mahdollisimman varhaisessa vaiheessa

2. hankkeen hallittu toteutus vaatimusmäärittelystä tuotantokäyttöön

3. toimiva vuorovaikutus eri osapuolien välillä.

Keskijohdolla on entistä merkittävämpi rooli toimia tuotantohenkilöstön jaylimmän johdon rajapintana. Työskennellessä organisaation informaatiovirtojenkeskipisteessä heidän tehtävänään on tietovirtojen käsittely ja kanavointi organi-saation eri sidosryhmille. Näin ollen he toimivat eräänlaisina muutosagentteina(ks. Nonaka et al. 1999a, s. 26–29, 39; Zuboff 1988).

2. Toiminnan muutos – työssä oppiminen

Dynaamisessa ja ennustamattomassa toimintaympäristössä organisaatioidenmuutokset eivät ole lopullisia ja täydellisiä. Näin ollen on orientoiduttava toi-minnan jatkuvaan kehittämiseen; toimintaedellytysten sekä vaihtoehtoehtoistenstrategioiden, toimintamallien ja menettelyjen tarkasteluun, luontiin ja kokei-luun. Edistämällä työntekijöiden ja toimihenkilöiden mahdollisuuksia osallistuatyön ja työyhteisön suunnittelu- ja kehittämistoimiin pyritään rakentamaan kes-tävät lähtökohdat toiminnalliselle joustavuudelle sekä henkilöstön jatkuvalleoppimiselle ja ammatilliselle uudistumiselle.

71

Tämän artikkelin johdannossa kuvattiin ulkoisia, organisaation toimintaympä-ristöstä kohdistuvia muutospaineita ja niiden aikaansaamia teknologisia, organi-satorisia ja työnjaollisia muutoksia organisaation toiminnassa sekä edelleennäiden vaikutuksia työtehtävien sisältöön ja niiden edellyttämään osaamiseen.Tarkasteltaessa organisaatiota toimintaja oppimisympäristönä voidaan saman-aikaisesti tunnistaa toimintatapojen muutosta rajoittavia, mahdollistavia sekäohjaavia tekijöitä kuten teknologiset uudistukset tai sosiaalinen paine ja tuki.

Seuraavaksi siirrytään tarkastelemaan, mitä nämä muutokset merkitsevät työyh-teisön toimintakulttuurin sekä sen jäsenten ajattelu- ja toimintatapojen kehitty-misen kannalta. Oppimisen kontekstuaalista luonnetta painotettaessa tarkastelu-kohteena ovat oppimisen, toimintakäytäntöjen ja toimintaympäristön suhteet.Tätä suhdetta on problematisoitu niin käyttäytymistieteellisen kuin organisaa-tiotutkimuksenkin piirissä eri tutkimustraditioiden lähtökohdista (ks. mm. Senge1990; Argyris 1992; 1994; Kauppi 1993; Engeström 1995; Nonaka ja Takeuchi1995; Lave ja Wenger 1995; Mezirow et al. 1996; Wenger 1998; Poikela 1999).Organisationaalista oppimista käsittelevien teorioiden kirjosta voidaan eritelläkolme erilaista lähestymistapaa, joita ovat systeeminen, organisaatiopsykologi-nen ja informaatioperustainen paradigma sekä niitä edustavat tutkijat ja kehittä-jät. Tämä luku rakentuu näille kolmelle organisationaalisen oppimisen lähesty-mistavalle ja näiden kritiikille.

2.1 Toiminnan ja oppimisen kontekstuaalisuus ja systeeminen näkemysorganisationaaliseen oppimiseen

Ihmisen toiminnalle on tyypillistä pyrkimys ympäristönsä ymmärtämiseen jahallintaan. Toimintaa leimaa tavoitteellisuus sekä eri asteinen toiminnan perus-teiden, edellytysten, vaihtoehtoisten toimintatapojen sekä tulosten arviointi.(Argyris 1992, s. 90; Mezirow et al. 1996, s. 11–36.) Engeström (1995, s. 73)määrittelee toiminnan keskeisiksi tunnuspiirteiksi kohteellisuuden, välittynei-syyden, moniäänisyyden, historiallisuuden sekä sisäisen ristiriitaisuuden.

Organisaation kehittämisparadigmoista pitkään vallalla ollut ja yritysmaailmas-sakin vähitellen omaksuttu systeemiajattelu on auttanut näkemään ja ymmärtä-mään organisaatioiden monimutkaista todellisuutta myös oppimisen kannaltatarkoituksenmukaisesti. Systeemiajattelu painottaa kokonaisuuksien hahmotta-mista, osajärjestelmien vuorovaikutussuhteiden ja keskinäisten riippuvuuksien

72

ymmärtämistä sekä huomion kiinnittämistä vähitellen tapahtuviin muutoksiin.Systeemiajattelu auttaa myös irrottautumaan lineaarisesta syy-seuraus-suhteeseen pohjautuvasta ajattelusta ja näkemään todellisuuden vuorovaikutus-suhteista muodostuvina kehinä, joissa olemme itse mukana vaikuttamassa asioi-den kulkuun. (Senge 1990, s. 68–73.) Organisaatioiden kehittämisen haasteelli-suus johtuu pitkälti organisatorisen muutoksen monitahoisuuden ja kontekstisi-donnaisuuden ymmärtämisestä eli siitä, kuinka eri osajärjestelmien keskinäinendynamiikka ymmärretään ja otetaan huomioon uudistuksia suunniteltaessa.

Engeströmin (1995) kehittämässä toiminnan teoreettisessa lähestymistavassayksilön teot ja ominaisuudet nähdään kollektiivisessa toimintajärjestelmässä(kuten työyhteisössä) historiallisesti ja järjestelmän sisäisten ristiriitojen yhteis-toiminnallisen ratkaisun kautta muodostuneina ja jatkuvasti uudelleen muotou-tuvina. Samalla tavoin yksilön toiminta muokkaa jatkuvasti tätä dynaamistatoimintajärjestelmää. Näin ollen yksilön tekoja ja toimintaa ei voida tarkastellasosiaalisesta ja institutionalisoituneesta toimintajärjestelmästä irrallisena, vaantoiminnan kontekstuaaliset tekijät huomioiden. Tavoitteena on kuvata yksilöntekojen ja kollektiivin toiminnan välistä suhdetta (Engeström 1995, s. 45).

Kohde

TyöyhteisöTyönjako,roolit

Välineet, mallit

Säännöt

Tekijä

Kuva 1. Engeströmin (1995) toiminnan teorian malli.

Lähestyttäessä yksilön ja yhteisön toimintaa ja niiden keskinäisiä suhteita toi-minnan teorian näkökulmasta huomio kiinnitetään järjestelmän sosio-kulttuu-risiin tekijöihin, kuten yhteisöön, sen sääntöihin ja työnjakoon sekä fokuksenaolevaan subjektiin, hänen käyttämiin välineisiin ja toiminnan kohteeseen (ks.

73

kuva 1) (Engeström 1995, s. 41–48). Engeströmin teorian mukaan toiminta (jatieto kohteesta) on aina välittynyttä toimijan käyttämien työvälineiden ja käsit-teiden kautta. Toiminta on myös aina kollektiivisesti välittynyt, kuten kuvassa 1oleva työyhteisö, sen säännöt ja viralliset roolit havainnollistavat.

Lähestymistavoista ja painotuseroista huolimatta organisaatiotutkimuksen jakäyttäytymistieteilijöiden piirissä vallitsee tänä päivänä varsin yhtenäinen näke-mys sosiaalisen ympäristön sekä yksilön ajattelun ja toiminnan dynaamisesta jadialektisesta vuorovaikutussuhteesta; yksilön tavoitteellinen toiminta ja senkehittyminen edellyttävät sosiaalista vuorovaikutusta ja ovat siten aina kyseisensosiokulttuurisen kontekstin muokkaamia. Sosiaalisessa vuorovaikutuksessaihminen ei kuitenkaan vain passiivisesti omaksu yhteisön ajattelu- ja toimintata-poja, vaan kehittyminen edellyttää aina sosiokulttuuristen merkitysten tulkintaaomasta kokemusperspektiivistä. Yksilö on myös aktiivinen osallistuja, jokatoiminnallaan koko ajan muuttaa toimintajärjestelmää. Organisaatiokontekstissatämä merkitsee jatkuvaa neuvotteluprosessia, jossa yhteisön jäsenet uusintavat jamuokkaavat yksilöllistä ammatti-identiteettiään sekä kollektiivisia sääntöjään jatoimintatapojaan. Oppiminen on eri asteista osallistumista tähän sosiaaliseenmerkityksen luomiseen ja yhteisölliseen toimintaan. Merkityksistä neuvottelu onhistoriallinen, ainutkertainen ja jatkuvasti tapahtuva prosessi, johon sisältyykaikki toiminnan ulottuvuudet. (mm. Giddens 1984; Lave ja Wenger 1995;Berger ja Luckman 1994; Wenger 1998)

Oman työn ja sen kohteen tarkasteleminen laajemmassa koko toimintajärjestel-män (esim. työyhteisön) kontekstissa on tärkeää työn sujumisen, mielekkyydenja ammatillisen kehittymisen kannalta. Työntekijät voivat hahmottaa selkeäm-min mihin toiminnalla pyritään, mitä tehdään ja miksi. Samalla ylitetään myöstyöyhteisön jäsenten toimenkuvien totutut rajat, ja henkilöstölle tarjoutuu mah-dollisuus jäsentää työtään ja erilaisia roolejaan osana laajempaa kokonaisuutta javuorovaikutus-suhteiden verkostoa. Engeströmin (1995) mukaan työpaikanristiriitaiset tehtävät tai vaatimukset ovat tyypillinen tilanne, joka voi aktivoidakoko toimintajärjestelmää koskettavan muutosprosessin. Tästä nk. ekspansiivi-sesta oppimisesta muotoutuu tarkoituksenmukaisesti tuettuna yhteisöllinen,kompleksinen, monia eri osaprosesseja ja oppimisen muotoja käsittävä pitkäai-kainen muutosprosessi. (Engeström 1995; ks. Virkkunen et al. 1999, s. 12–27.)Toiminnan ja oppimisen kiinteä yhteys, sekä niiden yhteisöllinen ja konteks-

74

tuaalinen luonne on otettava lähtökohdaksi myös kehitettäessä yrityksen toi-mintaa tietojärjestelmien avulla (vrt. Sachs 1995).

2.2 Toimintakäytäntöjen kehittäminen ja oppiminen organisaatiopsykologi-sesta näkökulmasta

Toiminnan kontekstuaalisen luonteen vuoksi on keskeistä tutkia ja tiedostaa,millaista oppimista kyseinen organisatorinen toimintaympäristö tukee ja mil-laista se mahdollisesti ehkäisee, jotta näihin oppimisen ja muutoksen esteisiinvoidaan aktiivisesti niin johdon kuin jokaisen yhteisön jäsenen toimesta vaikuttaa.

Toimintakäytäntöjen kehittymisessä on erotettavissa kaksi erilaista prosessia,reproduktio ja transformaatio, jotka edellyttävät puolestaan erilaista oppimista jatietoperustaa. Päivittäin toistuvat, jatkuvuutta ylläpitävät toimintatavat ja-käytänteet muodostavat päivittäisen toiminnan ytimen, minkä pohjalta toimijantietoisuus rakentuu vähitellen piilevälle ja luonteeltaan ideografiselle ja kon-tekstuaaliselle tietoperustalle. Se on hyvin kokemusperustainen ja yksittäisiin,intuitiivisiin tilannearviointeihin pohjautuva kognitiivinen ajatusrakennelma,systemaattisen ja analyyttisen sijaan. Ihmiset ovat oppineet toimimaan tietyllätavalla ja samalla muovanneet tätä toimintaansa tukevat ajattelumallit. Toisaaltapraktisen skeeman toimivuutta testataan jatkuvasti käytännön ongelmia ratkais-taessa. Oppiminen ja kehittyminen kohdentuvat olemassa olevien toimintatapo-jen sujuvuuden parantamiseen esimerkiksi käytännön ongelmakohtiin puuttu-malla tai suoritusten automatisoimisella. Tavoitteena on hyväksi havaittujenkäytänteiden uusintaminen eli ylläpitäminen ja säilyttäminen (reproduktio).(Kauppi 1993, s. 65–68.)

Argyris (1992, s. 9–10; Argyris ja Schön 1996) toteaakin monien työyhteisöjenkehittämisen jäävän vakiintuneita ajattelu- ja toimintatapoja uusivalle oppimisentasolle, jota hän kuvaa yksisilmukkaiseksi oppimiseksi. Tällä hän pelkistetystitarkoittaa toiminnassa omaksuttua ongelman ratkaisustrategiaa, jossa tiedonkerääminen ja käsittely havaitun häiriön tai ongelman selvittämiseksi on pinnal-lista, eikä missään vaiheessa kyseenalaisteta käytettyjä toimintastrategioita taitoiminnan taustalla olevia perusolettamuksia. Tämä on hyvin tyypillinen tilanne,johon organisaatioiden kehittämistyössä törmätään. Käytännössä se ilmeneearkitoiminnassa esiintyvien häiriöiden näennäisenä, mahdollisimman pikaisenatai väliaikaisena korjaamisena. Samalla usein tiedostamattomastikin siirretään

75

ongelma muihin toimintoihin, mistä seuraa järjestelmän rakenteellisten häiriöi-den ja ristiriitojen vähittäinen muodostuminen ja verkottuminen. Päivittäinentoiminta on jatkuvaa ”lutvimista, luovimista ja tulipalojen sammuttelua”. (Vrt.Engeström 1995: Virkkunen et al. 1999.)

Toimintakäytäntöjen uudistaminen (transformaatio) sen sijaan merkitsee laadul-lisia ja rakenteellisia muutoksia niin yksilön kuin työyhteisönkin aiempiin ajat-telu- ja toimintatapoihin. Se edellyttää toimijoilta reflektiivisempää eli tietoi-sempaa otetta työhönsä sekä syvällisempää, teoreettisempaa ja diskursiivisem-paa tietoperustaa. Reflektointi voi kohdistua toimijoiden tai toimijoiden ja väli-neiden keskinäiseen vuorovaikutukseen, toiminnan sisältöön tai toimijoidenajattelu- ja toimintamalleihin. (Kauppi 1993, s. 65, 85; Mezirow et al. 1996, s.17–36.) Kriittisen reflektion eli omien ennakko-oletusten kyseenalaistaminennähdään perusedellytyksenä ajattelu- ja toimintatapojen muutokselle, mitä myösArgyris (1992, s. 8–10) kuvaa yksisilmukkaisen ja kaksisilmukkaisen oppimisenperustavanlaatuisena erona. Kaksisilmukkaisessa ongelmanratkaisu- ja oppimis-strategiassa palataan toiminnan perusoletuksiin ja toimintastrategiaan, joitatutkimalla ja kyseenalaistamalla orientoidutaan koko tilanteeseen uudella tavalla.Kuva 2 havainnollistaa näiden kahden ongelmanratkaisukeinon perustavanlaatui-sia eroja.

Kuva 2. Yksi- ja kaksisilmukkainen oppiminen (Argyris 1999, s. 8).

Muutosvalmiutta ja uuden oppimista estävien puolustusrutiinien purkamiseksiorganisaatioissa Argyris (1990, s. 65–66) pitää tärkeänä seuraavia strategioita.Organisaation johtamisessa ja toiminnan suunnittelussa tulisi välttää tilanteita,jotka työntekijät todennäköisesti kokisivat uhkaavina tai häpeällisinä. Työnteki-jöiden osallistumis- ja vaikuttamismahdollisuuksien parantaminen sekä yleinenyhteisön toimintaa koskevan tiedon avoimuus ja saatavuus hälventävät puolus-tusrutiineja. Toinen strategia perustuu yksiköiden kouluttamiseen siten, että he

76

oppivat uusia käsitteitä ja taitoja, joilla puolustusrutiineihin on mahdollistavaikuttaa. Yhteisen keskustelun ja uusien taitojen käyttämisen kautta puolustus-rutiineista tulee hallittavia ja niiden muuttaminen on mahdollista. Tämä liittyyyleisemmin työyhteisössäkin yhä tärkeämmäksi muodostuvaan yksilöllisten jakollektiivisten oppimisvalmiuksien ja niiden tukijärjestelmien kehittämiseen elink. oppimaan oppimiseen (deuterolearning). (Ks. Argyris ja Schön 1996.)

Samalla kun henkilöstö osallistuu oman työnsä ja työympäristönsä kehittämi-seen, myös sosiaalinen paine uudistusta kohtaan kääntyy ikään kuin positiivisek-si. Kaikkien on tarkasteltava kriittisesti omia työskentelytottumuksiaan ja niidenperusteita, mietittävä vaihtoehtoisia ratkaisuja, kokeiltava niitä työssään sekäreflektion kautta uudistettava toimintatapojaan. Työyhteisön tarjoaman sosiaali-sen paineen ja tuen tasapaino on myös organisaation tietojärjestelmäuudistustenonnistumisen kriittisiä tekijöitä, mikä saavutetaan ottamalla henkilöstö aktiivi-sesti ja määrätietoisesti mukaan kehittämistoimintaan. Kriittinen ja reflektiivinentyöskentelyote ei kuitenkaan yksinomaan saa aikaan muutosta, vaan siihen tar-vitaan konkreettisia toimintaympäristön tarjoamia edellytyksiä ja työvälineitä.

2.3 Oppiva ja tietoa luova organisaatio – tietoperusteinen näkökulma

Oppiva organisaatio on useiden nykypäivän organisaatioiden tavoittelema toi-mintaihanne, jolle organisaatiotutkimuksen piiristä löytyy monenlaisia määri-telmiä. Tyypillisesti sillä tarkoitetaan organisaatiota, jolle on ominaista kaikkienjäsenten vahva sitoutuminen yhteisesti muokattuun visioon, halu ottaa riskejä,kyky kyseenalaistaa ja kehittää jatkuvasti työtapoja ja palveluita, tiimityösken-tely sekä uusimman teknologian monipuolinen hyödyntäminen. Tämä edellyttäämatalaa, muuntautumiskykyistä organisaatiorakennetta sekä osallistavaa johta-juutta, joka tukee asiakaslähtöistä, vuorovaikutteista ja kokeilevaa organisaatio-kulttuuria. (Pedler et al. 1991, s. 1; Watkins ja Marsick 1993, s. 8; Ruohotie1996, s. 43; Sarala ja Sarala 1996, s. 53–63.)

Swieringan (1992, s. 33) mukaan oppivan organisaation luomisessa on otettavahuomioon kollektiiviset prosessit, joilla koko organisaation käyttäytyminenmuuttuu. Yksilön oppiminen on välttämätön, mutta ei riittävä tae organisaationoppimiselle. Organisaatio ei ainoastaan ”opi” siitä, että joku tekee työnsä pa-remmin, vaan yksilön oppimisen myötä organisaation muutkin jäsenet toimivateri tavalla. (Swieringa 1992, s. 33; Sydänmaalakka 2000, s. 47.) Organisaatioi-

77

den keskeinen haaste onkin siinä, miten yksilön oppiminen kyetään yleistämäänkoko organisaatiota hyödyntäväksi toiminnaksi. Eräs keino on, että oppiva orga-nisaatio pyrkii reflektoimaan yksilöiden toimintatapoja ja kehittämään sellaisiakollektiivisia toimintatapoja, jotka ovat koko organisaation ominaisuutta (esim.upotettuna proseduureihin, patentteihin, dokumentteihin, virallisiin ja epäviralli-siin rutiineihin) ja näin ollen eivät ole sidottuja alkuperäänsä, eli yksilöidenoppimiseen (ks. Järvinen et al. 2000, s. 75–80). Jos asiantuntemus on hyvinhenkilöitynyttä ja vaikeasti yleistettävää, vaihtoehtoinen strategia on varmistaanäiden henkilöiden pysyvyys organisaatiossa ja samalla luoda monipuolisiaedellytyksiä kyseisen asiantuntemuksen edelleen kehittymiseksi.

Oppivaa organisaation moninaisia teorioita on myös paljon kritisoitu. Oppivaorganisaatio -kirjallisuudessa muutosta ja oppimista pidetään itsestäänselvyyte-nä, vaikka toisaalta henkilöstön epäilevä ja kriittinen asennoituminen uudistuk-siin nähdään ”luonnollisena” vastarintana, joka johdon tulisi ”voittaa”. Riskinäon myös, että oppivan organisaation paradigmaa käytetään johdon yksipuolistenintressien legitimointiin, eli perustelemaan ikävät ja jopa kyseenalaiset muutok-set. Henkilöstö ei kuitenkaan välttämättä edes ”oikeiden” johtamistoimenpitei-den jälkeen halua uhrautua työlleen vapaa-ajan kustannuksella tai kehittyä jaoppia jatkuvasti jotain uutta. Myös taloudelliset realiteetit ja johdon haluttomuusdelegoida tehtäviään ja sijoittaa henkilöstön kehittämiseen vaikeuttavat todelli-seksi oppivaksi organisaatioksi kehittymistä. Usein henkilöstön oppimishaluk-kuutta heikentää se, että oppimisen ”tulosta” pidetään organisaation omaisuute-na. Oppivan organisaation vision tulisikin konkretisoitua molemminpuolisinatavoitteina, hyötyinä, eikä yksinomaan näyttäytyä vain yrityksen taloudellisenhyödyn tavoitteluna. (Ks. Tuomisto 1999, s. 37; Sarala ja Sarala 1996, s. 63–64.)

Yksilön ja kollektiivisen oppimisen problematiikkaa on myös lähestytty mm.Nonakan ja hänen kollegoidensa (1995; 1999a; 1999b) edustamasta tietoperus-teisesta näkökulmasta. Lähestymistavan mukaan organisaation tärkein kilpailu-tekijä on sen kyky luoda jatkuvasti uutta tietoa, mikä on lähtökohtana uusilletuoteinnovaatioille sekä prosessien ja liiketoiminnan kehittämiselle. Organisaa-tion tiedon luonti käsitetään jatkuvana ja dynaamisena prosessina, joka tapahtuuhiljaisen ja eksplisiittisen tiedon vuorovaikutuksen tuloksena. Hiljaisen (tacit)tiedon käsite on alunperin Polanyin (1958) käyttämä nimitys yksilön sellaiselletietämykselle, joka ei ole artikuloitavissa. Hiljainen tieto on upotettuna yksilönkokemuksiin ja sosiaalisiin suhteisiin. Eksplisiittinen tieto on sen sijaan objektii-

78

vista, rationaalista ja siten ilmaistavissa esim. käsitteiden, symboleiden tai tie-teellisten teorioiden avulla. (Ks. Nonaka ja Takeuchi 1995; Nonaka et al. 1999a;1999b.)

Tietoperusteisen lähestymistavan mukaan organisationaalinen tieto rakentuu,muokkautuu ja muuntuu sosiaalisessa vuorovaikutuksessa nelivaiheisen spiraalinkautta (kuva 3). Lähtökohtana on yksilöiden hiljaisen tiedon muuntaminen orga-nisaation käyttöön. Sosialisaatiossa yksilöt välittävät ja jakavat persoonallistahiljaista tietoaan yhteisten kokemusten kautta, mistä tyypillinen esimerkki onoppisopimuskoulutus tai mentorointi. Ulkoistaminen tarkoittaa hiljaisen tiedonjakamista muille, eli eksplikointia, jolloin se muodostaa perustan uudelle tiedol-le. Esimerkkinä käytetään laatupiiritoimintaa, jossa työssä esiintyvät ongelmattuodaan yhteistoiminnalliseen ratkaisuun – apuvälineinä erilaiset mallit ja meta-forat. Organisaation sisältä ja ulkoa hankittua tietoa yhdistellään eli muokataansystemaattisemmaksi ja kompleksisemmaksi esim. atk:n avulla. Seuraavaksi uusitieto levitetään jälleen organisaatiossa jäsentensä omaksuttavaksi osaksi heidänhiljaista tietoaan. Tätä sisäistämisprosessia leimaa ”learning by doing” -strategiaeli uusi tieto omaksutaan reflektoinnin ja kokeilun avulla vähitellen osaksi aiem-pia ajattelu- ja toimintatapoja, minkä seurauksena toimintakäytänteet uudistuvat.Koulutusohjelmat, uudet toimintaohjeet ja manuaalit toimivat reflektointipinta-na. (Nonaka ja Takeuchi 1995; Nonaka et al. 1999a, s. 13–15; 1999b, s. 6–8.)

Taci

t

Sosialization

ExperientalKnowledge

Combination

Externalization

ConceptualKnowledge

Internalization

Tacit Tacit

Taci

t

Explicit

Explicit

Explicit

Explicit

SystemicKnowledge

RoutineKnowledge

Kuva 3. Neljä tiedon muodostuksen mallia ja niiden tuloksena syntyvät tiedonlajit (Nonaka ja Takeuchi 1995; Nonaka et al. 1999a mukaillen).

79

Uudelleen konstruoidun jaetun tiedon muuttuessa hiljaiseksi tiedoksi, eli osaksiyhteisön jäsenten toimintaa, ja jälleen uudelleen jaettavaksi tulee siitä arvokas yhtei-söllinen tietoresurssi. Tämä organisatorinen tiedontuottamisspiraali toteutuu niinorganisaation sisällä kuin organisaatioiden välillä. (Nonaka et al. 1999b, s. 9–10.)

Nonakan ja hänen kollegoidensa esitys organisaation ja sen jäsenten tiedonmuo-dostusprosesseista on yksi tunnetuimmista tämänhetkisistä lähtökohdista pyrkiäymmärtämään organisaatiossa tapahtuvia monimutkaisia, inhimillisiä ja uuttaluovia prosesseja. Vaikkakin he korostavat tiedon muodostuksen jatkuvaa spi-raalimaista luonnetta, prosessin vaiheet jäävät mallissa irrallisiksi, eikä niidenvälille muodostu keskinäisiä riippuvuussuhteita (vrt. Engeström 1995). Tutkijoi-den esimerkkien perusteella ne ovatkin pikemminkin eräänlaisia tiedon muo-dostuksen tiloja ja sosiaalisessa vuorovaikutuksessa syntyneitä tiedon muotoja,jotka tapahtuvat yhteisön ja sen jäsenten sosiaalisissa prosesseissa jatkuvasti,samanaikaisesti, limittäin ja toisiinsa kietoutuneina.

Tietoperusteinen lähestymistapa tarjoaa huomionarvoisen näkökulman tarkas-teltaessa toiminnanohjausjärjestelmän käyttöönottoa organisatorisena oppimis-prosessina. Lähestymistapa tuo esiin sekä organisatorisen ja yksilöllisen ettähiljaisen ja eksplisiittisen tiedon sekä niihin liittyvien prosessien moninaisuudenyrityksen perustavanlaatuisena toimintana ja kriittisenä kilpailutekijänä. Näidenprosessien, tietoresurssien ja -virtojen ymmärtäminen tulisi olla lähtökohtanatoiminnanohjausjärjestelmähankkeissa. Tämä edellyttää prosessien ja niihinliittyvien tietovirtojen selvittämistä sekä tietoista kannanottoa siitä, mikä ontoiminnanohjausjärjestelmän rooli ja miten sitä hyödynnetään sekä millaisiatarpeita ja tavoitteita organisaatiolla ja sen yksittäisillä toimijoilla on.

Toisaalta on keskeistä kiinnittää huomiota organisaation tukeen vaihtoehtoisilletavoille hankkia, jalostaa ja levittää tietoa ja osaamista – toisin sanoen ymmärtäätietojärjestelmän rajat ja mahdollisuudet. Johdon tehtävänä on edistää yksilöidenja tiimien keskinäistä tiedonvaihtoa ja erilaisia yhteistyömuotoja sekä organisaa-tion eri tasojen ja yksikköjen välillä että organisaation ulkopuolisten verkostojenkesken. (vrt. Nonaka et al. 1999b, s. 26–39; Sydänmaalakka 2000, s. 45–46,187–192.)

80

2.4 Organisatorisen oppimisen paradigmojen herättämiä ajatuksia ja kri-tiikkiä

Työssä oppiminen ei rajaudu pelkästään asiantuntemuksen (tiedon) karttumiseenja työyhteisön rutiineihin adaptoitumiseen. Oppiminen kohdistuu myös tunteisiinja asenteisiin ja oman sosiaalisen (ammatti)identiteetin määrittelemiseen. Orga-nisaation jäsenet oppivat toisaalta oman työnsä sisältöön liittyviä asioita, toi-saalta myös erilaisia asenteita organisaatioon, muihin työntekijöihin ja sidos-ryhmiin. Samoin jokaisella työntekijällä on jonkinlainen käsitys omasta roolis-taan organisaatiossa sekä tämän roolin vaikutuksista muihin organisaation toi-mijoihin.

Tällaista työntekijän työssään omaksumaa tietoa voidaan kutsua työprosessitie-tämykseksi (engl. work process knowledge). Se on tietoa, jota työntekijä tarvit-see työnsä suorittamiseen: työprosessit, muiden toimijoiden roolit sekä yhteydetoman ja muiden toiminnan välillä (Kruse 1986). Suuri osa tästä tiedosta on ns.hiljaista tietoa ja yhteisön kollektiivista omaisuutta. Työprosessitietämys on näinollen olennainen osa organisaation kulttuuria. Työyhteisön jäsenten keskeisintietolähde (oppimisen lähde) eivät ole organisaation säännöt tai viralliset koulu-tusohjelmat. Sen sijaan tieto ja osaaminen syntyvät organisaation jäsenten vuo-rovaikutuksesta ja yhdessä tekemisestä ja ovat suurelta osin ns. hiljaista (tacit)tietoa.

Työprosessitietämys sisältää työn vaiheiden suorituksen lisäksi tietoa siitä kon-tekstista, jossa yksilö työskentelee sekä yksilön työn vaikutuksista muihin toi-mijoihin ko. toimintaympäristössä. Tämä toimintaympäristöä koskeva tietokäsittää myös toimintaympäristön viralliset ja epäviralliset normit ja rutiinit, eliorganisaation kulttuurin. Työprosessitietämyksen syntymistä ja kehittymistävoidaan tukea osallistavalla työprosessien suunnittelulla, informaatiojärjestel-millä ja erilaisilla mentorointimenetelmillä, mihin organisaatioissa tulisikinpanostaa, koska sen merkitys kasvaa automaatio- ja informaatioteknologiankäyttöönoton lisääntymisen myötä. (WHOLE 2000.)

Kirjallisuudessa hiljaisen tiedon muuntamista eksplisiittiseksi tiedoksi pidetääntyypillisesti keskeisenä osana oppivaa organisaatiota (ks. esim. Nonaka jaTakeuchi 1995). Tällöin hiljainen ja eksplisiittinen tieto käsitetään jatkumonkahdeksi pääksi. Nonakan ja kumppaneiden teorian epistemologisia ristiriitai-

81

suuksia on kritisoinut mm. Cook ja Brown (1999), joiden mukaan hiljainen(tacit) ja eksplisiittinen tieto ovat itsenäisiä tiedon lajeja, joita ei voi muuttaatoiseksi. Sen sijaan esimerkiksi eksplisiittistä tietoa voidaan käyttää hyväksitacit-tietoa omaksuttaessa (esim. teoreettiset mallit, joita testataan käytännössä).Toiminnassa hyödynnetään kaikkia neljää tiedon lajia (ks. kuva 4) ja syntyvätieto on aina generoitua uutta tietoa, ei koskaan muunnettu esim. yksilöllisestäkollektiiviseen tai hiljaisesta eksplisiittiseen. Tämä tarkoittaa muutosta Nonakanja Takeuchin (1995) teoriaan, jonka mukaan oppivan organisaation on kyettävämuuttamaan hiljaista tietoa eksplisiittiseksi tiedoksi mahdollisimman tehok-kaasti. Cookin ja Brownin mukaan tacit-tietoa ei missään olosuhteissa olemahdollista muuttaa eksplisiittiseksi tiedoksi tai päinvastoin. Tieto syntyy ainavuorovaikutuksessa ympäristön kanssa ja on yksilölle uutta, yksilön toiminnassaluomaa tacit- tai/ja eksplisiittistä tietoa. Cook ja Brown (1999) esittävät Nonakanja Takeuchin (1995) teoriaan perustuvan mallinsa tiedon lajeista (ks. kuva 4).

Explicit

Tacit

Individua l Group

Kuva 4. Tiedon lajit Cookin ja Brownin (1999) mukaan.

Kuvassa 4 genrellä tarkoitetaan mm. jaettua käsitystä oikeasta tavasta toimiaorganisaatiossa ja jaettua ymmärrystä erilaisten ulkopuolisille triviaalien asioi-den merkityksestä, eli organisaation kulttuuria. Tarinoilla (stories) viitataanyhteen organisaatiokulttuurin osaan eli kollektiiviseen organisatoriseen ”kan-santarustoon”, joka on tehokas keino levittää osaamista esimerkkien (ns. sankari-ja kauhutarinoiden) avulla. Myös Lave ja Wenger (1995) puhuvat työyhteisönkollektiivisesta kokemusvarannosta, joka ilmenee esimerkkien ja esikuvienlisäksi puheena ja kertomuksena. Tämä kokemusvaranto toimii hypoteesien

82

lähteenä yksittäiselle ongelmanratkaisijalle. Käsitteet (concepts) ovat artikuloi-tavissa olevia ajattelumalleja. Taidot (skills) viittaavat artikuloimattomaanosaamiseen (know-how). (Cook ja Brown 1999.)

Oppiminen käsitetään usein liian kapeasti viitaten ainoastaan työssä hyödynnet-tävän tietämyksen karttumiseen tai hyvien toimintatapojen kehittymiseen. Toi-mintaa ja oppimista ei kuitenkaan ole mahdollista erottaa. Oppimisen luonnettatyöyhteisön jäsenten kehittymistä ja ”parantumista” tukevana käsitteenä voidaannäin ollen kritisoida. Esim. mentorointijärjestelmän toimivuuteen vaikuttaaorganisaation kulttuuri – Cookin ja Brownin mallissa genre – joka vaikuttaasiihen, millaisen kuvan mentori antaa työstä ja työnteosta oppilaalleen. Mentorisiis välittää ns. hyvien toimintatapojen ja implisiittisen osaamisensa lisäksi myöstahtomattaan tai tarkoituksella muun työyhteisössä oppimansa materiaalin(asenteet johtoa kohtaan, epäviralliset normit jne.). Samoin kuvan 4 tarinat (sto-ries) voivat koskea ns. sankarillisia alisuoriutujia tai muita organisaation johdonperspektiivistä antisankareita. Tietojärjestelmähankkeiden kohdalla sosialisaa-tion monimuotoisuuteen törmätään hyödynnettäessä ns. avainkäyttäjiä järjestel-män muiden käyttäjien kouluttajina ja opastajina, jolloin samalla siirretään totu-tut käyttötavat sekä niihin sisältyvät asenteet ja käsitykset tietojärjestelmienkäytöstä ja merkityksestä työssä.

Perinteiset teoriat lähtevät tyypillisesti siitä idealistisesta oletuksesta, että kaikkiorganisaation jäsenten omaksuma tieto on organisaation eduksi ja oppimista onainoastaan se, kun toiminta kehittyy haluttuun suuntaan. Tämä on riittämätönlähtökohta jos halutaan tutkia organisaation sisäisiä ristiriitoja toiminnan kehit-tämisen esteinä ja työssä oppimista (toimintaa) teoreettisena käsitteenä. Työyh-teisön jäsenten oppiminen ei ole (johdon) projekti, joka on mahdollista keskeyt-tää tai lopettaa tarvittaessa. Myöskään työntekijöiden oppimisen sisältö ei olejohdon määrättävissä.

Myös Wenger (1998) seikkaperäisessä työyhteisön sosiokulttuurisessa analyy-sissaan korostaa, että oppimisen ollessa erottamaton osa käytännön sosiaalistatoimintaa sitä ei voi suunnitella tai täysin kontrolloida osallistujien kuin ulko-puolistenkaan taholta. Oppimista voidaan ainoastaan tukea ja jossain määrinohjata luomalla keskinäisen sitoutumisen (mutual engagement), jaetun yrityksen(joint enterprise) sekä jaettujen välineiden (shared repertoire) muodostamistavahvistavat sosiaaliset puitteet. Wengerin mukaan näiden kolmen ulottuvuuden

83

kautta tapahtuu merkityksellinen oppiminen, jonka toteutumaa hän kutsuu käy-tännön yhteisöiksi (communities of practice). Nämä epämuodolliset yhteisötmuodostuvat käytännön toiminnassa jatkuvasti toistensa kanssa tekemisissäolevista ihmisistä, jotka keskinäisessä toiminnassaan muodostavat, ylläpitävät jauudelleen muotoilevat kollektiivisia tapoja, rituaaleja, kertomuksia – jaettujaajattelu- ja toimintatapoja sekä niiden ilmentymiä. Niiden avulla käytännönyhteisöt jäsentävät, perustelevat ja ohjaavat toimintaansa sekä ratkaisevat siinäilmeneviä ongelmia. Yhteisöjen toiminnan ja oppimisen ulkopuolinen ohjaustapahtuu siten aina välittyneesti – kollektiivisen neuvotteluprosessin suodatta-mana.

3. Toiminnanohjausjärjestelmähanke toiminnan muutoksen ja organisato-risen oppimisen näkökulmista

Tietojärjestelmäprojektiin on suhtauduttava yrityksen strategisena hankkeena,joka vaatii myös toiminnan ja toimintatapojen muutosta. Forsman (1995, s. 49–50) korostaakin eräänä tietojärjestelmäprojektin kriittisenä tekijänä sen hallittuatoteutusta tarvemäärityksestä tuotannolliseen käyttöön eli kytkentää organisaa-tion toimintatapoihin ja niiden pitkäjänteiseen ja aktiiviseen kehittämiseen.

Se kuinka laajasti toiminnanohjausjärjestelmää kehitetään vaikuttaa luonnolli-sesti siihen, millaisia kehitysvaatimuksia ja -tarpeita siitä aiheutuu yrityksentoiminnanohjaukselle ja prosesseille. Tietojärjestelmien ja toiminnan kehittämi-sen laajuudesta ja rinnakkaisuudesta on olemassa monenlaisia käsityksiä jakokemuksia, eikä tähän keskeiseen ongelmaan varmasti ole löydettävissä yksi-selitteistä ratkaisua. Talonpoikaisjärjellä ajateltuna mitä laajempi toiminnanoh-jausjärjestelmähanke ja mitä enemmän muutoksia uuden ja vanhan systeeminvälillä on, sitä enemmän tulee panostaa prosessien ja toimintatapojen kehittämi-seen. Toteutetaanko nämä prosessit rinnakkain, limittäin vai peräkkäin tuleeratkaista projekti- ja yrityskohtaisesti.

Seuraavissa kappaleissa tarkastellaan joitakin keskeisiä toiminnan kehittämisenja oppimisen kannalta kriittisiä seikkoja, joihin pk-yrityksissä tyypillisesti tör-mätään toiminnanohjausjärjestelmää kehitettäessä. Samalla esitetään joitainerityisesti pk-yrityksille soveltuvia kehitysehdotuksia, menetelmiä ja työkaluja,joiden hyödyntämisen lähtökohtina ovat edellä esitellyt kolme organisatorisenoppimisen näkökulmaa. Esille nostetaan kaksi keskeistä ongelma-aluetta, jotka ovat

84

1. hankkeeseen osallistuvien tahojen keskenään ja sisäisesti ristiriitaiset ta-voitteet, mistä seuraa kommunikaation ja yhteistyön pelisääntöjen merkitys

2. toiminnanohjausjärjestelmän aikaansaamat muutokset työtehtävissä ja am-mattitaitovaatimuksissa, mikä korostaa käyttäjien osallistumisen ja kehitys-toiminnan työvälineiden merkitystä.

3.1 Tavoitteen asettelun ongelmat

Toiminnanohjausjärjestelmähankkeiden luonteeseen kuuluvat olennaisesti risti-riitaiset tavoitteet (Ruohonen ja Salmela 1999, vrt. Engeström 1995). Hankkei-den laajuudesta johtuen niiden vaikutukset koskettavat monia työntekijöitä yliyksikkö- ja toimintorajojen, jolloin eri henkilöstöryhmien tavoitteetkin ovatmoninaisia ja usein keskenään ristiriitaisia. Tietojärjestelmähankkeissa ongel-makenttä on vielä usein monimutkainen ja epämääräinen, samoin kuin ollaanepätietoisia uudistusten toimivuudesta ja seuraamuksista. Tällöin yhtenäisten jaselkeiden tavoitteiden asettaminen sekä niiden tuloksellisuutta mittaavien kritee-rien muodostaminen on erityisen vaikeaa (Keen 1981; Forsman 1995). Nämä joorganisaatiotasolla ristiriitaiset tavoitteet (kustannussäästöt vs. työn rikastami-nen, informatisointi vs. automatisointi, vrt. Zuboff 1988) heijastuvat yksilöta-solla hankkeesta vastaavien henkilöiden päätöksenteon ja toiminnan ongelmina.Tavoitteenasetteluun ja niiden muuttamiseen hankkeen kuluessa, kuten myösniihin kytkeytyviin projektin resurssikysymyksiin, liittyvät tyypillisesti myöspäätöksenteko- sekä valta- ja vastuudilemmat, joita voidaan kutsua myös vallan-käytön pelitilanteiksi (Keen 1981; Ruohonen ja Salmela 1999, s. 159–160, 166–168). Pk-yrityksille tyypillisen puutteellisen tietohallinto ja -järjestelmä-osaamisen myötävaikutuksena riskinä on epärealistinen tavoitteenasettelu, mihinmyös toimittajataholta aggressiivisessa myyntivaiheessa saatetaan sortua.

Lisää monimutkaisuutta asiaan tuo käyttöönottoprosessissa kahden yrityksen –loppukäyttäjän ja ohjelmistotoimittajan – yhteinen projekti, jossa molemmilla onomat tavoitteensa ja motiivinsa. Toimittajan intresseissä on nopea ja kustannus-tehokas toimitus, minimiin rajatut konsultointi- ja koulutuspalvelut sekä standar-doitu järjestelmätuki. Käyttäjäorganisaatiot etenkin pk-sektorilla puolestaantavoittelevat pitkäaikaista asiakassuhdetta sekä monipuolista asiantuntijapalveluasoveltuvuusanalyysistä ja vaatimusmäärittelystä aina hallittuun käyttöönottoon

85

ja asiakaslähtöiseen ylläpitotukeen. Toisaalta asiakas usein edellyttää nopeaakäyttöönottoa.

Yrityskohtaista toimintaa tukeva järjestelmä edellyttäisi usein jonkintasoistaräätälöintiä, kun puolestaan toimittajan intressissä on usein pikemminkin mah-dollisimman standardoitujen toiminnanohjausjärjestelmien myyminen. Useim-miten Pk-yritysten investointiresurssien rajallisuus pakottaakin ne valitsemaanstandardoidun järjestelmän mahdollisimman vähäisin käyttöönotto-kustan-nuksin. Toimintamalli tukee siten toimittajien liiketoiminnallisia tavoitteita,mutta koituu usein käyttäjäyrityksen päänvaivaksi ja maksettavaksi (esim. tieto-järjestelmän käytön tehottomuuden muodossa). Toisaalta voidaan olettaa, ettämyös toimittajan tavoitteet ovat osittain sisäisesti ristiriitaisia (tehokkuus vs.asiakastyytyväisyys jne.).

3.2 Kommunikaation ja yhteistyön merkitys

Toiminnanohjausjärjestelmähankkeen onnistumisen eräs perusedellytyksistä ontoimiva kommunikaatio osapuolten välillä (ks. Forsman 1995; Ruohonen jaSalmela 1999; Airaksinen 2000) sekä yhteiset käsitteet ja mallit kommunikaa-tion avuksi. Uutta toiminnanohjausjärjestelmää harkittaessa on keskeistä kuu-lostella eri käyttäjä- ja sidosryhmien edustajien välityksellä yleisiä käsityksiätietojärjestelmän koetuista kehitystapeista ja vallitsevasta kehittämisilmapiiristä.Henkilöstön tiedottaminen ja henkilöstön orientointi muutokseen on aloitettavaprojektin varhaisessa valmisteluvaiheessa. Tietojärjestelmän (avain)käyttäjillevoidaan järjestää tilaisuuksia keskustella, jakaa kokemuksiaan ja kysellä muu-toksen tiimoilta heräävistä kysymyksistä. Apuna voidaan käyttää ulkopuolisiaasiantuntijoita (toimittajat, konsultit, tutkijat, muut käyttäjäyritykset) ja yritys-vierailuja. Näin voidaan edesauttaa tiedotuksen perillemenoa, rakentaa yhteis-ymmärrystä ja yhteistä tavoitetilaa eri käyttäjäryhmien kesken sekä tarjota käyt-täjille vaikuttamisen ja osallistumisen kokemuksia, jotka ovat erityisen tärkeitähankkeeseen sitoutumisen kannalta.

Tehokkaan viestinnän ja suotuisan vuorovaikutusilmapiirin avulla tuetaan ke-hittämisprosessin selkeyttä ja järjestelmällisyyttä. Tehokkaan kommunikaationkeskeisiä tehtäviä on muutosten tavoitteiden ja saavutettavien hyötyjen peruste-leminen ymmärrettävästi kaikille, joita muutos koskee sekä tavoitetilan ja senedellyttämien toimenpiteiden konkreettisuus ja perusteltavuus. Tietohallinnon ja

86

tietojärjestelmien kehittämisen tulisi olla mahdollisimman vuorovaikutteinenoppimisprosessi johdon ja käyttäjien ym. sidosryhmien välillä, mikä edesauttaayhteisen näkemyksen muodostumista organisaation tietoresursseista, niiden it-tuesta sekä hallinnosta osana organisaation toimintaa. (Airaksinen 2000.)

Hankkeiden vastuu- ja tehtäväkysymyksiin tulisi panostaa riittävästi suunnittelu-vaiheesta alkaen, mutta myös läpi hankkeen tulee käydä avointa keskustelua eriosapuolten kesken. Systemaattisella dokumentoinnilla projektin suunnittelusta jakehitystyön etenemisestä on olennainen merkitys esim. erimielisyyksien estämi-seksi. Jotta uusiin työrooleihin ja -tehtäviin sekä niiden edellyttämään uudenoppimiseen sitoudutaan, täytyy organisaation kulttuurin korostaa kommunikoin-tia, luottamusta ja informaation jakamista (ks. Zuboff 1988, s. 432–433; Tuo-misto 1999).

3.3 Muutokset työtehtävissä ja ammattitaitovaatimuksissa

Toiminnanohjausjärjestelmän käyttäjinä organisaatiossa ovat ensisijaisesti toi-mihenkilöt ja työnjohto, eli joukko yrityksen avainhenkilöitä. Heidän kauttaanjärjestelmän vaikutukset usein ulottuvat koko organisaatioon.

Yrityksen toiminnanohjausjärjestelmä on havainnollinen esimerkki siitä, mitensen toimintaprosessien suunnittelu-, ohjaus- ja kontrollointi muuttuu välittyneek-si ja siirtyy käsitteelliselle tasolle ja symbolikielelle (ks. Zuboff 1988, s. 192–201). Organisaation toimintaa ohjataan pitkälti informaatiovirtojen välityksellä,jotka linkittävät organisaation eri toiminnot, kuten tuotesuunnittelun, tuotannon-suunnittelun ja -ohjauksen, ostot, myynnin, markkinoinnin sekä taloushallinnontoisiinsa kompleksiseksi systeemiksi. Tietojärjestelmissä ja niiden sovelluksissaon taustalla oma logiikkansa, jolloin yrityksen toiminnanohjauksen kattavattietojärjestelmät saattavat merkitä käyttäjilleen uudenlaisen ajattelu- ja toimin-tamallin oppimista (kuten toimintojen jäsentäminen uudella tavalla, toimintojenvälisten suhteiden, keskinäisten informaatiovirtojen sekä yhteisten tietokantojenmerkityksen ymmärtäminen, toimintospesifien sovellusten symbolikielen tunte-minen jne.). Pienyrityksille tämä tyypillisesti merkitsee melkoista muutosta.Monissa pienyrityksissä esim. tuotannonohjaus hoidetaan vielä tänä päivänätuotantopäällikön tai työnjohtajan toimesta ruutupaperilla.

87

Omien työtehtävien lisäksi myös vuorovaikutus toisiin työntekijöihin muuttaamuotoaan. Työssä tarvittava tietämys muuttuu näiltä osin, kuten myös vaaditta-vat toimintatavat. Toimintojen keskinäisten yhteyksien sekä koko tilaus-toimitusketjun huomioonottaminen suunnittelu- ja päätöksentekotilanteissaedellyttävät prosessien tuntemusta ainakin yleisellä tasolla oman toimialan hal-linnan ohella – eli toisin sanoen aiemmin mainitun työprosessitietämyksenomaksumista (ks. Kruse 1986).

Toiminnanohjausjärjestelmän myötä tiedot ovat periaatteessa yhä useampienhyödynnettävissä jokapäiväisessä työssä (käyttöoikeuksien määrittämissä rajois-sa). Samalla se lisää ainakin järjestelmän käyttöönottovaiheessa erilaisten vir-heiden ja häiriöiden todennäköisyyttä eri toimintospesifien sovellusten hyödyn-täessä samoja tietokantoja (virheen monistuminen). Toiminnanohjausjärjestelmäsiten systematisoi ja yhdenmukaistaa organisaation tiedon hankintaa, jäsentä-mistä, muokkaamista, tallentamista, ylläpitämistä sekä hyödyntämistä toimin-nassa. Suunnittelu-, ohjaus- ja kontrollointiprosesseihin liittynyt tietämys myöseksplikoituu ja osaltaan näihin prosesseihin liittyvän hiljaisen tiedon ja osaami-sen merkitys vähenee. Seurauksena saattaa myös olla ristiriita uusien käsitteel-listen mallien – jotka määräytyvät usein järjestelmän ominaisuuksien mukaan –ja vanhan tacit-osaamisen välillä.

Samalla osaamisen ja tietämyksen omistajuus muuttuu yhä enenevässä määrinkollektiiviseksi, jolloin siihen liittyneet valta ja status menettävät merkitystään(Ks. Hakkarainen 2000; Wenger 1998). Kyseinen tilanne koskee erityisestityönjohdollisia tehtäviä, joita on vähitellen siirretty tuotantosolujen ja tiimienvastuulle. Tietämyksen omistajuuteen ja uudistusten tuomaan epävarmuuteenliittyvät arvovalta- ja rooliristiriidat heijastuvat henkilöstön muutosvastarinnaneri muotoina. Taustalla on pelkoa työtehtävien ja työskentelytapojen muutoksistaja kyvystä omaksua uusia taitoja ja toimintatapoja, valta-aseman ja statuksenmenettämisen uhka sekä rooliristiriitojen ja uuden toimenkuvan epämääräisyy-destä aiheutuva hämmennys. Tämän artikkelin johdannossa todettiin stressin jauupumuksen lisääntyneen erityisesti toimihenkilötasoilla, jossa myös työn luon-ne on tietojärjestelmien myötä eniten muuttunut.

Tietojärjestelmän muutosten aiheuttamien epävarmuuden ja epätietoisuudentuntemusten käsittelemiseksi ja toimintatapojen muutosten mahdollistamiseksityötehtävien ja vastuusuhteiden uudelleen muotoiluun yhteistyössä henkilöstön

88

kanssa on panostettava. Lisäksi on korostettava kollektiivisen tietämyksen jatoimintatapojen merkitystä organisaation toiminnan sujumisen ja tehokkuudenkannalta. Käytännössä tämä merkitsee töiden uudelleen organisointia ja roolienuudelleen määrittelyä niin että ne edesauttavat tiedonkulkua sekä yhteistyötähorisontaalisella ja vertikaalisella tasolla.

3.4 Käyttäjien osallistuminen ja kehitystoiminnan työkalut

Muutokset ajattelu- ja toimintatavoissa edellyttävät oppimiselle myönteistäympäristöä, joka rohkaisee keskustelemaan ja tekemään kysymyksiä.

− ”Sellainen ympäristö tuntuu edellyttävän tasavertaisuutta tiedon hallinnassaja toverillisia suhteita. Ympäristö tukee pelaamista ja kokeiluja sekä ottaahuomioon herkän yhteyden abstraktin työn ja sosiaalisen kanssakäymisentarpeen samoin kuin älyllisen tutkimisen ja kohonneen vastuuntunnon välil-lä.” (Zuboff 1988, s. 342.)

Toimintaympäristön tulisi olla sellainen, että se rohkaisee yleistämään ja tuotta-maan omista ja jaetuista kokemuksista uusia ja omaa toimintaa tukevia työväli-neitä ja käytänteitä (Wenger 1998; Hakkarainen 2000, s. 90–92).

Tietojenkäsittelyn kehittämisessä huomioonotettavia tekijöitä määritellessäänAiraksinen (2000, s. 111–116) painottaa henkilöstön laajaa osallistumista kehit-tämistoimintaan sitoutumisen ja motivoinnin kannalta. Pk-sektorille ominaistenniukkojen aika- ja osaamisresurssien vuoksi hän kuitenkin myös korostaa osal-listumisen priorisointia sekä järjestelmän tulevien käyttäjien, johdon ja tietojär-jestelmän ylläpitäjien osaamisen ja koulutustarpeiden kartoittamista. Näin ke-hittämistyö ja koulutus voidaan kohdistaa mahdollisimman taloudellisella jatarkoituksenmukaisella tavalla.

Toiminnanohjausjärjestelmän suunnittelu- ja käyttöönottoprosessia voidaantarkastella Laven ja Wengerin (1995) asteittain syvenevän osallistumisen näkö-kulmasta; muutokseen sitoutumisen ja siten sen onnistumisen kannalta on olen-naista ottaa (avain)käyttäjät mukaan tietojärjestelmäprojektiin alusta lähtien. Hemäärittelevät työssä kehittymistä legitimate peripheral participation -käsitteen(LPP) kautta, jolloin oppimisen kannalta on kriittisintä yksilön (oikeutetut)mahdollisuudet osallistua ja vaikuttaa omien ja yhteisöllisten toimintatapojen

89

jatkuvaan uusintamiseen ja muokkaamiseen. Jotta toimijoilla on riittävästi aikaaomien uusien työtehtäviensä, työvälineidensä ja toimintatapojensa kokeiluun jaopettelemiseen, on osallistuminen toteutettava asteittain (vrt. myös VII artikke-lissa esitetyt näkemykset prosessien liiallisen tehostamisen vaaroista).

Systeemityön näkökulmasta tietojärjestelmän käyttäjien panos nähdään tietojär-jestelmähankkeissa merkittävimpänä järjestelmän määrittely- ja suunnitteluvai-heessa. Käyttäjien on kyettävä kuvaamaan nykyisen järjestelmän ongelmat jakehittämistarpeet oman työnsä kannalta sekä hahmottamaan syntyvä toiminnal-linen kokonaisuus. Heidän on myös pystyttävä arvioimaan tietojärjestelmäntoiminnallisuutta suhteessa muuttuvaan toimintaympäristöön eli järjestelmäntoiminnallista joustavuutta, kykyä selviytyä poikkeustilanteista sekä toiminnanyhteyksiä muihin toimintoihin. (Forsman 1995, s. 147.) Näin he myös todellajoutuvat pohtimaan uudistuksen vaikutuksia omaan työhönsä sekä omaa rooliaansuhteessa organisaation toiminnan kokonaisuuteen ja muihin toimijoihin. Toi-saalta käyttäjien keskeinen rooli projektin alkuvaiheessa asettaa heille kohtuut-tomiakin vaatimuksia ja vastuun järjestelmän suunnittelu- ja kehittämistyönlähtökohtien määrittäjänä (vrt. Lave ja Wenger 1995).

Käyttäjien keskeisen roolin vuoksi järjestelmäkoulutuksen vaiheistuksen jasisällöllisten tarpeiden suunnittelulla on entistä suurempi merkitys muutoksenonnistumisen kannalta. Samalla atk-ammattilaisilta edellytetään kykyjä ymmär-tää kohdeyrityksen liiketoimintaa sekä mennä käyttäjän tasolle menetelmineen,käsitteineen ja asenteineen. Oppiminen on tehokkainta silloin, kun oppimisym-päristö vastaa mahdollisimman tarkasti ympäristöä, jossa opittuja kykyjä tullaankäyttämään. Jos uuden järjestelmän käyttöä opetellaan tai koulutetaan irrallisenaorganisaation toiminnan kokonaisuudesta, tietojärjestelmän käyttöön liittyvistäsuorituksista muodostuu helposti jäykkiä tottumuksia. Niiden muuttaminenjälkikäteen on vaikeaa (ks. Engeström 1995, s. 41). Näin ollen koulutus tulisitoteuttaa mahdollisimman lähellä käytännön toimintaa.

Kehitysryhmätyöskentely on yksi monipuolinen ja käytännönläheinen työsken-tely- ja oppimismuoto, jota voidaan hyödyntää useammassa toiminnanohjaus-järjestelmän suunnittelu- ja käyttöönottoprosessin vaiheessa (esim. vaatimus-määrittelyssä, testausvaiheessa jne.). Kehitysryhmien työskentelyssä oleellisiaovat niihin sisältyvät koulutus- ja oppimisprosessit. Kehitysryhmät muodoste-taan ongelman ympärillä toimivista henkilöistä ja ongelma-alueen asiantunti-

90

joista (toimittajaorganisaation edustajat, muut konsultit). Kehitysryhmätyösken-telyn tarkoituksena on aktivoida yrityksen henkilöstö – eli ne joita työssä esiin-tyneet ongelmat ja kehitystarpeet koskevat – ratkomaan yhteistyössä valittujakehityskohteita. Tavoitteena on hyödyntää työntekijöiden asiantuntemus sekämotivoida ja sitouttaa henkilöstö tietojärjestelmäprojektiin. (Ks. Simons jaHyötyläinen 1999, s. 141–148.)

Tietojärjestelmän kehittämisessä tämä merkitsee, että on ”paikannettava todelli-set tulevat käyttäjät, ymmärrettävä heidän nykyinen tapansa toimia, muutostar-peet ja siltä pohjalta kuvattava heille, miten uusi järjestelmä tulee toimimaan javaikuttamaan heidän työhönsä” (Forsman 1995, s. 49). Tällöin pyritään varmis-tamaan uudistuksen tarkoituksenmukaisuus, molemminpuolinen ymmärrysteknisistä ja toiminnallisista muutoksista ja siten tietojärjestelmän optimaalinenhyödyntäminen työssä. Tavoitteena on myös saada osallistujat tiedostamaanuudistusten merkitys ja vaatimukset uusien työskentelytapojen muodostumisellesekä edesauttaa niiden vakiintumista osaksi jokapäiväistä työtä.

Yleisestikin pk-yrityksillä ja järjestelmätoimittajilla on tarvetta yksinkertaisilleja helppokäyttöisille järjestelmäprojekteja tukeville työkaluille. Näitä voidaanmyös kutsua ajattelun ja toiminnan apuvälineiksi (vrt. Engeström 1995). Neauttavat toimijoita hahmottamaan ja eksplikoimaan omia työskentelytapojaan ja-tottumuksiaan sekä ymmärtämään oman roolinsa osana organisaation toimintaa(vrt. work process knowledge). Niin ikään ne harjaannuttavat tietojärjestelmienedellyttämää teoreettista ajattelua ja ongelmanratkaisuvalmiuksia. Ajattelu- jaongelmanratkaisuvälineet voivat olla konkreettisia tai käsitteellisiä kuten seinä-taulutekniikka, erilaiset prosessimallit, työnkuvaukset, syypuut, riesalistat sekäuuden tietojärjestelmän koulutus- ja kokeilutarkoitukseen räätälöidyt esiversiot.

Nykyiseen systeemityöhön kuuluu jo perinteisiä tarvemäärityksiä käyttäjäystä-vällisempiä menetelmiä, kuten näyttö- ja raporttimallit ym. dokumenttiaineisto.Ongelmana on kuitenkin kehittämiskohteiden ja kontekstin monimutkaisuussekä käyttäjien ja atk-ammattilaisen kommunikaatiokuilu. Sen sijaan prototyyp-pien (järjestelmän esiversioiden) käytöllä voidaan tarjota käyttäjälle havainnolli-nen ja todentuntuinen kuva tavoitellusta järjestelmästä ja sen vaikutuksista työ-tehtäviin. Niiden avulla järjestelmän tulevilla käyttäjillä on mahdollisuus tutus-tua järjestelmään ja kokeilla sitä eri tilanteissa ja toiminnoissa sekä arvioida sentoimivuutta käytännön työssä. Lisäksi esiversioiden avulla on mahdollista saada

91

tärkeää tietoa järjestelmän puutteista sekä itse järjestelmään että toimintatapoihinkohdistuvista muutostarpeista. Prototyypin rakentamisen sijasta voidaan myöshyödyntää sovelluskehitintä, jolla tuotetaan testattavat sovelluksen toiminnot.(Forsman 1995, s. 147–152.)

Käyttäjillä (avainhenkilöstö) on tärkeä rooli myös järjestelmän testausvaiheessa,jossa käydään järjestelmän äärellä läpi tärkeimmät toiminnot (tyypilliset kuva-ruutunäytöt, niiden tietosisältö, muodostettavat raportit, tapahtumalajien suorit-taminen normaali- ja poikkeustilanteissa sekä varamenettelyt) sekä selvitetääntoimintojen kehitystarpeet (Forsman 1995, s. 147–152). Järjestelmän käyttöön-otossa on varattava riittävästi aikaa rutiinisuoritusten harjoitteluun ja uusienkäytänteiden muotoutumiseen. Asteittaisen osallistumisen näkökulmaa tukeekehitysryhmätyöskentelyn ja prototyyppien käytön lisäksi järjestelmän käyt-töönotto moduuleittain. Sen ei olettaisi rasittavan liiketoimintaa ja henkilöstöäniin laajasti ja suuressa mittakaavassa, kuin mitä koko järjestelmän implemen-tointi kertarysäyksellä tekee.

Moduuleittain tapahtuvassa käyttöönotossa lähtökohtana on, että järjestelmäntoimivuutta pystytään arvioimaan todellisissa käyttötilanteissa ja että kokemuk-sia saadaan pidemmältä ajanjaksolta kuin pelkästään prototyyppejä hyödynnet-täessä. Tarkoituksena on, että järjestelmän käyttökokemuksista voidaan kerätätietoa systemaattisesti ja yhteistyössä käyttäjien kanssa. Avainkäyttäjät pyritäänottamaan mukaan kokeilemaan ja arvioimaan järjestelmän toimivuutta, kehittä-mään uudistusten edellyttämiä toimintatavallisia tai työmenetelmällisiä ratkai-suja sekä pohtimaan, miten kertyneitä käyttökokemuksia voidaan parhaitenhyödyntää muiden moduulien käyttöönoton yhteydessä. Avainkäyttäjillä ontällöin merkittävä rooli eräänlaisina mentoreina ja tietojärjestelmän käytönopastajina. Samalla tietoisesti pyritään rikkomaan ja ylittämään eri työ- ja hen-kilöstöryhmien välisiä rajapintoja osaamisen ja tietämyksen välittämiseksi jaedelleen jalostamiseksi (ks. Wenger 1998).

92

4. Lopuksi

Tässä artikkelissa esitelty käyttäytymistieteisiin pohjautuva, organisatoristaoppimista ja käyttäjien aktiivista osallistumista painottava näkökulma tietojär-jestelmähankkeisiin ei ole ideana uusi, mutta se on silti vielä varsin ideaalisellatasolla. Kuten johdannossa tuotiin esille, tietojärjestelmähankkeita on tutkittuorganisatorisen muutoksen näkökulmasta jo useita vuosikymmeniä. Samassaajassa tietojärjestelmät, kuten tässä erityisesti käsitellyt toiminnanohjausjärjes-telmät, ovat kehittyneet valtavasti. Yhtäältä niistä on tullut yhä käyttäjäystävälli-sempiä, toisaalta ne ovat monimutkaistuneet ja levittäytyneet yhä laajemmalleyrityksissä ja yritysverkostoissa. Samalla niistä on muodostunut yhä merkittä-vämpi strateginen kilpailutekijä, jolloin niiden tehokkaasta ja monipuolisestahyödyntämisestä on tullut toiminnan tuloksellisuuden kannalta entistä kriitti-sempää. Järjestelmien käyttöönottoprosessi on kuitenkin yhä monelle pk-yritykselle suuri organisatorinen ja liiketoiminnallinen haaste ja samalla myösriski. Tämä johtuu mm. yritysten rajallisista resursseista investointien, it-osaamisen, muutosprosessin hallinnan sekä toiminnan jatkuvan kehittämisensuhteen.

Pk-yrityksissä yhden henkilön osaaminen ja yritykselle tuottama lisäarvo onmerkittävämpi kuin suuryrityksissä, mutta toisaalta yhteistyön ja verkostoitumi-sen kautta syntyvä kollektiivinen osaaminen ja tietämys on yhä merkittävämpikilpailutekijä. Näin ollen yrityksen avainhenkilöiden osallistaminen ja sitoutta-minen tietojärjestelmähankkeeseen mahdollisimman alkuvaiheesta on hankkeenonnistumisen kulmakiviä. Pk-yrityksiltä kuitenkin puuttuu erityisesti niille so-veltuvia kehitystoiminnan menettelyitä ja työvälineitä, joiden kautta ne voisivatjoko omatoimisesti tai asiantuntijoiden avustamana tehostaa ja selkeyttää moni-tahoisten tietojärjestelmähankkeiden läpivientiä. Tämä pätee myös useisiinjärjestelmätoimittajiin, joilta usein puuttuu pk-yrityksten tarpeisiin soveltuvia,yksinkertaisia ja helppokäyttöisiä työvälineitä. Pk-yrityksille myös eri alojenasiantuntijoiden palkkaaminen on kallista puuhaa.

Monitieteisistä (tai -alaisista) asiantuntijoista koostuvat tietojärjestelmäprojektitvoivat silti tarjota vaihtoehtoisen ratkaisun hankkeiden monitahoisen problema-tiikan hallintaan. Esimerkiksi tietojärjestelmä-, tuotantotalous- ja käyttäytymis-tieteellistä osaamista yhdistävän monitieteisen asiantuntijaryhmän avulla onainakin periaatteessa mahdollista luoda monipuolinen ja kokonaisvaltainen

93

ymmärrys kehityskohteesta sekä rakentaa entistä paremmin yksilön ja työyhtei-sön oppimisprosesseja ja organisatorisia muutoksia huomioiva kehitysote myöstietojärjestelmähankkeisiin. Käyttäytymistieteellisellä näkökulmalla on merkit-tävä rooli tämän asiantuntemuksen tuojana.

Tieteen (toimi)alojen edustajien yhteistoiminta konkreettisissa tietojärjestelmä-projekteissa tarjoaa monipuolisia mahdollisuuksia yrityksiä hyödyttävien konk-reettisten kehitysmenettelyjen, koulutustapojen sekä apuvälineiden kehittämi-seen ja kokeiluun. Näin voidaan 1) tukea pk-yritysten tarpeisiin soveltuvienkäyttäjäkeskeisten käyttöönottoprosessien kehittämistä, 2) edesauttaa oppimis- jaorganisaatiopsykologisiin teorioihin tukeutuvien työvälineiden sekä toiminnantutkimuksen kehittämistä ja 3) luoda edellytyksiä eri tieteenalojen tähän astivarsin eriytyneiden paradigmojen ja kehitysotteiden yhdistämiselle. Monialais-ten osaajien yhdistäminen liiketoiminnassa on eräänlainen kehitystrendi, jonkaesim. informaatioteknologiaa tuottavat yritykset ovat jossain määrin omaksu-neet. Kuitenkin edelleen haasteena on sen monipuolinen ja (kustannus)tehokashyödyntäminen järjestelmätoimituksissa.

Lähdeluettelo

Airaksinen, T. 2000. Tietojenkäsittelyn kokonaisvaltainen suunnittelu Pk-yrityksissä. Tietojärjestelmätieteen pro gradu -tutkielma. Jyväskylän yliopisto.Tietojenkäsittelytieteiden laitos.

Argyris, C. 1990. Overcoming Organizational Defences. Facilitating Organiza-tional Defences. Boston: Allyn and Bacon.

Argyris, C. 1999. On Organizational Learning. 2nd ed. Oxford: Blackwell Busi-ness.

Argyris, C. & Schön D. A. 1996. Organizational Learning II. Theory, Methodand Practice. Massachusetts: Addison-Wesley Publishing Company.

Berger, P. & Luckmann, T. 1994. Todellisuuden sosiaalinen rakentuminen.Helsinki: Gaudeamus.

94

Cook, S. D. N. & Brown, J. S. 1999. Bridging Epistemologies: The generativeDance Between Organizational Knowledge and Organizational Knowing.Organization Science, Vol. 10, No. 4, July–August 1999, s. 381–400.

Engeström, Y. 1995. Kehittävä työntutkimus. Perusteita, tuloksia ja haasteita.Helsinki: Edita.

Forsman, L. 1995. Atk-projektin läpivienti. Espoo: Atk-kustannus Oy.

Giddens, A. 1984. The Constitution of Society: Outline of the Theory ofStructure. Berkeley, CA: University of California Press.

Hakkarainen, K. 2000. Oppiminen osallistumisen prosessina. Aikuiskasvatus2/2000, s. 84–98.

Holopainen, S., Lillrank, P. & Paavola, T. 1999. Tietotekniikan linkki liiketoi-mintaan. Otava.

Järvinen, A., Poikela, E. & Koivisto, T. 2000. Työssä ja työyhteisössä oppimi-nen. Juva: WS Bookwell Oy.

Kasvio, A. 1994. Uusi työnyhteiskunta: suomalaisen työelämän muutokset jakehittämismahdollisuudet. Helsinki: Gaudeamus.

Kauppi, A. 1993. Aikuinen oppimisensa ohjaajana. In: A. Kajanto (toim.).Aikuisten oppimisen uudet muodot. Vapaan sivistystyön 34. vuosikirja. Kansan-valistusseura ja Aikuiskasvatuksen tutkimusseura. Saarijärvi: Gummerus Kirja-paino Oy. S. 21–50.

Keen, P.G.W. 1981. Information Systems and Organisational Change. Com-munication of the ACM. January, Vol. 24, No. 1, s. 24–33.

Kempis, R.-D. & Ringbeck, J. 1999. Do It Smart. Seven Rules for SuperiorInformation Technology Performance. New York: The Free Press.

Kruse, W. 1986. On the Necessity of Labour Process Knowledge. In: Schweit-zer, J. (ed.). Training for a Human Future. Weinheim, Basle. S. 188–193.

95

Lave, J. & Wenger, E. 1995. Situated Learning, Legitimate Peripheral Participa-tion. New York: Cambridge University Press.

Leppänen, A. 1999. Työn muutos ja työntekijä – stressi, kriisi vai oppimismah-dollisuus. In: Tuomisto, J. & Sallila, P. (toim.). Työn muutos ja oppiminen.Aikuiskasvatuksen 38. Vuosikirja. Saarijärvi: Gummerus Kirjapaino Oy. S. 56–73.

Mezirow J. et al. 1996. Uudistava oppiminen (Leevi Lehto suom.) Helsinki:Painotalo Miktor.

Nonaka, I. & Takeuchi, H. 1995. The Knowledge-Creating Company. NewYork: Oxford University Press.

Nonaka, I. et al. 1999a. A Firm as a Knowledge Creating Entity: A New Pers-pective on the Theory of the Firm. Industrial and Corporate Change. OxfordUniversity Press. Vol. 9 (1).

Nonaka, I. et al. 1999b. SECI, Ba and Leadership: A Unified Model of DynamicKnowledge Creation. (To be published in Long Range Planning. Vol. 4–5/1.)

Pedler, M., Burgoyne, J. & Boydell, T. 1991. The Learning Company. A Strate-gy for Sustainable Development. London: McGraw-Hill Book Company.

Poikela, E. 1999. Kontekstuaalinen oppiminen. Oppimisen organisoituminen javaikuttava koulutus. Väitöskirja. Tampereen yliopisto, kasvatustieteiden laitos.Vammalan kirjapaino Oy.

Polanyi, M. 1958. Personal Knowledge. Towards a Post-Critical Philosophy.Chicago: Chicago University Press.

Roukala, V. 1998. Toiminnan muutoksen toteutus. Suomen Atk-kustannus Oy.Jyväskylä: Gummerus kirjapaino Oy.

Ruohonen, M. J. & Salmela, H. 1999. Yrityksen tietohallinto. Helsinki: Edita.

Ruohotie, P. 1996. Oppimalla osaamiseen ja menestykseen. Helsinki: Edita.

96

Sachs, P. 1995. Transforming Work: Collaboration, Learning and Design.Communication of the ACM. September, Vol. 38, No. 9, s. 36–44.

Sarala, U. & Sarala, A. 1996. Oppiva organisaatio. Oppimisen, laadun ja tuotta-vuuden yhdistäminen. Tampere: Tammer-Paino.

Senge, P. 1990. The Fifth Discipline. The Art & Practice of the Learning Or-ganization. London: Century Business.

Simons, M. & Hyötyläinen, R. 1999. Monenkeskisen verkostotoiminnan kehit-tämisen menetelmät ja välineet. In: Martin, O., Ranta, J. & Ylä-Anttila, P.(toim.). Verkostojen vallankumous – miten johtaa verkostoyritystä? Sitran jul-kaisuja. Vantaa: Tummavuoren Kirjapaino Oy. S. 132–149.

Sydänmaalakka, P. 2000. Älykäs organisaatio. Tiedon, osaamisen ja suorituksenjohtaminen. Jyväskylä: Gummerus Kirjapaino Oy.

Swieringa, J. 1992. Becoming a Learning Organization. Beyong the LearningCurve. Wokingham: Addison-Wesley Publishing Company.

Tuomisto, J. 1999. Työelämän uudet oppimisvaatimukset – lähtökohdat, haasteetja ongelmat. In: Tuomisto, J. & Sallila, P. (toim.). Työn muutos ja oppiminen.Aikuiskasvatuksen 38. Vuosikirja. Saarijärvi: Gummerus Kirjapaino Oy. S. 11–55.

Virkkunen, J. et al. 1999. Muutoslaboratorio – uusi tapa oppia ja kehittää työtä.Kansallinen työelämän kehittämisohjelma, Raportteja 6. Helsinki: Oy Edita Ab.

Warhurst, C. & Thompson, P. 1998. Hands, Hearts and Minds: Changing Workand Workers at the End of the Century. In: Thompson, P. & Warhurst, C.(toim.). Worplaces of the Future. London: Macmillan. S. 1–24.

Watkins, K.E. & Marsick, V.J. 1993. Sculpting the Learning Organization.Lessons in the Art and Science of Systematic Change. San Francisco: Jossey-Bass.

97

Wenger, E. 1998. Communities of Practice: Learning, Meaning and Identity.Cambridge: University Press.

WHOLE. 2000. Work Process Knowledge in Technological and OrganisationalDevelopment. Final Report. Framework Programme IV. European Union.

Zuboff, S. 1988. In the Age of the Smart Machine. The Future of Work andPower. New York: Basic Books.

98

IV Pk-yrityksen tietohallintostrategianmäärittely

Timo SiiraJyväskylän yliopisto, Tietotekniikan tutkimusinstituutti (TITU)

1. Johdanto

Tietoteknisten ratkaisujen ulottuminen yhä syvemmälle jokapäiväiseen työhönedellyttää sitä, että tietotekniikkaan liittyvät asiat hoidetaan suunnitelmallisesti jataloudellisesti, eikä niiden anneta ajelehtia oman onnensa nojassa. Tietoteknii-kan hallintaan organisaatioissa on kehitetty erilaisia menetelmiä ja strategioita.Useimmat niistä on suunniteltu suuria yrityksiä tai julkishallintoa varten, jotenniitä ei voida sellaisenaan käyttää pk-yrityksissä.

Pk-yrityksille on usein ominaista se, että tietotekniikkaan liittyviä asioita hoide-taan oman toimen ohella tai siihen liittyvät palvelut ostetaan kokonaan omanyrityksen ulkopuolelta. Toiminnanohjausjärjestelmien ja muiden strategisestitärkeiden sovellusten käytön lisääntyminen myös pk-yrityksissä asettaa paineitasuunnitelmallisuuden ja omien resurssien kasvattamiseen.

HANSKA-projektissa on tavoitteena lisätä pk-yritysten valmiuksia nykyisten jatulevien tietoteknisten ratkaisujen hallittuun käyttöönottoon. Tähän työhön ontarkoitus luoda yksinkertaisia, mutta ytimekkäitä menetelmiä, joiden avulla pk-yritykset voivat luoda kokonaiskuvan omasta tilanteestaan.

Aihealueeseen liittyviä käsitteitä on paljon ja niitä käytetään eri tutkimuksissaristikkäin. Kohdassa 2 selvitellään käsitteitä, niiden eroja ja niiden käyttöä erilai-sissa tilanteissa. Kohdassa 3 käydään hieman läpi tietojenkäsittelyyn liittyvienstrategioiden taustoja. Tietohallintostrategian suunnittelun lähestymistapojaesitellään kohdassa 4. Tietohallintostrategian laadintaan suunniteltuja mallejakäydään läpi kohdassa 5. Mitä tietohallintostrategian tulisi sisältää, käsitelläänkohdassa 6. Kohtaan 7 on kerätty niitä käytännön työn kautta saatuja kokemuk-sia, joita tietotekniikan kehittämisessä on kohdattu.

99

2. Käsitteitä

Pk-yrityksistä puhuttaessa on hyvä pitää mielessä, miten yritykset rajataan erikategorioihin kokonsa mukaan. ”Pienet ja keskisuuret yritykset määritelläänyrityksiksi,

− joiden palveluksessa on enintään 250 työntekijää

− joiden vuosiliikevaihto on enintään 40 miljoonaa euroa tai taseen loppu-summa on enintään 27 miljoonaa euroa ja

− jotka ovat itsenäisiä siinä mielessä, että niiden osakkeista enintään 25 % onsellaisen yrityksen omistuksessa, johon pk-yrityksen määritelmää ei voidasoveltaa.” (Pk-yritysraportti 1998, s. 98.)

Tietotekniikkaan liittyvistä käsitteistä ei alan tutkijoidenkaan keskuudessa ollapäästy yksimielisyyteen, joten asioita käsitellään eri lähteissä erilaisilla nimillä.Häiritsevintä on se, että samoja käsitteitä käytetään eri lähteissä eri tavoin. Tässäkohdassa pyritään selventämään keskeisiä käsitteitä ja määritellään, miten niitäkäytetään tässä raportissa.

− Tietotekniikalla (information technology) tarkoitetaan tiedon automaattistakäsittelyä ja siirron välineitä ja menetelmiä sekä niiden käytön osaamista(ATK-sanakirja 1999). Luftman et al. (1993) määrittelevät tietotekniikkaankuuluviksi laitteistot (tietokoneet, tiedontallennusvälineet, verkot ja kommu-nikaatiovälineet), sovellukset sekä palvelut (esimerkiksi help desk, ohjel-mistonkehitys, kantojen ylläpito), joita organisaatio käyttää jakaakseen da-taa, tietoa ja tietämystä. Earlin (1989, s. 95) mukaan tietotekniikka koostuuneljästä elementistä, jotka ovat: tietojenkäsittely (laitteistot ja niihin liittyvätkäyttöjärjestelmät), viestintä (viestintäverkot ja niiden toteuttamisessa jatoiminnassa tarvittavat välineet), tieto (yrityksen tietoresurssi ja tietoon koh-distuvien toimintojen vaatimukset) ja sovellukset (yrityksen tietojärjestel-mät, niiden toiminnat ja järjestelmien väliset riippuvuudet sekä kehittämis-menetelmät).

− Tietojärjestelmä (information system) ”on ihmisistä, tietojenkäsittelylait-teista, tiedonsiirtolaitteista ja ohjelmista koostuva järjestelmä, jonka tarkoi-

100

tuksena on tehostaa tai helpottaa jotain toimintaa tai tehdä toiminta mahdol-liseksi” (ATK-sanakirja 1999).

− Tietohallinto (information management) voidaan määritellä seuraavasti:”Organisaation toiminnot, jotka ohjaavat ja tukevat tietojen hankkimista,säilytystä, käsittelyä ja käyttöä” (ATK-sanakirja 1999).

− Tietojenkäsittely ”on tietoihin kohdistuvan toimituksen, kuten yhdistelyn,valinnan, uudelleen järjestämisen tai laskutoimituksen, tai tällaisten toimi-tusten sarjan suorittaminen haluttujen lopputulosten saamiseksi” (ATK-sanakirja 1999).

− Tietoväline ”on aines tai fysikaalinen ilmiö, jota voidaan käyttää tiedonesittämiseen” (ATK-sanakirja 1999).

ATK-sanakirjassa esitetyt käsitteet poikkeavat jonkin verran alan akateemisessakirjallisuudessa käytetyistä käsitteistä. Pk-yrityksissä varmaankin useimmitenturvaudutaan alan suomalaiseen kirjallisuuteen, joten on järkevämpää käyttääsiihen ympäristöön vakiintuneita termejä. Lisäksi akateemisessa kirjallisuudessaerilaisia määritelmiä kustakin käsitteestä on useita, jolloin niiden analysoimises-sa ja valinnassa on omat koulukuntansa, joiden arvioiminen tässä ei palveletarkoitustaan.

Kuvassa 1 esitetään tietohallinnon ja tietotekniikan käsitteet ja suhde siten, kunniitä tullaan tässä raportissa käyttämään.

101

ATK-laitteet

Ohjaa jatukee

Tietohallinto

TIETOTEKNIIKKA

Tietojenkäsittely

TietojärjestelmäTietoturva

Tieto

Kuva 1. Tietohallinnon suhde tietotekniikkaan.

Strategian (strategy) käsitteitä on käytössä paljon, ja ne poikkeavat toisistaanjonkin verran.

− Strategia koostuu Hamelin (1997) mukaan yksinkertaisimmillaan kahdestaasiasta: siitä, mihin yrityksen halutaan menevän, ja siitä, kuinka tämä toteu-tetaan. Ruohosen ja Salmelan (1999) mukaan Mintzbergin viiden p:n (plan,ploy, pattern, position ja perspective) määritelmä on kattavin. Yrityksenstrategia sisältää ominaisuuksia kaikista näistä viidestä tasosta (suunnitelma,ase tai isku, toimintatapa, asema tai asemointi ja näkökulma).

− Tietohallintostrategia (information management strategy) on pitkän aikavä-lin suunnitelma tietoresurssien hyväksikäytön suunnittelua, johtamista, to-teutusta ja valvontaa varten (Ruohonen ja Salmela, 1999; Reponen et al.1995).

Strategioiden hierarkioistakin on hieman erilaisia näkemyksiä. Leppänen et al.(1991) määrittelevät (kuva 2) strategioiden hierarkian siten, että tietojenkäsitte-lystrategian alle kuuluvat tietojärjestelmästrategia, tietotekniikkastrategia jatietohallintostrategia.

102

Ruohonen ja Salmela (1999) esittävät jaottelun (kuva 3), jossa käsitteitä onkäsitelty hieman eri tavalla. Yritysstrategian (eli liiketoimintastrategian) alaisenaon tietohallintostrategia, joka kattaa tietojärjestelmästrategian ja tietotekniikka-strategian. Henkilöstöstrategia on nostettu myös esille sen ja tietohallintostrate-gian vahvan vuorovaikutuksen vuoksi. Muihin strategioihin heidän mallissaan eiole otettu kantaa. Tässä raportissa käytetään kuvan 3 mukaista jaottelua.

Pk-yrityksessä strategioiden hierarkioiden suhteet eivät ole käytännössä kovin-kaan oleellisia, koska useimmissa tehdään (ja on järkevintä tehdä) vain yksistrategia, jossa määritellään tietotekniikkaan liittyvät asiat.

Liiketoiminta-strategia

Rahoitus-strategia

Tuotanto-strategia

Markkinointi-strategia

Tietojenkäsittely-strategia

Tietojärjestelmä-strategia

Tietotekniikka-strategia

Tietohallinto-strategia

……

………

………

…

Kuva 2. Strategiahierarkia (Leppänen et al. 1991).

103

Kuva 3. Strategiahierarkia (Ruohonen ja Salmela 1999).

3. Taustaa

Tietojenkäsittelyn strategioita alettiin laatia 1960- ja 1970-lukujen taitteessa,jolloin tavoitteena oli luoda pitkäntähtäimen suunnitelmia, joiden avulla voitai-siin mm. tunnistaa laitekapasiteetin tarve ja kustannukset (Sääksjärvi 1990).MIS-strategian (Management Information Systems) esittelivät McLean ja Sodenvuonna 1977. Se jakaantui lyhyen, keskipitkän ja pitkän aikavälin suunnitteluun.Lähtökohtana oli useimmiten tietotekniikka ja sen tarjoamat mahdollisuudet.

BSP-menetelmän (Business Systems Planning) julkaisi IBM vuonna 1975. Me-netelmä oli kehitetty jo 1960-luvun puolella IBM:n sisäiseen käyttöön. BSP oliensimmäinen kokonaisvaltainen tietojenkäsittelyn suunnittelumenetelmä, jonkalähtökohtana oli yrityksen strategia ja jota laadittiin yhteistyössä liikkeenjohdonkanssa. BSP jakaantui kahteen vaiheeseen: liiketoimintojen tarpeiden tunnista-miseen ja tietojärjestelmien määrittelyyn.

Ein-Dor ja Segev (1978) esittelivät strategian ulottuvuuksina neljä dimensiota:

− kehittämisen suunta (top-down, bottom-up, inside-out, parallel, evolu-tionary)

− organisaation rakenne (tuote-markkina-kombinaatioiden lukumäärä, tulos-vastuullisten yksiöiden lukumäärä)

Yritysstrategia

Henkilöstö-strategia

Tietohallinto-strategia

Tietojärjestelmä-strategia

Tietotekniikka-strategia

104

− integraatio (yhteisen tiedon ja sovellusten osuudet)

− pioneerirooli (ainutlaatuisten sovellusten osuudet verrattuna saman toimialanmuihin yrityksiin).

Heidän käsityksensä mukaan tietojärjestelmien strategisen suunnitelman olioltava eksplisiittisesti ilmaistu ja yrityksen tilannetta vastaava.

Tietojenkäsittelyn kokonaistutkimuksen menetelmää kehitettiin 1970-luvun lo-pulla ja 1980-luvun alussa Suomessa (Sääksjärvi, 1983). Menetelmällä haluttiinpidentää suunnittelun aikaperspektiiviä ja liittää tietojenkäsittelyn suunnitelmatyksikön toiminnan suunnitelmiin. Menetelmää kehitettiin pääasiassa valtionhal-linnossa. Menetelmästä on olemassa käsikirja METO 2. Keskeistä menetelmässäon nykytilanteen kartoittaminen, tulosten analysointi, tietojärjestelmän arkki-tehtuurin suunnittelu ja kehittämistavoitteiden sekä hankemääritysten tuottaminen.

James Martin toi vuonna 1980 BSP:hen mukaan tiedonhallinnan menetelmiä(Sääksjärvi 1990). SRM-menetelmän (SysteemienRakentamisMalli) luoneetMikkonen ja Soini käyttivät lähtökohtinaan BSP:tä täydentäen sitä Martininmenetelmillä. Tarkastelun lähtökohtana ovat organisaation toiminnot, jotkaoletetaan pysyväisluonteisiksi.

METO 2:n jälkeen ilmestyi METO 3, jossa kehittämistyöhön tarvittavaa työ-määrää pyrittiin vähentämään. Tavoitteeksi asetettiin tietojenkäsittelystrategianmukauttaminen osaksi yrityksen liiketoimintastrategiaa (Sääksjärvi 1990).

SPITS-menetelmässä (Strategic Planning of Information Technolgy Services)tavoitteena on tukea toimintaa, jolla analysoidaan ja kehitetään organisaationpalvelustrategiaa hyväksikäyttämällä tietoteknisiä ratkaisuja sekä suunnitellaantietotekniikkastrategia, joka palvelee mahdollisimman hyvin palvelustrategiaa(Leppänen et al. 1991).

SISP (Strategic Information Systems Planning) eli tietojärjestelmien strateginensuunnittelu sai alkunsa 1980-luvun loppupuolella. Siinä organisaatio pyrkiilöytämään tietojärjestelmäportfolion, jolla se panee täytäntöön liiketoiminta-suunnitelmansa ja pyrkii saavuttamaan liiketoiminnalliset tavoitteensa. Spilin jaSalmelan (1999) mukaan suunnitteluprosessin keskeisiä menestystekijöitä ovat:

105

1. Se sopii organisaation ympäristöön ja suunnittelukulttuuriin.2. Se on realistinen huomioidessaan saatavissa olevat resurssit.3. Se tarjoaa riittävästi kykyä tietohallintostrategian ja liiketoimintastrategian

sovittamiseen.4. Se tarjoaa riittävästi kykyä tuottaa tarpeellisia analyysejä.5. Se varmistaa yhteisymmärryksen ja tukee päätösten ja suunnitelmien toteu-

tumista.6. Se sisältää itsearvioinnin ja suunnitteluprosessista oppimisen.

Tietojenkäsittelyn rooli organisaatioissa voidaan Wardin (1990) mukaan kar-keammalla tasolla jakaa kolmeen aikakauteen:

1. tiedon käsittely (Data Processing, DP)2. johdon tietojärjestelmät (Management Information Systems, MIS)3. strategiset tietojärjestelmät (Strategic Information Systems, SIS).

Tietohallintoon liittyvien strategioiden ja menetelmien suunnittelu alkoi ensim-mäisen aikakauden loppupuolella. Toisella aikakaudella keskeistä oli järjestel-mistä saatava informaatio päätöksenteon tueksi. Kolmannella aikakaudella tie-tojärjestelmien rooli on muuttunut yhä kriittisemmäksi organisaatioiden toimin-nan kannalta. Vaikka jaottelu on jo yli kymmenen vuotta vanha, niin tällä het-kellä elämme edelleen kolmatta vaihetta. Muutos uuteen aikakauteen on kuiten-kin jo käynnissä, kun uusien yritysten toiminta saattaa perustua lähes pelkästääntietojärjestelmien hyödyntämiseen.

Tietojenkäsittelyn strategioita on tutkittu lähinnä suuryrityksissä. Pk-yritykseteivät useinkaan toimi niin formaalisti kuin suuryritykset. Tällainen toimintatapavähentää yleistä strategista suunnittelua ja siten myös tietojenkäsittelyn strate-gista suunnittelua organisaatioissa (Halttunen 1995). Pk-sektorinkin on otettavakantaa tietotekniikkaan, koska sekä tuotannossa että kommunikoinnissa tietotek-nisten välineiden mukaantulo on lähes väistämätöntä.

4. Tietohallintostrategian suunnittelun lähestymistavat

Lähes kaikki lähestymistavat, joita käytetään tietohallintostrategioiden suunnit-teluun, pohjautuvat jollain lailla tietojärjestelmien suunnitteluun. Alan kirjalli-suudessa strateginen suunnittelu ja tietojärjestelmät yhdistetään yhdeksi koko-

106

naisuudeksi, jossa useimmiten on tavoitteena tietojärjestelmien suunnittelu tainiiden kehittäminen.

Earl (1993) esittelee jaottelun viiteen lähestymistapaan:

1. liiketoimintalähtöinen lähestymistapa2. menetelmälähtöinen lähestymistapa3. hallinnollinen lähestymistapa4. teknologinen lähestymistapa5. organisatorinen lähestymistapa.

Liiketoimintalähtöisessä lähestymistavassa liiketoiminnan suunta ja tulevatliiketoimintasuunnitelmat ovat ainoa perusta, jolle tietohallintosuunnitelmiavoidaan rakentaa. Liiketoimintastrategia siis määrittelee tietohallintostrategian.Liiketoimintastrategiaa tai -suunnitelmia analysoimalla pyritään löytämäänkohteet, joissa on suurin tarve tietojärjestelmille. Lähestymistavan keskeisiäpuutteita ovat:

− Liiketoimintastrategiat eivät ole riittävän selkeitä ja yksityiskohtaisia tieto-hallinnon tarpeisiin.

− Tietotekniikan strategista merkitystä on vaikea tuoda esiin.

− Käyttäjät ja linjajohto voivat vaikuttaa vain vähäisessä määrin tietotekniik-kaan liittyviin ratkaisuihin.

Hyvinä puolina voidaan mainita tietojärjestelmien näkeminen strategisena re-surssina. Tietohallinnon olemassaololle on selkeä oikeutus.

Menetelmälähtöisessä lähestymistavassa tietohallinnon suunnittelun oletetaantehostuvan formaaleja tekniikoita tai menetelmiä käyttämällä. Menetelmävetoi-suus ei kovinkaan usein toimi. Tämä johtuu mm. menetelmien heikkouksista,toteuttajien taitojen puutteesta, konsulttivetoisuudesta tai käyttäjien vastarinnas-ta. Lähestymistapa voi kuitenkin osoittaa tarpeen liiketoimintastrategialle tai sevoi opettaa tietohallinnolle liiketoiminnan lainalaisuuksia.

107

Hallinnollisessa lähestymistavassa pääpaino on resurssien suunnittelussa. Lii-ketoimintayksiköt tuovat tarpeita esiin, jonka jälkeen tarpeet priorisoidaan jatarpeet toteutetaan resurssien mukaisesti tärkeimmästä alkaen. Ongelmana onradikaalien muutosten tekeminen ja kokonaisvaltaisen strategisen ajattelun puu-te. Lähestymistavan vahvuutena voidaan mainita se, että toimintatapa on kaik-kien tiedossa, jolloin kaikki voivat tuoda tarpeitaan esiin. Tietohallinnon johta-minen on hankalaa tällaisessa tilanteessa, ja budjetin leikkauksien ei oletetaolevan kovinkaan kohtalokkaita, koska ne leikkaavat vain vähemmän tärkeätprojektit pois.

Teknologisessa lähestymistavassa perusoletuksena on, että tietojärjestelmä-orientoinut malli liiketoiminnasta on välttämätön ja että tämän vuoksi analyytti-set mallinnusmenetelmät kuuluvat asiaan. Lähestymistapa on raskas runsaan jamonipuolisen mallinnuksen vuoksi. Hyvinä puolina voidaan mainita selkeidenmallien saaminen, joiden avulla voidaan joustavammin edetä mm. tietokantojenja laitteistoarkkitehtuurien suunnitteluun.

Organisatorisessa lähestymistavassa perustana on tietohallinnon ja organisaa-tion jatkuva integraatio. Menetelmiä käytetään, mutta ne valitaan tilanteen mu-kaan. Keskeistä on johdon ymmärrys ja osallistuminen. Organisatorinen oppimi-nen on tärkeää kolmella tavalla. Ensiksikin tietohallinnon suunnittelussa pitääkeskittyä yhteen tai kahteen teemaan. Toiseksi tietohallinnon asiantuntijoidenmukaan ottaminen johdon tiimiin jo suunnitteluvaiheessa auttaa suuntaamaan rat-kaisuja. Kolmanneksi teemojen jakaminen selkeisiin osiin tukeen niiden toteut-tamista. Ongelmista voidaan mainita kokonaissuunnittelun puute, uusien teemojenlöytymisen vaikeus ja heikkotasoisten rakenteellisten ratkaisujen syntyminen.

Toinen jaottelu perustuu Mats Lundebergin tutkimuksiin (Ruohonen ja Salmela1999), ja siinä painotetaan mallintamisen lähtökohtia. Lähestymistavat kuvaavattietojärjestelmille annettavaa roolia organisaatioissa. Lähestymistavat ovat aika-järjestyksessä vanhimmasta uusimpaan:

1. rutiinikeskeinen lähestymistapa2. tietokeskeinen lähestymistapa3. toimintokeskeinen lähestymistapa4. liiketoimintakeskeinen lähestymistapa5. organisaatiomuutoskeskeinen lähestymistapa.

108

Rutiinikeskeisessä lähestymistavassa tietojärjestelmän rooliksi nähdään vainrutiiniluonteisten operaatioiden hoitaminen. Tämä lähestymistapa on jo vanhen-tunut, sillä tietotekniikan on tarjottava paljon muitakin mahdollisuuksia kuinvain rutiiniluonteisen työn helpottaminen.

Tietokeskeisessä lähestymistavassa lähtökohtana ovat organisaation tiedot janiiden yksityiskohtainen mallintaminen. Mallien avulla voidaan suunnitellatietojärjestelmiä, integroida eri järjestelmiä ja hallita koko organisaation tieto-pääomaa. Nykyiset toiminnanohjausjärjestelmät pohjautuvat osin tähän lähesty-mistapaan, koska niiden keskeisenä tehtävänä on hallita keskitetysti organisaationtietoja. Lähestymistavan heikkoutena on toiminnallisuuden unohtaminen. Pelkällätietojen mallintamisella järjestelmistä tulee usein kankeita käyttää ja muokata.

Toimintokeskeisessä lähestymistavassa keskeisellä sijalla ovat olleet (organisaa-tion) toiminnot. Kullekin organisaation toiminnolle on haluttu rakentaa sellainenjärjestelmä, joka parhaiten tukee ao. toiminnon omaa työskentelytapaa. Lähtö-kohtana ovat olleet liiketoiminnan tarpeet ja toimintaperiaatteet, mutta ongel-maksi on usein noussut toimintoja ylittävien järjestelmien toteuttaminen sekätiedon siirtäminen toimintojen välillä.

Liiketoimintakeskeisessä lähestymistavassa on edellytetty tietojärjestelmientoteuttamisen lähtevän liiketoiminnalle asetettavista tavoitteista. Tietojärjestel-mille on olemassa oikeutus vain, jos niiden nähdään tuottavan organisaatiollelisäarvoa. Lisäksi liiketoiminnoilla on oltava ymmärrystä pitkäntähtäimen muu-toksille, jotta järjestelmiä rakennettaessa mahdolliset muutokset voidaan huo-mioida.

Organisaatiomuutoskeskeisessä lähestymistavassa lähtökohtana ovat organisaa-tion ja sen työntekijöiden tarpeet sekä liiketoiminnalle asetetut tavoitteet jatulokset. Tietojärjestelmien tulee ottaa huomioon erilaisten käyttäjien sekä mo-nenlaisten sidosryhmien tarpeita, jotta se voi tarjota riittävän vahvan tuen työnsuorittamiselle. Organisaatiossa tapahtuva oppiminen tulisi kyetä tallentamaanjärjestelmään niin, että sitä voitaisiin jatkossa hyödyntää liiketoiminnassa.

Tietotekniikan ja liiketoiminnan suhdetta on kuvattu kolmella erilaisella näkö-kulmalla (Ruohonen ja Salmela 1999):

109

1. Nykyinen ja tuleva liiketoiminta määrittelevät tietotekniikan hyväksikäytön.2. Tietotekniikan kehitys ohjaa liiketoimintaa.3. Liiketoiminta ja tietotekniikan kehitys kulkevat rinnakkain.

Ensimmäinen näkökulma kuvaa perinteistä ajattelutapaa, jolla suhtaudutaantietotekniikkaan. Tällöin tietotekniikka alistetaan palvelemaan tiettyjä tavoitteita,mutta sillä itsellään ei ole sellaista arvoa, jota voitaisiin hyödyntää esim. liike-toiminnan kehittämiseen.

Toinen näkökulma on melko radikaali, ja sitä ei varmaankaan toteuteta kovin-kaan monessa yrityksessä. Näkökulmana se on kuitenkin vahvistumassa, sillä ns.virtuaaliyrityksien (toimivat vain Internetissä) määrä on kasvamassa. Tällaisetyritykset voivat muokata liiketoimintaansa uusien teknisten ratkaisujen mukai-seksi ja saavuttaa tällä kilpailuetua tai jopa merkittävän markkina-aseman.

Kolmas vaihtoehto on ehkä kaikkein haluttavin, mutta se on melko vaikea to-teuttaa. Liiketoiminta saattaa muuttua erittäin hitaasti ja tietotekniikka nopeasti,jolloin niiden yhteensovittaminen kunakin hetkenä voi olla hyvinkin vaikeaa.

Tietohallinnon suunnittelun ja johtamisen kehitystyyppejä ovat (Ruohonen1989):

1. kustannusohjautuva tietojärjestelmäsuunnittelu2. tekniikkaohjautuva tietojärjestelmäsuunnittelu3. liiketoimintaohjautuva tietojärjestelmäsuunnittelu4. strateginen tietojärjestelmäsuunnittelu.

Kustannusohjautuvassa tietojärjestelmäsuunnittelussa tietotekniikka on tukitoi-minto ja sen rooli on toimia kustannusten vähentäjänä. Projektien arviointipe-rusteena on kustannus-hyötyanalyysi. Välillisiä ja vaikeasti mitattavissa oleviahyötyjä ja vaikutuksia ei pystytä ottamaan huomioon (ks. myös tämän julkaisunVIII artikkeli).

Tekniikkaohjautuvassa tietojärjestelmäsuunnittelussa korostetaan kustannustenlisäksi valmiita teknisiä ratkaisuja. Tietotekniikalla on rooli myös tuotantopro-sessissa, mutta lähtökohtana ovat tekniset ratkaisut, eivät liiketoiminnan tarpeet.Suunnittelu on tekniikkavetoista ja tavoitteena on etsiä valmiita laitteisto- ja

110

ohjelmistoratkaisuja. Kilpailuetua on vaikea saavuttaa, koska kuka tahansa voitoteuttaa vastaavia ja parempia ratkaisuja.

Liiketoimintaohjautuvassa tietojärjestelmäsuunnittelussa otetaan kustannusten jatekniikan lisäksi huomioon liiketoiminnat tarpeet ja vaatimukset. Suunnittelussahuomio kiinnittyy liiketoiminnan muutoksiin, ja liiketoimintastrategiaa pyritääntoteuttamaan tietotekniikan hyväksikäytön avulla.

Strategisessa tietojärjestelmäsuunnittelussa pyritään ottamaan huomioon kustan-nusten, tekniikan ja liiketoiminnan lisäksi organisaation rakenne, kulttuuri jahenkilöiden osaaminen. Tärkeää on arvioida organisaation tietoresurssien johta-misen kypsyys. Tietojärjestelmien avulla pyritään toteuttamaan yrityksen strate-giaa kokonaisvaltaisesti, jolloin tietohallintostrategian rinnalle on nostettavamyös henkilöstöstrategia.

5. Tietohallintostrategian laadintamalleja

Pk-yrityksen tietohallintostrategian luomisessa raskaiden metodologioiden hyö-dyntäminen ei ole mielekästä, vaan järkevämpää on käyttää yksinkertaisia mal-leja, joilla voidaan helposti päästä asian ytimeen.

Moniulotteinen malli (Earl 1989) on nimestään huolimatta (a multiple metho-dology) kohtuullisen yksinkertainen malli strategian laadintaan (kuva 4). Pk-yrityksissä mallista voidaan ottaa käyttöön tukipylväät, joilla tietohallintostrate-giaa lähdetään toteuttamaan.

Perusajatuksena on se, että strategian luonnissa on kolme lähtökohtaa: liiketoi-minnan suunnitelmat ja tavoitteet, nykyiset järjestelmät ja tietotekniikan tarjoa-mat mahdollisuudet.

111

Liiketoiminnansuunnitelmat ja

tavoitteet

Nykyisetjärjestelmät

Tietotekniikantarjoamat

mahdollisuudet

Analyyt-tinen

Metodo-logia

Tiimityö

Kokeileva

Kyselyt jamittaamiset

Käyttäjät jaasiantuntijat

Luova

Tekniikat,prosessit jaympäristö

Älyn-väläyksetja huippu-tuotteet

Toteutustason strateginen suunnitelma

Ylhäältäalas

Alhaalta ylös

Sisältäulos

Kuva 4. Moniulotteinen malli strategian laadintaan (Earl 1989).

Liiketoiminnan suunnitelmat ja tavoitteet toimivat ylhäältä alas -lähestymistavan(top-down) lähtökohtana, jolloin tavoitteena on toteuttaa esim. tietojärjestelmiäliiketoiminnan tavoitteisiin. Liiketoiminnan mallintamisessa ja suunnitelmientarkentamisessa sekä tietojärjestelmien tarpeiden kartoittamisessa formaalitmenetelmät ovat tarpeen, jolloin tarvitaan jotain metodologiaa. Mallinnus onmahdollista toteuttaa ainoastaan tiimityönä, johon osallistuvat yrityksen työnte-kijät eri organisaatiotasoilta. Mallin ensimmäinen tukipylväs tuottaa strategiaavarten liiketoiminnan vaatimukset tietotekniikalle.

Nykyisten järjestelmien analysointi on tärkeää, jotta voidaan selvittää, mitä pitääparantaa, miksi se pitää tehdä ja miten se voitaisiin tehdä. Tämä tapahtuu al-

112

haalta ylös -lähestymistavalla (bottom-up) keräämällä tietoa järjestelmistä jakatsomalla niiden kattavuutta suhteessa liiketoimintaan. Yrityksellä oleva koke-mus on tärkeä tiedon lähde tehtäessä päätöksiä uusista investoineista. Liiketoi-minnalle tuotettava kilpailuetu ei synny useinkaan standardituotteilla, vaan niitäon kehitettävä omiin tarpeisiin sopiviksi. Järjestelmiä on tutkittava ja mitattavakäyttäjien ja asiantuntijoiden yhteistyöllä, jotta nykyinen tilanne ja järjestelmienkattavuus saadaan selvitettyä.

Tietotekniikan tarjoamat mahdollisuudet voidaan jakaa kolmeen luokkaan:tekniikat, prosessit ja teknologiat. Sisältä ulos -lähestymistavan (inside-out)ajatuksena on lähteä liikkeelle tietotekniikasta ja katsoa, mitä mahdollisuuksia sevoi liiketoiminnalle tarjota. Useimmiten tätä tietoa on ostettava yrityksen ulko-puolelta tahoilta, jotka ovat asiaan perehtyneet. Tietotekniikan uudet sovelta-mistavat vaativat huomattavaa innovatiivisuutta, mutta useimmiten huomattaviaparannuksia voidaan tuottaa pienelläkin työllä.

Moniulotteinen malli antaa hyvän lähtökohdan tietohallintostrategian laadintaan.Kolmesta tukipylväästä ensimmäinen on selkeimmin yrityksen sisältä lähtöisin.Kolmas tukipylväs on ulkopuolelta hankittavaa osaamista. Toinen tukipylväs onosin yrityksen sisäistä arviointia ja osin ulkopuolisen suorittamaa auditointiajärjestelmille. Näillä kolmella elementillä voidaan yrityksen avainhenkilöiden jaulkopuolisten konsulttien avulla rakentaa toimiva tietohallintostrategia.

EMIS-mallia (Evolution Model for Information Strategy) on usean vuoden ajankehitelty Turun kauppakorkeakoulussa. Malli kuvaa tietohallinnon strategiatyös-kentelyä (mm. Reponen 1987 ja Ruohonen ja Salmela 1999). Sitä on kokeiltuuseissa suomalaisyrityksissä. EMIS (kuva 5) ei ole puhdas vaihejakomalli, vaantarkoituksena on kuvata erilaiset teemat, joita työskentelyyn liittyy.

Suunnittelun lähtökohtana on luoda johdon oppimis- ja suunnitteluprosessi, jossajohto ja asiantuntijat laativat yhteisen näkemyksen liiketoiminnan ja tietoteknii-kan soveltamisen yhdentämisestä. Suunnittelu- ja oppimisprosessin vieminenrinnakkain on mallin keskeisiä ajatuksia. Strategia syntyy ensin ajatuksissa,jonka jälkeen se kootaan strategiapaperiksi. Tarkoituksena ei ole edetä kaava-maisesti, vaan johonkin vaiheeseen voidaan palata täydentämään tietoja.

EMIS-malli keskittyy seuraaviin alueisiin (Ruohonen ja Salmela 1999):

113

− kehittämistarpeen havaitseminen ja projektin aloittaminen− nyky- ja tavoitetilan kartoitus− strategisen suunnittelun suuntaviivojen luominen− varsinainen suunnittelutyö− strategiaehdotuksen muotoilu ja käsittely− strategian toteutus ja seuranta.

Organisaationrakenne japrosessit

TekniikkaKilpailuvoimat

Tarpeenhavaitseminen

ja ajoitus

Analyysi

Strategisensuunnittelunsuuntaviivat

Suunnittelu

Tavoitteet

ToimintamalliResurssit

Strategia

Toteutus jaseuranta

Kuva 5. EMIS-mallin vaiheet (Ruohonen ja Salmela 1999).

114

Lopputuloksena syntyy tietohallintostrategian osat (kuva 6). Tavoitteissa määri-tellään tietotekniikan asema ja siihen liittyvät kilpailulliset tavoitteet. Resurssitkäsittävät ihmiset, tiedot, sovellukset, laitteistot ja tietoliikenteen. Toimintamal-lissa määritellään se, miten resursseja käytetään ja organisoidaan, jotta halututtavoitteet saavutettaisiin.

Organisaationrakenne japrosessit

TekniikkaKilpailuvoimat

Tavoitteet

ToimintamalliResurssit

Kuva 6. Tietohallintostrategian osat (Ruohonen ja Salmela 1999).

6. Tietohallintostrategian sisältö

Tietohallintostrategian sisältöä voidaan kuvata monin tavoin ja monella erilai-sella tarkkuustasolla. Mitä tarkemmalle tasolle mennään, sitä laajemmaksi jakattavammaksi se muuttuu. Pk-yrityksen kannalta on ehkä järkevintä pitää sy-vyystaso kohtuullisen matalana, jotta strategian päivittäminen ei jäisi sen vaati-man suuren työmäärän vuoksi.

Tietohallintostrategian keskeistä sisältöä ovat (kuva 6): tavoitteet (tietotekniikanasema ja siihen liittyvät kilpailulliset tavoitteet), resurssit (ihmiset, tiedot, so-vellukset, laitteistot ja tietoliikenteen) ja toimintamalli (resurssien käyttö jaorganisointi, haluttujen tavoitteiden saavuttamiseksi). Sisältöön vaikuttavia

115

muutosvoimia ovat: kilpailuvoimat, organisaation rakenne ja prosessit sekätekniikka (Ruohonen ja Salmela 1999).

Tavoitteet kuvaavat karkealla tasolla, mitä tietotekniikan käytöllä pyritään yri-tyksessä saavuttamaan ja miten muutoksia voidaan toteuttaa. Tavoitteita voivatolla mm. liikesuhteiden hallinta, tehokkuuden parantaminen ja päätöksenteontukeminen. Tavoitteiden tarkistaminen on syytä suorittaa aina, kun muutosvoi-missa tapahtuu huomattavia muutoksia.

Yrityksen menestymiseen vaikuttavat huomattavasti sen resurssit. Ihmisten tietoja osaaminen ovat keskeisiä resursseja, joiden korvaaminen voi olla todellavaikeaa. Tietotekniikka niveltyy liiketoimintaan ihmisten työn kautta, jotenihmisten tietojen ja taitojen tulee olla ajan tasalla. Tietojen ja sovellusten suun-nittelulla määritellään tietovirrat, tietojen hajautus ja sovelluskehityksen rytmi-tys. Laitteistojen ja tietoliikenteen suunnittelulla pyritään varmistamaan järjes-telmien yhteensopivuus ja laajennettavuus. Tietoliikenteessä tulee ottaa huomi-oon myös organisaatioiden välinen tiedonsiirto ja viestintä. Resurssien riittä-vyyttä on tarkasteltava tekniikan kehittyessä ja henkilöstövaihdoksissa.

Toimintamallilla määritellään se, miten asetetut tavoitteet toteutetaan saatavissaolevilla resursseilla. Toimintamallissa tulisi olla määriteltynä tietohallinnonorganisointi, liiketoimintayksiköiden asema, vastuut, henkilöstön valinta jakoulutus sekä investointipolitiikka. Toimintamalliin vaikuttavat eniten organi-saation rakenne ja prosessit sekä niissä tapahtuvat muutokset.

Tietohallintostrategian sisältö voidaan jakaa neljään periaatteeseen (Bäckman jaLemmetyinen 1992):

1. kehittämistyön luonne2. arkkitehtuurien periaatteet3. toimintaperiaatteet4. turvaamisen periaatteet.

Kehittämistyön luonne muodostuu liiketoiminnan analyysien pohjalta. Siihenkuuluvat toimintoja tukevien tietojärjestelmien kehittämistyö, arvio nykyjärjes-telmistä ja strategiaperustasta johdetut tietojenkäsittelyn tavoitteet. Tätä osiotavoitaisiin verrata Ruohosen ja Salmelan (1999) tavoitteiden määrittelyyn.

116

Arkkitehtuurien periaatteita on viisi: käyttöliittymä, tietojenkäsittely, tiedonhal-linta, tietoyhteydet ja laitearkkitehtuuri. Käyttöliittymän periaatteissa määritel-lään mm. erilaisten käyttöliittymien määrä ja suhtautuminen niiden räätälöintiin.Tietojenkäsittelyn periaatteissa määritellään mm. sovellusjaon perusteet (esim.toiminto- vai tulosyksikköperustaisuus), vaatimukset sovelluksille ja vastuutietotekniikan soveltamistavoista. Tiedonhallinnan periaatteissa määritelläänmm. hallittavien tietojen valinta, tiedonhallinnan keskittämisaste ja kokonais-vastuu. Tietoyhteyksien periaatteissa määritellään mm. ulkopuolisten yhteyksienhoito, ulkopuolisten käyttäjien oikeudet ja yhteystarpeet. Laitearkkitehtuurissamääritellään mm. vaatimukset yhteentoimivuudelle, käyttöympäristön yhtenäi-syydelle ja laitteille. Tämä osio vastaa Ruohosen ja Salmelan (1999) esityksessäresursseja, mutta tässä asiaa on lähestytty teknisemmästä näkökulmasta.

Toimintaperiaatteet kattavat toimintaja organisointitavat, joilla tietohallintoahoidetaan. Toimintaperiaatteet jakautuvat palveluiden hoitamiseen, kehittämis-työhön ja tietohallinnon kokonaisuuden ohjaukseen. Kutakin näistä kolmestatoimintaperiaatteesta voidaan verrata matriisissa arkkitehtuurien periaatteisiin jatätä kautta voidaan tarkentaa kunkin toimintaperiaatteen tarkkuustasoa. Tämäosio vastaa Ruohosen ja Salmelan (1999) esityksessä toimintamallia.

Turvaamisen periaatteet on nostettu omaksi osiokseen, jotta voitaisiin paljastaatietohallintoa uhkaavat riskitekijät ja vahinkoja aiheuttavat tapahtumat sekäniiden vaikutukset liiketoiminnalle. Turvaamisen periaatteet jakautuvat kolmeenosaan: riskien kartoitus, riskien arviointi ja turvaamistoimenpiteiden vaikutus.Riskien kartoituksessa määritellään riskilajit, vahinkotyyppi ja mahdollisetseuraukset. Riskien arvioinnissa määritellään vahingon esiintymistiheys ja va-hingon suuruus. Turvaamistoimenpiteiden vaikutuksessa toimenpiteet ja vahin-kotyypit määritellään, jolloin vaikutukset voidaan arvioida. Tätä osiota ei oleerillisenä Ruohosen ja Salmelan (1999) esityksessä, vaan se on vain yksi osatoimintamallia.

7. Pk-yritysten tietohallinnon suunnittelun erityispiirteitä

Tietohallintostrategian suunnittelussa yksi keskeinen tekijä on organisaationkoko. Koko vaikuttaa organisaatioiden rakenteeseen, kypsyyteen ja käytettävissäoleviin resursseihin. Suuryrityksillä on resursseja panostaa suunnitteluun, muttapk-yritysten resurssit ovat huomattavasti vähäisemmät. Pienet resurssit eivät ole

117

kovin hyvä lähtökohta strategiselle suunnittelulle, koska resursseja käytetäänpääasiassa operatiiviseen toimintaan.

Pk-yritysten johtamisprosessi eroaa suuryritysten johtamisprosessista (Jenningsja Beaver 1997). Pk-yritysten johtaminen on usein keskittynyttä (Pfeffer 1982),jolloin päätöksenteko on nopeaa ja joustavaa, mutta strateginen suunnittelu ei olevälttämättä yhtä kattavaa kuin suuryritysten hajautetuimmissa päätöksenteko-malleissa. Lisäksi selkeän näkemyksen puute (mm. näkökulma tietotekniikkaanon kapea) voi muodostua kompastuskiveksi pk-yrityksen tietohallintostrategiaamääriteltäessä (Airaksinen 2000).

Pk-yritykset toimivat myös epäformaalimmin kuin suuryritykset, mikä vaikuttaastrategioiden laadintaan (Halttunen 1995). Tietohallinnon organisointiin ja stra-tegioiden suunnitteluun tarkoitetut menetelmät edellyttävät usein, että organi-saatiolla on kohtuullisten resurssien lisäksi kutakin toimintoa varten määritellyttoimintatavat ja -mallit. Erilaisten menetelmien sovittaminen pk-yritysten toi-mintaympäristöön vaatii siten tutkimustyötä sekä teorian että käytännön tasolla.Suuremmille yrityksille luodut mallit ovat käytännössä liian raskaita toteutetta-viksi sellaisinaan pk-yrityksissä.

Airaksinen (2000) on listannut asioita, joita tulee ottaa huomioon suunniteltaessatietojenkäsittelyn kehittämistä pk-yrityksissä:

− tietotekniikan hyödyntämisen historia ja nykytila− johdon sitouttaminen− tietohallinnon toteuttaminen oman toimen ohessa− suunnitelmien helppokäyttöisyys ja nopea läpivietävyys− yksinkertaisuuden muistaminen− yhteisen kielen tärkeys organisaation sisällä ja suhteessa ulkopuolisiin− käyttäjien osallistuminen− tilannekohtaisuuden huomioiminen− asiantuntijapalveluiden saatavuus− ulkoinen painostus.

Tietotekniikan hyödyntämisen historia ja nykytila vaikuttavat huomattavastisiihen, miten toimintaa voidaan lähteä kehittämään. Organisaatio on aivan eri

118

tilanteessa, jos se on käyttänyt tietojärjestelmiä kymmenen vuotta kuin jos se onjuuri päättänyt ruveta käyttämään tietoteknisiä välineitä toiminnassaan.

Johdon sitouttaminen on erityisen tärkeää, koska päätöksenteko on keskittynyttä.Jos organisaation johto ei ole kehittämistyön takana, niin sen eteenpäinvieminenon vaikeaa tai mahdotonta. Johtajan henkilökohtainen kiinnostus tietotekniik-kaan edistää huomattavasti tietotekniikan käyttöä organisaatiossa.

Useissa pk-yrityksissä tietohallinnon tehtävät hoidetaan oman toimen ohessa,jolloin niihin paneutuminen jää vaillinaiseksi. Tietohallinnon hoitaminen ontällöin ongelmakeskeistä: ongelmat pyritään hoitamaan, mutta jos ei ole ongel-mia, niin silloin tehdään muita töitä. Tällainen asetelma ei edesauta toiminnanhuolellista suunnittelua.

Suunnitelmien tulee olla helppokäyttöisiä ja nopeasti läpivietäviä. Suunnitelmatja ohjeet ovat käytettävämpiä ja niitä käytetään, jos ne ovat helppoja, yksinker-taisia ja nopeita toteuttaa. Mahdollisimman yksinkertaiset suunnitelmat ja mallitovat sopivat pk-yritysten toimintatapaan, joten raskaita malleja tulee keventää.

Suunnittelun yhtenä ensimmäisistä tehtävistä on yhtenäistää organisaatiossakäytettävä kieli, jotta kaikki puhuisivat samoista asioista samoilla nimillä. Yhte-näistämisessä tulee ottaa huomioon se, että kyseisillä termeillä tulisi voidakommunikoida myös ulkopuolisten tahojen kanssa. Kielestä ei kannata tehdäkynnyskysymystä käyttäjien osallistumiselle.

Suunnittelun tulisi olla niin joustavaa, että se voidaan sopeuttaa kunkin organi-saation erityispiirteisiin ja tilanteeseen. Kaikki keskeiset asiat tulisi kuitenkinpystyä kattamaan aina määrittely- ja suunnittelutyön aikana. Tämä vaatii sekähyvää ammattitaitoa suunnittelijoilta että laatua käytettäviltä suunnittelumene-telmiltä.

Asiantuntijapalveluiden saatavuuteen vaikuttaa organisaation sijainti. Pysyviäasiantuntijoita voi olla vaikea saada houkuteltua kasvukeskusten ulkopuolelle.Myöskin lyhytaikaisten asiantuntijapalveluiden käyttö voi helposti tulla kalliiksi,jos matkat muodostuvat pitkiksi. Ulkopuolisten asiantuntijoiden käytön määrääusein organisaatiokulttuuri. Jos osaaminen on haluttu pitää talon sisällä, niinmyöskään tietotekniikkaan liittyviä asioita ei niin helposti ulkoisteta.

119

Pk-yritysten todellisuuteen liittyy myös voimakkaat ulkoiset paineet. Suuretasiakkaat voivat vaatia jonkin tietojärjestelmän käyttöönottoa liikekumppanuu-den edellytyksenä. Tällöin tietty järjestelmä on otettava käyttöön, vaikka se eivarsinaisesti sopisi organisaation omiin suunnitelmiin.

Pk-yritysten suunnitteluympäristö poikkeaa siis melko paljon suuryritystenvastaavasta. Perusasiat ovat samat, mutta niihin on tehtävä monia muutoksia jaerityisesti kevennyksiä, jotta pk-yritysten tietohallintoa voitaisiin järkevässämittasuhteessa kehittää.

Liiketoimintaympäristö muuttuu yhä kiihtyvällä vauhdilla (Kettunen et al.1998). Tämä muutos vaikeuttaa erityisesti pk-yritysten toimintaa, koska niillä eiuseinkaan ole käytössään suuria pääomia, joilla tietojärjestelmät voitaisiin jatku-vasti pitää ajan tasalla. Pk-yrityksissä tietojärjestelmät hankitaan edelleen sillämielellä, että ne palvelevat käytössä ainakin 5–10 vuotta. Liiketoimintaympä-ristö muuttuu nopeasti, mutta järjestelmien muuttaminen on usein vaikeaa jajoskus jopa mahdotonta.

Nopeasti muuttuvassa liiketoimintaympäristössä tietotekniikkaprojektien hallit-seminen on erittäin vaikeaa. Tietotekniikkaprojektien keskeiset riskit ovat toi-minnalliset ja poliittiset riskit. Toiminnallinen riski tarkoittaa, että valmis järjes-telmä ei vastaa nykyisiin tai tuleviin tarpeisiin. Poliittinen riski tarkoittaa, ettäprojekti päättyy organisaation vastustukseen tai vähittäiseen sitoutumisen hiipu-miseen. (Clemons et al. 1995.)

Toiminnallinen riski on pk-yrityksen kannalta erittäin suuri, koska päätöksente-ko on joustavaa ja suunnanmuutokset on helppo toteuttaa. Muutosten jälkeentietojärjestelmät eivät välttämättä enää vastaa niille asetettuihin haasteisiin.Poliittinen riski ei juurikaan poikkea suuryritysten riskistä, mutta matalampiorganisaatiohierarkia antaa mahdollisuudet asioiden selvittelyyn kasvotusten.

Tietohallintastrategian laadinnassa tulisi huomioida erilaiset tulevaisuudennä-kymät, jotta tietotekniikka pystyy vastaamaan liiketoiminnan vaatimuksiin sekähuomattavassa toiminnan kasvaessa että supistuessa (Kettunen et al. 1998).Tällaisten liiketoiminnan laajuutta ja luonnetta arvioivien tulevaisuudennäky-mien olemassaolo helpottaa tietohallinnon suunnittelua. Samalla keskustelemi-nen tietotekniikkatoimittajien kanssa helpottuu, kun he voivat arvioida sen ko-

120

koluokan, jossa lähivuosina liikutaan. Pk-yrityksissä ei useinkaan ole henkilöä,joka voisi tällaista arviota tehdä, vaan usein järjestelmät sovitetaan kulloiseenkintarpeeseen miettimättä tarkemmin tulevaisuuden vaihtoehtoja.

8. Yhteenveto

Tietotekniikan lisääntyvä käyttö edellyttää yhä parempaa ja huolellisempaasuunnittelua. Tietotekniikalla ei ole itseisarvoa, vaan se on suuri kuluerä, jokamenee hukkaan, jos sitä ei huolellisesti suunnitella.

Tietotekniikka tunkeutuu yhä pienempiin yrityksiin ja yhä syvemmälle yritystenprosessien suorittamiseen, jolloin sen strateginen merkitys kasvaa. Tietoteknii-kan rooli on muuttumassa yksittäisten rutiinitehtävien suorittajasta laajempienkokonaisuuksien hallitsijaksi. Tämä muutos tulee ottaa huomioon myös yrityk-sen liiketoimintastrategiassa. Siinä on otettava kantaa tietotekniikan roolin sekäalakohtaisesti että yrityskohtaisesti.

Tietojenkäsittelyn strategioita on tutkittu jo kymmeniä vuosia. Viimeisimpinätutkimusalueina tässä aihepiirissä on sen suhde liiketoimintastrategiaan. Tieto-tekniikka ei ole enää väline, vaan joillakin toimialoilla ja joissakin toiminnoissase on niin suuri mahdollistaja, että sillä on huomattavia strategisia vaikutuksia.

Tietohallintostrategiaa laadittaessa valittavaan lähestymistapaan vaikuttavatmonet asiat. Viime aikoina erityisesti liiketoiminta- ja organisaatiomuutoskes-keiset lähestymistavat ovat olleet suosittuja. Tietohallintostrategian laadinnassaapuna käytettävissä malleissa lähtökohtana on ollut liiketoimintastrategia. Niissäon pyritty myös huomioimaan tietotekniikan tuomat vaikutukset liiketoiminta-strategiaan.

Useimmat mallit, joilla tietohallintostrategioita laaditaan, on laadittu pitäensilmällä suuryrityksiä. Niiden soveltamisessa pk-yrityksiin on otettava huomioonuseita pk-yritysten ominaispiirteitä, joita ovat mm. joustava ja keskittynyt pää-töksenteko ja resurssien vähäisyys.

Tietohallintostrategian laatiminen ja sen todelliseen käyttöön saattaminen pk-yrityksessä on suuri haaste, jonka toteuttamiseen tarvitaan lisää tietoa pk-

121

yritysten toimintatavoista sekä kykyä muokata suuryrityksiin tarkoitetut mallittoisenlaisiin käyttötarkoituksiin.

Lähdeluettelo

Airaksinen, T. P. 2000. Tietojenkäsittelyn kokonaisvaltainen suunnittelu pk-yrityksissä, Pro-Gradu-työ. Jyväskylän yliopisto.

ATK-sanakirja 1999. 10. uusittu paino. Helsinki: Suomen Atk-kustannus Oy.

Bäckman, R. & Lemmetyinen, A. 1992. Strategia tietohallintoon: "Strategia ontie". Valtionhallinnon kehittämiskeskus, Koteva Oy, Turku.

Clemons, E. K., Thatcher, M. E. & Row, M. C. 1995. Identifying Sources ofReengineering Failures: A Study of the Behavioral Factors Contributing toReengineering Risks. Journal of Management Information Systems, Vol. 12, No.2, s. 9–36.

Earl, M. J. 1989. Management Strategies for Information Technology. Cam-bridge: Prentice Hall International (UK) Ltd.

Earl, M. J. 1993. Experiences in Strategic Information Systems Planning, MISQuarterly, March 1993, s. 1–24.

Ein-Dor, P. & Segev, E. 1978. Strategic Planning For Management InformationSystems. Management Science, Vol. 24, No. 15, November.

Hamel, G. 1997. Making strategy. Economist, Vol. 342, Issue 8006, 3/1/97.

Halttunen, V. 1995. Organizational perspectives on strategic information sys-tems planning: Towards a better understanding of organizational contingencies.Technical Reports TR-11, University of Jyväskylä, Department of computerscience and information systems.

Jennings, P. & Beaver, G. 1997. The Perfomance and Competitive Advantage ofSmall Firms: A Management Perspective. International Small Business Journal,Vol. 15, No. 2, s. 63–75.

122

Kettunen S., Heikkilä J. & Lyytinen K. 1998. Beyond Strategic Planning ofInformation Technology: The use of Scenarios in Turbulent Environments. In:the proceedings of the 6th European Conference on Information Systems, June4–6 1998, Aix-en-Provence, France. Baets W.R.J., (editor). University of Aix-Marseille III, Vol. I. S. 408–421.

Kovacevic, A. & Majluf, N. 1993. Six stages of strategic management SloanManagement Review, Summer 1993, Vol. 34, No. 4, s. 77–87.

Leppänen, M., Lyytinen, K. & Halttunen V. 1991. Tietojenkäsittelystrategianmäärittely: strateginen tietohallintopalveluiden kehittämismenetelmä (SPITS),Jyväskylän yliopisto.

Luftman, J. N., Lewis, P. R. & Oldach, S. H. 1993. Transforming the enterprise:The alignment of business and information technology strategies. IBM SystemsJournal, Vol. 32, No. 1.

McLean, E. R. & Soden, J. V. 1977. Strategic Planning for MIS. John Wiley andSons.

Mintzberg, H. 1994. The fall and rise of strategic planning. Harvard BusinessReview, January-February, s. 107–114.

Pfeffer, J. 1982. Organizations and organizations theory. Cambridge. Massachu-setts: Baalinger Publishing Company.

Pk-yritysraportti 1998. Kauppa- ja teollisuusministeriön tutkimuksia ja raportteja21/1998. Kauppa- ja teollisuusministeriö, Yrityskehitysosasto, Oy Edita Ab.

Reponen, T. 1987. Tietotekniikka yritysstrategian osana. SITRAn julkaisujaA80.

Reponen, T., Auer, T., Pärnistö, J. & Viitanen, J. 1995. Tietoresurssien johta-misstrategia kilpailukyvyn välineenä. Turun kauppakorkeakoulun julkaisuja C-8:1995. Turku, Paino-Raisio Oy.

123

Ruohonen, M. 1989. Johdon tietojärjestelmäkoulutuksen asema strategisessatietojärjestelmien suunnittelussa – teoreettinen viitekehys. Turun kauppakorkea-koulun julkaisusarja D-4:1989.

Ruohonen, M. J. & Salmela, H. 1999. Yrityksen tietohallinto. Helsinki: Oy EditaAb.

Spil, T. A. M. & Salmela, H. 1999. The fall of Strategic Information SystemsPlanning and the rise of a dynamic IS Strategy, In: Proceedings of the22nd Information Systems Research Seminar in Scandinavia (IRIS), Keu-ruu, August 6–9. Jyväskylä: University of Jyväskylä.

Sääksjärvi, M. 1983. Tietojenkäsittelyn kokonaistutkimuksen työmenetelmät(METO 2). Helsinki: Valtion painatuskeskus.

Sääksjärvi, M. 1990. Tietojenkäsittelyn strateginen suunnittelu: tutkimus tieto-jenkäsittelyn strategiasta ja sen yhteensovittamisesta liiketoiminnan strategiankanssa (METO 3). Helsinki: Helsingin kauppakorkeakoulu.

Thompson, J. L. 1996. Strategic Management: Awareness and Change. London:Chapman and Hall.

Ward, J. 1990. Strategic planning for information systems. Chichester: JohnWiley & Sons.

124

V Toiminnanohjausjärjestelmänvaatimusten määrittely pk-yrityksessä

Iris Karvonen, Teemu TommilaVTT Automaatio

1. Johdanto

Tässä artikkelissa tarkastellaan vaatimusten määrittelyä toiminnanohjausjärjes-telmän käyttöönotossa pk-yrityksessä. Vaatimusmäärittely luo yleisesti pohjantietojärjestelmähankkeille ja siksi sen läpivienti on hankkeiden onnistumisenkannalta merkittävä. Vaatimusten määrittelyyn ja esittämiseen onkin kehitettylukuisia menetelmiä ja malleja. Nämä eivät yleensä suoraan sovellu loppukäyt-täjille, joilla ei ole ammattitaitoa määrittelyyn tai toiminnan kehittämiseen. Pk-yrityksissä keskeisen haasteen aiheuttavat toisaalta rajalliset resurssit ja toisaaltavaatimusmäärittelyn rooli loppukäyttäjien ja tietojärjestelmäammattilaistenvuorovaikutuksen välineenä. Artikkelissa kuvataan vaatimusmäärittelyn näkö-kulmia, sijoittumista toiminnanohjaushankkeeseen, vaiheita sekä kehitystarpeita.

2. Vaatimusmäärittely tietojärjestelmähankkeen lähtökohtana

2.1 Mitä vaatimukset ovat

Kukin tietojärjestelmähanke sisältää periaatteessa samanlaiset elinkaaren vaiheetkonseptista, tarpeiden tunnistuksesta ja vaatimusmäärittelystä suunnittelunkautta toteutukseen, käyttöönottoon ja käyttöön. Tietojärjestelmän vaatimusmää-rittelyksi kutsutaan vaihetta, jossa tunnistetaan tavoitteet, tarpeet ja odotuksetkehitettävänä olevalle tietojärjestelmälle ja jossa ne pyritään esittämään järjes-tetyssä muodossa esim. eri käyttäjien tai roolien mukaan luokiteltuna. Vaati-musmäärittelyn tarkoituksena on esittää, mitä kehitettävältä systeemiltä vaadi-taan mutta ei vielä sitä, miten se toteutetaan.

Vaatimusmäärittely on nähty yhtenä tietojärjestelmien rakentamisen keskeisim-mistä tehtävistä; vaikuttaahan se ratkaisevasti siihen, millainen lopullisestajärjestelmästä tulee. Koska myöhemmät vaiheet rakentuvat vaatimusmäärittelynpohjalle, on selvää, että sen puutteet kostautuvat jatkovaiheissa ja järjestelmän

125

käytössä Virheellinen tai puutteellinen vaatimusmäärittely voi estää järjestel-mältä odotetun hyödyn saavuttamisen tai aiheuttaa huomattavan lisäkustannuk-sen tietojärjestelmän käyttäjälle. Vaatimusten määrittely on tarpeen sekä järjes-telmän loppukäyttäjän että sen toimittajan kannalta.

Vaatimukset perustuvat yrityksen tavoitteisiin ja eri käyttäjäryhmien eteenpäinjalostettuihin tarpeisiin. Tarve on ilmaisu siitä, mitä järjestelmältä haluttaisiin.Vaatimusmäärittely-vaiheessa tehtävänä on tunnistaa, koota, ryhmitellä, muo-kata ja karsia tarpeet sekä asettaa ne tärkeysjärjestykseen esim. teknisten jataloudellisten tekijöiden perusteella. Näin tarpeista muodostuu järjestelmään taisen osaan kohdistuvia vaatimuksia, joilla voi olla joukko prioriteettitasoja. Osavaatimuksista voi esim. olla ”ehdottomia” ja osa ”toivottavia”. Vaatimustentoteuttaminen onkin yleensä jonkinlainen kompromissi. Vaatimusten karsinnassavoidaan käyttää hyväksi tarkastelua toteuttamisen vaatimista kustannuksista.

Vaatimukset voivat kohdistua johonkin järjestelmän toiminnalliseen tai toteu-tustekniseen kokonaisuuteen, tai vaihtoehtoisesti sen suunnittelu-, käyttö- ja/taiylläpitoprosesseihin. Voidaan myös esittää koko järjestelmää koskevia yleisiävaatimuksia ja toisaalta tiettyyn järjestelmän osaan kohdistuvia erityisiä vaati-muksia. Yleensä erotetaan kaksi perustyyppiä. Toiminnalliset vaatimukset ku-vaavat, millaisia toimintoja tai palveluita järjestelmältä halutaan. Ei-toiminnalliset vaatimukset liittyvät yleensä sen suorituskykyyn (esim. tarkkuusja vasteajat).

Jotkut vaatimuksista esittävät tavoitteita, tilaa, jonka suuntaan asiakas haluaapäästä jättäen keinojen valitsemisen järjestelmän suunnittelijalle tai toimittajalle.Suunnittelurajoitus sen sijaan vähentää suunnittelijan tai toimittajan liikkumava-pautta esittämällä toteutustapoja koskevia vaatimuksia (esim. ”on käytettäväkäyttöjärjestelmää X”). Rajoitukset voivat olla peräisin esim. yrityksen tietotek-niikkastrategiasta ja suunnittelustandardeista tai lakivelvoitteista. Rajoitustensuhteen on oltava varovainen, koska tarpeettomat ja ennenaikaiset rajoituksetvoivat estää optimaalisen tuloksen saavuttamisen. Usein kovilta näyttävät rajoi-tukset eivät ole ehdottomia, vaan niitä voidaan siirtää rahalla, tai ne voivat jopaolla peräisin esittäjänsä ennakkoluuloista tai tottumuksista. Usein kannattaakinkysyä muutaman kerran ”miksi”, jotta tarpeen tai rajoituksen perimmäinen syytulisi esiin.

126

Vaatimusmäärittely olisi hyvä dokumentoida siten, että vaatimusten toteutumistavoidaan seurata ohjelmistohankkeen läpi (vaatimusten hallinta). Tämä auttaamyös pk-loppukäyttäjää yhteistyössä ohjelmistotoimittajan kanssa. Dokumen-toidun vaatimusmäärittelyn sisällöstä on olemassa suosituksia (esim. IEEE1998), mutta ne soveltuvat parhaiten ohjelmistoyritykselle, eivät niinkään pk-yrityksille tai loppukäyttäjille.

2.2 Vaatimusmäärittelyn näkökulmat

Vaatimusmäärittelyn tavoitteet, sisältö ja toimijat riippuvat siitä, mitkä ovathankkeen tavoitteet ja kenen näkökulmasta se lähtee. Vaatimusmäärittely-termiäkäytetään varsin erilaisissa ympäristöissä ja tavoitteilla tehtävissä hankkeissa.Toiminnanohjausjärjestelmähankkeissakin voidaan tunnistaa kolme erityyppistänäkökulmaa vaatimusmäärittelyyn (kuva 1).

Toiminnanohjaus-järjestelmäntuotekehitys- tuotekonseptit,uudet tarpeet jamahdollisuudet- ongelmien käsittely- vaatimusten luomi-nen ja formalisointiohjelmistokehityksentarpeisiin

Pkt-yrityksentoiminnanohjaus-järjestelmänhankinta- ongelmat, tarpeet jamahdollisuudet,toimituksen valinta jasuunnittelu

Toiminnanohjaus-järjestelmäntoimitusasiakkaalle- konfigurointiasiakkaan tarpeidenmukaan

Loppukäyttäjä Toimittaja jaloppukäyttäjä

Toimittaja

Kuva 1. Tietojärjestelmän vaatimusmäärittelyn näkökulmat.

1. Toiminnanohjausjärjestelmän vaatimusmäärittely loppukäyttäjän näkökul-masta. Hanke voi perustua huolellisesti mietittyyn liiketoiminnan tarpeista läh-tevään tietotekniikkastrategiaan, jossa on pohdittu tietotekniikan soveltamisentuomat kustannus- ja aikasäästöt ym. hyödyt sekä uudet tarjoutuvat liiketoimin-tamahdollisuudet (ks. myös tämän julkaisun IV artikkeli). Etenkin pk-yrityksissänäin ei kuitenkaan usein ole laita, vaan hankkeen käynnistäjinä voivat olla yk-sittäiset käytännön toiminnan ongelmat, ulkoiset muutokset (esim. v. 2000,

127

euro), asiakkailta, ympäristöstä tai yrityksen sisältä esitetyt vaatimukset tai halu”tehdä sitä, mitä muutkin” (esim. e-business), johon usein liittyy pelko ”kelkastaputoamisesta”.

2. Toiminnanohjausjärjestelmän toteutus asiakkaalle on toimittajan ja asiakkaanyhteistyöhanke. Sen yhteydessä joudutaan yleensä jälleen käymään asiakkaanvaatimukset läpi, vaikka asiakas olisikin dokumentoinut ne yksityiskohtaisestiennen toimittajan valintaa. Toimittajalla voi olla oma tuote, tai toimittaja voiedustaa muiden kehittämiä tuotteita ja tarvittaessa kokoaa sovelluksen eri toi-mittajien tuotteista (integraattori). Toimittajan tuotteista ja toimintatavoista sekäasiakkaan valmiuksista riippuu, miten asiakkaan vaatimuksia käytetään ja kehi-tetään toteutusprojektissa.

3. Toiminnanohjausjärjestelmän tuotekehitys on ohjelmistotoimittajan tekemääohjelmistokehitystä. Se ei ole täysin irrallaan asiakasprojekteista: kehitysimpuls-sit tulevat tyypillisesti asiakkailta ja usein itse kehitystä myös tehdään asiakas-projekteissa. Vaatimusten esittämiseen ohjelmistokehityksen tarpeisiin on kehi-tetty lukuisia tietojärjestelmien määrittely- ja kehitysmenetelmiä sekä -proses-seja (esim. UML). Nämä menetelmät eivät yleensä sovellu suoraan keskusteluunpk-yritysten loppukäyttäjien kanssa. Toisaalta tuotekehityksen yhteydessä laa-dittuja kuvauksia vaatimuksista voitaisiin mahdollisesti muokattuna käyttäähyväksi asiakasyhteistyössä. Ohjelmistotoimittajan tuotekehitys ei kuulu tämänartikkelin rajaukseen, vaan tässä tarkastellaan asiaa pk-yrityksen näkökulmasta.

3. Loppukäyttäjän näkökulma toiminnanohjausjärjestelmän vaatimuksiin

3.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ä artikkelissayksittäisen tietojärjestelmähankkeen näkökulmasta, ts. lähtien tilanteesta, jossa

128

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, esimerkiksiyleisen tietohallintostrategian kehittäminen tai koko tietojärjestelmä-arkkitehtuurin määrittely. Tällainen strategisen tason vaatimusmäärittely ohjaakoko 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 taituotetta ei vielä ole valittu. Tällöin on yleensä tarkoituksenmukaista tunnistaakeskeisimmä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 aikanaettä varsinaisessa käyttövaiheessa.

2. Toimittajan ja ohjelmistotuotteen (-tuotteiden) valinnan jälkeen tehdääntarkempi 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ä vaatimustentasolla. 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 jaympäristö myös tapa, jolla yrityksen tietojärjestelmä rakennetaan. Toiminnan-ohjausjärjestelmät voidaan jakaa toteutustavaltaan kolmeen luokkaan:

129

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äänvalmiista ratkaisusta. Räätälöinnin hyvänä puolena on, että voidaan saada juurisellainen järjestelmä kuin halutaan. Haittana on tietysti kehittämisen ja ylläpidonvaatimat suuret resurssit sekä ohjelmistotoimittajalta että asiakkaalta. Samoinriskit 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 luodaankuitenkin 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ä sovelluksen 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 jastandardituotteen 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 olemassaoleviinyrityksen 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ä roolisiinä on asiakkaalla ja toimittajalla. Realistisia ratkaisuja pk-yrityksille ovatyleensä vain paketoidut tuotteet (luokat 2 ja 3), jolloin toimittajan valintaa edel-tävä vaatimusmäärittely voi olla tehokasta jakaa kahteen vaiheeseen:

130

− tavoitteiden ja tarpeiden kartoitus ja keskeisten ja ehdottomien vaatimustenmäärittely

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

Molemmissa vaiheissa on tarpeellista käydä läpi yrityksen toiminnan ja senohjauksen kokonaisprosesseja sekä luoda pohjaa järjestelmän organisatorisellekä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 varsinvarhaisessa 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 ratkaisuaniistä 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 suunnatvoivat jäädä siinä pohtimatta.

Jos yritys ei koe käytössä olevien järjestelmien voivan toimia pohjana uudellejä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. tarpeidenmäärittely, omin voimin. Tyypilliselle pk-yritykselle hanke on usein vaativa jayritykset voivatkin helposti joutua ”toimittajien vietäviksi”. Saadakseen realisti-sen kuvan tuotteista pk-yritys voi esim. kokeilla tai testata ohjelmistoja omallaaineistollaan ja tutustua muissa yrityksissä käytössä oleviin sovelluksiin ja yri-tyksen käyttökokemuksiin. Myös toimittajan referenssien ja laatujärjestelmänarviointi voi olla tarpeen.

Etenkin suurilla ohjelmistotoimittajilla voivat tarjolla olevat ratkaisut, asiakas-toimitusprosessi ja sen työkalut olla varsin pitkälle määritellyt. Konfiguroitavistaratkaisuista 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äksikäytettävät välineet soveltuvat usein vain tietotekniikkaa syvällisemmin ym-märtävien osapuolien keskustelun tueksi. HANSKA-projektin haasteena onkin

131

kehittää nimenomaan pk-yrityksille soveltuvia tehokkaita menettelytapoja myösvaatimusmää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 jakäyttäjien tarpeista. Nämä on toivottavasti kuvattu yleisellä tasolla teknologia-strategiassa.

Yritysten tietojärjestelmähankkeiden laajuus ja vaikuttavuus organisaatiossavaihtelee laajoista organisaatioiden uudelleenjärjestelyistä lähes puhtaisiin tie-tojärjestelmäostoihin. Ei ole olemassa yhtä sääntöä, miten laajasti ja syvällisestivaatimuksia tulisi kartoittaa – vaatimusmäärittelyn tarve riippuu mm. hankkeentavoitteista. 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ää hankettamerkittä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, eriosien yhteensovittamista ja päätöksentekopisteitä.

− Epäonnistumisen mahdollisuudet ovat suuret, jos vain ostetaan systeemi”kaupan hyllyltä” pohtimatta lainkaan sitä, mihin sitä tarvitaan ja miten sentukemana 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ösolla, että järjestelmää ei saada lainkaan käyttöön tai vain vajaakäyttöön.

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

132

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

4. Vaatimusmäärittelyn vaiheet

4.1 Tavoitteiden määrittely

Toiminnanohjausjärjestelmän tavoitteena on paitsi tukea yrityksen toimintaamyös sen toiminnan ohjausta. Järjestelmän tulisi vahvistaa yrityksen strategiantoteutumista ja auttaa seuraamaan ja ohjaamaan niitä tavoitteita ja tekijöitä, jotkaovat yrityksen kilpailukyvyn kannalta oleellisia. Asiakastyytyväisyyteen vaikut-tavia tavoitteita ovat paitsi hintakilpailukyky myös laatu (tuotteet ja palvelu)sekä aikatekijät (läpäisyaika, toimitusaika, toimitusvarmuus). Yrityksen omanmenestymisen kannalta tärkeää on tyypillisesti kustannusten hallinta (ml. varas-tot), tuottavuus, kapasiteetti, käytettävyys jne. Toiminnanohjausjärjestelmäntulisi tukea näiden tavoitteiden saavuttamista; erityisesti siltä osin kuin ne tuot-tavat ongelmia. Lisäksi järjestelmä voi tuoda hyötyä myös yrityksen asiakkailleesim. saattamalla järjestelmään kertyvän (esim. asiakasta koskevan) tiedon myösyrityksen asiakkaiden saataville.

Koska toiminnanohjausjärjestelmä on varsin suuri ja pitkävaikutteinen inves-tointi, on sen tavoitteita tarkasteltaessa syytä käydä läpi myös kehityssuuntia japitkän tähtäimen tavoitteita ja näin varmistaa, ettei järjestelmä jatkossa muutukehityksen jarruksi.

Tavoitteiden saavuttamista auttaa, jos yleisistä liiketoiminnallisista tavoitteistavoidaan johtaa tietojärjestelmähanketta varten konkretisoidut tavoitteet: mitähalutaan saada aikaan järjestelmän käyttöönotolla. Tällaisia voivat olla esimer-kiksi määrättyjen prosessien tai työnkulkujen nopeuttaminen, tietyn päällek-käistyön vähentäminen, eri toimipisteiden yhteispelin kehittäminen, tiedonsyöttö vain yhteen kertaan ja parempi hyödyntäminen jne. Tavoitteiden tarkas-telu aika ajoin vaatimusten määrittelyssä ja käyttöönoton aikana auttaa suuntau-tumaan niihin asioihin, jotka ovat yrityksen kannalta oleellisia.

133

4.2 Tarpeiden tunnistus

Tietojärjestelmähankkeesta päätettäessä yrityksellä on yleensä jokin käsitys siitä,mihin järjestelmää tarvitaan. Tarpeet eivät kuitenkaan useimmiten ole niin sel-keitä, että ne voitaisiin vain kerätä yhteen vaatimuksiksi. Konkreettinen tavoit-teen asettelu tukee myös tarpeiden tunnistusta. Tyypillisesti tarpeet pitää tunnis-taa, poimia, perata ja kypsyttää ennen kuin niistä saadaan vaatimuksia.

Kuvassa 2 on yksi esitys niistä asiakokonaisuuksista, joita pk-yrityksen tulisikäydä läpi tietojärjestelmähankkeen tarpeita kartoitettaessa. Lähtökohtana on,että päätös tietojärjestelmähankkeesta on jo tehty perustuen esim. yrityksenliiketoiminta- tai/ja tietotekniikkastrategioihin.

Kuten edellä todettiin, on tärkeä pitää mielessä, mitkä ovat liiketoiminnan kan-nalta tärkeät tavoitteet, ts. mistä yrityksen kilpailukyky muodostuu, jotta järjes-telmän avulla pystytään seuraamaan ja ohjaamaan näitä tekijöitä. Nykytilanne janykyiset toimintaprosessit ja niiden ongelmat tulee tunnistaa, jotta osattaisiintarttua oikeisiin asioihin. Olemassa olevat järjestelmät, joista ei luovuta, tuleeottaa huomioon.

Koska järjestelmähankinta on aina kauaskantoinen hanke, tulee miettiä myöstulevaisuuden vaatimuksia. On syytä varautua muutoksiin sekä tuotantolaitteis-toissa, tuotteissa että organisaatioissa. Järjestelmä ei siis saa olla niin jäykkä, ettäsitä ei pystytä kohtuullisin ja mieluiten yrityksen omin resurssein muokkaamaantoimintaympäristön muutosten tullessa.

Yritykset toimivat jatkuvassa yhteydessä muihin yrityksiin, toisaalta asiakkaisiinja toisaalta alihankkijoihin tai toimittajiin päin. Näihin suhteisiin liittyy myösinformaation välitys ja käsittely. Tietojärjestelmätarpeita mietittäessä kannattaamyös käydä läpi sitä, miten tietojärjestelmä voisi tukea näitä yhteistyösuhteita.Erityisen tärkeitä ovat esim. sopimusvalmistajan suhteet päämies-yritykseen ym.pidemmälle kehittyneet yhteistyösuhteet.

134

Nykytilanne:Toimintaprosessi

ja järjestelmät

Kohteen taiyrityksentavoitteet

Ongelmat jatarpeetnykytilanteessa

Ympäristöntai yhteistyöntarpeet

Teknologianantamatmahdollisuudet

Uudenjärjestelmänvaatimukset

Tulevaisuudenhaasteetmuutosvalmius

Tulevaisuudentarpeet janäkymät

Uusitoimintaprosessi

Johto

Loppukäyttäjät

Yhteistyökumppanit(asiakkaat, alihankkijat...)

Ohjelmistotoimittajat, konsultit

Toteutusprojektinsuunnittelu

Kuva 2. Vaatimusten tunnistaminen pk-yrityksen tietojärjestelmähankinnassa.

Teknologian kehittyessä esiin on noussut tietotekniikan rooli ei ainoastaan toi-minnan tukena, vaan myös uusien mahdollisuuksien luojana liiketoiminnalle.Tältä osin pk-yrityksen voi olla vaikea yksin tunnistaa ja löytää mahdollisuuksi-aan. Tällöin mieluiten yrityksen luottamusta nauttivan tietojärjestelmäkumppa-nin, esim. ohjelmistotoimittajan tai -konsultin, tuki voisi olla tarpeen. Tässäpohdinnassa tulee olla mukana yrityksen liiketoiminnan tuntemus.

Tarpeiden tunnistus luo pohjan uusien toimintaprosessien määrittelylle ja vaati-musten esittämiselle. Kuva 2 ottaa kantaa myös siihen, minkä osapuolien tulisiottaa osaa kuhunkin pohdintavaiheeseen. Se, miten vahvasti osapuolet ovatmukana prosessissa, vaihtelee yrityksen tilanteen ja asioiden painotuksen mu-kaan. Vaikka tietojärjestelmäkonsulteilla olisi esitettyä isompi rooli prosessissa,tarvitaan joka tapauksessa hankintaprojektille yrityksen sisäinen päällikkö, jokatietää missä mennään ja joka pitää huolta yrityksen tavoitteista.

Koska toiminnanohjausjärjestelmä integroi laajasti yrityksen eri toimipisteitä,toimintoja ja henkilöitä, sen tarpeiden tunnistusta ei voi jättää pelkästään johdontai atk-tuen tehtäväksi. Tyypillisesti ainakin taloushallinto ja sen eri osa-alueet,tuotanto ja varastotoiminnot on saatava mukaan tarpeiden kartoitukseen. Josjärjestelmää on tarkoitus soveltaa useissa erillisissä toimipisteissä, on hyväpäästä selville niiden toimintakulttuurien ja -tapojen eroista realistisen toteutuk-

135

sen saavuttamiseksi. Menetelminä voidaan käyttää mm. työryhmiä, keskusteluja,haastatteluja ja kyselyitä. Loppukäyttäjien mukaan ottaminen on tarpeellistapaitsi teknisen määrittelyn tuloksen myös organisatorisen käyttöönoton, henki-löstön sitouttamisen kannalta. Jo kartoitusvaiheessa hankkeella on hyvä ollaprojektipäällikkö.

4.3 Tarpeista vaatimuksiksi

Koska tarpeiden kartoitusta tehdään yleensä useilla menetelmillä ja useissaryhmissä, voivat kootut tarpeet sisältää toisaalta päällekkäisiä ja toisaalta myösristiriitaisia asioita. Lisäksi esitystasot voivat vaihdella. Niinpä vaatimustenluominen vaatii tarpeiden usein iteratiivista käsittelyä mm. listaamalla, ryhmit-telemällä ja asettamalla tärkeysjärjestykseen. Jos hankkeelle on alunperin mää-ritelty konkreettiset tavoitteet, ne auttavat priorisoinnissa.

Koska tarpeet tyypillisesti kertyvät eri toiminnoista, tässä vaiheessa on tärkeäähahmottaa toimintakokonaisuus: miten eri tarpeet yhdistetään, miten kokonais-prosessi toimii ja mikä on järjestelmän rooli siinä.. Yhteistä käsittelyä ja valintaatukemaan voidaan käyttää myös toimintaprosessien mallintamista ym. menetel-miä. Aina pk-yrityksillä ei ole kuitenkaan valmiuksia ko. kuvaukseen, jolloin netarvitsevat siihen joko ohjelmistotoimittajan tai konsultin apua. Tästä syystäesim. prosessien kuvaaminen nousee usein esiin vasta siinä vaiheessa, kun tar-kastellaan potentiaalisen tuotteen soveltuvuutta yrityksen toimintaan.

Tarpeiden läpikäynnin yhteydessä on syytä pohtia myös sitä, mikä on ihmisen jamikä järjestelmän rooli eri toiminnoissa, ts. mitä pyritään automatisoimaan jamitä jätetään ihmisen hoidettavaksi. Vaikka toiminnanohjausjärjestelmän avullavoidaan automatisoida esim. taloushallinnon toimintoja, sen tärkein rooli onkuitenkin tukea ihmisten toimintaa tiedon hallinnan kautta. Jo informaationtallennus ja helppo saatavuus kaikille, jotka organisaatiossa sitä tarvitsevat,auttaa toimintaa. Haluttaessa voidaan automatisointiastetta lisätä informaationjalostuksella, esim. eri tietojen yhdistelyllä ja analysoinnilla, sekä päätöksenteontuella lisäämällä mukaan kvalitatiivista asiantuntemusta (esim. entä-jos-analyysejä, simulointia, sääntöjä jne...). Kaikkia toimintoja ei kuitenkaan voidatoteuttaa automaattisesti, vaan välissä tarvitaan ihmisen päätöksentekoa ja osal-listumista.

136

4.4 Vaatimusten dokumentointi

Hankkeen tavoitteet sekä analysoinnin, muokkauksen ja priorisoinnin tuloksenasaatavat vaatimukset tallennetaan dokumenttiin, jota voidaan käyttää paitsiorganisaation oman hankkeen ohjauksen tukena myös yhteyksissä ohjelmisto-toimittajiin. Tarjouspyynnön liitteeksi voidaan vielä laatia keskeisistä vaatimuk-sista lista, johon toimittajaa pyydetään ottamaan kantaa (miten ko. tuote täyttäävaatimukset). Mahdolliset prosessikuvaukset/mallit liitetään dokumentaatioon.

4.5 Vaatimukset ja ohjelmistotuote

Pk-yritysten valmiudet vaatimusten määrittelyyn vaihtelevat. Vaikka pk-yritysolisikin selvittänyt tarpeitaan ja tavoitteitaan ennen yhteydenottoa ohjelmisto-toimittajiin, on usein ongelmana se, että tarpeet ovat irrallisia toisistaan ja yri-tyksessä ei ole pystytty hahmottamaan kokonaisprosesseja: miten yritys koko-naisuutena toimii, mikä vaikuttaa mihinkin. Jos koko prosessia ei tunneta, eimyöskään ymmärretä toiminnanohjausjärjestelmän eri osien ja toimintojenmerkitystä ja systeemin hyödyt voivat jäädä saavuttamatta. Siksi on edullista, josohjelmistotoimittaja voi tuotettaan tarjotessaan mahdollisimman konkreettisestiesittää, miten systeemi tukee yrityksen toimintaa ja millaisia toimintatapoja semahdollistaa tai vaatii. Yhtenä mahdollisuutena tässä on kuvata ohjelmistotuo-tetta ja sen eri vaihtoehtoja prosessi-, työnkulku- tai tietovuomalleilla.

Mallien hyväksikäyttö ei ole itsetarkoitus eikä se takaa hankkeen onnistumista.Mallien avulla on tarkoitus lisätä ymmärrystä siitä, mitä tavoitellaan, ja sitensaada aikaan mahdollisimman hyvä toteutus. Sovellettaessa malleja pk-yrityksissä tulee löytää oleelliset asiat (esim. vaihtoehtoiset toimintatavat) jasopiva esitystaso. Mallien hyväksikäyttö myynnistä alkaen auttaisi loppukäyttä-jää ymmärtämään, mitä on ostamassa. Samojen prosessimallien käyttö läpikäyttöönoton totuttaisi asiakasyrityksen toimijat prosessiajatteluun sekä loisipohjaa myös asiakasorganisaation yhteiselle näkemykselle.

5. Kehittämistarpeet

Vaatimusten määrittelyyn ja kuvaamiseen on kehitetty lukuisia menetelmiä, joitaon kuvattu mm. tämän julkaisun 6. artikkelissa. Menetelmät lähtevät usein kui-tenkin tietojärjestelmän kehittämisen näkökulmasta, eikä monilla pk-yrityksillä

137

ole hyviä valmiuksia eikä resursseja niiden soveltamiseen. Lisäksi on otettavahuomioon vaatimusmäärittelyvaiheen merkitys henkilöiden sitouttamiseen jamotivointiin. Siten vaatimusmäärittely luo pohjaa paitsi systeemin teknisellemyös organisatoriselle käyttöönotolle.

Kun pk-yritys hankkii toiminnanohjausjärjestelmän, yleensä ainoa realistinenvaihtoehto on ostaa valmis pakettiratkaisu, joka enemmän tai vähemmän voidaansovittaa yrityksen toimintaan. Tällöin tarpeita ja vaatimuksia ei välttämättä kan-nata hioa mahdollisimman pitkälle ennen yhteydenottoa järjestelmätoimittajiin,vaan vaatimusten luomiselle tulisi löytää riittävä esitystaso ja -menetelmät, joillavoidaan keskustella toimittajan kanssa tarjousvaiheessa. Tällöin voidaan tarvit-taessa tarkentaa myös yksityiskohtaisia vaatimuksia; tärkeintä on kuitenkin päästäkonkreettisesti selville siitä, miten tuote tukee yrityksen kokonaisprosesseja, mitense muuttaa toimintatapoja ja mitä sen käyttöönotto edellyttää yritykseltä.

HANSKA-hankkeessa on tarkoitus kehittää malleja ja käytännönläheistä opas-tusmateriaalia siihen, miten pk-yrityksen toiminnanohjaushanke tulisi viedä läpi.Tähän sisältyy pk-yrityksen vaatimusmäärittelyprosessin kehittäminen sekäsopivien kuvaustapojen löytäminen. Ongelmana ei ole niinkään vaatimustenformaali esittäminen kuin niiden tunnistaminen ja käsittely yrityksessä yhteis-työssä toimittajan kanssa. HANSKA-hankkeessa onkin tavoitteena kehittäätoimittajan ja asiakkaan keskinäistä vuorovaikutusprosessia sekä sen tueksisopivia työvälineitä ja kuvaustapoja siten, että asiakas voisi ymmärtää mitä onostamassa ja että järjestelmästä saataisiin aikaan asiakasta parhaiten palvelevatoimitus.

Lähteet

IEEE 1998. IEEE Recommended Practice for Software Requirements Specifica-tions, IEEE Std 830-1998. New York, USA: The Institute of Electrical andElectronics Engineers Inc. 31 s.

138

VI Tietojärjestelmän kehittämistä tukevatmenetelmät pk-yrityksessäVeikko Halttunen, Antti Lehtinen, Kalle Lyytinen

Jyväskylän yliopisto, Tietotekniikan tutkimusinstituutti (TITU)

1. Johdanto

Tietojärjestelmien kehittämisessä teknistä ratkaisua tärkeämpi ja usein vaikeam-pi tehtävä on määrittää, millaisen tietojärjestelmän käyttäjäorganisaatio tarvitsee.Nykypäivän verkostoitunut organisaatio on jatkuvassa muutostilassa, ja toimin-tojen väliset rajat on vaikea määrittää. Sen vuoksi on myös vaikeaa määritelläpaitsi tietojärjestelmien kokonaisarkkitehtuuria myös yksittäiseltä tietojärjestel-mältä vaadittavia toiminnallisia ominaisuuksia.

Tietojärjestelmien kehittäminen ja sitä tukevat menetelmät jakautuvat kahteentasoon: kokonaissuunnitteluun (engl. Information Systems Planning, ISP) jayksittäisen tietojärjestelmäratkaisun suunnitteluun (engl. Information SystemsDesign, ISD). Nykyisin kokonaissuunnittelusta käytetään yhä useammin nimi-tystä tietohallinnon tai tietojärjestelmien strateginen suunnittelu. Sillä tarkoite-taan koko organisaation kattavan tietoja tietojärjestelmäarkkitehtuurin luomistasiten, että koko tietohallinto palvelee organisaation olemassaolon kannalta kes-keisiä strategisia tavoitteita.

Organisaation selvitettyään itselleen, miksi ja millaisia tietojärjestelmiä se tarvit-see, tulee kokonaisratkaisun yksittäisiä osia ryhtyä kehittämään käytännön ta-solla. Kehittämisellä tarkoitetaan joko kokonaan uusien ratkaisujen luomista taivanhojen ratkaisujen ominaisuuksien parantamista. Perinteiset tietojärjestelmiensuunnittelumenetelmät (ISD Methods) kuten rakenteisen suunnittelun (Structu-red Desing/Analysis) menetelmät palvelevat tätä tarkoitusta.

Tässä artikkelissa tarkastelemme tietojärjestelmien kehittämismenetelmiä jaerityisesti niiden soveltuvuutta pk-yrityksissä tehtävään kehittämistyöhön. Ta-voitteena on luoda kokonaiskuva tietojärjestelmätieteen menetelmistä ja ku-

139

vaustavoista sekä arvioida niiden lähtökohtia, tavoitteita ja sisältöä. Raportissaesitetään myös viitekehys, jonka avulla menetelmiä arvioidaan.

2. Tietojärjestelmien kehittämisen menetelmät

Tietojärjestelmiä voidaan kuvata systemaattisesti menetelmien avulla sekä ylei-sellä että yksittäisen tietojärjestelmän tasolla. Englanninkielisessä terminologias-sa tietojärjestelmien kehittämiselle on kaksi eri käsitettä riippuen siitä kumpaatasoa tarkoitetaan: strategia- ja arkkitehtuuritason suunnittelusta puhuttaessakäytetään termiä information systems planning (ISP) ja yksittäisen tietojärjes-telmän suunnittelusta puhuttaessa termiä information systems design (ISD). Onkuitenkin huomattava, että käsitteet menevät päällekkäin siten, että osa ISP:nvaiheista (arkkitehtuurin tarkempi suunnittelu) ulottuu jo lähelle ISD:tä ja vas-taavasti useimmat ISD-menetelmät sisältävät vaiheen, jossa tietojärjestelmänympäristöä, kontekstia, voidaan ainakin jollain tasolla tarkastella. Koska suomenkieleen ei ole vakiintunut yhtä yksikäsitteisiä ja selkeitä termejä, puhumme tässäraportissa ISP:stä ja ISD:stä.

Tietojärjestelmien suunnittelumenetelmiä (sekä ISP- että ISD-menetelmiä) ontarjolla runsaasti. Niillä yleisesti ottaen on hyvin samankaltaisia ominaisuuksia. Senvuoksi tyydymme tässä yhteydessä tekemään vain karkean jaon ISP-menetelmien jaISD-menetelmien välille sekä ISD-menetelmien sisällä tarkastelemaan kahta pää-linjaa, rakenteista suunnittelua ja oliosuuntautunutta suunnittelua.

2.1 Yleistä menetelmistä

Menetelmällä tarkoitetaan tietojärjestelmätieteessä yleensä ohjeistusta siitä,miten tiettyjä kuvaustapoja tai tekniikoita tulisi käyttää. Myös kuvaustavat kat-sotaan kuuluvaksi menetelmään. Usein eri menetelmiin liittyy samankaltaisia taijopa samoja kuvaustapoja (kuva 1). Kuvaustapojen taustalla on implisiittinen taieksplisiittinen käsitys kuvaustapaan liittyvistä käsitteistä. Esimerkiksi prosessinmallintamismenetelmä voi rakentua tietovirta- ja tehtävä-käsitteiden varaan.Tällöin kaikki mallin kannalta keskeiset asiat on kyettävä kuvaamaan joko tieto-virtoina tai tehtävinä. On kuitenkin hyvin tavanomaista, että menetelmän käsite-rakennetta muutetaan (esim. täydennetään) kesken mallintamisen. Tämä sinänsävaarattomalta tuntuva toimenpide voi kuitenkin tietyissä tilanteissa johtaa han-kaliin ongelmiin esimerkiksi eri aikoina tehtyjen mallien vertailussa, koska ei

140

voida tietää, johtuvatko mallien erot puutteista tai epätäsmällisyyksistä itsemalleissa vai siitä, että on käytetty käsiterakenteeltaan poikkeavaa mallintamis-menetelmää (ts. menetelmän eri versioita).

Kuva 1. Menetelmät ja tekniikat.

Tietojärjestelmien suunnittelumenetelmien ”kulta-aika” ajoittui 1970-luvunlopulta 1990-luvun alkupuolelle. Tuona aikana kehitettiin valtaisa määrä niinISP- kuin ISD-menetelmiäkin. 1990-luvulla tietojärjestelmien kehittämisentärkeimmäksi paradigmaksi on noussut oliokeskeisyys. Oliokeskeisiä menetel-miä on käytetty jossain määrin ”väljemmin” kuin rakenteisia menetelmiä. Syynälienee se, että olioajattelu on kehittynyt useasta eri suunnasta (ennen kaikkeatietokantojen hallintajärjestelmien (OODBMS) ja olio-ohjelmoinnin (OOP)suunnasta), minkä vuoksi oliolähestymistavasta ei ole muodostunut täysin yhte-näistä käsitystä.

Viimeaikainen tietojärjestelmiin kohdistuva tutkimus (esim. Russo et al. 1995) onnostanut esiin erityisesti käytännön elämässä käytettävien menetelmien tilanne-ja/tai organisaatioriippuvuuden: lähes poikkeuksetta käytetty menetelmä onrakennettu itse tai olemassa olevaa menetelmää on muutettu omaan toimintaym-päristöön sopivaksi (engl. local method development). Menetelmien kehittämi-nen ja muokkaaminen (method engineering) on muodostunut omaksi sarakseentietojärjestelmien alueella (Brinkkemper 1996, Tolvanen 1998). Tämä kehitys onjohtanut myös siihen, että entistä suurempi paino on pantu yksittäisiin kuvausta-poihin ja kuvauskieliin. 1990-luvulla syntynyt UML (Unified Modeling Langu-age) (OMG 1999) on ehkä tunnetuin esimerkki kuvauskokoelmasta, joka ei

141

sisällä laajamittaisia ohjeita siitä, miten eri kuvaustapoja tulisi erilaisissa tilan-teissa soveltaa.

Pk-yrityksissä, joissa resurssit ovat yleensä hyvin rajalliset, on usein mahdotontakäyttää monimutkaisia menetelmäkokonaisuuksia. Sen sijaan tarvitaan joustaviatapoja tilanteen mukaan kuvata riittävällä tasolla tietojärjestelmän ominaisuuk-sia. Tämä ei tietenkään sulje pois sitä mahdollisuutta, että tietyissä tilanteissakäytettäisiin olemassa olevia valmiita menetelmiä. Pääsääntöisesti on kuitenkinaina pyrittävä tarkastelemaan huolella tilannetta ja tarkoitusta, miksi ja mitenkuvaustapoja ja -välineitä ollaan käyttämässä.

Osa-alueet, jotka tietojärjestelmien kehittämisessä tulee ottaa huomioon, onesitetty kuvassa 2 (muokattu lähteestä Päivärinta 2000). Erilaiset painotuksetnäiden tekijöiden suhteen johtavat myös erilaisiin menetelmävalintoihin. Kuvanmukaan tietojärjestelmien kaksi pääkomponenttia on sosiaalinen ja teknologinenjärjestelmä. Teknologia nähdään tietojärjestelmien toteutusvälineenä. Tärkey-destään huolimatta teknologia nähdään tässä viitekehyksessä sitä kautta, mitense liittyy sosiaalisen järjestelmän osiin. Sosiaalinen järjestelmä muodostuu (1)rooleista ja roolien muodostamista rakenteista (organisaatiorakenteet), (2)tavoitteista ja rajoitteista sekä (3) prosesseista ja tehtävistä. Tavoitteet ja rajoit-teet ovat kaiken järjestäytyneen, tarkoituksellinen toiminnan perusta. Niistäkäsin määritellään toimijat (roolit ja rakenteet), toiminta (tehtävät) ja toimintata-pa (prosessit). Tavoitteet liittyvät teknologiaan paitsi sosiaalisen järjestelmänvälityksellä, mutta myös itsenäisenä osana (tekniikka toiminnan mahdollistaja-na).

Tieto on tässä viitekehyksessä sosiaalisen ja teknologisen järjestelmän leikkaus-alueella. Sen käsittely ja tallennus muodostaa mitä suurimmassa määrin tietotek-nisen ongelman. Toisaalta tietojärjestelmien hyväksikäyttö perustuu juuri tiedonhyväksikäyttöön, joka puolestaan tapahtuu sosiaalisen järjestelmän ehdoilla,rajoitteilla, tavoitteilla ja resursseilla. Ihminen älyllisenä toimijana liittyy jokai-sen osa-alueen määrittelyyn ja toteutukseen.

Eri menetelmät painottavat kuvan 2 viitekehityksen osa-alueita eri tavoin. ISP-menetelmät kattavat yleensä kaikkien komponenttien tarkastelun, mutta painot-tuvat tavoitteiden määrittelyyn. Ne vastaavat kysymyksiin ”mitä” ja ”miksi”.ISD-menetelmät puolestaan ovat toteutuspainotteisia vastaten kysymykseen

142

”miten”. Riippuen ISD-menetelmän soveltamiskohteesta painopiste on yleensätiedon, prosessien tai teknologian suunnittelussa.

Roolit jarakenteet

Teknologinenjärjestelmä

Sosiaalinen

järjestelmä

Tieto

Teknologia

Prosessit jatehtävät

Tavoitteet jarajoitteet

Kuva 2. Järjestelmäkehityksen osa-alueet.

Esittelemme seuraavassa lyhyesti tietojärjestelmätieteen alueella kehitettyjämenetelmiä ja tarkastelemme niitä yllä olevaa viitekehystä vasten. Aluksi ker-romme lyhyesti ISP-menetelmistä, sen jälkeen luomme katsauksen rakenteisiinja oliosuuntautuneisiin ISD-menetelmiin. Varsinaisten menetelmien jälkeentarkastelemme esimerkinomaisesti menetelmäriippumattomia kuvaustapoja ja-välineitä. Lopuksi esitämme tiivistetyn kuvauksen Jyväskylän yliopiston Tieto-tekniikan tutkimusinstituutissa kehitetystä smeISP-menetelmästä, joka on erityi-sesti pk-yritysten tarpeisiin kehitetty suunnittelumenetelmä.

143

Menetelmien soveltamista pk-yrityksiin tarkastellaan kohdassa 3.

2.2 ISP-menetelmät

ISP-menetelmien kirjo on laaja. Tarjolla olevat menetelmät ovat joko kattaviakokonaismenetelmiä, tai ne keskittyvät joko strategiseen suunnitteluun tai vaih-toehtoisesti tietoja tietojärjestelmäarkkitehtuurien suunnitteluun. Yhteistäkaikille ISP-menetelmille on se, että niiden avulla ei mallinneta yksittäisiä tieto-järjestelmiä, vaan ne pyrkivät tukemaan organisaatiota koko tietohallinnon to-teutuksessa, mukaan lukien laitteisto- ja ohjelmistoratkaisut, tiedonhallinnan jatietohallinnon organisoinnin.

Vanhin ISP-menetelmistä lienee IBM:n kehittämä Business Systems Planning(BSP, ks. esim. IBM 1984), jonka ensimmäinen versio otettiin käyttöön jo 1960-luvulla. BSP:tä tai sen osia käytetään edelleen. BSP sisältää tarkkaan vaiheiste-tun prosessin, jonka lopputuloksena yritys saa tietohallintosuunnitelman. BSP-menetelmän oleellisena osana on matriisit, joiden avulla hahmotetaan yrityksentieto- ja tietojärjestelmäarkkitehtuurit. Matriisiesitykset ovat osoittautuneet niintoimiviksi, että monissa muissa menetelmissä on omaksuttu sama esitystapa(esim. Information Engineering, Martin 1989).

Matriisiesityksistä kaikkein kuvausvoimaisin lienee toiminto-tietokohdematriisi(BSP-matriisi), jossa toisella akselilla kuvataan yrityksen toiminta prosessienmuodossa ja toisella akselilla liiketoiminnan kannalta keskeisimmät tietokohteet(taulukko I). Tietokohteiden ja prosessien välille luodaan yhteys täyttämällämatriisin asianomaiset kohdat erilaisin symbolein riippuen siitä, luodaanko,käytetäänkö tai poistetaanko tietoa kyseisessä prosessin vaiheessa. Matriisinavulla pyritään määrittelemään selkeästi, mikä organisaation osa vastaa tiedosta.Tavoitteena on muodostaa tietojärjestelmärajaukset ja saada kuvattua yrityksentietojärjestelmien kokonaisarkkitehtuuri, joka kertoo mitä järjestelmiä yritykselläon ja mitkä ovat järjestelmien väliset liittymät.

144

Taulukko I. Esimerkki BSP- (toiminto- tai tietokohde-) matriisista.

Vastaan-otto

Han-kinta

Priori-teetin

tarkistus

Varas-tointi

Asiakas-palvelu

Huo-linta

Ostotilaus lukee luoToimittajatiedot lukee lukee päivittääHinnat lukee lukeeTuotetiedot lukee lukee lukee lukeeVarastotiedot päivittää päivittää lukeeKuljetustiedot luo lukee lukee päivittää päivittääMuistutustiedot lukee

BSP on kokonaisvaltainen menetelmä, joka lähtee liikkeelle liiketoimintaproses-seista ja kriittisistä tietotarpeista. Vaikka tarkastelukohteina ovat tiedot ja pro-sessit, voidaan menetelmää pitää myös liiketoiminnan tavoitteisiin pureutuvana,sillä BSP-suunnittelun alkuvaiheet tarkastelevat tietoresurssia ylimmän johdonnäkökulmasta. BSP:n matriisikuvaukset soveltuvat erittäin hyvin tilanteeseen,jossa yrityksen tietojärjestelmiä tulee kokonaisuudessaan arvioida uudelleen,mutta irrallisina kuvauksia (ilman tavoitemäärittelyä) niiden hyöty on kyseen-alainen. Lisäksi matriisien tekeminen, varsinkin organisaation laajuisesti, ontyöläs tehtävä. Esim. pk-yrityksillä on harvoin riittävästi resursseja BSP-menetelmän kaltaiseen suunnittelutyöhön. BSP:n käyttö edellyttää yleensä myöshuomattavaa asiantuntija-apua.

Muista ISP-menetelmistä mainittakoon Martinin (1989) Information Enginee-ring (Osa: Planning and Analysis) ja METO-3 (Sääksjärvi 1990), jotka ovatviitekehyksen valossa varsin samankaltaisia kuin BSP. Sen sijaan usein muihinmenetelmiin sisällytetyt, mutta myös omina menetelminään käytetyt CriticalSuccess Factors -menetelmä (CSF, Rockart 1982) ja CATWOE (Checkland1981) ovat esimerkkejä ISP:hen soveltuvista menetelmistä, jotka painottuvaterityisesti tavoitteiden määrittelyyn. CSF:n painopiste on tavoitteiden ja rooliensekä tavoitteiden ja tehtävien välisten vuorovaikutussuhteiden määrittelyssä.CATWOE, joka pyrkii luomaan kohdejärjestelmästä ”rikkaan kuvan”, soveltuu

145

erityisesti kuvattavan kohteen toiminta-ajatuksen (tarkoituksen) määrittelyyn.Rikas kuva syntyy tarkastelemalla kohdejärjestelmää useista eri näkökulmista.

2.3 Arkkitehtuurisuunnittelusta

ISP-menetelmät käsittelevät teknistä järjestelmää harvoin yksityiskohtaisellatasolla. Sen sijaan arkkitehtuureihin painottuvat ISP-menetelmät tarkastelevatsiirtymää organisatorisesta ratkaisusta kohti teknistä toteutusta. Arkkitehtuurientehtävänä on jäsentää kohdejärjestelmän osat ja niiden väliset vaikutussuhteet.

Liiketoiminnan globalisoituminen ja tietoliikenteen nopea kehitys ovat johtaneethajautettujen tietojärjestelmien yleistymiseen, samalla kun tietojärjestelmistä ontullut yhä monimutkaisempia (esim. ERP-järjestelmät). Kehitys on lisännytarkkitehtuurisuunnittelun merkitystä. Tietojenkäsittely tapahtuu enenevässämäärin tietoverkoissa, minkä vuoksi arkkitehtuurisuunnittelu on tullut yhä tär-keämmäksi. Ensinnäkin tietoverkoissa on kytketty valtava määrä erilaisia lait-teita toisiinsa, joiden on kyettävä kommunikoimaan keskenään sisäisten ratkai-sujensa eroista huolimatta. Toiseksi tieto on hajaantunut tai hajautettu eri puo-lille tietoverkkoa, jolloin tiedonhallinta muodostuu monimutkaiseksi. Kolman-neksi liiketoiminnan globalisoituminen on johtanut esimerkiksi siihen, että tuo-tekehitystiimin on voitava tehdä yhteistyötä reaaliaikaisesti, vaikka tiimin jäse-net työskentelisivätkin eri mantereilla.

Arkkitehtuurisuunnittelua, joka kytkee yksittäiset tietojärjestelmät yrityksenkokonaisjärjestelmäksi (Enterprise Architecture) ja joka tukee tehokkaasti nyky-aikaista komponenttipohjaista tietojärjestelmän kehitysstrategiaa, voidaan pitääitsenäisenä tietojärjestelmien suunnittelun osa-alueena. Tässä yhteydessä olem-me kuitenkin sisällyttäneet arkkitehtuurisuunnittelun (ja vastaavat menetelmät)ISP-menetelmiin, sillä sen painopiste on pikemminkin kokonaisjärjestelmänkuin yksittäisen järjestelmän hallinnassa.

Ehkä tunnetuin arkkitehtuurisuunnittelun viitekehys on Zachmanin (1987) esit-tämä Framework for information systems architecture. Se kuvaa arkkitehtuuri-suunnittelun kohteet ja tasot. Zachmanin viitekehystä voidaan pitää nykyaikaisenEnterprise Architecture -ajattelun yhtenä perustana, josta on johdettu useat muutviitekehykset, kuten The Information FrameWork (IFW) (Evernden 1996).Zachmanin viitekehyksen ohella toinen kokonaisvaltainen arkkitehtuurisuunnit-

146

telun viitekehys on Scheerin (1998) ARIS, jota on hyödynnetty ennen kaikkealaajojen toiminnanohjausjärjestelmien suunnittelussa.

Pk-yritykset saattavat jossain määrin säästyä kansainvälisen kehityksen rajuim-milta muutoksilta (esim. yritys voi toimittaa tasaisella volyymilla yksinkertaistaalihankintatuotetta paikalliselle asiakkaalleen). Pitkällä tähtäyksellä pk-yritystentietojärjestelmiin kohdistuu kuitenkin myös samankaltaisia paineita kuin suur-yritystenkin: järjestelmien on kyettävä toimimaan osana maailmanlaajuistatietoverkkoa ja ennen kaikkea osana sitä yhteistoimintaverkkoa, johon yrityskuuluu.

2.4 ISD-menetelmät

ISD-menetelmät voidaan karkeasti ottaen jakaa rakenteisen suunnittelun (struc-tured desing/analysis) menetelmiin ja oliosuuntautuneisiin (object-oriented)menetelmiin.

Rakenteinen suunnittelu

Rakenteisella suunnittelulla tarkoitetaan vaiheittain kokonaisuuksista yksityis-kohtiin menevää suunnitteluperiaatetta. Ensin kuvataan kokonaisuus, joka suun-nittelun edetessä jaetaan yhä pienempiin osiin. Hierarkkinen ositus muodostaaloogisen kokonaisuuden. Osittaminen tapahtuu sellaisilla kuvaustavoilla, jotkatukevat sekä suunnittelun että ohjelmointityön jakamista itsenäisesti hallittaviinosiin. Suunnittelun keskeisenä kuvauskohteena ovat tietovirrat. Muita keskeisiäkäsitteitä ovat prosessi/toiminto, tietovarasto ja ulkoinen kohde.

Rakenteisen suunnittelun menetelmät perustuvat selkeästi määriteltyyn, vaiheit-taisen etenemistapaan. Ne tuottavat melko helposti ymmärrettäviä malleja koh-dejärjestelmän toiminnasta. Sopivalla tavalla soveltaen niitä voidaan hyödyntäämyös koko organisaation toimintojen kuvaamiseen, vaikka ne on yleensä tar-koitettu rajatumpien kohteiden kuvaamiseen.

Yksi laajalle levinneistä rakenteisen suunnittelun menetelmistä on SADT ja senjohdannainen IDEF0 (FIPS 1993). IDEF0-kuvaustavan perusrakenne on esitettykuvassa 3 ja kuvauskohteen osittamisen periaate on esitetty kuvassa 4.

147

TOIMINNONNIMI

Ohjaus

Syöte

Mekanismi

Tulos

Kuva 3. IDEF0-kuvaustavan peruselementit.

4

3

2

1

3

2

1

A0

A4

A-0

Yleisempikaavio

Yksityiskohtaisempi

Laatikon sisältö tarkemmintässä toisessa kaaviossa

A4

A42Numerot osoittavatkuvauksen tasoa.

A00

Kuva 4. IDEF0-rakenteinen kuvaustapa.

148

Rakenteisen suunnittelun menetelmät ovat perinteisesti painottaneet suunnitte-lussa tietoa ja prosessia, ts. miten tieto kulkee prosesseissa ja miten sitä käsitel-lään eri vaiheissa. IDEF0:n kaltainen menetelmä ottaa myös jossain määrinkantaa toiminnan ohjausrakenteisiin ja toimijoihin. Näin ollen sen voidaankatsoa tarvittaessa mahdollistavan myös roolien kuvaamisen. Rakenteisen me-netelmän tuottamat kuvaukset ovat yleensä semanttisesti selkeitä: virhetulkintojatulee harvoin, jos kuvaussymbolit on selkeästi määritelty. Mikäli tämä etu halu-taan säilyttää, on rakenteista kuvaustapaa uusiin tarkoituksiin (esim. tavoitteidenkuvaamiseen) sovellettaessa pidettävä mielessä notaation yksityiskohtainenmäärittely. Esimerkiksi vaatimusmäärittelyyn rakenteisen suunnittelun menetel-mät soveltuvat varsin hyvin, kun kuvauksia tehtäessä muistetaan, että kyseessäon nimenomaan järjestelmän toiminnallisten vaatimusten kuvaaminen eikätoteutuksen suunnittelu (vaatimusmäärittelyvaiheessa voidaan unohtaa moniakäyttäjän kannalta vähän kiinnostavia toteutuksen yksityiskohtia).

Oliosuuntautunut suunnittelu

Oliosuuntautunut suunnittelu tarkoittaa sitä, että ohjelmistoa tai järjestelmääsuunniteltaessa pyritään etsimään ja mallintamaan kohdealueen luonnollisiakokonaisuuksia, joita kutsutaan olioiksi. Suunnittelussa pyritään mahdollisim-man suureen vastaavuuteen reaalimaailman ja siitä laadittavan mallin välillä.Oliosuunnittelussa pyritään siis esittämään kohteet sellaisina kuin ne todellisuu-dessa ilmenevät toiminnallisine ja muine ominaisuuksineen.

Olioajatteluun liittyy keskeisesti hierarkkinen jäsennystapa ja yksityiskohtienpiilottaminen. Hierarkkinen jäsennys tarkoittaa olioluokkien järjestämistä hie-rarkkisesti siten, että alemman luokan oliot perivät ylemmän luokan ominaisuu-det (kuva 5). Periytyminen onkin olioajattelun ehkä keskeisin piirre. Yksityis-kohtien piilottamisella tarkoitetaan sitä, että olioluokan toteutuksessa ei tarvitseottaa huomioon muiden olioluokkien toteutusta. Oliot tietävät toisistaan vainsen, mitä palveluja ne voivat toisiltaan saada, mutta eivät sitä, miten palvelu ontuotettu. Tällainen yksityiskohtien piilottaminen helpottaa oleellisesti olioidenkäyttämistä itsenäisinä komponentteina eri sovelluksissa. Oliosuunnittelua onkinpidetty tärkeänä askeleena kohti tietojärjestelmäkomponenttien uudelleenkäyt-töä. Olioajattelun peruspiirteet tukevatkin tätä tavoitetta. Siitä huolimatta oliolä-hestymistapa ei ole ainoa ratkaisu tietojärjestelmien uudelleenkäytön alueella.

149

Päivittää

VarastoIDOsoiteKaupunkiMaa

Varasto

Vaihda tuoteSijoita tuotePäivitä tuotetiedot

TuoteIDTuotenimiVäriPaikka

Tuote

KorkeusLeveysHyllyID

HyllyKäytäväID

Käytävä

0,M1,M

0,M

1,M

Tekee jälkitoimituksenTekee laskunTarkista tuotteen saatavuusTilaa tuotteita

NimiHloIDOsoiteOsasto

Myyjä

Tilaa tuotteitaTarkista tuotteen saatavuus

AsiakasIDNimiOsoiteMaaPuhnro

Asiakas

Luo

Päivitä tuotetiedotTarkista tuotteen saatavuus

TilauskäsittelijäTuotenimiMääräTilauspvmHinta

Tilaus

1,M

Alennus%Myyntitilaus

Alennus%Ostotilaus

Luo ilmoitus asiakkaalle

ToimituspvmJälkitoimitus

Periytymissuhde

Kuva 5. Esimerkki oliokaaviosta.

Oliomenetelmät ovat jossain määrin toteutusorientoineempia kuin rakenteisensuunnittelun menetelmät. Tällä tarkoitetaan lähinnä sitä, että oliosuunnitteluetenee ”liukuvasti” kohti toteutusta (luokkien suunnittelu → luokkien toteutus),kun taas rakenteisen suunnittelun ja toteutuksen raja on selvemmin määriteltä-vissä (suunnitelmien ”kääntäminen” ohjelmointikielelle). Oliomenetelmienpainopiste on tiedon ja tehtävien (reaalimaailman kohteiden ja niihin liittyvientehtävien) mallintamisessa. Oliomallintamisessa voidaan kuvata myös tehtävä-ketjuja (esim. käyttötapaukset) tai prosesseja (esim. toimintakaavio). Olioajat-telun keskeinen periaate kulminoituu kuitenkin olioluokkiin liittyvien tietojen jatoiminnallisuuden kuvaamiseen. Olioluokkien suunnittelu ja toteutus, jotkatukevat kyllä hyvin komponenttiajattelua, eivät välttämättä tue esim. liiketoi-mintaprosesseihin perustuvaa ajattelutapaa.

Menetelmäriippumattomat kuvaustavat

On teoreettinen ongelma vetää tarkkaa rajaa menetelmien ja kuvaustapo-jen/tekniikoiden välille. Menetelmäkuvauksen katsotaan yleensä sisältävänpaljon tietoa mallintamisprosessista, mutta niin myös kuvaustekniikankin tulee

150

sisältää jonkinlaiset ohjeet siitä, miten kuvaus koostetaan. Niinpä periaatteessairrallisia kuvaustapoja voidaankin käyttää ”menetelmämäisesti” ottamalla huo-mioon mallinnuksen tarkoitus ja konteksti. Hyvin usein kokonaisvaltaisten me-netelmien sijaan käytetäänkin yksittäiseen tehtävään soveltuvaa menetelmäriip-pumatonta kuvaustapaa. Esimerkiksi oliosuunnittelussa tämä suuntaus on johta-nut UML-kuvauskielen kehittämiseen (ks. Fowler ja Scott 1997). Seuraavaksitarkastelemme esimerkinomaisesti, millaisia yleiskäyttöisiä kuvaustapoja ontarjolla.

Työnkulkukaaviot (Process flowcharts)

Lähes koko atk-pohjaisten tietojärjestelmien historian ajan on järjestelmientoimintaa kuvattu työnkulkukaavioiden avulla. Tavoitteena on ollut toistuvientehtäväkokonaisuuksien hahmottaminen ja usein prosessien pitkälle viety auto-matisointi. Työnkulkujen suunnittelussa käytetään yleensä jonkinlaista graafistatyökalua, jolla voidaan määritellä työnkulkuun kuuluvat osatehtävät, niidensuoritusriippuvuudet ja mahdolliset toimintoihin liittyvät vaatimukset.

Työnkulkua kuvaavat graafiset mallit eli työnkulkukaaviot voidaan jakaa 1)viestintäpohjaisiin, 2) toimintopohjaisiin sekä 3) hybridimalleihin (Joutsjärvi1996). Viestintäpohjaisia malleja ovat neuvottelu- ja puheaktimallit. Neuvotte-lumalli kuvaa liiketoimintaprosessin yksittäiset toiminnot nelivaiheisina silmu-koina, joilla pyritään kuvaamaan viestintää suorittajan ja asiakkaan välillä.SAMPO (Speed act-based information analysis methodology with computer-aided tools) on puheaktiteoriaan perustuva, neuvottelumallia kattavampi ku-vausmenetelmä, joka auttaa havainnoimaan ristiriitaisuuksia ja epätäsmällisyyk-siä viestinnässä ja sitoutumisessa tehtävien suorittamiseen (Auramäki et al.1992). Puheakti on SAMPO-menetelmässä yksittäinen viestintätapahtuma jakeskustelu on järjestetty puheaktien sarja. Toimintopohjaiset mallit ovat vuokaa-vioita, jotka kuvaavat työn suoritusjärjestystä, mutta eivät ota huomioon suorit-tajia. Hybridimalleissa esitetään useampia työnkulun ulottuvuuksia yhtä aikaa,kuten tehtävien suorittajat ja tehtävien suoritusjärjestys.

Käsitemallit (Entity-relationship models)

Siinä missä työnkulkukaaviot kuvaavat järjestelmää peräkkäisten toimenpiteidenmuodostaman dynamiikan näkökulmasta, on järjestelmän staattisen rakenteen

151

kuvaamiseen luotu myös joukko kuvaustapoja. Tietojärjestelmien kehittämisenalueella käytetyimpiä lienevät erilaiset käsitemallinnustekniikat. Niiden avullapyritään löytämään reaalimaailman kohteita, joihin liittyvään tietoon mallinnet-tavan järjestelmän toiminta kohdistuu. Järjestelmän kohdealueesta muodostetaankäsitemalli, joka kuvaa paitsi relevantit kohteet, myös niiden väliset suhteet(kuva 6). Käsitemallia voidaan täsmentää liittämällä siihen kohteita kuvaaviaattribuutteja. Englannin kielessä laajennetusta käsitemallista puhutaan nimellä’ERA model’ (Entity-relationship-attribute model). Kohteiden välisiä suhteitavoidaan niin ikään kuvata eri tarkkuustasoilla (esim. asettaa tai olla asettamattasuhteisiin rajoitteita tai ehtoja).

Osa#

Tuote

Nimi

TyöntekijäID

Ostotilaus

NimiOsasto

Projekti

ToimittajaID

Tilauspäivä

Jakelupvm

Tekee

TilausID

Osoite

Nimi

Osoite

Määrä

Sisältää

Osallistuu

Väri

OsastoID

Kuuluu

Projekti ID

Työntekijä

M

1,M

1

1

M

M

M

Nimi

Toimittaja

Jakelee

M

M

Kuva 6. Esimerkki käsitemallista (Entity-Attribute-Relationship model).

Käsitemallit ovat käyttökelpoisia sekä rakenteisessa että oliosuunnittelussa,mutta varsinkin oliosuunnittelussa ne palvelevat hyvin olioluokkien määrittelyä.Oliomenetelmien olioluokkakaaviot muistuttavatkin hyvin pitkälle käsitemallejasillä erotuksella, että olioluokkakaavioissa otetaan yleensä huomioon huomatta-vasti enemmän toteutuksessa tarvittavia näkökohtia ja sen vuoksi niissä on mää-

152

ritelty myös olioiden toiminnalliset piirteet. Viitekehyksessämme käsitemallitsijoittuvat puhtaasti tiedon mallintamiseen.

UML:n sisältämiä kuvaustapoja

UML (Unified Modeling Language) sisältää suuren joukon erilaisia kuvausta-poja, jotka on koostettu useista eri oliopohjaisista menetelmistä (OMG 1999,Fowler ja Scott 1997). Seuraavassa käydään lyhyesti läpi keskeisimpien UML:nkuvaustapojen (tekniikoiden) käyttötarkoitukset.

− Toiminta- ja aktiviteettikaavio (activity diagram) kuvaa käyttäytymistä jakontrollirakenteita. Se soveltuu varsinkin tilanteisiin, joissa on useita rin-nakkaisia prosesseja (prosessi haarautuu). Riippuen siitä, onko kyseessä kä-sitetason vai toteutustason mallinnus, toiminnalla (activity) tarkoitetaan jokosuoritettavaa tehtävää tai olioluokan metodia (toiminnallista ominaisuutta).

− Luokkakaavio (class diagram) kuvaa kohdealueen käsitteiden, tyyppien jaluokkien staattisen rakenteen. Käsitteet ovat tapa kuvata käyttäjän näkökul-masta kohdealuetta. Tyypit puolestaan kuvaavat ohjelmistokomponenttienväliset rajapinnat. Luokat kuvaavat ohjelmistokomponenttien toteutuksen.

− Toteutus- ja sijoittelukaavio (deployment diagram) on varsin vähän käytettykuvaustapa, jonka avulla kuvataan ohjelmistoja laitteistokomponenttienliittyminen toisiinsa.

− Pakkauskaavio (package diagram) kuvaa luokkien ryhmät ja niiden keski-näiset riippuvuudet.

− Käyttötapaus (use case) esittää käyttäjien vaatimukset tarkoituksenmukaisinakokonaisuuksina tai siivuina. Rakennesuunnittelu tehdään joidenkin käyttöta-pausten ympärille. Käyttötapaus toimii perustana järjestelmän testaamiselle.

− Vuorovaikutuskaavio (interaction diagram) kuvaa sitä, kuinka useat oliotkommunikoivat yksittäisessä käyttötapauksessa.

− Tilakaavio (state diagram) kuvaa yksittäisen olion käyttäytymistä useassakäyttötapauksessa.

153

UML:n kuvaustapakokoelma on laaja. Kärjistäen voidaan kuitenkin sanoa, ettäUML:n kuvaustavat kokonaisuudessaan painottavat hyvin pitkälle samoja näkö-kulmia kuin kattavat oliosuuntautuneet menetelmätkin.

2.5 Apuvälineitä menetelmien käyttöön ja mallien laatimiseen

Tässä kohdassa käsitellään kahta erilaista tapaa tukea menetelmien ja kuvausta-pojen käyttöä: seinätaulutekniikkaa ja (meta)CASE-välineitä.

Seinätaulutekniikka

Tietojärjestelmien kehittämisessä paljon käytetty tekniikka on seinätaulutekniik-ka (ks. esim. Saaren-Seppälä 1997). Nimestään huolimatta seinätaulutekniikka eiole yhtenäinen tekniikka vaan joukko suosituksia, kuinka tietojärjestelmiä voi-daan kuvata seinätaulujen avulla. Niinpä seinätaulujen käyttötavat ovatkin muo-toutuneet mitä moninaisimmiksi. Seinätauluja voidaan soveltaa yhtä hyvin raken-teisen suunnittelun tietovirtakaavioiden, oliosuunnittelun luokkakaavioiden kuinmonien muidenkin kaavioiden visualisoimiseksi (usein laajalle kohderyhmälle).

Seinätaulutekniikan vahvuus on sen visuaalinen kuvausvoima sekä helppokäyt-töisyys. Jo pienellä koulutuksella voi asiaan aiemmin perehtymätönkin saadaaikaan käyttökelpoisia kuvauksia. Ongelmana on usein vakiintumattomat ku-vaustavat: epäformaaliudesta johtuen syntaksia1 ei ole ja kuvausten täsmällinensemanttinen tulkinta voi olla vaikeaa.

Ajan myötä on pyritty vakiinnuttamaan tiettyjä seinätaulutekniikoita. Esimerkkisellaisesta on lävistäjämatriisi, jonka avulla pyritään yleensä kuvaamaan organi-saation osien välisiä tietovirtoja. Tekniikka on sisällytetty mm. myöhemminesiteltävään smeISP-menetelmään.

1 Syntaksi eli lauseoppi (engl. syntax) on välttämätön kaikille formaaleille kielille jaesitystavoille, kuten ohjelmointikielille.

154

CASE- ja metaCASE-välineet

Menetelmien käytön tehostamiseksi on jo useiden vuosien ajan ollut tarjollatietokonepohjaisia suunnitteluohjelmistoja, CASE-ohjelmistoja (Computer AidedSoftware/System Engineering). Ne ovat usein tukeutuneet yhden menetelmän taimetodologian tukemiseen. Jotkut CASE-välineet saattavat tarjota vaihtoehtoi-sesti rakenteisen tai oliosuuntautuneen mallinnustavan.

Kuten jo aiemmin on mainittu, menetelmiä joudutaan usein muokkaamaan ku-hunkin tilanteeseen sopiviksi. On myös tavallista, että yksi menetelmä ei riitäkattamaan kaikkia mallinnustarpeita, vaan menetelmiä joudutaan yhdistelemään,usein vieläpä vastoin menetelmän kehittäjän alkuperäistä tarkoitusta. Meta-CASE-ympäristöt ovat tietokonepohjaisia ohjelmistoja, joiden avulla tilanne-kohtainen menetelmäkehitys (local method development) helpottuu. Ne muo-dostuvat tyypillisesti kuvauskannasta ja työkaluista, joilla luodaan, muokataan jahallitaan sekä malleja että metamalleja. Mallit ovat varsinaisen mallinnuksettuloksia (esim. tietovirta- tai käsitekaavioita) ja metamallit tietomalleja varsinai-sen mallintamismenetelmän käsitteistä ja niiden välisistä suhteista. MetaCASE-ympäristöistä esimerkkinä mainittakoon Jyväskylän yliopistossa kehitetty Meta-Edit+(Kelly 1997).

3. Menetelmien soveltamisesta pk-yrityksissä

Tietojärjestelmien suunnitteluun ja toteutukseen on pk-yrityksessä käytettävissäpienemmät resurssit kuin suurissa yrityksissä. Tämä vuoksi myös käytettävillemenetelmille asetetaan erityisvaatimuksia. Menetelmien tulee olla käsiteraken-teeltaan yksinkertaisia ja helposti omaksuttavia, jotta menetelmän ominaispiir-teiden ja käytön oppiminen olisi mahdollista kohtuullisessa ajassa. Koska pk-yrityksellä on harvoin käytettävissä omia asiantuntijoita, menetelmän käyttöön-otto edellyttää usein ulkopuolista konsultointiapua. Menetelmän on kuitenkinoltava sellainen, että yrityksen henkilöt pystyvät lyhyehkön koulutuksen jälkeenitse tuottamaan huomattavan osan kuvauksista tai muista suunnitelmista. Toi-saalta menetelmä ei saisi olla liian epämääräinen, vaan sen tulisi tukea syste-maattista etenemistapaa ja sen avulla tulee syntyä riittävä dokumentaatio suun-nitteluprosessin tuloksista.

155

Tietojärjestelmien suunnittelumenetelmien kehittämisessä on harvoin otettuhuomioon em. pk-yritysten erityispiirteitä. Jyväskylän yliopistossa 1990-luvunalussa kehitetty SPITS-metodologia (Leppänen et al. 1991) on yksi esimerkki ns.tilannekohtaisista menetelmistä, mutta sitäkään ei ole suunniteltu erityisesti pk-yrityksiä silmällä pitäen. Sitä vastoin Jyväskylän yliopistossa kehitetty smeISP-menetelmä on alun perin suunniteltu pk-yritysten tietojärjestelmien kokonais-suunnitteluun. Se on kehitetty pk-yritysten ominaispiirteiden tarkan analysoinninsekä aiemmin kehitettyjen ISP-menetelmien sisältämien yleisten piirteiden poh-jalta.

Seuraavaksi tarkastellaan edellisessä kohdassa esitettyjen menetelmien ja teknii-koiden käyttömahdollisuuksia pk-yrityksissä sekä arvioidaan smeISP:n kaltaisenkokonaisvaltaisen menetelmän soveltuvuutta pk-yrityksiin. Lopuksi pohditaanmenetelmien käytön ongelmia ja haasteita.

3.1 Menetelmien ja tekniikoiden käyttäminen pk-yrityksissä

Tietojärjestelmien kehittäminen pk-yrityksissä on usein ollut epäsystemaattistaja menetelmien käyttö vähäistä. Keskeisimpinä syynä lienee resurssipula: pk-yrityksiä vaivaavat vähäiset henkilö- ja taloudelliset resurssit sekä oman tieto-järjestelmäasiantuntemuksen puuttuminen, varsinkin aivan pienimmissä yrityk-sissä (Palvia et al. 1994). Menetelmätuki lienee useimmiten tarpeen monella eritasolla: organisatoristen tavoitteiden määrittelyssä, tietoresurssien kokonais-kartoituksessa, tietojärjestelmien kehittämistarpeiden ja vaatimusten määritte-lyssä sekä teknisen ratkaisun määrittelyssä. Pk-yritys tarvitsee siis sille soveltu-via ISP- ja ISD-menetelmiä.

Tietojärjestelmätutkimuksessa on viime vuosina yhä enemmän kiinnitetty huo-miota pk-yritysten tietojärjestelmien kehittämiseen (esim. Cragg ja Zinatelli1995, Winston ja Dologite 1999, Toh et al. 1998). Tavoitteena tulee olla pk-yritysten toiminnan suunnitelmallisuuden lisääminen ottaen samalla huomioonpk-yritysten rajoitteet. Seuraavassa pohditaan ISP- ja ISD-menetelmien soveltu-vuutta pk-yritysten tarpeisiin.

156

Lähestymistapojen vertailu

Rakenteisen suunnittelun menetelmät soveltuvat hyvin tietojärjestelmäsuunnitte-lijoiden käyttöön. Niiden tehokas käyttö edellyttää kuitenkin varsin laajaa pe-rehtymistä menetelmiin. Mikäli pk-yrityksellä ei ole omasta takaa henkilöä, jokahallitsee rakenteisen suunnittelun perusteet, eivät kyseiset menetelmät tarjoajärkevää lähtökohtaa ainakaan suunnittelun alkuvaiheessa, jolloin kuvaus onluotava ”tyhjästä”. Rakenteisen suunnittelun menetelmät tuottavat kuitenkinhyvin loogisia kuvauksia, joita on asiaan perehtymättömänkin kohtuullisenhelppo lukea ja tulkita. Siinä mielessä ne soveltuisivat keskusteluvälineeksilähellä toteutusta olevissa suunnitteluvaiheissa. Toisin sanoen asiantuntija voisituottaa kuvaukset, joita yrityksen kanssa käytäisiin yhdessä läpi. Myös liiketoi-mintaprosessien kuvaamiseen rakenteisen suunnittelun menetelmät soveltuvatmonissa tapauksissa hyvin.

Oliosuuntautuneet menetelmät tähtäävät rakenteistakin suunnittelua enemmäntoteutukseen (suunnittelun ja toteutuksen välinen raja on oliosuunnittelussavarsin häilyvä). Toteutuspainotteinen terminologia ja ajattelutapa voivat ollahyvin vieraita järjestelmien loppukäyttäjille. Toisaalta oliosuunnittelussa ”alku-pään” menetelmät (kuten käsitemallintaminen) ovat yleistajuisia ja soveltuvathyödynnettäväksi silloinkin, kun suunnittelu ei jatkossa etene olioperiaatteidenmukaisesti. Mikäli toteutusvälineeksi on jo etukäteen kiinnitetty jokin oliotek-nologia (olio-ohjelmointikieli tai oliotietokanta), voi olla järkevää käyttää vali-koidusti oliosuunnittelun menetelmiä myös käyttäjäorganisaation puolella. Tuo-tesuunnittelun järjestelmät on tyypillinen esimerkki kohdealueesta, jonka toteu-tukseen käytetään yhä lisääntyvässä määrin oliotekniikoita.

UML:n kaltainen kuvaustekniikkakirjasto helpottaa (olio)menetelmien sovelta-mista pk-yritysten tarpeisiin. Tekniikoiden seikkaperäinen kuvaus yhdessäkäyttöesimerkkien kanssa auttaa ymmärtämään, millaiseen mallintamiseen ku-vaustekniikat parhaiten soveltuvat. Se, että UML ei ota kantaa soveltamisproses-seihin (toisin kuin menetelmät), tuo joustavuutta tekniikoiden käyttöön, muttatoisaalta vaikeuttaa tekniikan oppimista. MetaCASE-ympäristöt saattavat tarjotamyös pk-yrityksille käyttökelpoisen vaihtoehdon tilannekohtaisen menetelmänmäärittelemiseksi. Ongelmana on se, että pk-yritys tarvitsee asiantuntija-apuamenetelmän määrittelyyn.

157

Seinätaulutekniikka soveltuu erittäin hyvin käytettäväksi pk-yrityksissä. Se onhelppokäyttöinen ja nopea tapa saada järjestelmiä kuvatuksi. Seinätaulutekniikkaei kuitenkaan saa olla ad hoc -tyylistä, vaan etukäteen on tarkkaan määriteltäväseinätaulun käyttötarkoitus suunnitteluprosessissa. Toisin sanoen ensin on tie-dettävä, mikä on suunnittelutehtävän tarkoitus ja tavoitteet, vasta sen jälkeenvoidaan päättää seinätaulutekniikan tarkoituksenmukaisesta käytöstä. Voidaan-kin sanoa, että ensin on valittava mallintamiskohde ja -tapa ja vasta sitten pää-tettävä, miten sitä seinätaululla tuetaan.

Mallintaminen tiedon ja toiminnan näkökulmasta

Tietojärjestelmien kehittämiseen liittyvä mallintaminen voidaan jakaa karkeastikahteen osaan: tiedon ja toiminnan mallintamiseen. Tiedon mallintamismene-telmistä pk-yritysten tarpeisiin sopivia ovat erilaiset käsitemallintamisen mene-telmät sekä esim. erilaiset matriisiesitykset, jotka voidaan toteuttaa seinätaului-na. Erittäin soveltuvaksi on osoittautunut lävistäjämatriisin käyttö. Lävistäjämat-riisin avulla löydetään yrityksen keskeisimmät tietokohteet, joiden tarkempianalysointi edellyttää yleensä kuitenkin jatkotoimenpiteitä.

Lävistäjämatriisi soveltuu myös toiminnan kuvaamiseen toiminto- tai toimija-näkökulmasta. Prosessikuvausten tekeminen edellyttää huomattavasti syvälli-sempää asiantuntemusta. Mikäli pk-yrityksellä on käytössä omia asiantuntijoitatai ulkopuolista asiantuntija-apua, soveltuvat myös perinteiset tietovirta- ja toi-mintokaaviot yrityksen toiminnan mallintamiseen. Kaaviot on kuitenkin yleensäsyytä pitää kohtuullisen yleisellä tasolla, jotta liialliset yksityiskohdat eivätvaikeuttaisi liiaksi kuvausten ymmärrettävyyttä.

Prosessien mallintamiseen soveltuvat erityisen hyvin kaikki ne tekniikat, joidenavulla pystytään kuvaamaan rinnakkain tai vaihtoehtoisesti eteneviä toiminta-ketjuja. Tällaisia kuvaustapoja ovat mm. perinteiset työnkulkukaaviot, tietovir-takaaviot sekä UML:n toimintakaavio.

3.2 Menetelmien käyttö toiminnanohjausjärjestelmää kehitettäessä

Toiminnanohjausjärjestelmä on poikkeuksetta monimutkainen kokonaisuus,jonka kehittäminen – hankinta, ominaisuuksien parantaminen tai ominaisuuksienlisääminen – edellyttää suunnitelmallisuutta. Toiminnanohjausjärjestelmät pe-

158

rustuvat jollekin käsitykselle, mallille, toiminnasta (kuva 7). Mitä paremmintodellinen toiminta, sitä kuvaava malli ja mallia hyödyntävä ohjausjärjestelmäsaadaan vastaamaan toisiaan, sitä parempaa lopputulosta voidaan odottaa. Me-netelmien käyttö on siis toivottavaa ja todennäköistäkin toiminnanohjausjärjes-telmää kehitettäessä.

Reaalimaailma ”Mallien maailma”

Toiminnan-ohjausjärjestelmä

ToimintaToiminnan

organisointi (esim. prosessit)

Teknologia

Kuva 7. Reaalimaailma, toiminnanohjaus ja organisointi.

Tarkastelemme seuraavassa lyhyesti, miten menetelmiä olisi tarkoituksenmu-kaista käyttää.

Mitä?

Pk-yrityksille toiminnanohjausjärjestelmän kehittäminen on vähäisten resurssienvuoksi vieläkin hankalampaa kuin suurissa yrityksissä. Toisaalta pk-yritystentoiminnan laajuus on paremmin hallittavissa.

Scheer (1998) esittää tunnetussa ARIS-kirjassaan (s. 7–8), että juuri pk-yrityksettarvitsevat laajojen järjestelmien käyttöönotossa viitekehyksiä, menetelmiä jatyökaluja kompensoimaan vähäisistä resursseistaan johtuvaa asiantuntemuksen

159

puutetta. Menetelmien ja työkalujen tavoitteena tulee olla tietojärjestelmäkus-tannusten alentaminen sekä käyttäjätyytyväisyyden lisääminen.

ARIS pyrkii UML:n tavoin hyödyntämään olemassa olevia kuvaustapoja jatekniikoita ja muodostamaan niistä kattavan kokonaisuuden laajojen tietojärjes-telmäarkkitehtuurien ja -ratkaisujen kehittämisen tueksi. Sen keskeisenä lähtö-kohtana on liiketoimintaprosessien mallintaminen. Toiminnanohjausjärjestelmääkehitettäessä on muistettava, että järjestelmän rakentaminen ei hyödytä, mikäliensin ei ymmärretä kokonaisvaltaisesti liiketoimintaa. Liiketoimintaprosessienmallintaminen on paitsi oman liiketoiminnan mallintamista, myös oman toimin-nan ja sidosryhmien toiminnan kytkösten mallintamista.

Prosessien ja tehtävien ohella ARIS kattaa hyvin alussa esittelemämme viiteke-hyksemme (kuva 2) kohdat Roolit ja rakenteet ja Tieto. Kahta muutakin osa-aluetta (Teknologia sekä Tavoitteet ja rajoitteet) on myös jossain määrin tarkas-teltu ARISissa. (ks. esim. Scheer 1998, s. 34–35 ja s. 39.)

Pk-yritys hyötyisi suurella todennäköisyydellä menetelmistä ja työkaluista, jotkahelpottaisivat liiketoimintaprosessien määrittelyä. Menetelmien tulisi sisältäähelposti omaksuttavia kaaviotekniikoita prosessien visuaaliseen kuvaamiseensekä tietovarastoratkaisun laadittavien mallien tallentamiseen ja järjestämiseentarkoituksenmukaisella tavalla myöhempää käyttöä varten.

Missä vaiheessa?

Toiminnanohjausjärjestelmää kehitettäessä menetelmien suurin hyöty painottuuvarmasti kohdeorganisaation toiminnan mallintamiseen sekä järjestelmävaati-musten ja kokonaisarkkitehtuurin määrittelyyn. Näin ollen menetelmien käytönpainopiste on kehittämistyön alkupäässä. On kuitenkin muistettava, että useatuudenaikaiset menetelmät ja työvälineet pyrkivät integroimaan suunnittelunmahdollisimman hyvin toteutukseen. Toisaalta pk-yritys joutuu yleensä hankki-maan ns. valmisohjelmiston ja voi näin ollen vaikuttaa ainoastaan rajallisestiohjelmiston toteutukseen jonkinasteisen parametroinnin avulla. Mikäli paramet-rointia voidaan tukea, on hyöty todennäköisesti huomattava. Edellä mainitunARIS-lähestymistavan yhtenä tavoitteena on juuri parametroinnin tukeminen.

160

Miten?

Menetelmien käytön tulisi aina olla tarkoituksellista. Monimutkaisten järjestel-mien kuten toiminnanohjausjärjestelmien tapauksessa menetelmien käytöltäedellytetään erityistä tavoitteellisuutta ja kokonaisnäkemystä. On parempi käyt-tää hallitusti pientä joukkoa menetelmiä kuin kokeilla erilaisia kuvaustapoja erivaiheissa. On tärkeää, että etukäteen määritellään, miten menetelmien tuottamiakuvauksia aiotaan käyttää hyväksi. Toisin sanoen kuvaukset tehdään käyttöävarten. On myös muistettava, että kuvauksia voidaan todennäköisesti käyttäähyväksi myös myöhemmin, minkä vuoksi on mietittävä, miten kuvaukset jamenetelmän käyttökokemukset (!) dokumentoidaan.

3.3 smeISP-menetelmä

Pk-yrityksillä, ainakin johdolla, on yleensä intuitiivisesti selkeä kuva yrityksentoiminta-ajatuksesta ja tavoitteista. Harvoin strategioita on kuitenkaan kirjoitettupaperille, minkä vuoksi niistä keskusteleminen ja niiden ottaminen kehitystyönlähtökohdaksi on vaikeaa. Vielä useammin pk-yrityksiltä puuttuu kirjallinensuunnitelma tietojärjestelmien käytön ja kehittämisen suhteen. Syitä voi ollamonia, mutta usein kyse lienee siitä, ettei tiedetä mitä tietohallintosuunnitelmanpitäisi sisältää ja miten se tehdään. Asian helpottamiseksi yritys tarvitsisi mene-telmän, joka vaihe vaiheelta ohjaa suunnitelman tekoa.

smeISP on Jyväskylän yliopiston Tietotekniikan tutkimusinstituutissa kehitettyISP-menetelmä, joka pohjautuu pk-yritysten ominaispiirteiden ja vaatimustenperusteelliseen analysointiin (ks. Airaksinen 2000). Menetelmä pyrkii saman-kaltaisiin lopputuloksiin kuin mikä tahansa ISP-menetelmä, eli liiketoimintaapalvelevan tietojenkäsittelysuunnitelman määrittelyyn tietojärjestelmä-arkki-tehtuureineen. Erona aiempiin menetelmiin on suunnitteluprosessin ja käytettä-vien kuvausmenetelmien ”keventäminen”.

smeISP on suhteellisen täsmällisesti vaiheistettu menetelmä. Se sisältää yhdek-sän päävaihetta (taulukko II), jotka jakautuvat yhteensä 35 askeleeseen. Tavoit-teena on kerätä suunnittelussa tarvittava tieto mahdollisimman helposti ja resurs-seja säästäen kuitenkin siten, että yrityksen henkilöstö sitoutuu mahdollisimmanhyvin prosessin läpiviemiseen. Tiedonkeruussa käytetään lomakkeita, haastatte-luja sekä seinätaulutekniikkaa, joka toimii samalla myös suunnittelun ja analy-

161

soinnin apuvälineenä ja dokumentaationa. Analysoinnissa käytetään seinätaulu-tekniikan ohella myös Excel-taulukkolaskentasovellusta ja valmiita jäsennys-malleja (esim. kehittämistarpeiden jäsentämiseksi). Kaikki oleelliset analyysintulokset kirjataan tietojenkäsittelyn kehittämissuunnitelmaan.

Taulukko II. smeISP-menetelmän päävaiheet.

Vaihe Vaiheen nimi

1 Perustietojen kerääminen

2 Aloitus

3 Koulutus

4 Liiketoiminnan mallintaminen

5 Tietojen tarkentaminen

6 Tietojenkäsittelyn nykytilan määrittely

7 Kehittämisideointi

8 Tietojenkäsittelyn kehittämissuunnitelman laatiminen

9 Päätös

smeISP-menetelmän menettelytapoja ja kuvaustekniikoita voidaan hyödyntääpaitsi smeISP:n prosessimallin mukaisesti myös itsenäisesti tarkemmin rajatullaalueella. Erityisen hyödyllinen apuväline minkä tahansa liiketoiminnassa käy-tettävän järjestelmän analysoimiseksi on seinätaulutekniikalla tehtävä lävistäjä-matriisi (kuva 8). Sillä voidaan nopeasti ja yksinkertaisesti kuvata toiminto-jen/toimijoiden välillä kulkevia tietoja, liittää toiminnallisiin kokonaisuuksiin taitietovirtoihin ongelmakohtia tai kehittämistarpeita sekä hahmottaa järjestelmienvälisiä liittymäkohtia.

162

Kuva 8. Esimerkki lävistäjämatriisista – tietokohteiden edeltäjyys- ja seuraus-suhteiden kuvauksesta laskutuksen osalta.

Toinen yleishyödyllinen väline on menetelmän sisältämä taulukkolaskentaso-vellus (Tietolista) lävistäjämatriisin tietovirtojen tarkempaa analysoimista varten(kuva 9). Analysointi paljastaa kuhunkin tietovirtaan liittyvät tietojenkäsittelylli-set ominaisuudet ja vaatimukset. Tietolistassa tarkasteltavat tietokohteet saadaanlävistäjämatriisista. Tietolistassa muokatut tietokohteet voidaan palauttaa lävis-täjämatriisin muotoon automaattisesti (alkuperäistä seinätaulua vastaava sähköi-nen esitysmuoto, jossa mahdolliset muutokset on otettu huomioon). Sähköinenseinätaulu helpottaa aineiston dokumentointia ja myöhempää käsittelyä.

smeISP sisältää tietojärjestelmien kokonaissuunnittelun kannalta kaikki tär-keimmät osat: liiketoiminnan kuvaamisen, keskeisten tietotarpeiden ja (toimin-tojen, prosessien tai yksiköiden) vuorovaikutussuhteiden kuvaamisen sekä ke-hittämiskohteiden kuvaamisen ja priorisoinnin. smeISP:ssä käytetyt kuvaustavatmahdollistavat myös arkkitehtuurisuunnittelun karkealla tasolla lähinnä tietojär-

163

jestelmäarkkitehtuurin osalta: lävistäjämatriisia ja tietolistan luokittelutoimintoakäyttäen voidaan hahmotella tietojärjestelmien rajaamista ja vuorovaikutussuh-teita. Menetelmän jatkokehityksessä tulisi kuitenkin panostaa erityisesti arkki-tehtuurisuunnittelua tukeviin osiin: yrityksen on jatkossa kyettävä paremminsuunnittelemaan omia tietojärjestelmäratkaisujaan osana liiketoiminnallistayhteistyöverkostoa.

TietolistaLähde /tuottaja

Nimike Määrän-pää /käyttäjä

Sovellus,jollatuotetaan

Sovellus,jollakäytetään

Jakelu-media(nykytila)

Jakelu-media(tavoite-tila)

Mihinvarastoi-daan(nykyti-la)?

esim. Excel, Word,Access, PowerPoint,Outlook, InternetExplorer, Eudora, jokumuu?

esim. e-mail,paperi,suullinen,intranet,extranet,internet,faksi, jokumuu?

esim. e-mail,paperi,suullinen,intranet,extranet,internet,faksi, jokumuu?

Mahdolli-nen tietova-rasto

Tuottaja-osa-kokonai-suus

Tieto-kohde

Käyttäjä-osakoko-naisuus

Tuotta-misso-vellus

Käyttä-misso-vellus

Jakelu-media(nykyi-nen)

Jakelu-media(tavoite-tila)

Varasto(nyk.)

toimisto Nimitys-esitys-pohjathenkilöit-täin

tiedekun-nankokous

toimisto Doku-mentti-pohjat(nimikyltit,tiliöinti...)

projekti-työntekijä

toimisto Kopio-tunnus

projekti-työntekijä

Kuva 9. Esimerkki osasta tietolistaa.

smeISP-menetelmää ja sen edeltäjiä on käytetty Tietotekniikan tutkimusinsti-tuutissa menestyksellisesti jo parin vuoden ajan. Käyttökokemukset ovat osoitta-neet, että menetelmä soveltuu varsin hyvin pk-yrityksille. Siitä huolimatta ontähänastisen kokemuksen valossa välttämätöntä, että yrityksellä on koko suun-nitteluprosessin ajan ulkopuolinen konsultti, joka hallitsee hyvin menetelmän

164

piirteet ja käytön. Vaikka smeISP:n prosessi onkin huomattavasti kevyempi kuinuseimpien muiden kokonaissuunnittelumenetelmien, jää ulkopuolisen konsultti-avun tarve yhä huomattavaksi (vähintään 10 henkilötyöpäivää). Avun tarveluonnollisesti pienenee yrityksen oppiessa menetelmän vaiheistuksen ja välinei-den käytön.

3.4 Menetelmien käytön ongelmat ja haasteet

Menetelmien käyttöön liittyy monia ongelmia ja haasteita – muutenhan esimer-kiksi pk-yritykset käyttäisivät menetelmiä huomattavasti nykyistä enemmän.Toisaalta nykyaikainen liiketoiminta on niin nopealiikkeistä, että pienetkinyritykset joutuvat miettimään, miten muutoksia hallitaan. Yksi keino on hallitaniitä mallien ja menetelmien avulla. Tarve siis on olemassa, mutta myös joukkohaasteita. Käymme seuraavassa läpi muutamia tekijöitä, jotka voivat estää taihankaloittaa menetelmien käyttöä.

Menetelmien paljous

Tietojärjestelmien suunnittelumenetelmiä on tarjolla todella runsaasti (Jayaratna1994). Käyttötarkoitukseen sopivan menetelmän valinta on asiantuntijallekintoisinaan vaikea tehtävä. Menetelmien kehittäjät kiinnittävät usein liian vähänhuomiota menetelmän soveltuvuuden ja tavoitteiden tutkimiseen ja kuvaami-seen. Näin ollen voi olla vaikeaa saada käsitystä menetelmän soveltuvuudesta,vaikka käyttäjällä olisi selkeä kuva siitä, mihin hän aikoo menetelmää käyttää.Helpoimmalla yritys todennäköisesti pääsee, jos käyttää alkuvaiheessa asiantunti-ja-apua itselleen sopivien menetelmien ja työvälineiden valinnassa ja opettelussa.

Menetelmien monimutkaisuus

Menetelmät ovat usein monimutkaisia käyttää. Niiden kehittäjät ovat pyrkineetkattavuuteen unohtaen sen tosiasian, että käytännön elämässä tarvitaan vain osaamenetelmän piirteistä. Menetelmiä pitäisi siis usein pystyä sovittamaan käyttö-tilanteeseen. Yleensä se merkitsee tarvetta yksinkertaistaa menetelmää. Ongelmaon siinä, että menetelmän ”yksinkertaistaminen” ei ole erityisen yksinkertainentehtävä muille kuin menetelmien kehittäjille. Yrityskohtaisten menetelmienräätälöinti edellyttää ainakin alussa asiantuntijan apua, mutta mikäli kokemusmenetelmäkehityksestä saadaan talletettua yrityksen sisälle (organisaatiomuis-

165

tiin), voi yritys jatkossa tehdä hyvinkin paljon menetelmien kehitystyötä itseesimerkiksi metaCASE-työvälineen avulla.

Resurssien vähäisyys

Pk-yrityksissä menetelmien käyttöä rajoittaa erityisesti resurssien vähäisyys:menetelmän oppimiseen ei ole käytettävissä riittävästi aikaa tai rahaa eikä yri-tyksessä yleensä ole ”valmista” asiantuntemusta. Toisaalta menetelmän käyttösaattaa jäädä puolitiehen resurssien puutteen vuoksi aiheuttaen siten huonojakäyttökokemuksia ja esteitä myöhemmälle käytölle. Menetelmien käyttöönottoja opetteleminen pitäisikin nähdä investointina, joka hyödyttää yritystä pitkälläaikajänteellä. Menetelmien ja mallintamistyökaluihin liittyvän osaamisen hank-kimista ei siten tulisi tarkastella ainoastaan yhteen projektiin liittyvänä kerta-luonteisena toimenpiteenä.

4. Yhteenveto

Tietojärjestelmien kehittäminen muodostuu yhtäältä yksittäisten tietojärjestelmä-ratkaisujen ja toisaalta tietojärjestelmien kokonaisarkkitehtuurin kehittämisestä.Molempia käyttötarkoituksia varten on kehitetty lukuisia suunnittelumenetelmiä(ISD- ja ISP-menetelmät). Laajoja järjestelmäratkaisuja, kuten toiminnanoh-jausjärjestelmiä, kehitettäessä ovat usein sekä ISP- että ISD-menetelmät tarpeen.

ISD- ja ISP-menetelmät ovat sellaisenaan tyypillisesti liian monimutkaisia jaraskaita pk-yrityksissä sovellettaviksi. Sen vuoksi menetelmien todellinen hyö-tykäyttö edellyttää tilanteeseen sopivien menetelmien muokkaamisesta.

Pk-yrityksille sopivien menetelmien luomisessa apuna voivat olla tietokone-avusteiset menetelmäkehitysympäristöt (metaCASE-ympäristöt) ja erilaisetmenetelmäkokoelmat (kuten UML ja metaCASE-ympäristöjen sisältämät val-miit menetelmät). Menetelmien luominen edellyttää kuitenkin pk-yritysten omi-naispiirteiden ja vaatimusten hyvää tuntemusta ja luonnollisesti myös mahdolli-simman laajaa kokemusta menetelmän kehittämisestä.

Pk-yrityksille soveltuvat menetelmät ovat yleensä rakenteeltaan yksinkertaisia.Vastoin yleistä käsitystä tämä ei kuitenkaan tarkoita sitä, etteikö pk-yrityksillesoveltuvien menetelmien kehittämisessä tulisi pyrkiä formaaleihin menetelmiin

166

ja kuvaustapoihin. Päinvastoin pk-yritykset hyötyvät formaaleista kuvaustavoistaerityisesti siksi, että formaalein menetelmin tuotettujen kuvausten avulla voidaanparhaiten taata ylimääräisen (päällekkäisen) työn karsiminen sekä suunnitelmienmahdollisimman tehokas uudelleenkäyttö.

On ilmeistä, että pk-yrityksiin suunnattu menetelmäkehitys edellyttää tiivistäyhteistyötä tietojärjestelmätieteen asiantuntijoiden ja yritysten välillä. On tär-keää, että menetelmien käyttöön liittyvät ongelmat havaitaan ajoissa, jolloinmenetelmiä voidaan muuttaa vastaamaan paremmin käyttötarkoitusta ja-tarpeita.

Lähteet

Airaksinen, T. 2000. Tietojenkäsittelyn kokonaisvaltainen suunnittelu pk-yrityksissä. Pro gradu. Jyväskylän yliopisto.

Auramäki, E., Hirschheim, R. & Lyytinen, K. 1992. Modelling offices throughdiscource analysis: the SAMPO approach. The Computer Journal, Vol. 35, No 4,1992, s. 342–351.

Brinkkemper, S. 1996. Method engineering: Engineering of information systemsdevelopment methods and tools. Information and Software Technology, 38, s.275–280.

Checkland, P. 1981. Systems thinking, Systems Practice. Chichester: John Wiley& Sons.

Cragg, P. & Zinatelli, N. 1995. The evolution of information systems in smallfirms. Information & Management, 29, s. 1–8.

Evernden, R. 1996. The Information Framework. IBM Systems Journal, Vol. 35No. 1, s. 37–68.

FIPS 1993. Integration definition for function modeling (IDEF0). Federal Infor-mation Processin Standards Publication, 183 (FIPS 183). (http://www.idef.com/).

167

Fowler, M. & Scott, K. 1997. UML Distilled: Applying the Standard ObjectModeling Language, Addison-Wesley.

IBM 1984. Business Systems Planning – Information Systems Planning Guide.Application Manual, IBM Corporation, July 1984.

Igbaria, M., Zinatelli, N., Cragg, P. & Angele, C. 1997. Personal ComputingAcceptance Factors in Small Firms: A Structural Equation Model. MIS Quar-terly, September 1997.

Jayaratna, N. 1994. Understanding and Evaluating Methodologies. McGraw-HillBook Company.

Joutsjärvi, J. 1996. Työnkulun kuvausmallit ja niiden valinta – sovellusalueenateknisen erittelyn tuottaminen Valmet Oy Rautpohjassa. Pro gradu. Jyväskylänyliopisto.

Kelly, S. 1997. Towards a Comprehensive MetaCASE and CAME Environment:Conceptual, Architecturel, Functional and Usability Advances in MetaEdit+.Jyväskylä Studies in Computer Science, Economics and Statistics.

Leppänen, M., Lyytinen, K. & Halttunen, V. 1991. Tietojenkäsittelystrategianmäärittely – Strateginen tietohallintopalveluiden kehittämismenetelmä (SPITS).Tutkimuksia TU-10, Tietojenkäsittelytieteen julkaisuja, Jyväskylän yliopisto.

Martin, J. 1989. Information Engineering, Planning and Analysis. Prentice Hall,EagleWood Cliffs, New Jersey.

OMG 1999. OMG Unified Modeling Language Specification. Version 1.3, June1999. http://www.omg.org/uml/ (Viitattu 29.5.2001)

Palvia, P., Means, D. & Jackson, W. 1994. Determinants of computing in verysmall businesses. Information&Management, 27, s. 161–174.

Päivärinta, T. 2000. Organisaation dokumenttien hallinnan suunnitteleminen:periaatteet, osa-alueet ja lähtökohdat. METODI-raportti n:o 008. Jyväskylänyliopisto, Tietotekniikan tutkimusinstituutti.

168

Rockart, J. 1982. The Changing Role of the Information Systems Executive: Acritical Success Factors Perspective. Sloan Management Review, Vol. 24, No. 1,s. 3–13.

Russo, N., Wynekoop, J. & Walz, D. 1995. The use and adaptation of systemdevelopment methodologies. Proceedings of International Conference of IRMAInternational Resources Management Association, Atlanta, May 21–14.

Saaren-Seppälä, K. 1997. Seinätekniikka prosessien kehittämisessä. Kari Saaren-Seppälä Ky.

Scheer, A.-W. 1998. ARIS – Business Process Frameworks. Berlin: Springer.

Sääksjärvi, M. 1990. Tietojenkäsittelyn strateginen suunnittelu (METO3). Hel-sinki.

Toh, K. T. K., Newman, S. T. & Bell, R. 1998. An information systems archi-tecture for small metal-working companies. Proc Instn Mech Engrs, Vol. 212,Part B.

Tolvanen, J.-P. 1998. Incremental Method Engineering with Modeling Tools,Theoretical Principles and Empirical Evidence. University of Jyväskylä.

Winston, E. & Dologite, D. 1999. Achieving IT Infusion: A Conceptual Modelfor Small Businesses. Information Resources Management Journal, January–March 1999.

Zachman, J. A. 1987. A Framework for Information Systems Architecture. IBMSystems Journal. 26 (3).

169

VII Prosessiajattelun voima ja rajatMarkku I. Nurminen, Olli Järvinen

Turun yliopisto, Matemaattisten tieteiden laitos, Laboris-yksikkö

1. Johdanto

Toiminnanohjausjärjestelmät (Enterprise Resource Planning, ERP) ovat tieto-järjestelmiä, jotka koskettavat tyypillisesti organisaation kaikkia toimintoja.Tästä syystä niiden odotetaankin tuovan merkittäviä etuja toimintojen koordi-nointiin.

− ”Enterprise systems appear to be a dream come true. These commercialsoftware packages promise the seamless integration of all the informationflowing through a company – financial and accounting information, humanresource information, supply chain information, customer information.”(Davenport 1998.)

Toiminnanohjausjärjestelmää käyttöönotettaessa pyritään usein myös itse toi-minnan kehittämiseen. Käsitteellisenä apuvälineenä käytetään tällöin tavallisestiliiketoimintaprosesseihin (Business Process) perustuvaa ajattelutapaa (Hammer& Champy 1993). Tämä onkin luontevaa, sillä useimmat toiminnanohjausjär-jestelmät perustuvatkin juuri tällaiselle prosessiajattelulle sekä rakenteeltaan ettätoiminnoiltaan.

Tämän artikkelin tarkoituksena on tarkastella juuri tätä prosessiajattelua ja tun-nistaa siihen sisältyvät vahvuudet ja ne rajoitukset, mitä sillä on. Lopuksi poh-ditaan, millä tavalla prosessiajattelun viitekehystä voitaisiin laajentaa tai yleistääniin, että nämä rajoitukset jäisivät vähemmän vakaviksi.

Erityisenä sovellusalueena tässä pidetään perusterveydenhuollon tietojärjestel-miä. Tämä johtuu siitä, että HANSKA-hankkeessa Laboris on valinnut tutki-muksensa kohteeksi Pegasos-järjestelmän käytön ja käyttöönoton Turun ter-veystoimessa. Kyseessä on asiakastietojärjestelmä, joka jo yksin sisältämiensäsairaskertomusten ja ajanvarausten kautta toimii hyvin paljon toiminnanohjaus-järjestelmän kaltaisesti. Järjestelmä pitää sisällään tietoa sekä työn kohteesta

170

(asiakkaista ja heidän terveydestään) että työn kulusta (esim. ajanvaraukset).Näin on yleisemminkin laita toiminnanohjausjärjestelmien kohdalla.

2. Prosessin käsite

2.1 Asiakaslähtöisyys ja lisäarvo

Prosessi-käsitteen (tässä siis liiketoimintaprosessin) syntymähetkeä on näinjälkikäteen vaikea kovin tarkasti määrittää, mutta kasvuympäristönä sillä onepäilemättä ollut Porterin arvoketju (Porter 1985) Arvoketjussa (value chain)tarkastellaan organisaation toimintaa kriittisesti asiakkaan kannalta. Kaikkiorganisaation sisällä tapahtuva tekeminen asetetaan arvioinnin kohteeksi kysy-mällä mitä lisäarvoa kustakin toiminnasta on asiakkaalle. Taustalla on tietenkinkysymys siitä, että voitaisiinko jokin toimenpide jättää kokonaan tekemättä.Yksi harkinnan kriteeri voisi olla, voidaanko tarkasteltavan toimenpiteen kus-tannukset lisätä tuotteen tai palvelun hintaan. Jos katsotaan, että hyödykkeenarvo ei kasva niin paljoa, että asiakas on valmis tuon erotuksen maksamaan, onsyytä jättää toimenpide tekemättä.

Terveydenhoidon alalla eivät kaikki liikeyritysten ominaisuudet ole sellaisenaanvoimassa. Asiakaskeskeisyys on kuitenkin yksi piirre, jota myös terveyden-huollon alalla on viime aikoina pyritty korostamaan. Tällöin ei riitä, että arvo-ketjuja tarkastellaan vain terveyspalveluita tuottavien organisaatioiden kannalta.Asiakkailla on omat intressinsä, joita kenties hyvinkin voidaan tarkastella arvo-ketjujen kautta. Asiakasta ei saa esimerkiksi vaatia odottamaan palvelua enem-män kuin on tarpeellista. Tällaiset toisiinsa liittyvät arvoketjut muodostavatarvosysteemejä seuraavaan tapaan:

− ”An organization’s value chain is a part of a value system composed of thevalue chains of a company, its suppliers, its distributors and its customers.By paying attention to the intercompany linkages in the value system a com-pany can add value not only to itself but those in the value system.” (Porterja Millar 1985.)

Terveydenhoidon asiakas saa usein kahdenlaisia palveluita. Ensin tunnistetaanongelma, johon halutaan puuttua (diagnoosi). Sen jälkeen laaditaan hoitosuun-nitelma, jonka avulla ongelma pyritään poistamaan tai ainakin lievittämään sitä.

171

Molemmat osiot tuottavat selvästi lisäarvoa asiakkaalle, eihän tämä itse olisipystynyt tekemään kumpaakaan.

Tuotteiden kustannuslaskentaa ja hinnoittelupäätöksiä ei useinkaan ole (onneksi)jätetty asiakkaan ratkaistavaksi (muuten kuin markkinoiden välityksellä).Useimmat hyödykkeet ovat sekä rakenteeltaan että semantiikaltaan niin moni-mutkaisia että asiakas ei voi kruksata niitä niin kuin pizzan lisätäytteitä tai Dellintietokoneen varustelua valitessaan. Ajattelutavan voima onkin enemmän organi-saation omassa itsetutkiskelussa: miten voisimme tehdä työmme paremmin jatehokkaammin? (Klimas 1997, Hammer ja Champy 1993.)

Menestyksekkäästi toiminnanohjausjärjestelmiä on hyödynnetty suurissa organi-saatioissa, joissa on sovellettu erikoistunutta funktionaalista työnjakoa (Daven-port 1998). Erikoisesti osastojen rajapinnoille on aikojen saatossa kehittynytmonenlaisia rajamuodollisuuksia, joiden läpikäymisessä on menetetty sekä aikaaettä rahaa. Nämä molemmat, (toimitus)aika ja raha, ovatkin olleet prosessiajat-telijoiden erityistarkkailussa. Näiden ajatellaan olevan myös asiakkaalle tärkeitäasioita.

− ”Reengineering eliminates not just waste but nonvalue-adding work as well.Most of checking, reconciling, waiting, monitoring, tracking – the unpro-ductive work that exists because of boundaries within an organization and tocompensate for process fragmentation – is eliminated by reengineering,which means that people will spend more time doing real work. After re-engineering, work becomes more satisfying, since workers achieve a greatersense of completion, closure, and accomplishment from their jobs. They ac-tually perform a whole job – a process or a subprocess – that by definitionproduces a result that somebody cares about.” (Hammer ja Champy 1993.)

Terveydenhoidon alalla tällaisia ongelmallisia rajoja löytyy varmaan monistapalveluita tuottavista yksiköistä. Laajemmassa katsannossa raja perusterveyden-huollon ja erikoissairaanhoidon välillä on erityisen kiinnostava. Asiakkaan siir-tyessä käyttämään palveluita toiseen yksikköön tuon rajan ylitse voi käydä niin,että asiakastiedot eivät siirry hänen mukanaan. Uudessa hoitopaikassa voidaanottaa vastaavia laboratoriokokeita tai röntgenkuvia, jotka juuri on hetkeä aikai-semmin otettu edeltävässä hoitopaikassa. Eikä se siirtymisen sujuminenkaanaina tapahdu ilman asiakkaalle harmittavaisia odotuksia.

172

− ”Palveluketju on ennen kaikkea toimintamalli, jossa asiakkaan ongelmako-konaisuuden vaatimat toimet muodostavat ajasta, paikasta ja toteuttamisor-ganisaatiosta riippumattoman kokonaisuuden. Palveluketju on siis toimin-tatapa, jossa ammattilaisten verkostomaisella yhteistyöllä sekä ammattilai-sen ja asiakkaan vuorovaikutuksella on keskeinen tehtävä ... Palveluketjunajatuksella on yhtymäkohtia teollisuudessa jo pitkään käytettyyn JOT-ajatteluun (just on time) ja uudempiin asiakashallintaa korostaviin toimin-tamalleihin.” (Nouvo-Juvonen et al. 2000.)

Prosessiajattelua on usein sovellettu radikaalisella tavalla, jossa organisaationkaikki prosessit on analysoitu ja perattu. Näin on ajateltu saavutettavan hyvinkinhuomattavia ajan ja kustannusten säästöjä. Odotukset perustuvat erityisesti sii-hen, että voidaan vähentää saman työn monenkertaista tekemistä ja monet tar-peettomat tehtävät voidaan jättää tykkänään tekemättä. Muutamat menestysker-tomukset (Krcmar et al. 1995, Selander ja Cross 1999) kertovat dramaattisistaedistysaskelista. Niiden vastapainona on raportteja, joiden mukaan 3–4 viidestäBPR-projektista on epäonnistunut. Tässä voidaan mieltä rauhoittaa toteamalla,että prosessiajattelua voi toki soveltaa vähemmän radikaalisti ja toiminnanoh-jausjärjestelmän käyttöönotto ei siksi ole etukäteen tuomittu epäonnistumaan.

− ”Our unscientific estimate is that as many as 50 % – 70 % of organizationsthat undertake a reengineering effort do not achieve the dramatic resultsthey intended.” (Hammer ja Champy 1993, s. 200.)

2.2 Prosessin kuvaaminen

Prosessin tehokkuustavoite edellyttää, että on useita mahdollisia tapoja tietynasian tekemiseen. Silloin voidaan sanoa että yksi niistä on toista parempi, jolloinvoidaan etsiä sitä parasta mahdollista. Jos tuo tekeminen on luonteeltaan moni-mutkainen ja -vaiheinen, niin sitä on todennäköisesti tekemässä useita henkilöitäeri rooleissa. Ainakin tässä tapauksessa on helppo oivaltaa, että kyseisen asiantekeminen, siis prosessi, voidaan järjestää hyvinkin monella eri tavalla. Jottatällä tehokkuuden etsimisellä olisi käytännön merkitystä, on prosessin suoritta-minen mielellään toistuva, se tehdään siis moneen kertaan. Lisäksi siinä tehtävänsuoritteen on oltava riittävän hyvin määritelty. Edelleen prosessilla pitää ollaselvästi määritelty alku ja loppu. Samoin tulee olla selvillä mitä prosessiin me-nee sisään ja mitä sieltä tulee ulos; toisin sanoen se, millaisen transformaation

173

toiminnan kohteen on määrä kokea prosessin kuluessa. Tämähän edustaa juurisitä asiakkaan kannalta tarkasteltua lisäarvoa, jota prosessin on tarkoitus saadaaikaan. Usein on vielä tärkeätä tietää, mikä käynnistää prosessin ja miten sepäätetään asianmukaisesti.

Hyvän esimerkin prosessista terveydenhoidon alalta saa esimerkiksi neuvola-käynnistä. Etukäteen on laadittu suunnitelma lapsen käynneistä tietyssä iässä.Jokaiseen käyntiin liittyy luettelo suoritettavista toimenpiteistä: mittauksia,rokotuksia ynnä muita. Tällainen suunnitelma tukee vierailun jäntevää toteutta-mista ja toimii samalla hyvänä muistilistana.

Prosessin kuvauksessa ei kuitenkaan riitä, että kuvataan suoritteen lopputulos.Siinä esitetään usein myös työn kulku; siis se, millaisten vaiheiden kautta toi-minta etenee. Kuvauksesta käy siis ilmi, mitä prosessin missäkin vaiheessa tulisitehdä seuraavaksi. Tehtävät jaksottuvat peräkkäisiksi ketjuiksi, joihin vaihteluatuovat toimintaa mallinnettaessa yleisemminkin käytetyt haarautuminen ja tois-to. Haarautuminen (IF THEN) johtaa tilanteesta riippuen yhteen kahdesta taiuseammasta vaihtoehtoisesta toimintahaarasta; toistossa taas jotakin tehtäväsar-jaa toistetaan niin kauan kuin jokin annettu ehto on voimassa.

Ei ole mitenkään yllättävää, että samat rakenneperiaatteet soveltuvat käytettävik-si myös tietokoneohjelmoinnissa. Voidaanhan niiden avulla kuvata myös tervey-denhoidon toimintoja. Potilasta voidaan esimerkiksi kutsua verenpaineen tar-kistusmittaukseen toistuvasti, esimerkiksi kahdesti viikossa. Mittaustuloksenperusteella päätetään, pitääkö lääkityksen tasoa korjata.

Prosesseja mallinnettaessa tuotetaan tavallisesti ensin nykytilanteen kuvaus.Prosessin reitti kulkee mielellään usean organisaatioyksikön (osaston) kautta.Tämän kuvauksen kriittinen arviointi paljastaa usein, että joitakin tehtäviä teh-dään kahteen tai useampaankin kertaan, tavallisesti eri osastojen toimesta. Näistävoidaan usein poistaa päällekkäistä työtä. Analyysi voi nostaa esiin myös tehtä-viä, joiden tarpeellisuus on erityisesti arvoketjun kannalta epämääräinen. Proses-siajattelu tähtää tällaisten tarpeettomina pidettyjen tehtävien poistamiseen (Se-lander ja Cross 1999). Nykytilan kuvauksessa tiedettiin tarkoin, kenen toimestamitäkin tehtäviä tehtiin, mutta ei tämä työnjako olekaan enää itsestään selvääoiottujen prosessien suhteen. Niillä onkin sen kaltainen leima, että kuka tahansa

174

järkevä ihminen osaisi toimia näin kuvatun uuden prosessin mukaan. On tieten-kin selvää, että uudet prosessit pitää uudelleen jakaa eri toimijoiden tehtäviksi.

Prosessimalli ei ole tarkoitettu ainoastaan kuvaukseksi siitä, millä tavalla asiatovat. Se on myös työntekijöitä velvoittava ohje. Uuden työntekijän koulutuksenon perustuttava määritettyihin prosesseihin ja kokeneemmatkin saavat luvansovittaa työtapansa niiden mukaisiksi. Velvoittavuus ilmenee esimerkiksi siten,että prosessimallia käytetään organisaation laatujärjestelmän osana. Kuka tahan-sa ulkopuolinen tarkkailija (asiakas, laadunvalvoja) voi tämän ajattelun mukai-sesti olla vakuuttunut siitä, että tietyt asiat tuossa organisaatiossa hoidetaantietyllä tavalla, joka on kirjattu vastaavaan projektimalliin. On esimerkiksi tär-keää, että kuolintapauksen toteaminen ja todistuksen kirjoittaminen siitä tapah-tuu selvästi määritetyllä tavalla.

2.3 Esimerkki ARIS

Prosessimallissa kuvataan toimintaa, työn tekemistä organisaatiossa. Työtätarkastellaan tässä ulkoa päin, ei toimijoiden omasta näkökulmasta. Asiakkaannäkökulma on lähtökohtaisesti hallitseva, mutta se säteilee eteenpäin top-down -logiikan (osittavan) mukaisesti organisaation johdon ja eri tasoisten esimiestenkautta itse varsinaiseen työhön (jota tietysti esimiehetkin tekevät!). Työn ku-vaamisessa on käytetty monia erilaisia tekniikoita. Tällaista tekniikkaa sommi-teltaessa on lähes ensimmäiseksi otettava kantaa kysymykseen, mitä asioita työntekemisessä halutaan kuvata. Edellä on jo hajanaisesti tullut esille, minkälaisiaasioita sisällytetään tyypillisesti prosessiajatteluun. Eräänlaisena tarkistuksenateemme pikavierailun yhteen viitekehykseen: kyseessä on ARIS (Architecture ofIntegrated Information Systems) (Scheer 1998).

ARIS-lähestymistavan toiminnallinen perusyksikkö on nimeltään funktio (func-tion), joka vastaa tämän artikkelin (tähänastisessa kielenkäytössä) tehtävä-käsitettä. Funktio on ymmärrettävä prosessikokonaisuuden kannalta mielekkääk-si toimintakokonaisuudeksi. Mielekkyys on tässä ymmärrettävä niin, että tällai-sen tehtävän jakaminen usealle toimijalle tai peräti usealle osastolle on jo intui-tiivisestikin epätarkoituksenmukaista. Tämä ei tarkoita sitä, etteikö olisi joskustarkoituksenmukaista esittää funktiosta myös tarkennettua kuvausta. Esimerkiksitilauksen vastaanottaminen voi jakautua siten, että se sisältää useiden tilausrivienkirjaamisen (toisto), toimitusehtojen määräämisen (haarautuminen) sekä kaikki

175

muut toimenpiteet, jotka hyvin määritellyn tilauksen kirjaaminen vaatii. Injektio-ruiskeen antaminen tai reseptin kirjoittaminen voisivat olla tällaisia funktioitaterveydenhoidon alalla.

Toinen näkökulma prosessimalliin ARIS-arkkitehtuurissa on datanäkökulma.Siihen sisältyvät tapahtumat (events) sekä ehdot (conditions). Tapahtumat toimi-vat prosessin alkamisen käynnistäjinä, ja keskellä prosessia ne edustavat proses-sin tilan kuvausta, joka usein toimii prosessin sisällä kulloinkin seuraavan vai-heen herätteenä. Ehdot ovat itse asiassa tietojoukkoja, joiden mukaan prosessienhaarautumiset ja toistot osataan suorittaa, mutta niihin sisältyy myös se tieto,jotka funktioissa tarpeen mukaan joutuvat tietojenkäsittelyn kohteiksi. Potilas-tiedot ovat varmaankin tällaista tietoa.

Funktion ja datan näkökulmat vastaavat mielenkiintoisella tavalla sitä dualismia,joka tietojärjestelmissä ja niiden kuvauksessa on perinteisesti tehty tietojenkäsittelemisen (function) ja tallettamisen (data) välillä. Alun perin jaottelu lieneeperäisin yleisen systeemiteorian käsitemaailmasta. Nyt on kuitenkin tehtäväselväksi, että kysymys ei ole pelkästään tietojenkäsittelystä ja talletuksesta, vaankysymys on toiminnasta, esimerkiksi teollisuustuotannosta, ja funktiot ja tehtä-vät kohdistuvat tällöin sekä materiaalisiin esineisiin että tietoon. Todettakoon jotässä alustavasti, että tietojenkäsittelytehtävät muodostavat yleisen tehtäväluokanaidon osaluokan.

Kun edellä todettiin, että prosessin kulku kuvataan subjektittomasti, on funktionja datan näkökulmista muodostuva kuva juuri tällainen. Kolmas näkökulma tuomukaan organisaation toimijat. Nämä ovat yksittäisiä henkilöitä, roolinhaltijoita(voi olla useita samassa roolissa) tai sitten organisaatioyksiköitä. Nämä toimijatkytkeytyvät suoraan funktionäkökulmaan ja epäsuorasti datanäkökulmaan. Tällätavalla menetellen saadaan havainnollisesti esitetyksi prosessin kulku eri yksi-köiden lävitse. Näin voidaan vielä varmistua, että näihin rajanylityksiin ei liitytarpeettomia tehtäviä ja ylimääräistä viivettä.

2.4 Prosessiajattelun vahvuudet

Ensimmäiseksi hyödyksi prosessiajattelun soveltamisesta on syytä todeta sevaikutus, minkä työn tekeminen näkyväksi yleensäkin saa aikaan. Mukana olijatjoutuvat ottamaan kantaa siihen, miten eri asiat työyhteisössä tehdään, ja tämä

176

reflektiivinen asenne sinänsä on useimmissa tapauksissa hyödyllinen riippumattasiitä, mitä menetelmää käytetään ja millaisia tuloksia siitä saadaan. Prosessienyhteinen kirjaaminen nostaa myös esiin toimintatapojen erilaisuuden eri toimi-joiden kesken, millä voidaan odottaa olevan vaikutusta toimintatapoja yhtenäis-tävään suuntaan, vaikka tähän tähtääviä prosesseja ei lopulta saataisikaan muo-toilluiksi.

Tärkeämpi ja samalla prosessiajattelulle spesifisempi vahvuus on kuitenkintoiminnan rationaalisessa tarkastelussa. Jos työorganisaatiossa on työntekijöitä,jotka tekevät turhaa työtä, on kaikille osapuolille parempaa, että siitä pyritäänpääsemään eroon. Ei nimittäin ole työntekijällekään kovin motivoivaa puurtaasellaisten askareiden eteen, jotka hän tietää tarpeettomiksi. Yhtä vähän sytyttä-vää on saman tehtävän tekeminen useaan kertaan. Vaikka uhkana olisi työpaik-kojen vähentyminen, niin tässä pätee sama tarpeettomuuden leima kuin äskenkuvatussa turhassa työssä; kiistaa voi syntyä siitä kuka saa tehdä tai joutuu te-kemään tarkasteltavan tehtävän. Joskus tosin tarvitaan kahdenkertainen suoritusesimerkiksi tarkistuksen tai valvonnan takia. Positiivista yleisvaikutelmaa jääkuitenkin nakertamaan epävarmuus siitä, miten voidaan varmuudella tietää,mitkä tehtävät todella ovat tarpeettomia ja mitkä eivät.

Tällainen muutosten miettiminen antaa tuntuvan tuloksen vasta kun ne pannaantoimeen. Prosessimallit antavat tällöin hyvän lähtökohdan organisaation muu-toksille ja vastaaville tietojärjestelmien kehittämisprojekteille. Työntekijät voivatopetella uusia toimintatapoja prosessimalleja simuloiden. Tässä kohdassa jäämieltä askarruttamaan se, riittävätkö prosessimallissa esitetyt asiat työn tehok-kaaseen ja laadukkaaseen suorittamiseen vai pitääkö niitä täydentää jollakintavalla. Näitä epäilyksiä tarkastellaan seuraavassa jaksossa.

3. Prosessien ongelmia

3.1 Anoreksia

Tämä huolen aihe ei kosketa kaikkia prosessiajattelun soveltamisen muotoja,mutta se on hyvä pitää mielessä jo senkin takia, että muutoin tarjoutuu hyvätilaisuus tehdä organisaation ja sen tulevaisuuden kannalta kohtalokkaita virhei-tä. Liikalaihdutuksella tarkoitetaan tässä sellaista prosessien määrittelyä ja to-teutusta, jossa kaikki löysät on karsittu pois. Löysät ovat sellaisia asioita, joiden

177

ei nähdä tuottavan prosessissa lisäarvoa. Siinä menee helposti lapsi pesuvedenmukana. Terveydenhoidossa keskimääräinen kuormitus tuntuu nykyisin useinolevan kohtuuttoman korkea.

Suomessa 1990-luvulla koettu lamakausi sai aikaan yrityskulttuurissa oikeananoreksiabuumin. Henkilöstöä vähennettiin ja samalla jäljelle jääneiden työnkuormittavuus kiristyneen työtahdin ja ylitöiden muodossa lisääntyi niin, ettätyössä uupumisesta tuli varsin laajalle levinnyt ammattitauti, vaikka oikeampaaolisi monesti ollut puuttua työolosuhteisiin kuin auttaa uupunutta jaksamaansyntyneissä olosuhteissa. Laihduttaminen ei koskenut pelkästään yksityisiäyrityksiä, vaan myös monet julkisen sektorin organisaatiot joutuivat vastaavan,elleivät pahemmankin, kuurin kohteeksi. Terveydenhoidon ala tunnetaan laajaltitällaiseksi toimialaksi.

Ei ole kohtuullista mitenkään väheksyä työssä uupumista ja sen traagista merki-tystä yksilölle kulttuurissa, jossa sentään vielä työn tekeminen on korkeallearvostettu asia. Laihduttaminen on kuitenkin vaarallista myös itse työorganisaa-tiolle, koska lukitsemalla itsensä määriteltyihin prosesseihin organisaatiosta voitulla tehokas tekemään asioita tuolla määrätyllä tavalla, mutta kyvytön muutta-maan näitä toimintatapoja. Pahimmillaan tämä voi johtaa siihen, että työntekijätluopuvat terveestä pyrkimyksestä kehittää omaa ammattitaitoaan, koska sillä eiole enää merkitystä: riittää kun seurataan prosessimallien tarjoamia ohjeita. Näinsitten maailma ympärillä muuttuu ja organisaatio on kyvytön reagoimaan näihinmuutoksiin omaa toimintaansa muuttamalla. Muutoskyvyn lisäksi heikkeneesamalla myös kasvukyky. Yhtenä tärkeänä syynä tähän vaaralliseen kehitykseenon, että hyvään työn tekemiseen liittyy mielellään oman toiminnan reflektio,arviointi ja kehittämisen pyrkimys. Jos näitä varten ei ole lainkaan aikaa (löy-siä!) eikä niiden tekemiseen muutoinkaan rohkaista, jämähtää toiminta helpostisille aikanaan määritellyn prosessimallin mukaiseksi.

3.2 Epäprosessit

Anoreksian vaarallisuus on hyvä tiedostaa, jotta sitä osattaisiin varoa. Sen vaaraei kuitenkaan kohdistunut itse prosessiajatteluun, vaan sen tiettyyn, yltiöpäiseensoveltamisen tapaan. Seuraavaksi tarkastelemme toimintoja, jotka perusluon-teensa takia soveltuvat huonosti prosessien avulla esitettäviksi. Ensimmäisessätavoitteena ei ole tehtävien tehokas suorittaminen, vaan siitä huolehtiminen, että

178

mitään ei tapahdu. Tätä kutsumme antiprosessiksi. Toinen toiminnan tyyppi onsellainen, jossa tavoitteena ei ole sen tehokas saattaminen päätökseen, vaanpikemminkin päättymisen estäminen. Näitä kutsumme hivenen leikillisesti iäi-syysprosesseiksi. Koska tehokas toteutus ja ripeä loppuunsaattaminen ovat pro-sessiajattelun kulmakiviä, on aihetta maistella miten sana epäprosessi soveltuukattokäsitteeksi kuvaamaan näitä molempia epätyypillisyyksiä.

Antiprosessi nousi aikanaan esille, kun Laboriksen tutkijat eräässä projektissapyrkivät muotoilemaan varaston toiminnan johtoajatusta. Saatoimme helpostitunnistaa kaksi perusprosessia, tavaran vastaanoton ja tavaran luovutuksen.Mutta varastonpidon luonteesta nämä prosessit antavat varsin pinnallisen kuvan.Kysymyshän on siitä, että tavaran omistaja on antanut varaston pitäjälle tavaransäilytettäväksi tietyn sopimuksen mukaan. Tärkeä osa tällaisessa sopimuksessaon tilinpitovelvollisuus: tavara pitää vaadittaessa luovuttaa sen omistajalle.Tilinpitovelvollisuuden takaa löytyy kokonainen hyvä varastonpitotapa, jokasisältää esimerkiksi FIFO (First In First Out) periaatteen. Tärkeätä on edelleen,että tavara luovutetaan mahdollisimman kuranttina. Tässä on tämän antiproses-sin ydin: varastonpitäjän on huolehdittava, että tavaralle ei tapahdu mitään.Tavara ei saa rikkoutua eikä pilaantua. Sitä ei saa varastaa eivätkä rotat saa sitäjyrsiä. Prosessimallissa lueteltujen transformaatioiden tehokkaan suorittamisensijasta on transformaatiot pidettävä loitolla.

Tällaisia ja vastaavia antiprosesseja on yllättävän monessa toiminnassa. Esimer-kiksi useat arkistointitehtävät ovat juuri tällaisia. Potilastietoja tulee säilyttäähuolellisesti eivätkä ne saa muuttua eivätkä kadota. Niin ikään monet ehkäisevättoimet ovat tämän luonteisia. Tietojärjestelmät on suojattava asiattomilta tunkei-lijoilta. Kuntalaiset olisi hyvä saada pysymään sairaaloiden ulkopuolella, mie-lellään vielä työkykyisinä.

Tietenkin tällaisten antiprosessien toimittamiseksi voidaan määritellä prosesseja.Esimerkiksi varastossa voidaan järjestää inventaari kahdesti viikossa tai terveys-viranomaiset voivat sommitella erilaisia valistus- ja seulontaprosesseja. Nämäeivät kuitenkaan tavoita tarkasteltavan toiminnan ydintä. Tavaran pitäminenvarastossa tai kuntalaisen väestövastuinen terveydentilasta huolehtiminen ovatikään kuin eheitä pyykkinaruja, joihin sitten toki voidaan ripustaa monenlaisiaprosesseja. Prosessit eivät kuitenkaan pysy edes käsitteellisesti ilmassa ilmantällaista pyykkinarua.

179

Iäisyysprosessejakin Laboriksen tutkijat ovat löytäneet useissa kenttätyökohteis-sa. Esimerkiksi asiakassuhteen hallinnassa (Customer Relationship Manage-ment, CRM) tavoitteena on pitää asiakassuhdetta voimassa pitkäaikaisesti javälttää sen katkeaminen. Yksi tapa toimia on tehdä siirtyminen kilpailijan asiak-kaaksi vähemmän houkuttelevaksi kuin vanhan suhteen jatkaminen. Riippuvuu-den aikaansaaminen ja sitominen ovat yleisiä keinoja, mutta monet kokevatmyönteisempinä tavat, joilla asiakas saa suoranaista lisäarvoa asiakkuuden jat-kamisesta. Vakuutusyhtiö voi esimerkiksi tarjota asiakkaansa käyttöön riskienarvioinnin ja torjunnan asiantuntemustaan niin, että asiakas voi pienentää riske-jään tekemällä tuotantolaitoksissaan yhtiön suosittelemia korjauksia. Palkkioksiyhtiö tällöin myöntää asiakkaalle perustellusti alennettuja vakuutusmaksuja.Tämänkaltaisesta ajattelusta lienee kysymys kunnallisen terveydenhoidon asia-kassuhteissakin, vaikka kyseessä ei olekaan puhtaasti palvelun tarjoajien välinenkilpailu asiakkaista. Ajateltakoon vaikka äitiys- tai lastenneuvolatoimintaa,joissa seurannan avulla pyritään riittävän aikaisin havaitsemaan riskitekijät japuuttumaan niihin, ennen kuin ne kasvavat liian suuriksi. Laajemmassa mitta-kaavassa tällainen toimintalogiikka tulee toteutuneeksi väestövastuupohjaisessaterveydenhoidossa.

Prosessiajattelun orientoituneisuus prosessin lopputuloksen tehokkaaseen saa-vuttamiseen soveltuu sellaisenaan kovin huonosti toimintaan, jonka päättymistäpyritään välttämään ja jopa estämään. Ääriesimerkki terveydenhuollon alaltalöytyy kansalaisen elinkaaresta, jonka ylläpitäminen – vieläpä mahdollisimmanlaadukkaana – on koko terveydenhuollon kantava ajatus. Prosessimallin ideaalitehtävän nopeasta ja kustannustehokkaasta loppuunsaattamisesta on tähän koh-teeseen sovellettuna ankarasti sivistysvaltion ja hyvinvointiyhteiskunnan peri-aatteiden vastaista. Jälleen voidaan todeta, että jokainen neuvolakäynti itsessäänon sellainen, että prosessiajattelusta on siinä selvää hyötyä, koska silloinhanasiakas joutuu esimerkiksi odottamaan mahdollisimman vähän aikaa. Prosessitsijoittuvat kuitenkin osaksi jotakin laajempaa tai syvempää kokonaisuutta ilmanettä ne kykenevät tuon kokonaisuuden mieltä tavoittamaan.

Tällaisen laajemman toimintakehikon etsiminen ei ole mikään uusi asia, vaan seon sisältynyt moniin jo vakiintuneisiin lähestymistapoihin. Hyvän esimerkintästä saa vaikkapa lähteestä Checkland ja Scholes (1990, Luku 4: An applicationof soft systems methodology in the national health service).

180

− ”They approved its focus on planning and organizing (but not itself actuallydelivering) health care; and they liked its emphasis on continuous process.In the system ... planning is not an event (producing ‘the plan’) but is a con-tinuous process in which health is a norm rather than an attainable goal.What is seen as an acceptable norm will change as medical technology, re-source levels, lifestyles and public attitudes change; but, like ol’ man river,the system just keeps rolling along, seeking an ever new state of health for adefined population in line with current views and values. The model also in-dicates that helping to define and organize health programmes will entailmanaging a complex web of relationships.” (s. 103–104.)

Tällainen yleinen toiminnan tavoite on terveyden hoidossa vielä tärkeämpi kuinsairauden hoidossa. Pyrkimys sairauden parantamiseen muistuttaa tavoitteisuu-tensa vuoksi prosessia, mutta paraneminen ei suinkaan aina tapahdu laaditun”prosessimallin” mukaisesti, vaan hoitosuunnitelmaa joudutaan korjaamaantilanteen mukaan. Tällaisen tilannekohtaisen korjaamisen muotoilu prosessimal-liksi ei taas ole yksinkertaista, jos lainkaan mahdollista.

3.3 Tekijän panos

Yksi prosessiajattelun kritiikin kohteista on sen ulkopuolisuus. Tekemistä ei siiskatsota toimijan näkökulmasta, vaikka kuitenkin esimerkiksi edellytetään, ettätoimijalla on kyky ja ammattitaito selviytyä hänelle annetuista tehtävistä. Tee-moiksi tässä nousevat ainakin kulloisenkin tilanteen huomioon ottaminen, pro-sessien valinta ja muuntamistarpeet, priorisointi sekä itse muotoillut ja käynnis-tetyt toiminnot.

Mistä toimija kulloinkin tietää, minkä prosessin mukaan mitäkin tapausta pitääkäsitellä? Entä sopiiko tuo malli tähän tapaukseen sellaisenaan, vai pitäisikö sitävähän muuntaa? Tai onko tällaisessa tilanteessa edes lupa tuollaisiin muunnok-siin? Ja jos prosesseja saa ruveta omin päin peukaloimaan, mitä virkaa niilläsitten enää on – velvoittaviahan niiden piti olla? Tämänkaltaisiin kysymyksiinvastaaminen ei ole helppoa, ellei tarkastelun suuntaa käännetä niin, että toimin-taa katsotaankin tekijän näkökulmasta. Silloin käy ilmeiseksi, että ei jokaistatilannetta varten voida määrittää omaa prosessia, vaan prosessit pitää tehdätarkoituksellisesti alimääräytyneiksi niin, että toimija täydentää puuttuvat osat

181

kulloinkin tilanteeseen soveltuvalla tavalla. Prosessimalli voi toki sisältää ”eh-dotuksia” erilaisia tilanteita varten, jos niitä on mahdollista ennakoida.

− ”If each patient’s illness is a project then the types of damaged products arediverse and outcomes are often unpredictable and difficult to evaluate.”(Strauss 1988.)

Prosessin kuvaus voidaan tällöin ymmärtää eräänlaiseksi minimivaatimukseksi,jota seuraamalla ei saada mitään lopputulosta aikaan mutta jossa esiintyvientoimenpiteiden pitää sisältyä kaikkiin siitä syntyneisiin variaatioihin ja poik-keustilanteisiin. Kaikkien näiden kattava kuvaaminen on nähty mahdottomaksisekä käytännöllisistä (valtava määrä) että käsitteellisistä syistä:

− ”Articulation work is work that gets things back ”on track” in the face of theunexpected, and modifies action to accomodate unanticipated contingencies.The important thing about articulation work is that it is invisible to ra-tionalized models of work.” (Star 1991.)

Terveydenhoidossa on paljon sellaisia korkeaan ammattitaitoon ja kokemukseenperustuvia tehtäviä, joiden pukeminen prosessin muotoon on keinotekoista javajavaista. Ne vaativat täydentävää artikulaatiotyötä. Ajateltakoon vaikka diag-noosin tekemistä. Asiakas ei luonnollisista syistä usein voikaan tietää, mikähäntä vaivaa. Vaivan tunnistaminen on joskus hyvinkin monimutkainen salapo-liisitehtävä, jossa esimerkiksi vaihtoehtoja pois sulkemalla lopulta päästäänriittävän varmalta tuntuvaan tulokseen. Joskus tähän tarvitaan tutkimussarja.Tilanteiden vaihtelevuus ei kuitenkaan tee prosessityyppistä mallintamista koko-naan tarpeettomaksi:

− ”They speak of a 'veritable hurricane' of problems for the head nurse thatmake it important to build a library of standard operating procedures or ar-ticulation strategies, that help with the ordering of local chaos.” (Strauss etal. 1985.)

− ”We must note that hospital personnel can hardly organize their patient careaccording to any model of industrial production (although recent govern-mental regulations are attempting to force hospitals in that direction).”(Strauss 1988.)

182

Prosessin käsite vastaa hyvin sitä toiminnan tapaa, jota on kutsuttu suunnitelluk-si (planned). Sen rinnalle on nostettu tilannekohtainen toiminta (situated action,Suchman 1987), jossa toimija tilannetajunsa, tulkintansa, kokemuksensa jatiedostamiensa tavoitteiden perusteella toimii tavoitteisesti ja pätevästi ilman ettätästä toimintaketjusta on ainakaan etukäteen laadittu selkeää suunnitelmaa.Tekeminen on tällöin paikan päällä artikuloitua. Edellisessä kohdassa annettiinjo vihje siitä, miten suunnitelman, tässä prosessin, alimääräytyneisyys voi tarjotatavan käyttää hyväksi hyödyllisiä aineksia kummastakin toiminnan muodosta.

− ”Projects can be located along routine-to-nonroutine and simple-to-complex” (Strauss 1988).

Prosessiajatuksen lähtöviivana on asiakkaan tahdonilmaus; maaliviiva on samas-sa paikassa. Töitä tehdään siten ulkopuolelta tulevan tilauksen herätteestä. Kui-tenkin kaikissa työpaikoissa on tehtäviä, joita on tarpeen toimittaa jotta tuovarsinainen työ sujuisi mahdollisimman hyvin. On huolehdittava osaamisesta jasen ylläpitämisestä (yksilö- ja ryhmätasolla), työvälineistä (teroitus, tankkaus,voitelu), työtiloista (siivous, lukitus, lämmitys, valaistus, jne.). Osa näistä tehtä-vistä voidaan ennakoida, ja niitä varten voidaan laatia suunnitelmat. Kuitenkinjokaisen toimijan vastuualueelle jää aina kohdattavaksi odottamattomia tilantei-ta, joissa toimijan on itse osattava toimia kokonaan ilman prosessien tukea.Toimijalla on sen takia oltava tarpeeksi hyvä käsitys omasta vastuualueestaan jasen toiminta-ajatuksesta. Täältä lähtevät lopulta ne kriteerit, joiden perusteellahän voi muotoilla ja toteuttaa omia, sisäisiä prosesseja ja muunnella olemassaolevia. Sieltä syntyy myös priorisoinnin perusta. Kun tehtävänä on useita tehtä-viä (ja osa niistä on jo aloitettu, mutta kesken), niin toimija joutuu valitsemaan,mitkä ovat tärkeimpiä suorittaa ennen toisia.

Terveydenhoidon alalla esiintyy usein tilanteita, joissa muutos potilaan tilassapitää havaita ja tunnistaa. Tällöin on tärkeätä, että nopeasti ja pätevästi ryhdy-tään tarvittaviin toimiin, vaikka tilannetta varten ei olisikaan käytettävissä pro-sessikuvausta. Onpa monissa terveyspalveluja tuottavassa yksikössä erityinentarkkailuosasto, jossa esimerkiksi toimenpiteestä toipuvien potilaiden tilaa jat-kuvasti seurataan.

183

3.4 Teollisuuden ja palvelun prosessit

Prosessiajattelun kukoistus on epäilemättä suurimmillaan teollisuustuotantoaharjoittavissa yrityksissä. Siellähän tuotteistamista ja standardisointia sisältävätmuutokset on usein kohtuullisen suoraviivaisesti toteutettavissa. Palvelujenalalla ei vastaavia etuja aina ole olemassa. Katsomme seuraavassa eräitä ongel-mia, jotka näiden kahden toimintatavan välillä tyypillisesti on.

Tuotteistaminen

Teollisuustavara on usein standardisoitavissa sekä tuotteistettavissa. Lisäksi sitävoidaan luonnehtia pääosin aineelliseksi ja siten kosketeltavissa olevaksi. Tuo-tantotapaan liittyvä mahdollisuus mekanisointiin ja automatisointiin pystyyhyödyntämään standardisointiin liittyvän edun myös tilanteessa, jossa teolli-suuskin on siirtynyt entistä räätälöidympään tuotantotapaan. Tavaraan sidottuydinarvo tuotetaan tehtaassa. Lisäksi tuotanto ja jakelu on nähtävä kulutuksestaerillään oleviksi toiminnoiksi.

Palvelu puolestaan on aina henkilökohtainen ja pääosin aineeton. Palvelulle ontyypillistä se, että sitä ei pystytä tuottamaan varastoon. Yleensä palvelu on ai-nutlaatuinen teko tai prosessi, joka on vaikea vakioida. Luonteenomaista on ettäpalvelun tuotanto, jakelu ja kulutus tapahtuvat samanaikaisesti. Tietoverkot ovatjonkin verran tätä vaatimusta lieventäneet, mutta palvelun perusasetelmanavoidaan pitää tätä samanaikaisuutta ja samapaikkaisuutta (tukanleikkuu, injek-tioruiske?). Materiaalisten tuotteiden valmistaminen varastoon ja jakelu tekevätniiden saatavuuden järjestämisen palvelujen saatavuutta yksinkertaisemmaksi.

Tuotantoprosessin näkökulmasta on huomattava, että asiakkaat eivät tavallisestiosallistu tavaran valmistusprosessiin, mutta palvelun osalta on luonnollista, ettäasiakkaat osallistuvat prosessiin osana tuotantoa. Tästä muodostuu eräs palvelu-prosessin oleellinen piirre:

− ”Kaikissa palvelutapahtumissa yrityksen kontrollin ulkopuolelle jää keskei-nen ja arvaamaton tekijä: asiakas itse” (Mannermaa 1993, s. 206).

Koska asiakas on osana prosessia, niin myös asiakkaan suhde tuotantoprosessinmuodostuu ja rakentuu huomattavasti henkilökohtaisemmalla tasolla:

184

− ”Palveluyritykset ovat yleensä ratkaisevalla tavalla riippuvaisia osaavastahenkilöstöstään. Asiakkaan side palveluja tuottavaan henkilöön on merkittä-vämpi kuin side palveluja tuottavaan yritykseen. Jos pidetty lääkäri vaihtaalääkärikeskusta, asiakkaat seuraavat mukana.” (Mannermaa 1993, s. 206.)

Asiakkaan suhde palvelujen tuottajaan voi siis olla joko henkilö- tai organisaa-tiosidonnainen. Lisäksi on huomattava, että palvelututkijoiden mukaan asiak-kaan kokemalla laadulla on kaksi ulottuvuutta: tekninen laatu eli mitä asiakassaa ja toiminnallinen laatu eli miten hän sen saa. (Mannermaa 1993, s. 209.)

Terveydenhuollon alalla palvelujen laatuun vaikuttavat useat eri asiat. Palvelujentarjonnassa resurssien korkea käyttöaste johtaa helposti asiakkaiden pidentynei-siin jonotusaikoihin. Ratkaisua on etsittävä toiminnan suunnitelmallisuutta li-säämällä, jossa mahdollisimman moni kysynnän ja tarjonnan kohtaaminen val-mistellaan etukäteen, ei vain ajanvarausten tasolla vaan toimenpiteiden enna-kointina ja valmisteluna.

Symmetria ja asiakaskeskeisyys

Edellä esitetyn perusteella tuntuu selvältä, että palvelujen tarjonnassa vallitseeselvästi suurempi symmetria tuottajan ja asiakkaan välillä, onhan asiakkaantultava tukanleikkuuseen henkilökohtaisesti. Tämä tarjoaa asiakkaalle tilaisuu-den lausua (ja saada toteutetuksi) toivomuksia räätälöidystä palvelutuotteensisällöstä. Kaikki tämä vastaa hyvin niitä trendejä kohti asiakaskeskeisyyttä(Vuokko, 1997), joita terveydenhoidossa nykyään on.

Asiakaskeskeisyydellä ei tarkoiteta ainoastaan sitä, että yksittäiset hoitotapahtu-mat sujuisivat vähällä odottamisella ja kivulla. Monenlaiset kehittämispyrki-mykset tähtäävät nimittäin siihen, että asiakkaan omahoidon osuus tulee lisään-tymään ja että myös ehkäisevän hoidon merkitys kasvaa. Kuntalaiset yritetäänsaada itse aktiivisesti myötävaikuttamaan siihen, että he pysyisivät poissa sai-raaloista ja jopa terveyskeskuksista. Hoitotoimenpiteet asettuvat silloin konteks-tiinsa tavalla, jossa ei riitä, että tutkitaan terveyskeskuksen tai sairaalan proses-seja, vaan yhtä tärkeätä on seurata asiakkaan prosesseja. Kysynnän ja tarjonnankohtaamisessa hoitotoimenpiteen aikana on kysymys kahden osapuolen välisestätransaktiosta, ja tässä tapauksessa transaktion seuraamuksen tärkein piirre ei

185

jääkään hoito-organisaation sisälle vaan lähtee ulos asiakkaan (toivottavasti)parantuneena terveydentilana.

Ihmisen elämä ei kuitenkaan ole prosessi. Terveyden ja muun hyvinvoinninkannalta tärkeitä tapahtumia sijoittuu päivittäiseen toimintaan jatkuvasti. Ham-paiden harjaus ja liikuntaharrastus ovat tärkeitä, jos kohta niiden tärkeys tuleeparhaiten esille niiden puuttuessa tai keskeytyessä. Jälleen tarvitaan jotakinlaajempaa tai yleisempää käsitettä kuin prosessi. Seuraavassa pyritään tätä hah-mottamaan.

4. Prosessiajattelun rajojen ylittäminen

Edellä on kirjattu joitakin prosessiajattelun vahvuuksia ja heikkouksia. Niidenmerkitys voidaan tiivistää seuraavasti. Prosessiajattelu sisältää monia hyödyllisiämahdollisuuksia toimintojen jäsentämiseksi ja järkeistämiseksi. Vaara tästäajattelusta muodostuu silloin, jos kuvitellaan, että työn tekeminen ja organisaa-tion toiminta voidaan ymmärtää ja kuvata jäännöksettömästi prosessien avulla,sillä silloin syntyy liian kapea ja köyhä käsitys työstä ja sen tekemisestä.

Tämä vaara tulee selvästi näkyviin, kun tarkastellaan niin sanottua italialaistalakkoa prosessiajattelun karikatyyrinä. Siinähän työntekijät noudattavat annet-tuja ohjeita (tässä nämä ohjeet ajatellaan puetuiksi prosessimallien muotoon) vii-meistä piirtoa myöten. Ohjeiden kattavuuden puute aiheuttaa toimintakatkoksia jakuormittaa esimiehiä, joilta pitää tuon tuostakin käydä neuvoa kysymässä. Omanaloitteisuuden puuttuminen johtaa työn ja sen tuloksen laadun romahdukseen.

Prosessit tuleekin mielestämme nähdä käyttökelpoisena sääntöjoukkona, jokavoi olla organisaatiolle arvokas resurssi, kun ne toimivat esimerkiksi minimi-vaatimuksina käytäntöjä yhtenäistäen. Niillä voi siten olla varsin hyödyllinenkinvaikutus, kun vasta-alkajille opetetaan työn tekemistä. Prosessien yläpuolelle taipikemminkin ympärille on kuitenkin tarpeen hahmottaa käsitteistö, joka on sitäolennaisesti rikkaampi. Sellaista on ja edellä alettu muotoilemaan vertaamallasitä esimerkiksi pyykkinaruun, johon prosessit voidaan ripustaa. Tarkastelemmenyt tällaista tarvittavaa viitekehystä ja kirjaamme joitakin siihen kohdistettaviavaatimuksia ja toivomuksia.

186

Kun lähtökohtana on organisaatiossa tapahtuvan toiminnan käsitteistäminen, onluonnollista etsiä analyysiyksikköä, jonka avulla tuo toiminta voitaisiin jossakinmielessä rakenteistaa. Silloin voitaisiin parhaassa tapauksessa käsitellä sekäpieniä että suuria tekemisiä.

Analyysiyksikön tulisi olla myös sellainen, että sen avulla voitaisiin esittää myösorganisaation ulkopuolista toimintaa. Erityisesti asiakkaan tilanteen näkeminenei ole tärkeätä vain terveydenhoidossa, vaan useimmiten myös liikeyritystentoiminnassa.

Rakenteellisesti olisi eleganttia, jos prosessi voitaisiin nähdä tämän analyysiyk-sikön erikoistapauksena ainakin sisältönsä ja rakenteensa puolesta. Prosessiinjouduttaisiin tietenkin lisäämään joitakin sitä rikastavia piirteitä.

Edellistä vaatimusta tukee käsitys, jonka mukaan nyt etsittävällä toiminnananalyysiyksiköllä on alku ja loppu. Olihan edellä käytetty iäisyysprosessin käsitetarkoitettu leikillisesti käytettäväksi tilanteessa, jossa koettiin tarpeelliseksiirtautua prosessiajattelua usein kuormittavasta pikaisen loppuun saattamisenpaineesta. Onhan toki ihmisen elinkaarella alkunsa ja loppunsa, vaikka senpäättymiseen ei tavallisesti pidetäkään eritystä kiirettä. Tämä antaakin aihettakutsua tarvittavaa analyysiyksikköä elinkaaren nimellä.

Elinkaarella on omistaja. Se voi liittyä organisaatiossa tehtävän toiminnan jo-honkin alueeseen, joka on jonkun työroolin haltijan vastuulla. Sille löytyy myösmielenkiintoinen analogia oliomallintamisesta. Oliostahan voidaan sanoa, että seon tietyssä tilassa, joka voi muuttua siihen kohdistuvien tapahtumien seurauksena.

Tapahtuma voi nyt olla elinkaaren haltijan itsensä aikaansaama. Usein kyseessäon kuitenkin transaktio, jossa on kaksi tai useampia osapuolia. Näin on erityi-sesti palvelujen kohdalla: tuottaja ja kuluttaja kohtaavat. Kun kuntalainen ter-veyskeskuksessa käy lääkärin vastaanotolla, suoritetaan transaktio, jonka tulok-sena kummankin osapuolen tila(nne) on muuttunut. Useasti transaktion seurauk-sena syntyy uuden olion elinkaari. Vastaanotolla käynti voi tehdyn diagnoosinperusteella johtaa hoitosuunnitelman tekoon, jonka elinkaari päättyy esimerkiksipotilaan paranemiseen.

187

Nähdään, että transaktioperustainen elinkaarimalli tarjoaa jo näin keskeneräisenäideanakin olennaisesti rikkaamman välineen toiminnan mallintamiseen kuinprosessit. Sen avulla voidaan myös helposti selviytyä epäprosessien kuvaami-sesta. Elinkaarella on alkunsa ja loppunsa, mutta siihen ei ole ladattu päättymistävälttämättömänä ja tehokkaasti saavutettavana tavoitteena. Siten kuntalaisenkoko elämä on elinkaari kirjaimellisesti, mutta niin on myös sellainen hoitojak-so, johon sisältyy vain lyhyitä episodeja hoitohenkilöstöä kohdattaessa, vaikkaparanemista tapahtuu koko ajan. Näin meillä on sellainen käsitemalli, jossaasiakkaan intressit tulevat otetuksi huomioon tasaveroisina palvelun tuottajanintressien kanssa. Tuottamisen puolella ainakin yksittäiset toimenpiteet sopivatuseasti hyvin prosessien avulla kuvattaviksi.

Elinkaari on – samoin kuin toiminnan käsitekin – rakenteinen, siten että elinkaa-ren avulla voidaan käsitellä sekä laajoja että suppeita toiminnan yksiköitä. Tällätavalla siitä tulee hyvä työväline kuvattaessa erilaisia yhteistyöasetelmia esimer-kiksi perusterveydenhoidon ja erikoissairaanhoidon välillä tai toisaalta lääkärinja sairaanhoitajan välillä. Kokonaisvaltaisuus ja vastuu omasta toiminnan alu-eesta saadaan täysmääräisenä mukaan.

Jatkotyöskentelyssä elinkaarimalli voidaan ankkuroida moniinkin erilaisiinteoreettisiin viitekehyksiin. Tällaisia ovat esimerkiksi toiminnan teoria ja struk-turaatioteoria. Tietojärjestelmien alueella CSCW-tutkimussuuntaus samoin kuinworkflow-tutkimuskin on tuottanut paljon käyttökelpoista tietoa.

Lähdeluettelo

Checkland, P. & Scholes, J. 1990. Soft Systems Methodology in Action.England: John Wiley & Sons Ltd.

Davenport, T. 1998. Putting the Enterprise into the Enterprise System. HarwardBusiness Review, July–August.

Hammer, M. & Champy, J. 1993. Reengineering the Corporation, A Manifestofor Business Revolution. New York: Harper Collins Publisher.

Klimas, J. 1997. Reengineering in the Real World, Management Accounting,May.

188

Krcmar, H., Björn-Andersen, N. & O’Callaghan, R. 1995. EDI in Europe, Howit Works in Practise. England: John Wiley & Sons Ltd.

Mannermaa, K. 1993. Moniulotteinen markkinointi. Jyväskylä: Weilin + Göös.

Nouko-Juvonen, S., Ruotsalainen, P. & Kiikkala, I. 2000. Hyvinvaltion palvelu-ketjut. Tampere: Kustannusosakeyhtiö Tammi.

Porter, M. 1985. Competitive Advantage. New York: Free Press.

Porter, M. & Millar, V. 1995. How Information Gives You CompetitiveAdvantage. Harward Business Review, July–August.

Rockart, J. 1979. Chief Executives Define Their Own Data Needs. HarwardBusiness Review, March–April.

Rockart, J. & Treacy, M. 1982. The CEO Goes On-Line Harward BusinessReview, January–February.

Romney, M., Steinbart, P. & Cushing, B. 1997. Accounting InformationSystems, Addison-Wesley.

Scheer, A.-W. 1998. Business Process Engineering Study Edition; ReferenceModel for Industrial Enterprises. Berlin: Springer.

Selander, J. & Cross, K. 1999. Process Redesign. Is It Worth It? ManagementAccounting, January 1999.

Star, S. 1991. The Sociology of the Invisible: The Primacy of Work in TheWritings of Anselm Strauss, Social Organization and Social Process. Essays inHonor of Anselm Strauss. New York: Aldine De Gruyter.

Strauss, A. 1988. The Articulation of Project Work: An Organizational Process.The Sociological Quarterly, Vol. 29, No. 2.

Strauss, A., Fagerhaugh, S., Suczek, B. & Wiener, C. 1985. Articulation Work.Social Organization of Medical Work, The University of Chigaco Press.

189

Suchman, L. 1987. Plans and Situated Action. Cambridge, UK: CambridgeUniversity Press.

Vuokko, P. 1997. Avaimena asiakaslähtöisyys. Helsinki: Yritysjulkaisut.

190

VIII Tietojärjestelmien tuottavuus javaikuttavuus

Jari Kettunen, Magnus Simons, Markku MikkolaVTT Automaatio

Systemaattisia investointien tuottavuusarvioita ja -laskelmia on tehty ainakin1900-luvun alusta lähtien. Keskustelu tietojärjestelmien tuottavuudesta sensijaan käynnistyi toden teolla vasta 1980-luvun lopussa. Tietotekniikka on ollutteollisuuden ja ennen kaikkea tutkimuslaitosten lempilapsi – jotakin, johon onsatsattu sen itsensä vuoksi ja edistyksen nimissä. Tätä voidaan osittain selittääalan uutuudella sekä tekniikan ja sen sovellusten nopealla kehityksellä, mitkäovat olleet omiaan luomaan ja ylläpitämään yhä suurempia tietotekniikan mah-dollisuuksiin kohdistuvia odotuksia. Monet tutkijat ovatkin nimittäneet tietotek-niikan kehitykseen nojautuvaa muutosprosessia kolmanneksi teolliseksi vallan-kumoukseksi (esim. Greenwood, 1997). Tällaisessa ilmapiirissä tietotekniikkaanpanostamista ei ymmärrettävästi ole aina osattu tarkastella kriittisessä valossa.

Tänään tietotekniikan tuottavuudesta kuitenkin kirjoitetaan paljon. Tähän voi-daan olettaa olevan kaksi perussyytä. Yhtäältä tietotekniikkaan liittyvä uutuu-denviehätys on alkanut vähitellen kadota. Tietotekniikka on levittäytynyt yri-tystoiminnan kaikille sektoreille ja tietojärjestelmistä on tullut osa useimpienyritysten, kuntien ja valtionhallinnon kantavaa infrastruktuuria. Tietokoneesta ontullut arkinen työkalu, jolta odotetaan toimintavarmuutta ja helppokäyttöisyyttä.Toisaalta tietojärjestelmien rakentamisen ja ylläpidon on havaittu muodostuneenmerkittäväksi kustannustekijäksi. Suuret järjestelmäprojektit ovat tulleet yhäkalliimmiksi, vaikka esim. kiristynyt kilpailu, uudet tieteellistekniset läpimurrotsekä tehokkaat tuotantomuodot pitävätkin perusteknologian hinnan kurissa.Nämä tekijät yhdessä ovat saaneet sekä tutkijat että monet yritysjohtajat pohti-maan tietotekniikan todellisia business-hyötyjä. Peruskysymys on, saadaankotietotekniikkaan investoiduille rahoille katetta.

Tässä artikkelissa luodaan katsaus tietotekniikan (erityisesti tietojärjestelmien)tuottavuuden ja vaikuttavuuden mittaamiseen liittyvään problematiikkaan.Perustavoitteena on antaa lukijalle käsitys tietojärjestelmien tuottavuuden ja

191

vaikuttavuuden arvioimiseen kehitettyjen lähestymistapojen ominaispiirteistä,pohtia näiden lähestymistapojen käyttöön liittyviä reunaehtoja sekä muodostaakokonaisvaltainen käsitys tietotekniikkainvestoinnin potentiaalisista hyödyistä jakustannuksista. Lopuksi pohditaan, millainen rooli tuottavuuden ja vaikutta-vuuden arvioinnilla voisi olla toiminnanohjausjärjestelmän käyttöönotto-prosessissa.

1. Tietotekniikan tuottavuusparadoksi

Tietotekniikan kustannusvaikutuksista on tehty useita tutkimuksia ja arvioita.Tulokset ovat olleet samansuuntaisia: rahaa palaa ja paljon. Esimerkiksi vuonna1996 yhdysvaltalaisten yritysten arvioitiin käyttäneen yhteensä noin 500 miljar-dia dollaria tietotekniikkaan sekä siihen liittyviin oheispalveluihin. Tämän luvunon arvioitu kasvavan 20–30 % vuodessa, ja koko maailman tietotekniikkamark-kinoiden kasvuvauhdiksi vuosina 1996–2000 on arvioitu 10 %. (mm. Willcocksja Lester, 1999a.)

Kehittyneissä teollisuusmaissa toimineiden yritysten kokonaismenoista tietotek-niikan osuus vuonna 1998 oli erään arvion mukaan keskimäärin 7–10 %, kunvastaava luku 1980-luvulla oli 2–3 %. Voimakkaasti tietotekniikkaan nojaavillaaloilla – kuten rahoituksessa – tietotekniikka muodostaa usein huomattavasti tätäsuuremman osan yrityksen kokonaiskuluista. On myös arvioitu, että 1990-luvunlopussa teollisuusmaissa toimivat yritykset suuntasivat noin 40 % kaikista uu-sista investoinneistaan tietotekniikkaan ja telekommunikaatioon. Kyse ei siis oleaivan pienistä rahavirroista vaan kansantalouden mittakaavassakin merkittävistäsijoituksista. (ks. esim. Willcocks ja Lester, 1999a; Holopainen et al., 1999; TheInformation Paradox, 1998.)

Monet tutkijat ovat esittäneet, että tietotekniikasta saadut hyödyt eivät ole olleetsuhteessa siihen sijoitettuihin rahamäärin. 1980-luvun lopulla nämä näkemyksettiivistyivät ns. tietotekniikan tuottavuusparadoksiksi (IT productivity paradox).Tuottavuusparadoksi perustui havaintoon, että yhtäältä tietotekniikkainvestoin-tien koon ja toisaalta yritysten tuottavuuden ja/tai taloudellisen tuloksen välilläei ollut selkeää (tilastollisesti merkitsevää) yhteyttä (mm. Strassmann, 1990).

Tämä tulos on saanut tukea myös yritysmaailmasta: mm. vuosina 1989 ja 1996toteutettujen kyselyiden mukaan yli 2/3 Fortune 100 -listaan lukeutuvien yritys-

192

ten pääjohtajista oli sitä mieltä, että heidän yrityksensä eivät hyödy tehdyistätietotekniikkainvestoinneista parhaalla mahdollisella tavalla (Anandarajan jaWen, 1999). Holopainen et al. (1999) viittaavat tutkimuksiin, joiden mukaantuottavuus jopa laski 1970- ja 1980-luvuilla, jolloin tietotekniikkaan alettiininvestoida voimakkaasti. Vaikka 1990-luvun loppupuolella julkaistuissa tutki-muksissa on usein päädytty vastakkaisiin tuloksiin, niin esim. Gartner Gruopinvuonna 1996 julkaiseman tutkimuksen mukaan tietotekniikkaan sijoitetun pää-oman keskimääräinen nettotuotto (net average return on investment) vuosina1985–1995 oli ainoastaan yksi prosentti (The Information Paradox, 1998). Täl-laiset tietotekniikan kaikkivoipaisuuden myyttiä horjuttaneet tutkimustuloksetjohtivat luonnollisesti uusiin tutkimuksiin ja lisäsivät aihepiirin kiinnostavuuttasekä akateemisen maailman että tietoteollisuuden piirissä.

2. Tuottavuusparadoksin uudelleenarviointia

Tällä hetkellä melko yleisesti vallitsevan käsityksen mukaan tietotekniikka onlisännyt yritysten keskimääräistä tuottavuutta ainakin Yhdysvalloissa, vaikkaasiasta ei täydellistä konsensusta olekaan. Sen sijaan siitä tunnutaan olevan yhtämieltä, että tietotekniikkainvestoinnit eivät automaattisesti eivätkä yksinäänjohda parantuneeseen tuottavuuteen. Keskeistä on, kuinka tietojärjestelmäpro-jekti toteutetaan ja kuinka järjestelmät saadaan palvelemaan yrityksen liiketoi-minnallisia tavoitteita. Eri yritysten välillä on tässä suhteessa luonnollisestisuuria eroja. Lisäksi on käynyt ilmeiseksi, että vastaavia eroja löytyy myös erikansantalouden sektoreiden (esim. valmistava teollisuus vs. palvelut) väliltä(esim. Willcocks ja Lester, 1999a).

Tietotekniikan tuottavuudelle on pyritty hakemaan selittäviä tekijöitä. van Nie-veltin (1999) yli 300 yrityksen tietoihin perustuvan tilastollisen analyysin mu-kaan kyse on useiden yrityksen toimintaa kuvaavien muuttujien yhteisvaikutuk-sista. Hänen mukaansa tietotekniikka tuottaa vasta, kun investointi tehdäänoikeissa olosuhteissa ja kun tietojärjestelmähankkeeseen yhdistyy jokin organi-saation rakennetta muuttava tai osaamispohjaa laajentava toimenpide. Organi-saation rakenteen muuttamiseen liittyvistä (ja yhdessä tietojärjestelmäinvestoin-nin kanssa yrityksen taloudelliseen suorituskykyyn vaikuttavista) tekijöistäkirjoittaja mainitsee mm. hierarkioiden purkamisen, henkilökunnan vähentämi-sen sekä tutkimus- ja tuotekehitysmenojen karsimisen.

193

van Nieveltin tulos on siinä mielessä erittäin kiinnostava, että se näyttäisi tuke-van mm. monissa yrityksissä suosittua henkilökunnan vähentämiseen perustuvaakustannusten karsimisen linjaa. Aivan eri asia onkin sitten se, millä aikajänteellätuottavuutta tarkastellaan, mitä mieltä yritysten henkilökunta saavutetuista tulok-sista on ja kuinka luotettavina ja tarkoituksenmukaisina käytössä olleita suori-tuskykymittareita voidaan pitää. Varmaa on vain se, että tietotekniikan tuotta-vuutta mitataan hyvin monella eri tavalla ja että yhtä ainoaa ja oikeaa tuotta-vuusmittaria ei ole olemassa.

Tuottavuusparadoksille on uusimpien tutkimustulosten valossa annettu useitaselityksiä. Usein viitataan mm.

− puutteellisiin arviointimenetelmiin (esim. tietotekniikan aineettomien hyö-tyjen arvottaminen)

− käyttöönottovaiheen ja oppimisen aiheuttamiin viiveisiin (ottaa aikansa,ennen kuin investoinnista saadaan kaikki hyöty irti)

− eri tekijöiden määrään ja yhdysvaikutuksiin (esim. tietotekniikan suhteellistapainoarvoa verrattuna muihin yrityksen tulokseen vaikuttaviin tekijöihin onvaikea arvioida)

− teknologian yleistymiseen (mikä tavallisesti johtaa suhteellisen kilpailuedunmenettämiseen tai vaihtoehtoisesti vasta avaa ovet ao. teknologian tehok-kaalle hyödyntämiselle)

− muihin ulkoisiin eli yksittäisen yrityksen omasta toiminnasta riippumatto-miin tekijöihin (esim. teknologian hinta, valuuttakurssit yms. yrityksen tu-lokseen vaikuttavat tekijät) sekä

− eri kansantalouden sektoreiden välisiin eroihin.

Lisäksi on hyvä muistaa, että joissakin yrityksissä tietotekniikka ei yksinkertai-sesti tuo toiminnalle mainittavaa lisäarvoa. Tällaisia yrityksiä on paljon niin kuinmyös syitäkin. (Selityksiä tuottavuusparadoksille mm. Brynjolfsson, 1993;Willcocks ja Lester, 1999b; Holopainen et al., 1999.)

194

3. Mitä on tietotekniikan tuottavuus?

Tuottavuudella tarkoitetaan yleensä toiminnan tulosten ja siihen satsattujenpanosten välistä suhdetta. Tuottavuus liittyy siten toiminnan tehokkuuteen ja oneri asia kuin toiminnan (taloudellinen) tulos. Yleisessä muodossa tuottavuuden”kaava” on output/input. Se mitä ”output” ja ”input” tässä kaavassa ovat, on sopi-muksenvarainen asia. Kirjallisuudessa on esitetty mm. seuraavanlaisia ehdotuksia:

− taloudellinen tulos / tietotekniikkainvestoinnin suuruus− tuotannon määrä / henkilötyötunti− tuotteen laatu / yksikkökustannukset− palvelun laatu / palvelun tuottamiskustannukset− informaation laatu / informaation tuottamiskustannukset.

Nämä tunnusluvut mittaavat eri asioita, ja jotkut niistä ovat helpommin ja jotkutvaikeammin laskettavissa. Perusero voidaan tehdä taloudellisten ja toiminnal-listen tunnuslukujen välille. Esitetyistä tunnusluvuista ensimmäinen on selkeästitaloudellinen ja neljä muuta toiminnallisia tunnuslukuja. Toiminnalliset tunnus-luvut eroavat taloudellisista tunnusluvuista siten, että niiden osoittaja kuvaamäärää tai laatua, kun taas puhtaasti taloudelliset tunnusluvut ovat muotoa ”eu-roa alle euroa”.

Tunnusluvut liittyvät toisiinsa siten, että taloudellisten tunnuslukujen huolellinenlaskeminen edellyttää käytännössä myös toiminnallisten ja laadullisten tekijöi-den huomioimista. Tämä siksi, että osa tietotekniikkainvestointien kustannuk-sista ja hyödyistä on epäsuoria eivätkä ne siten näy suoraan esim. yhtiön tulos-laskelmassa tai taseessa (ainakaan lyhyellä aikajänteellä). Yhteistä kaikille tuot-tavuuden tunnusluvuille on se, että niiden laskeminen edellyttää tietotekniikanvaikutusten mittaamista ja kvantifiointia.

Tietotekniikan tuottavuutta arvioitaessa on myös tehtävä päätös siitä, mikä onarvioinnin kattavuus. Kirjallisuudessa esitetään yleensä seuraavat neljä tasoa:

− kansantalous (esim. Yhdysvallat vs. Suomi)− kansantalouden sektori (esim. konepajateollisuus vs. palvelut)− organisaatio (esim. Pärnäsen korjaamo Haukiputaalta)− funktio tai prosessi (esim. myynti, tuotekehitys, tuotanto jne…).

195

Arvioinnin taso vaikuttaa käytössä olevien menetelmien valintaan ja saatavissaja/tai hyödynnettävissä olevien tietojen luonteeseen. Mitä korkeammalla tasollatoimitaan, sitä vaikeammaksi tulee erilaisten aineettomien hyötyjen ja kustan-nusten sisällyttäminen laskelmiin. Perusteellisen laadullisen tutkimuksen teke-minen onnistuu ainoastaan yksittäisiä organisaatioita tai niiden toimintoja tar-kastelemalla – kansantalouden tasolla toimiva tutkija turvautuu sen sijaan kan-santalouden tilastoihin ja yritysten tuloslaskelmiin ja taseisiin.

4. Tuottavuus vs. vaikuttavuus

Tietotekniikan vaikutuksista puhuttaessa on järkevää erottaa toisistaan tuotta-vuus ja vaikuttavuus yleensä. Näistä vaikuttavuus on tuottavuutta laajempi käsi-te. Tietotekniikan vaikuttavuudesta puhuttaessa tarkoitetaan tietotekniikan kaik-kia (joko verifioituja tai potentiaalisia) vaikutuksia yrityksen toimintaan jatyöntekijöiden toimenkuvaan riippumatta siitä, mikä niiden suhde on yrityksentaloudelliseen tulokseen tai tietotekniikkainvestoinnin tuottavuuteen.

Tuottavuutta kuvaavien tunnuslukujen laskeminen perustuu nimenomaan tieto-tekniikan (tai spesifimmin yrityksen tietojärjestelmien) vaikutusten arvioimiseenja kvantifiointiin. Vaikutuksia voidaan (ja pitääkin) sen sijaan arvioida myöspuhtaasti kvalitatiiviselta pohjalta. Voidaan ajatella, että tietojärjestelmän vai-kutusten arviointi on luontevaa aloittaa laadullisista, mm. ihmisten työtehtäviinliittyvistä tekijöistä, ja ulottaa vähitellen kohti toimintaprosessien tehokkuutta,tuotteiden ja palveluiden laatua sekä suoranaisesti yrityksen taloudelliseen tulok-seen vaikuttavia tekijöitä. Se, kuinka pitkälle tässä päästään, sanelee käytännössämyös sen, kuinka pitkälle vaikutusten kvantifiointi voidaan viedä. Vaikutuksiavoidaan siis hyvin arvioida, vaikka kvantifioinnissa ei onnistuttaisikaan.

5. Tuottavuuden ja vaikuttavuuden mittaamiseen liittyviä erityiskysymyksiä

Tietojärjestelmien tuottavuuden ja vaikuttavuuden mittaamisen liittyvä proble-matiikka voidaan tiivistää seuraaviin kysymyksiin:

1. Mitä tarkalleen ottaen pitäisi mitata?2. Kuinka mittaukset tulisi suorittaa, jotta ne tuottaisivat luotettavaa tietoa?3. Miksi tätä kannattaa tehdä ja kuka siitä hyötyy?

196

Jos kykenemme antamaan vastauksen ensimmäiseen kysymykseen, niin tie-dämme, mitä ”output” ja ”input” mittausmallissamme ovat, ts. mistä ilmiöistäolemme kiinnostuneita. Aivan keskeinen kysymys on, missä määrin ja millätarkkuudella haluamme tarkastella tietotekniikkainvestointien taloudellisia vai-kutuksia.

Toinen kysymys liittyy kiinteästi ensimmäiseen. Kun arvioinnin tavoitteet ovattäsmentyneet, niin voimme paneutua siihen, kuinka arvioinnit ja/tai mittauksettulisi suorittaa. Jos kykenemme antamaan vastauksen toiseen kysymykseen, niintiedämme, millaista dataa arviointien tekemiseen tarvitaan, mistä ja kuinka sitähankitaan ja miten tietoja tämän jälkeen käsitellään. Lisäksi on selvitettävä,millaisessa muodossa tiedot ovat saatavissa (kvantitatiivisessa vs. kvalitatiivises-sa) ja millaisia epävarmuustekijöitä niihin liittyy. Kvalitatiivisessa muodossaolevien tietojen kvantifiointi muodostaa mitä todennäköisemmin merkittävänhaasteen.

Kolmas kysymys on oleellinen, koska mittausmallien luominen, tiedon keräämi-nen ja arviointien suorittaminen maksavat. Kysymys siis kuuluu: kuka voisihyötyä – ja millä tavalla – tietotekniikan tuottavuusvaikutusten selvittämisestäniin paljon, että hänen kannattaisi panostaa siihen aikaa ja rahaa. Tähän kysy-mykseen olisi löydettävä vastaus erityisesti silloin, kun tavoitteena on yritystenkäyttöön suunnatun arviointimenetelmän kehittäminen ja/tai vastaavien asian-tuntijapalveluiden myyminen.

Arviointien suorittamiseen liittyviä keskeisiä ongelmia on pohdittu alan kirjalli-suudessa. Hyviä yleiskuvauksia on esimerkiksi seuraavissa lähteissä: Anandara-jan ja Wen (1999), Willcocks ja Lester (1999a, 1999b) ja Holopainen et al.(1999). Seuraavassa eri lähteistä kootut arviointien suorittamista vaikeuttavattekijät on jaettu ja tiivistetty neljään peruskategoriaan: mittausmallit, aineettomathyödyt ja piilokustannukset, tietotekniikan arvoketju sekä tietotekniikkainves-tointi ja yrityksen taloudellinen tulos.

Mittausmallit

Tällä hetkellä ei ole olemassa mitään vakiintunutta, yleisesti luotettavaksi jakäyttökelpoiseksi tunnustettua menetelmää tietotekniikan (tai tietojärjestelmien)tuottavuuden ja vaikuttavuuden mittaamiseen. Aihetta on lähestytty eri tavoin, ja

197

erilaiset arviointitavat ovat tuottaneet erilaisia tuloksia. Tulosten yhteismitallis-taminen on vaikeaa, koska eri menetelmät mittaavat itse asiassa eri asioita.

Saattaa olla myös niin, että toiminnan tavoitteita ei ole määritelty tai että toimin-nan tulosta ei voida mitata millään yksiselitteisellä mittarilla. Tällöin on myöshyvin vaikea arvioida, missä määrin esimerkiksi uusi tietojärjestelmä on vaikut-tanut toiminnan tehokkuuteen tai saavutettujen tulosten laatuun. Toiminnallistentunnuslukujen laskeminen on toki mahdollista, mikäli organisaation toiminta onhahmotettavissa erilaisten tehtävien, toimintojen tai prosessien kautta, joiden”hyvyydelle” voidaan määritellä mielekkäät kriteerit.

Keskeisen haasteen tietojärjestelmien tuottavuuden ja vaikuttavuuden mittaami-selle muodostaa aikaperspektiivi. Tutkijapiireissä korostuu usein mennyt aika-muoto kun taas yrityksen kannalta asia tulee ajankohtaiseksi erityisesti inves-tointipäätöksiä tehtäessä. Tällöin arviointi täytyy perustaa järjestelmän käyt-töönoton ja käytön ennakoitujen seurausvaikutusten varaan. Ja mitä pidemmälläaikajänteellä vaikutuksia pyritään arvioimaan, sitä suurempia epävarmuusteki-jöitä arviointeihin liittyy. Tulevaisuuteen suuntautuneet arvioinnit ovat par-haimmillaankin vain valistuneita arvauksia hankkeen tulevista hyödyistä jakustannuksista, olipa arvioinnin taustalla oleva mittausmalli millainen hyvänsä.

Aineettomat hyödyt ja piilokustannukset

Tietojärjestelmien hyödyistä ja kustannuksista puhuttaessa ei voida unohtaa niitävaikutuksia, jotka eivät realisoidu välittöminä ja täsmällisesti mitattavina sääs-töinä tai kuluina. Tavallisesti tällöin viitataan ns. aineettomiin hyötyihin (intan-gible benefits) ja piilokustannuksiin (hidden costs). Vaikka aineettomat hyödytja piilokustannukset ovat usein selkeästi havaittavissa, ne ovat siitä huolimattavaikeasti ”hinnoiteltavissa”; esimerkiksi tehostuneen tiedonhallinnan (aineetonhyöty) tai uuden järjestelmän käytön opettelun (piilokustannus) vaikutuksia onhyvin vaikea arvioida tai mitata rahassa. Lisäksi osa tämänkaltaisista hyödyistäja kustannuksista realisoituu vain tietyllä (vaikeasti arvioitavalla) todennäköi-syydellä.

Piilokustannusten kategoriaan on siten myös luettava järjestelmän käyttöönot-toon liittyvät riskit. Nämä voidaan periaatteessa määritellä odotusarvon käsitteenavulla epätoivotuista seuraustapahtumista aiheutuvien kustannusten (esim. jär-

198

jestelmän epäkäytettävyydestä koituvan vahingon arvioitu suuruus) ja ao. ta-pahtumien todennäköisyyksien tuloksi. Käyttöönotoon liittyvien riskien kvanti-fioiminen on kuitenkin erittäin vaikeaa – etenkin, jos kyseessä on kauaskantoi-nen hanke, jollaisista yrityksellä ei ole aikaisempaa kokemusta.

Tietotekniikan arvoketju

Tietotekniikan arvoketjulla (IT value chain) tarkoitetaan sitä tapaa, jolla tieto-tekniikka tuo lisäarvoa yrityksen toimintaan. Arvoketjun tunnistaminen on sitähelpompaa, mitä rajoitetumpi rooli tietotekniikalla yrityksessä (tai yleisemminorganisaatiossa) on. Jos yrityksen toiminta taas oleellisessa mielessä perustuutietotekniikan (tietojärjestelmien) varaan, voi niiden tuomaa suhteellista lisäar-voa olla vaikea (tai mahdotonta) erottaa toiminnan kokonaisuudesta. Tietotek-niikan arvoketjun tunnistamisen vaikeusaste on suoraan verrannollinen tuotta-vuuden arvioimisen ja mittaamisen vaikeuteen.

Tietotekniikan tuomien hyötyjen arviointi on siten helpompaa esimerkiksi pe-rinteisessä valmistavassa teollisuudessa kuin uuden talouden Internet-yrityksissä.Konepaja kun voi (ainakin teoriassa) toimia kokonaan ilman tietoteknisiä järjes-telmiä – tai käyttää niitä valintansa mukaan yksittäisten toimintojen (taloushal-linto, tuotannonsuunnittelu, koneenohjaus, jne…) tukemiseen. Tällöin uudelletietotekniikkainvestoinneille löytyy yleensä mielekäs vertailupohja, vaikka itselaskelmien tekeminen olisikin hankalaa.

Voimakkaasti tietotekniikkaan nojaavilla aloilla vastaavaa vertailupohjaa ei sensijaan useinkaan löydy. Yrityksen toiminta saattaa nojata siinä määrin tietojär-jestelmien käytön varaan, että muita vaihtoehtoja ei todellisuudessa ole edestarjolla. Mittavat tietotekniikkainvestoinnit voivat olla välttämättömiä esim.toiminnan käynnistämisen tai asiakaskunnan tehokkaan palvelun kannalta. Tie-tojärjestelmien tuottavuus rakentuu tällöin yrityksen muiden toimintojen tarkoi-tuksenmukaisuuden varaan. Toisaalta huonosti menneen tietotekniikkaprojektinvaikutukset ovat tavallisesti heti nähtävissä perusliiketoiminnan ongelmienjohdosta.

199

Tietotekniikkainvestointi ja yrityksen taloudellinen tulos

Jos tietotekniikkahankkeen kustannusten ja hyötyjen arvioiminen on hankalaa,niin vielä vaikeampaa on ennakoida tai selvittää hankkeen vaikutus yrityksentaloudelliseen tulokseen. Tämä johtuu siitä, että yrityksen taloudellinen tulos(voitto tai tappio) on lukemattomien eri tekijöiden summa. Tietotekniikka onvain yksi vaikuttava tekijä muiden joukossa. Investointi uuteen tietojärjestel-mään vaikuttaa yrityksen tulokseen osittain suoraan mm. kustannusten kauttamutta suureksi osaksi epäsuorasti esim. luomalla edellytyksiä uudelle liiketoi-minnalle (lisämyynti) tai sotkemalla aikaisemmin hyvin toimineet kuviot (piilo-kustannus). Lisäksi osa tulokseen vaikuttavista tekijöistä eri riipu yrityksenomista tietotekniikkahankkeista mitenkään (esim. valuuttakurssien vaihtelut).Tilannetta havainnollistaa kuva 1.

Kuva 1. Tietotekniikka ja yrityksen taloudellinen tulos.

Kirjallisuudessa ollaan melko yleisesti päädytty johtopäätökseen, että tietotek-niikkainvestoinnin suuruuden ja yrityksen taloudellisen tuloksen välillä ei voiolla kausaalista syy-seuraussuhdetta – olkoonkin, että tilastollinen yhteys olisilöydettävissä. Holopainen et al. (1999) ovat esimerkiksi ehdottaneet stokastistenmallien käyttöä kausaalimallien sijasta. Stokastiset mallit ovat muotoa: jos x(esim. tietotekniikan käytön aste) lisääntyy, niin y:n (esim. yrityksen liikevoitto)

TIETOTEKN.

f1

f2

...

fn

fn+1

fn+2

...

fn+m

KUST.

TULOT

TAL. TULOS

Tietojärjestelmientoiminnallisetominaisuudet

Yrityksen tuotteet, palvelutja toiminnot, joihintietotekniikka vaikuttaa

Muut yrityksentoimintaan tai

toimintaympäristöönliittyvät tekijät

Tietotekniikanvaikutus?

200

esiintymisen todennäköisyys lisääntyy, tai yleisemmin ƒ: x → P(y). Tällaisetmallit voivat olla hyödyllisiä ajattelun apuvälineitä riippumatta siitä, mitentäsmällisesti muuttujien suhteet formuloidaan.

6. Tietojärjestelmien hyötyjä ja kustannuksia

Kattavan esityksen laatiminen tietojärjestelmien potentiaalisista hyödyistä jakustannusvaikutuksista on jokseenkin mahdotonta. Tästä huolimatta on ehkäperusteltua pyrkiä luomaan kentästä mahdollisimman kattava yleiskuva tai malli,joka voi toimia työkaluna hyötyjä ja kustannuksia tunnistettaessa ja niiden vai-kutuksia arvioitaessa. Alla olevassa mallissa kirjallisuuden (mm. Anandarajan jaWen, 1999; Holopainen et al., 1999; Luoma et al., 1999; Willcocks ja Lester,1999a ja 1999b) ja päättelyn perusteella tunnistetut potentiaaliset hyödyt jakustannukset on jaettu kahteen pääluokkaan ja siitä edelleen alaluokkiin ao.tekijöiden taloudellisen vaikuttavuuden perusteella (taulukot I ja II).

Kaikki taulukoissa I ja II nimetyt hyödyt ja kustannukset (3. sarake) eivät var-masti toteudu kaikkien tietojärjestelmäprojektien yhteydessä. Ne, jotka toteutu-vat, toteutuvat mm. projektiosaamisen tasosta, projektiin sitoutuneista yrityksis-tä, yritysten toimialasta sekä niiden toimintaympäristössä tapahtuvista muutok-sista johtuen eri painoarvoilla eri projekteissa. Näin ollen mallin pääasiallinenkäyttötarkoitus on toimia eräänlaisena tarkistuslistana tietojärjestelmähankkeentavoitteita asetettaessa ja/tai sen tuottavuutta ja vaikuttavuutta arvioitaessa.

Taulukoissa ei ole erikseen luokkia aineettomille hyödyille ja piilokustannuksil-le. Tämä johtuu siitä, että keskeiseksi luokitteluperusteeksi on valittu taloudelli-nen vaikuttavuus (ts. vaikutus yrityksen kassavirtoihin). Tässä raportissa aineet-tomiksi hyödyksi ja piilokustannuksiksi on kutsuttu pääasiassa sellaisia tietojär-jestelmien aikaansaamia hyötyjä ja kustannuksia, jotka ovat ”vaikeasti hinnoi-teltavissa”, jotka eivät näy välittömästi yrityksen kassavirroissa ja joiden suhdeyrityksen taloudelliseen tulokseen on epäsuora.

201

Taulukko I. Tietotekniikan potentiaalisia hyötyjä.

Pääluokka Alaluokka Toimenpide/ potentiaalinenhyöty

Taloudellinenvaikuttavuus

työn tuottavuus nousee, työ-voiman määrää voidaanvähentää

toiminnantehostuminen,sama tulospienemmilläresursseilla

tuotantoprosessi tehostuu,vähemmän "hylkyä", tarvitaanvähemmän raaka-aineita

mahdollistaa muut-tuvien ja kiinteidenkustannusten karsi-misen

ostoprosessit: hankintojenoptimointi, elektronisetkauppapaikat

uudet mahdol-liset toiminta-mallit

logistiset prosessit: kuljetus-suunnittelu, valmistuksen jatoimitusten reaaliaikainenseuranta ...

tuovat potentiaalisiasäästöjä, joidenrealisoiminen edel-lyttää potentiaalinonnistunutta hyö-dyntämistä

säästöt

tietämyksen-hallinta

riskit tunnistetaan ja niihinosataan varautua paremmin

edesauttaa suurtenja vaikeasti enna-koitavien lisäkustan-nusten minimoimista

työn tuottavuus nousee, työn-tekijöiden työaikaa vapautuumuihin tehtäviin ja/tai perus-tehtävät voidaan tehdä pa-remmin

toiminnantehostuminen,enemmäntulosta sa-moilla resurs-seilla koneiden ja laitteiden kor-

keampi käyttöaste, mahdolli-suus lisätä tuotantomääriäilman lisäinvestointejauudet tutkimus- ja suunnitte-lumenetelmät, tuotteiden japalveluiden korkeampi laatu

uudet mahdol-liset toiminta-mallit

uudet tuote- ja palvelukonsep-tit, jotka tietotekniikka mahdol-listaalisääntynyt toiminnan jousta-vuusenemmän tietoa asiakkaista,kilpailijoista ja partnereista

lisätulot

tietämyksen-hallinta

tietojen tehokkaampi hyväksi-käyttö

luovat potentiaaliamyynnin lisäämisel-le, jonka realisoimi-nen edellyttääpotentiaalin onnistu-nutta hyödyntämistä

202

Taulukko II. Tietotekniikan käyttöönoton kustannuksia.

Pääluokka Alaluokka Kustannusten lähde Taloudellinen vaikuttavuustietokoneiden, oheislait-teiden ja ohjelmistojenhankintakonsultointi- ja tukipalve-lutuudet työntekijät (palkatja rekrytointikulut)

lisäkustan-nukset

järjestel-män han-kinta

ylityökorvaukset

kertaluontoisia ja pitkävai-kutteisia lisäkustannuksia

järjestelmän määrittelyynja käyttöönottoon sekähenkilöstön koulutukseenkuluva aika ja henkilöre-surssit

määrittely-ja käyt-töönotto-prosessi

järjestelmän käyttöön jauusiin työprosesseihinsopeutumiseen kuluvaaika ja henkilöresurssit(implementoinnin jälkeen)

toimintakapasiteetin pienen-tyminen ja/tai tuotteiden taitoimintaprosessien laadunväliaikainen heikentyminen,mikä voi johtaa tulojenmenetyksiin

järjestelmän käyttökun-nottomuus

tulojenmenetykset

ennakoi-mattomatvaikutuksetja häiriöti-lanteet

epätoivotut muutoksetasiakaspalveluproses-seissa

Aineettomat hyödyt voivat realisoitua sekä säästöinä että lisätuloina. Käytännös-sä aineettomiin hyötyihin luettavissa olevat vaikutukset sijoittuvat enimmäkseentaulukon I toiseen pääluokkaan, lisätulot (esimerkiksi ”uudet tuote- ja palvelu-konseptit”, jotka luovat edellytyksiä tulojen kasvattamiselle). Piilokustannuk-sista puhuttaessa tarkoitetaan erityisesti taulukon II toiseen pääluokkaan sijoittu-via tekijöitä, jotka liittyvät usein tietojärjestelmien käyttöönottoprosessien vai-keasti ennakoitaviin sivuvaikutuksiin (esimerkiksi ”epätoivotut muutokset asia-kaspalveluprosesseissa”, jotka saattavat heikentää yrityksen tuotteiden menek-kiä).

7. Net present value -menetelmä ja sen soveltaminen tietotekniikkainves-tointeihin

Net present value (NPV) -menetelmää (suomeksi nykyarvomenetelmää) käyte-tään tyypillisesti eri päätösvaihtoehtojen (mm. investointien) evaluointiin niiden

203

(arvioidun) taloudellisen kannattavuuden perusteella. Anandarajan ja Wen(1999) esittävät artikkelissaan, kuinka menetelmää sovelletaan tietotekniikkain-vestointien arvottamiseen ja kuinka tietotekniikkahankkeiden aineettomat hyö-dyt ja piilokustannukset sisällytetään analyysiin. Vaikka menetelmän soveltu-vuudesta tietotekniikkainvestointien todellisten hyötyjen ja kustannusten arvioi-miseen voidaankin olla montaa mieltä, voitaneen sitä kuitenkin pitää eräänlaise-na tuottavuuden arvioinnin tavoitemallina (siis silloin kun tavoitteena on raha-määräinen arvio). NPV-menetelmän periaate on esitetty kuvassa 2 (lähdettäAnandarajan ja Wen (1999) mukaillen).

NPV-menetelmä sisältää seuraavat neljä (4) päävaihetta:

1. kassavirtojen (tuottojen ja kustannusten) arviointi eri investointivaihtoehdoille2. kassavirtojen diskonttaaminen nykyhetkeen3. herkkyysanalyysit (yksittäisten muutosten vaikutus laskelman lopputulok-

seen)4. eri vaihtoehtojen laittaminen paremmuusjärjestykseen arvioidun tuottavuu-

den perusteella.

Näistä ensimmäistä vaihetta voidaan pitää kaikkein vaativimpana. Tavoitteenaon arvioida kuhunkin investointivaihtoehtoon sisältyvät vuotuiset tuotot ja kus-tannukset (kassavirrat) rahamääräisinä nykyhetkestä johonkin valittuun tulevai-suuden ajankohtaan saakka. Yksi tarkasteltavista vaihtoehdoista on että ei tehdämitään. Tulevaisuuden ajankohta (tarkasteluvälin pituus) voi määräytyä esim.ao. investoinnin kirjanpitolakiin perustuvan poistoaikataulun tai arvioidun käyt-töiän perusteella.

Menetelmän käyttö edellyttää sekä aineettomien hyötyjen että piilokustannustentunnistamista ja kvantifiointia, koska niillä voi olla merkittävä vaikutus tulevai-suuden kassavirtoihin. Keskeisen ongelman tässä muodostaa ao. tekijöihin liitty-vä epävarmuus. Anandarajan ja Wen (1999) esittävät tähän ratkaisuksi laskel-mien perustamista tuottoja ja kustannuksia koskevien odotusarvojen (arvioiden)varaan. Epävarmoissa tapauksissa toimitaan seuraavasti: laaditaan arvioihinperustuen vaihtoehtoisia kassavirtaennusteita, varustetaan vaihtoehdot todennä-

204

köisyysarviolla ja lasketaan kassavirran odotusarvoinen suuruus2. Herkkyystar-kastelut puolestaan perustuvat vastaavalla tavalla muodostettujen skenaarioidenja niiden arvioitujen tapahtumatodennäköisyyksien muunteluun.

Tuotot

Kustannukset

Kas

savi

rrat

Aika

Nykyjärjestelmäntuotot

Nykyjärjestelmänkustannukset

Uuden järjestelmäntuotot

Uuden järjestelmänkustannukset

Kassavirtaennusteet

Kuva 2. Net present value eli nykyarvo-menetelmän periaatekaavio. Pylväätkuvaavat eri vaihtoehtojen arvioituja tuottoja ja kustannuksia vuositasolla.

Toiminnanohjausjärjestelmän laajamittainen implementointi niin kuin kaikkimuutkin suuret muutosprosessit sisältävät aina riskejä. Tämän vuoksi nykyjär-jestelmään ja -käytäntöihin pitäytyminen on usein vähintäänkin harkinnanarvoi-nen vaihtoehto. Sen edut ovat helposti identifioitavissa: lyhyellä tähtäimelläsäästetään varmasti rahaa (vältetään suuri kertakustannus), prosesseihin tai hen-kilökunnan työskentelytapoihin ei tarvitse välttämättä koskea (vältetään työläs

2 Esimerkki. Arvioihin perustuvat vaihtoehtoiset kassavirtaennusteet toiminnan jousta-vuuden lisääntymisen vaikutuksesta myyntiin = 0–5, 6–10, 11–15, 16–20, 21–25 ja 26–30 miljoonaa euroa. Vaihtoehtojen todennäköisyysarviot = 0,05, 0,15, 0,30, 0,30, 0,15 ja0,05. Kassavirran odotusarvoinen suuruus (odotusarvoinen lisämyynti parantuneenjoustavuuden johdosta) = 0,05 × 2,5 + 0,15 × 8 + … + 0,05 × 28 ≈ 15,5 miljoonaa euroa.(Esimerkki on kirjoittajien laatima eikä sitä esitetä Anandarajanin ja Wenin artikkelissa.)

205

koulutus- ja muutosprosessi), ja riskit ovat paremmin hallinnassa (nykyjärjes-telmän vahvuudet ja heikkoudet tunnetaan ja niiden kanssa osataan elää).

Toisaalta aikaansa seuraava yrittäjä tai yritysjohto pitää silmänsä auki ja arvioieri vaihtoehtojen hyviä ja huonoja puolia: esim. millaisia etuja uuteen järjestel-mään siirtyminen voisi tuoda ja voisiko se – uuden järjestelmän hankintaan jakäyttöönottoon liittyvät kustannukset huomioiden – osoittautua järkeväksi vaih-toehdoksi vanhassa systeemissä pitäytymisen sijasta? Tietotekniikan nopeastakehityksestä ja tietotekniikan sovellusten nopeasta muutosvauhdista johtuenuusien järjestelmien ja sovellusten ominaisuuksien arviointi ja hankinnan poh-dinta on luonteva osa yrityksen arkipäivää. Ennemmin tai myöhemmin on jär-jestelmää päivitettävä, tai se on kokonaan korvattava uudella. Kysymys onkinsiten ennen kaikkea hankinnan ajoituksesta ja sen kriteereistä, mm. hinnasta.Tätä kautta tietotekniikan tuottavuuden ja vaikuttavuuden arviointi kytkeytyy(tulisi kytkeytyä!) saumattomasti yritysten strategiaprosesseihin.

8. Tuottavuus, tehokkuus ja eri sidosryhmien intressit

Tietojärjestelmien tuottavuuden tai tehokkuuden mittaaminen ei ole yksiselittei-nen asia. Tässä artikkelissa kuvattujen käsitteellisten ja mittausteknisten vai-keuksien lisäksi meidän on ymmärrettävä, että organisaatiolla ei ole vain yhtäjakamatonta näkemystä. Vastaus tietojärjestelmien tuottavuutta ja vaikuttavuuttakoskeviin kysymyksiin saattaa siis vaihdella vastauksen antajasta riippuen:talousmies katsoo usein asiaa kustannuslaskennan näkökulmasta siinä missätuotannonsuunnittelija painottaa operatiivisia hyötyjä jne.

Eri työntekijä- ja ammattiryhmillä on lisäksi puolustettavinaan omat intressinsä,näkemyksensä ja uskomuksensa, jotka ovat vain jossain määrin organisaationvirallisen linjan tai ajattelutavan mukaisia (sikäli kuin sellaista on edes olemas-sa). Useat tutkimukset ovat osoittaneet, että erityisesti tietotekniikka- ja muutos-hankkeisiin liittyy usein selkeä poliittinen aspekti: jokainen pyrkii pitämäänhuolta omista eduistaan, eivätkä nämä edut osu aina yksiin. Esimerkiksi työnte-kijäportaassa uusi tietojärjestelmähanke koetaan usein johdon ja omistajienyritykseksi lisätä työntekijöiden valvontaa ja työtaakkaa, tai vaihtoehtoisestijonkin yrityksen toiminnan kannalta merkittävän ammattiryhmän selkeäksi omanedun tavoitteluksi (useita lähteitä, mm. Walsham, 1992; Zuboff, 1988, Markus,1983; Keen, 1981).

206

Käsitteiden suhteen on syytä olla tarkkana. Työtyytyväisyys ei ole sama asiakuin toiminnan tehokkuus, eikä toiminnan tehokkuus välttämättä johda hyvääntaloudelliseen tulokseen. Tuottavuudesta puhuttaessa on hyvä aina erikseenmääritellä, mitä ao. termillä kulloinkin tarkoitetaan.

9. Operatiivinen näkökulma tietojärjestelmien vaikuttavuuteen

Tietojärjestelmien vaikutuksia voidaan lähteä arvioimaan myös korostetun ope-ratiivisesta ja/tai laadullisesta näkökulmasta. Tavoitteena voi olla esim. yrityksentoiminnalle koituvien operatiivisten hyötyjen ennakoiminen tai työntekijöidentoimenkuviin ja työn luonteeseen kohdistuvien vaikutusten analysoiminen.Tavoitteeksi voidaan asettaa myös yrityksen tietojärjestelmien toiminnallisenlaadun (tarkoituksenmukaisuuden ja luotettavuuden) arvioiminen.

Mainitut lähestymistavat eroavat toisistaan lähinnä sen suhteen, mistä lähdetäänliikkeelle: ensimmäisessä tapauksessa arviointien lähtökohdaksi otetaan järjes-telmien yleiset ominaisuudet, jälkimmäisessä organisaation toiminta ja toimin-nan tavoitteet. Kummankin lähestymistavan fokus on (operatiivisen) toiminnanja tietojärjestelmien rajapinnassa (kuva 3). Arviointien tukena voidaan käyttäämm. erilaisia mallinnusmenetelmiä.

207

TOIMINTAPROSESSIT, TOIMINNOT JA TEHTÄVÄT

TIETOJÄRJESTELMIEN TOIMINNALLISET OMINAISUUDET

Asettavat vaatimuksiajärjestelmien ominaisuuksille Vaikuttavat toiminnan

edellytyksiin ja luonteeseen

Kuva 3. Toimintaprosessien ja tietojärjestelmien vuorovaikutussuhteita.

Tietotekniikka tukee ja mahdollistaa

Toimintaprosessien ja toimintojen osalta tietotekniikkahyödyt jaetaan useinkahteen laadullisesti erilaiseen kategoriaan. Yhtäältä tietotekniikalla voidaantukea ja tehostaa olemassa olevia prosesseja ja toimintoja (1), toisaalta tietotek-niikka ja sen sovellukset mahdollistavat kokonaan uudenlaisia (liike)toiminnanmuotoja (2) (Luoma et al. 1999). Esimerkkejä:

1. Tietotekniikka tukee ja tehostaa:

− tiedon tallennus, muokkaus, tulostaminen ja jakelu (esim. tekstinkäsittely-ohjelmat)

− tiedonkäsittelyn rutiinit, laskenta (esim. palkanlaskenta)− suunnittelu-, tutkimus- ja kehitystoiminta (esim. simulointi)− tuotantoprosessi (esim. ohjelmoitavat automaatiojärjestelmät)− seuranta (esim. automaattinen vikadiagnostiikka).

208

Suunnitteluprosessien tehostuminen voi näkyä esim. parantuneina käyttöasteina,lyhyempinä tuotannon läpäisyaikoina sekä varastojen kiertonopeuden kasvami-sena. Tuotantoprosessin automatisointi voi vaikuttaa esim. lopputuotteidenlaatuun sekä virheiden vähenemisen johdosta myös toimitusaikapitoon. Tehok-kaat tiedonkäsittelyn rutiinit parantavat hallinnollisen työn tuottavuutta sekähelpottavat yrityksen tietovarastoihin kertyneen tiedon hyödyntämistä. Kaikkitämä edellyttää tietysti sitä, että uuden tekniikan käyttöönotossa onnistutaansuunnitellulla tavalla.

2. Tietotekniikka mahdollistaa:

− uudet tiedon haku- ja käsittelymenetelmät (esim. tietokantahaut)− uudet tiedon esitysmuodot (esim. hypertext)− uudet tuote- ja palvelukonseptit (esim. verkkopankki)− uudet markkinointikeinot ja -kanavat (esim. web)− potentiaalisen asiakaskunnan laajentamisen (esim. web)− työn ajallisen ja maantieteellisen diffuusion (esim. 24 h tuotekehitys)− automatisoidut toimintaprosessit (workflows).

Kategorioiden välinen ero liittyy siis siihen, missä määrin tietotekniikan voidaansanoa luoneen yritykselle aivan uusia toiminnan mahdollisuuksia. Rajanveto eikuitenkaan ole helppoa, ja tyypillisesti tietotekniikan käyttöönoton vaikutukset (jatavoitteet) ovat moninaisia – sekä toimintaa tehostavia että uutta mahdollistavia.

Tietotekniikka muuttaa työn luonnetta ja vaatimuksia

Toimintaprosessien lisäksi tietotekniikan vaikutuksia voidaan tarkastella myösyksittäisten työntekijöiden työtehtävien ja toimenkuvien tasolla. Zuboff (1988)on osoittanut laajaan empiiriseen aineistoon tukeutuen, että tietotekniikka vai-kuttaa syvällisellä tavalla työn luonteeseen sekä ammattitaidollisiin vaatimuk-siin. Eräs hänen perusteeseistään on, että tietotekniikan käytön seurauksena yhäsuurempi osa työstä tapahtuu symbolien välityksellä ja että esim. oppiminentulee näin ollen perustumaan enemmän analyysiin kuin manuaalisen työn kauttatapahtuvaan harjaantumiseen. Esimerkiksi teollisuuden prosesseja ohjataan janiiden käyttäytymistä seurataan suurelta osin erilaisten päätelaitteiden kautta.Prosessi-informaatio on siten luonteeltaan välittynyttä ja abstraktia, ei välitöntä

209

eikä konkreettista. Tämä tulee muuttamaan – ja on jo muuttanut – mm. monienteollisten ammattien luonnetta.

Zuboff kiinnittää huomiota myös siihen, miksi tietotekniikkaa yrityksiin oikeinhankitaan ja millaisia yleisiä mahdollisuuksia se yrityksille tarjoaa. Analyysiinsäperustuen Zuboff jakaa tietotekniikan potentiaaliset vaikutukset kahteen kategoriaan:

− Tietotekniikka mahdollistaa monien toimintojen automatisoinnin (auto-mating effect).

− Ttietotekniikka mahdollistaa monien työtehtävien informatisoinnin (infor-mating effect).

Puhuessaan tietotekniikan automatisoivasta vaikutuksesta Zuboff viittaa erityi-sesti toimistotyön luonteen muuttumiseen erilasten hallinnollisten tietojärjestel-mien käyttöönoton myötä. Hänen laaja aineistonsa antaa viitteitä siitä, että 1980-luvulla suurissa yhdysvaltalaisissa yrityksissä (mm. pankeissa ja vakuutusyh-tiöissä) toteutettujen suurten järjestelmäprojektien seurauksena toimihenkilöidentyön organisointi on saanut yhä enemmän fordistisia piirteitä. Hankkeiden ta-voitteena on ollut prosessien tehostaminen (esim. vakuutusyhtiössä korvausha-kemusten käsittelyn nopeuttaminen ja virheiden vähentäminen), ja tähän onpyritty keskittämällä työn suunnittelua ja standardisoimalla työprosessit niinpitkälle kuin se vain on ollut mahdollista. Zuboffin tutkimusten mukaan järjes-telmien käyttöönoton seurauksena työntekijöiden työtaakka on usein kasvanutsamalla kuin heidän toimenkuvansa on kaventunut. Useissa tapauksissa työnte-kijän ainoaksi tehtäväksi on muodostunut tietokoneohjelmaan sisäänrakennettu-jen rutiinien tarkka noudattaminen ja ohjelman vaatimien tietojen syöttäminen.

Tällaiset muutoshankkeet ovat useimmiten perustuneet ajatukseen ihmisistäepäluotettavina virhelähteinä. Looginen johtopäätös on siten pyrkiä ihmistentoimenkuvan rajaamiseen ja mahdollisimman tarkkaan määrittelyyn. Zuboffkäyttääkin näistä tuotantokoneiston osan asemaan alennetuista toimihenkilöistänimitystä the clerk as a laboring body (Zuboff, 1988, s. 136), mikä kuvaa hyvinautomatisoinnin kautta saavutettujen tehokkuusetujen inhimillistä hintaa. Tätähintaa ei makseta ainoastaan työn pakkotahtisuutena vaan myös ajan myötärapautuvana ammattitaitona: kun tietokone hoitaa kaiken ajattelun, niin toimi-henkilö menettää vähitellen myös merkittävän osan substanssiosaamisestaan.Tällainen kehitys heikentää edelleen hänen asemaansa työmarkkinoilla.

210

Näin ei kuitenkaan tarvitsisi välttämättä olla, sillä tietotekniikka tarjoaa myösmuunlaisia mahdollisuuksia. Automatisoinnin lisäksi tietotekniikka voi myösinformatisoida. Tietotekniikan informatisoivasta vaikutuksesta puhuessaanZuboff tarkoittaa sitä, että hyvin suunniteltu tietojärjestelmä voisi luoda edelly-tyksiä toimihenkilöiden toimenkuvan laajentamiselle ja työn mielekkyydenlisäämiselle. Tällöin tietojärjestelmän rooli olisi toimia ennemminkin työntekijänresurssina kuin toimenkuvaa rajaavana talutusnuorana. Tämän periaatteen mu-kaan toimivassa yrityksessä toimihenkilö ratkaisee asiakkaiden ongelmia jahyödyntää – mm. tietojärjestelmien avulla – yrityksen tietovarastoja huomatta-vasti tehokkaammin kuin mihin manuaalisella järjestelmällä voidaan ikinäpäästä. Rutiinitehtävien automatisoinnin ei siten tarvitse johtaa ihmisten suorit-tamien työtehtävien standardointiin. Zuboffin tutkimuksen tulos kuitenkin oli,että tietotekniikan informatisoivaa potentiaalia ei usein hyödynnetä.

Toimintaprosesseista tietojärjestelmien toiminnallisen laadun arvioimiseen

Tietojärjestelmien toiminnallista laatua voidaan lähteä arvioimaan joko toimin-taprosessien tai yksittäisten loppukäyttäjien näkökulmasta. Kummassakin ta-pauksessa arvioinnin lähtökohdaksi otetaan toiminnan tavoitteet ja reunaehdot,ja arvioinnin tavoitteeksi järjestelmän tarjoamien palveluiden tarkoituksenmu-kaisuuden ja luotettavuuden selvittäminen – menetelmät vain ovat erilaisia.Kattavan ja luotettavan arvioinnin tekeminen edellyttää todennäköisesti kum-mankin lähestymistavan käyttöä. Ensin mainittu prosessiorientoitunut lähesty-mistapa nojautuu systeemitekniikan (systems engineering) periaatteiden käyt-töön kun taas jälkimmäisestä käyttäjäorientoituneesta tavasta puhutaan useinkäytettävyystestauksena. Seuraavassa esitetään eräs tapa prosessiorientoituneenarvioinnin suorittamiseksi.

Prosessiorientoituneen arvioinnin erityistavoitteena on tunnistaa tietojärjestel-mien rooli organisaation toiminnan kokonaisuudessa. Tämä edellyttää toiminnanmallintamista, mikä voidaan tehdä esim. IDEF0-standardin mukaisesti tai jollainmuulla menetelmällä, joka mahdollistaa osaprosessien ja -tehtävien, ohjaustie-don, informaatio- ja materiaalivirtojen sekä resurssien kuvaamisen (IDEF0-standardin notaatio on esitetty tämän julkaisun VI artikkelissa). Usein on järke-vää keskittyä ns. kriittisten prosessien ja toimintojen sekä niihin liittyvien tieto-teknisten ratkaisujen tunnistamiseen. IDEF0-standardissa tietojärjestelmät voi-

211

daan mallintaa esim. resursseina (työtehtävässä hyödynnetään tietojärjestelmiä)tai prosesseina (automatisoitu prosessi eli ns. workflow).

Mallien taustalla oleva tieto hankitaan mm. haastattelemalla eri toiminnoistavastaavia henkilöitä. Erittäin tärkeää on pyrkiä muodostamaan realistinen kuvako. organisaation toiminnan luonteesta, toiminnan keskeisistä tavoitteista sekätoiminnan reunaehdoista.

Näin menetellen voidaan johtaa organisaation tavoitteisiin ja toiminnan arkipäi-vään maadoitettuja kriteereitä tietojärjestelmien toiminnallisen laadun arvioimi-seksi. Kriteerit liittyvät keskeisten informaatiovirtojen ja tiedonkäsittelypalve-luiden käytettävyyteen ja luotettavuuteen. Kriteereitä voidaan käyttää mm. uu-den järjestelmän vaatimusmäärittelyä laadittaessa tai käytössä olevien järjestel-mien toimintaa analysoitaessa. Systemaattinen mallinnus helpottaa myös järjes-telmien mahdolliseen käyttökunnottomuuteen tai uuden järjestelmän käyttöön-ottoon liittyvien riskien analysoimisessa.

10. Sovelluskohde: toiminnanohjausjärjestelmän käyttöönottoprosessi

Tässä toiminnanohjausjärjestelmän käyttöönottoprosessilla tarkoitetaan järjes-telmän koko elinkaarta nykytila-analyysista ja hankinnan suunnittelusta ainatuotantokäyttöön ja järjestelmän päivityksiin. Käyttöönottoprosessi voidaanjakaa vaiheisiin eri tavalla riippuen siitä, katsotaanko prosessia järjestelmätoi-mittajan vai loppuasiakkaan näkökulmasta (ks. myös tämän julkaisun I artikkelinelinkaarimallit). Lisäksi eri toimittajilla (kuten myös suurimmilla loppukäyttäjä-yrityksillä) on omia, osittain toisistaan poikkeavia malleja ja käytäntöjä.

Käyttöönottoprosessin rakenne

Seuraavassa toiminnanohjausjärjestelmän käyttöönottoprosessi on jaettu neljäänpäävaiheeseen, joista jokainen koostuu useammasta tehtävästä. Mallia ei tulekäsittää käyttöönottoprosessin ideaalimalliksi vaan erilaisten käyttöönottopro-sessin tavoitemallien ja käytäntöjen yleistykseksi. Mallin tarkoituksena on tässäyhteydessä muodostaa konteksti tietojärjestelmien tuottavuuden ja vaikuttavuu-den arviointimenetelmien käytön ideoinnille.

212

Käyttämämme mallin päävaiheet ovat suunnittelu, hankinta, käyttöönotto jatuotantokäyttö. Tehtävät noudattelevat suurelta osin (mutta eivät täysin vastaa)Suomen Tuotannonohjausyhdistyksen raportissa esitettyä jaottelua (STO, 1999).Käyttöönottoprosessimallin rakenne on esitetty taulukossa III.

Taulukko III. Käyttöönottoprosessin päävaiheet ja tehtävät.

Päävaihe Tehtävätsuunnittelu nykytila-analyysi,

tavoitetilan määrittely,vaatimusmäärittely

hankinta markkinakatsaus,valintakriteerien täsmentäminen,ohjelmiston ja toimittajan valinta,järjestelmän mitoitus,sopimusneuvottelut

käyttöönotto käyttöönotto-organisaation perustaminen,käyttöönottosuunnitelman laadinta,laitteiden ja ohjelmistojen asennus,perusjärjestelmän konfigurointi,mahd. räätälöinti (muutokset ohjelmakoodiin),linkkien rakentaminen muihin sovelluksiin,tuotantotiedon luominen,käyttöohjeiden laatiminen,käyttäjien koulutus,toimintatapamuutosten valmistelu,toimituksen testaus,uuden järjestelmän sisäänajo,käyttöönotto-organisaation purkaminen

tuotantokäyttö perusliiketoiminta,järjestelmän käytön seuranta,ongelmien ja kehittämistarpeiden dokumentointi

Käyttöönottovaiheen tehtävistä suuri osa etenee ainakin osittain päällekkäin jamahdollisesti eri järjestyksessä. Päävaiheiden järjestys on sen sijaan kiinteä.

Järjestelmän muutokset voidaan hahmottaa erillisenä, viidentenä päävaiheena.Sen tehtävät koostuvat soveltuvin osin suunnittelu-, hankinta- ja käyttöönotto-vaiheiden tehtävistä (esim. vaatimusmäärittelyn päivitys, laajennustarpeen mää-rittely, uusien ohjelmistokomponenttien hankinta jne.). Järjestelmän käyttöön-oton prosessimalli on esitetty kuvassa 4, jossa järjestelmän muutostöitä ja päivi-tyksiä kuvaa tuotantokäytön takaisin strategiaprosesseihin ja suunnitteluun yh-distävä luuppi.

213

Järjestelmän tuottavuuden ja vaikuttavuuden arviointi osana käyttöönottopro-sessia

Kuva 4 pyrkii havainnollistamaan käyttöönottoprosessin etenemistä sekä järjes-telmän tuottavuuden ja vaikuttavuuden arviointiprosessin mahdollista rooliakäyttöönoton eri vaiheissa. Perusidea on, että arviointiprosessilla ei ainoastaanseurata käytössä olevien järjestelmien tuottavuutta vaan myös aktiivisesti vai-kutetaan koko tietojärjestelmäprojektin lopputulokseen. Tällöin olisi kyettäväluomaan tarpeeksi yksinkertainen, tehokas ja luotettava menettelytapa järjestel-mien suunnittelu- ja hankintavaiheiden tukemiseksi tuottavuus- ja vaikuttavuus-arvioiden avulla. Järjestelmän hankinnasta koituvien hyötyjen ja kustannustentasapainoinen punninta olisi erityisen tärkeää silloin, kun hankintapäätös ontaloudellisesti mittava ja/tai kun järjestelmän hankinta vaikuttaa merkittävällätavalla organisaation toimintaan tai tulevaisuuden toimintaedellytyksiin.

Arvioinneissa suureksi ongelmaksi muodostuu luotettavien perustietojen puut-tuminen: esimerkiksi toiminnanohjausjärjestelmän todellisia toiminnallisia hyö-tyjä on vaikea arvioida, jos vastaavista hankkeista ei ole aikaisempaa kokemusta.Perustietoja on vain lähdettävä metsästämään systemaattisesti: ensin omastaorganisaatiosta ja aiemmista tietojärjestelmähankkeista saaduista opeista. Tämänjälkeen on luontevaa pyrkiä perehtymään muiden organisaatioiden kokemuksiinsekä alan tieteellisissä julkaisuissa raportoituihin (empiirisiin) tutkimuksiin.Benchmarking voisi olla erinomainen ja suhteellisen taloudellinen tapa hankkiatuottavuus- ja vaikuttavuusarvioinneissa tarvittavaa perustietämystä. Tätä edel-lyttää vain sitä, että vähintään kaksi organisaatiota/yritystä on valmis keskenäänjakamaan omien tietojärjestelmähankkeiden valmisteluun ja toteutukseen sekäjärjestelmien käyttöön liittyvää tietoa.

214

HANKINTA KÄYTTÖÖN-OTTO

TUOTANTO-KÄYTTÖ

STRATEGIAPROSESSIT, KONSEPTISUUNNITTELU, JOHTAMINEN

TUOTTAVUUDEN JA VAIKUTTAVUUDEN ARVIOINTIPROSESSI

Mitä

arv

ioid

aan

Arvioinnin tulokset, feedback

ohjaa ohjaa ohjaa ohjaa

tukee

SUUNNITTELU

tukee tukeeseuranta-

tietoja

ERP:n käyttöönottoprosessi

Muutokset olemassa olevaan järjestelmään

Informaatiovirtoja

Kuva 4. Tuottavuuden ja vaikuttavuuden arvioiminen osana toiminnanohjaus-järjestelmän käyttöönottoprosessia ja käyttöä.

Varsinainen käyttöönottovaihe (mm. uuden järjestelmän asennukset, koulutus,sisäänajo jne.) ei ole järjestelmien tuottavuuden tai vaikuttavuuden arvioimisenkannalta kovinkaan kiinnostava, sillä ratkaisevat hankintapäätökset on jo tehtymutta varsinaisia käyttökokemuksia ei ole vielä saatavilla. Tässä vaiheessa onkuitenkin mahdollista kerätä tietoja järjestelmän sisäänajon todellisista kustan-nuksista (esim. henkilöstön koulutuksen ja tuotantotiedon luomisen vaatimastalisätyöstä), joita järjestelmätoimittajan tarjoamat laskelmat eivät todennäköisestisisällä. Tuotantokäytön aikana on sitten aika kerätä käyttökokemuksia, joihinjärjestelmän tulevat laajennukset ja päivitykset myöhemmin perustuvat ja jotkaluovat entistä vankemman pohjan uusien tietojärjestelmähankkeiden valmiste-

215

lulle tulevaisuudessa. Keskeistä on verrata järjestelmän suorituskykyä sille ase-tettuihin tavoitteisiin, kirjata havainnot huolellisesti ylös ja jalostaa kokemuksetkonkreettisiksi toimenpidesuosituksiksi.

Tietojärjestelmien tuottavuuden ja vaikuttavuuden arviointi syö varmasti paljonvoimavaroja, mikäli se pyritään tekemään huolellisesti ja luotettavasti. Jokaisenorganisaation on itse arvioitava, kuinka paljon tällaiseen toimintaan kannattaapanostaa. Joka tapauksessa arviointiprosessin tulee kytkeytyä kiinteästi organisaa-tion muihin prosesseihin ja toimintoihin, jotta sen tuottamat tiedot saadaan hyöty-käyttöön. Tämän varmistaminen on viime kädessä yrityksen johdon vastuulla.

11. Tiivistelmä ja johtopäätökset

Yritykset käyttävät tietotekniikkaan ja sen erilaisiin tukipalveluihin valtaviarahamääriä. Monet tutkijat ja yritysjohtajat ovat väittäneet, että tälle rahalle eisaada täyttä vastinetta. 1980-luvun lopussa nämä näkemykset tiivistyivät ns.tietotekniikan tuottavuusparadoksiksi kun havaittiin, että tietotekniikkainves-tointien koon ja yritysten tuottavuuden ja/tai taloudellisen tuloksen välillä eiollut selkeää tilastollista yhteyttä. Tämän jälkeen asiasta on väitelty paljon, jauusia tutkimuksia on tehty. Nykyään ollaan melko yleisesti sitä mieltä, ettätietotekniikka nostaa yritysten tuottavuutta useilla toimialoilla. Näin ei tosin käyautomaattisesti: oleellista on, että järjestelmähanke on oikein mitoitettu ja ajoi-tettu ja että se liittyy kiinteästi yrityksen liiketoiminnan kehittämiseen.

Tuottavuuden käsite on tietotekniikkamaailmassa problemaattinen. Eri lähteissätuottavuus määritellään eri tavalla, tai sitä ei määritellä ensinkään. Tämä vai-keuttaa tutkimustulosten vertailua ja hyödyntämistä. Tässä artikkelissa tuotta-vuudella tarkoitetaan tietojärjestelmähankkeen tuoman taloudellisen hyödyn jasen vaatiman panostuksen suhdetta. Tuottavuuden arvioiminen edellyttää sitenhankkeen hyötyjen ja kustannusten tunnistamista ja rahamääräistä arviointia.Asian tekee vaikeaksi se, että monet hyödyt ja kustannukset ovat luonteeltaanlaadullisia, yrityksen toimintaan tai toimintaedellytyksiin liittyviä tekijöitä.

Tietojärjestelmähankkeisiin liittyvien potentiaalisten hyötyjen ja kustannustenkirjo on laaja. Hyötypuolella tietojärjestelmät yhtäältä tukevat ja tehostavat joolemassa olevia toimintoja, toisaalta mahdollistavat kokonaan uudenlaisia (lii-ke)toiminnan muotoja. Yrityksen tuotteista, palveluista, toimialasta ja toiminnan

216

luonteesta kuitenkin riippuu, millaista hyötyä se voi tietotekniikasta saada. Ta-loudellisilla mittareilla mitattuna hyödyt puolestaan ilmenevät joko säästöinä tailisätuloina. Kustannuksia kertyy puolestaan sekä tietojärjestelmien hankinnasta(esim. lisenssimaksut) että käyttöönoton ja uusien toimintatapojen opettelunvaatimasta lisätyöstä. Näitä jälkimmäisiä kutsutaan usein piilokustannuksiksi,koska niihin ei tavallisesti liity (välitöntä) kassavirtaa. Piilokustannukset reali-soituvat tavallisesti vasta pidemmällä aikajänteellä, esimerkiksi silloin kun pe-rusliiketoiminnan häiriöt alkavat vaikuttaa asiakashankintaan, tuotantoon ja/tailaskutukseen.

Yleensä vain suoraan järjestelmien hankinnasta koituvat kustannukset voidaanlaskea tarkasti, ja nekin usein vasta sen jälkeen kun järjestelmätoimittaja onlähettänyt viimeisen laskunsa. Piilokustannusten arvioiminen onkin jo huomat-tavasti hankalampaa, sillä laskelman tulos riippuu oleellisesti tarkasteluvälistä.Jos esimerkiksi asiakaspalveluprosessi on takkuillut uuden järjestelmän käyt-töönoton yhteydessä, niin usein vasta tulevaisuus näyttää, millainen merkityssillä on ollut yrityskuvaan ja tuotteiden menekkiin.

Sama pätee myös monien potentiaalisten hyötyjen arvottamiseen. Toiminnantehostaminen sekä tuotteiden ja palveluiden laadun parantaminen ovat esimerk-kejä tietojärjestelmän käyttöönoton tarjoamista potentiaalisista hyödyistä, joidenrealisoiminen (muuttaminen lisätuloiksi) edellyttää syntyneen lisäpotentiaalinjärkevää ja onnistunutta hyödyntämistä. Tämänkaltaisten hyötyjen muuntaminenrahamääräiseksi on hankalaa myös siksi, että jokaisen yrityksen tuloskuntolukuisten eri tekijöiden summa (myynti saattaa riippua esim. valuuttakurssienmuutoksista, joilla ei ole mitään tekemistä tietojärjestelmien toiminnallistenominaisuuksien kanssa). Ja kun hyötyjä ja kustannuksia ei voida tarkkaan laskea,on myös järjestelmähankkeen tuottavuuden arvioiminen hankalaa.

Mitä suurempi ja kalliimpi tietojärjestelmähanke on kyseessä, sitä tärkeämpääolisi pyrkiä muodostamaan mahdollisimman luotettava kuva eri vaihtoehtoihinliittyvistä hyödyistä ja kustannuksista, sekä koko hankkeen vaikutuksista yrityk-sen toimintaan yleensä. Keskeinen tulevaisuuden haaste on siten kehittää tieto-järjestelmien tuottavuuden ja vaikuttavuuden arviointimenetelmiä, joita tavallisetyritykset voisivat käyttää esimerkiksi uusien tietojärjestelmähankkeiden suun-nittelun tukena. Tällä hetkellä luotettavia ja helppokäyttöisiä menetelmiä einäytä olevan saatavilla, eikä sellaisia tietojärjestelmien luonteesta johtuen ehkä

217

koskaan pystytä edes kehittämään. Itse ongelma tulee kuitenkin olemaan ajan-kohtainen myös tulevaisuudessa, sillä tietojärjestelmähankkeiden koon jakompleksisuuden kasvu ei tunnu olevan rajoitettavissa. Toiminnanohjausjärjes-telmä tänään, toiminnanohjausjärjestelmien verkosto huomenna, ylihuomenna ...who knows?

Lähdeluettelo

Anandarajan, A. & Wen, H. 1999. Evaluation of information technology invest-ment. Management decision, 37/4, s. 329–337.

Brynjolfsson, E. 1993. The productivity paradox of information technology.Communications of the ACM, 36(12), s. 67–77.

Greenwood, J. 1997. The third industrial revolution: Technology, productivity,and income inequality. Working paper. Rochester Center for Economic Re-search, University of Rochester.

Holopainen, S., Lillrank, P. & Paavola, T. 1999. Tietotekniikan linkki liiketo-imintaan. Otava.

Keen, P. 1981. Information systems and organizational change. Communicationsof the ACM, 24, s. 24–33.

Luoma, J., Muhonen, T. & Huomo, T. 1999. Uudistuva tietotekniikka-arkkitehtuuri. HM&V Research Oy.

Markus, M. 1983. Power, politics, and MIS implementation. Communications ofthe ACM, 26, s. 430–445.

STO 1999. Toiminnanohjausohjelmiston hankinta ja markkinoiden nykytilanne.STO-työryhmäraportti. Suomen Tuotannonohjausyhdistys ry.

Strassmann, P. 1990. The business value of computers. New Canaan: The In-formation Economic Press.

218

The Information Paradox 1998. Realizing the business benefits of informationtechnology. Toronto: McGraw-Hill.

Walsham, G. 1992. Management science and organisational change: A frame-work for analysis. Omega, 20(1), s. 1–9.

van Nievelt, M. C. 1999. Bechmarking organisational and IT performance. In: L.Willcocks & S. Lester (Eds.), Beyond the IT productivity paradox. Chichester:John Wiley & Sons. S. 99–119.

Willcocks, L. & Lester, S. 1999a. Information technology: Transformer or sinkhole? In: L. Willcocks & S. Lester (Eds.), Beyond the IT productivity paradox.Chichester: John Wiley & Sons. S. 1–36.

Willcocks, L. & Lester, S. 1999b. In search of information technology produc-tivity: Assessment issues. In: L. Willcocks & S. Lester (Eds.), Beyond the ITproductivity paradox. Chichester: John Wiley & Sons. S. 69–97.

Zuboff, S. 1988. In the age of the smart machine. The future of work and power.New York: Basic Books.

219

JohtopäätöksetTässä julkaisussa on tarkasteltu yritysten toiminnanohjausta, toiminnanohjaus-järjestelmiä, tietojärjestelmien suunnittelu- ja käyttöönottoprosesseja sekä niitätukevia menetelmiä ja käytäntöjä monesta eri näkökulmasta. Keskeisellä sijallaovat olleet pk-yrityksen toiminnanohjaus ja sen tietojärjestelmät. Keskeisenätavoitteena on ollut kuvata, mitä em. aihealueista tällä hetkellä tiedetään, millai-sia haasteita ja ongelmia pk-sektorin toiminnanohjaukseen ja tietojärjestelmä-hankkeisiin liittyy ja mitä näiden haasteiden voittaminen käytännössä edellyttää.Perusproblematiikan voisi tiivistää seuraavaan kahteen kysymykseen:

1. Millainen toiminnanohjausjärjestelmän suunnittelu- ja käyttöönottoprosessintulisi pk-yrityksessä olla, kun verrattain rajatuilla resursseilla olisi kyettävämäärittelemään ja ottamaan käyttöön monimuotoista toimintaa tehokkaasti tuke-va järjestelmä?

2. Miten järjestelmätoimittaja pystyy parhaiten tukemaan pk-yritystä järjestel-män käyttöönottoprosessissa?

Julkaisun lähestymistapa näihin kysymyksiin on ollut yhtäältä teoreettinen,toisaalta empiirinen. Teoreettisissa artikkeleissa kysymyksiä on lähestytty aihe-aluetta käsittelevän kirjallisuuden valossa (esim. III ja VIII artikkelit), osa artik-keleista perustuu ensisijaisesti tutkijoiden omiin kokemuksiin tietojärjestelmä-hankkeiden suunnittelusta ja toteutuksesta (esim. V artikkeli), ja osa on yhdis-telmiä näistä kahdesta päätyypistä (esim. VI ja VII artikkelit).

Monessa julkaisun artikkelissa todetaan, että pk-yritysten toiminnanohjauksenproblematiikasta on olemassa hyvin vähän tutkimustietoa. Tietoa on yhtäältätoiminnanohjauksesta ja organisaatioiden kehittämisestä, toisaalta tietojärjestel-mien määrittelystä ja käyttöönottomalleista, mutta ei yleensä yksissä kansissaeikä varsinkaan pk-yrityksen näkökulmasta. Artikkelien yhteinen sanoma on se,että tietojärjestelmien käyttöönottoprosessien kehittämiseen on syytä panostaanykyistä enemmän sekä pk-yrityksissä että järjestelmätoimittajien taholta. Lisäk-si on syytä olettaa, että tietojärjestelmien roolin kasvaessa käyttöönottoprosessinmerkitys tulee entisestään korostumaan.

220

Tietojärjestelmät ja pk-yritykset – trendejä, mahdollisuuksia ja uhkia

Vallitseva kehitystrendi on, että tietojärjestelmien rooli pk-yrityksissä ja vastaa-vissa organisaatioissa kasvaa. II artikkelissa kuvataan, miten nykyiset toimin-nanohjausjärjestelmät ovat kehittyneet 1970-luvun materiaalinohjauksen jaresurssienhallinnan sovelluksista. Yhdessä taloushallinnon kanssa nämä olivatniitä alueita, joissa automaattisesta tietojenkäsittelystä havaittiin olevan enitenhyötyä. Kolmekymmentä vuotta myöhemmin toiminnanohjausjärjestelmällävoidaan kattaa lähes kaikki yrityksen toiminnan eri osa-alueet. Tietotekniikkaakäytetään yhä enemmän välineenä myös ihmisten ja organisaatioiden välisessäkommunikoinnissa. Sähköposti ja Internet ovat jo arkipäivää monessa pienessä-kin yrityksessä.

Tähän kehityskulkuun liittyy sekä mahdollisuuksia että uhkia. Yhtäältä tietotek-niikasta on todettu olevan hyötyä rutiinien tehostajana. Sen on havaittu myösmahdollistavan aivan uusia (liike)toiminnan muotoja, hyvänä esimerkkinä ver-kossa toimivat matkatoimistot ja pankkipalvelut. Toisaalta se sitoo yrityksiäohjelmistoihin sisäänrakennettuihin toimintamalleihin, jotka saattavat muodos-tua rasitteiksi joustavuutta korostavilla markkinoilla. Tämä pätee erityisestiraskaisiin ja alun alkaen suuryritysten tarpeisiin suunniteltuihin toiminnanoh-jausjärjestelmiin, kun loppukäyttäjäorganisaationa on monimuotoisessa ympä-ristössä toimiva ja joustavuudella kilpaileva pk-yritys. Suuret järjestelmähank-keet ovat myös kalliita ja siten erityisen riskialttiita pk-yrityksille.

On myös ilmeistä, että tietojärjestelmien kokonaisuudet tulevat koko ajan yhämonimutkaisemmiksi. Osasyynä tähän on järjestelmien kasvava integraatio.Perinteisessä toiminnanohjausjärjestelmässä eri osasovellukset kytketään yhtei-sen tietokannan välityksellä toisiinsa. Suurissa järjestelmissä, kuten SAP R/3,osasovelluksia (moduuleja) on useita kymmeniä. Kun yrityksessä käyttööntulevien osasovellusten määrä ja keskinäiset riippuvuudet kasvavat, tulee tieto-järjestelmän rakenne yhä monimutkaisemmaksi. Uusin tietotekninen kehitys vietietojärjestelmien integraation vielä askelta pidemmälle, kohti yritysten välisiäintegroituja järjestelmiä. On odotettavissa, että myös tämä kehityssuunta tarjoaapk-yrityksille sekä mahdollisuuksia että uhkia, riippuen yritysten toimialasta,toiminnan luonteesta sekä valmiuksista.

221

Yhtäältä uusin tietotekniikka tukee yritysten keskinäistä (b2b) sekä yritysten jaloppuasiakkaiden välistä (b2c) verkostoitumista. Pienet resurssit omaavalle pk-yritykselle tämä on eittämättä mahdollisuus. Kokemukset kuitenkin osoittavat,että mitä monimutkaisemmasta järjestelmien ja toimintojen kokonaisuudesta onkysymys, sitä haastavampi on määrittely- ja käyttöönottoprosessi. Potentiaaliteivät takaa käyttöönoton onnistumista. Monimutkaisten järjestelmien ominai-suuksista jää myös suurempi osa hyödyntämättä mm. siksi, että loppukäyttäjäteivät ole niistä tietoisia, tai siksi, että niihin perehtyminen koetaan usein liiantyölääksi. Järjestelmien laajetessa myös järjestelmien käyttöönottoympäristömuuttuu. Enää ei riitä, että yksi tai muutama henkilö oppii ymmärtämään jakäyttämään tiettyä sovellusta vaan asiaa on tarkasteltava usean toiminnon ja yhälaajeneva käyttäjäkunnan erilaisista näkökulmista, käyttäjäkunnan, joka koostuuerilaisen koulutus- ja osaamistaustan omaavista ihmisistä, joiden vastuualueet jaintressit poikkeavat huomattavasti toisistaan. Tämä asettaa erityisiä vaatimuksiajärjestelmien suunnittelu- ja käyttöönottoprosesseille.

Suunnittelun ja käyttöönoton haasteita ja ongelmia pk-yrityksissä

Tietojärjestelmän käyttöönottoprosessi pk-yrityksessä eroaa suuryrityksen vasta-vasta prosessista merkittävästi – ei ainoastaan laajuudeltaan vaan usein myöslaadullisesti. Tähän on kolme keskeistä syytä: pk-yritysten toiminnan luonne jatoimintatavat, resurssien rajallisuus ja osaamispohjan kapeus. Tämä voi muo-dostua ongelmaksi erityisesti laajojen toiminnanohjausjärjestelmien käyttöön-otossa, missä asiakasyrityksen omalla panoksella on aivan keskeinen merkityshankkeen onnistumisen kannalta.

Vaikka harva pk-yritys itse toimi kansainvälisillä markkinoilla, on yhä useampiniistä riippuvainen globaalisti toimivan päämiehen takia. Pk-yrityksen menesty-misen kannalta on oleellista, kuinka nopeasti yritys pystyy tunnistamaan mark-kinoilla tapahtuvia muutoksia, kuinka nopeasti se pystyy niihin reagoimaan jakuinka oikeansuuntaisia valitut toimenpiteet ovat. Käytännössä moni pk-yritystekee monenlaisia tuotteita ja palveluja yksittäiskappaleina tai lyhyinä sarjoina.Tämän seurauksena yhden yrityksen sisällä on monenlaista toimintaa, ja toi-minta muuttuu (markkinoiden paineessa) jatkuvasti. Tällöin toiminnan organi-sointi ja ohjaus perustuvat enemmän henkilökunnan osaamiseen ja ammattitai-toon kuin suuryrityksissä käytettyihin formaaleihin menetelmiin, rakenteisiinja/tai sääntöihin. Pk-yritykset eivät siis toimi yhtä säännönmukaisesti kuin

222

useimmat suuryritykset. Myös toiminnan kuvaamiseen käytettävä kieli (termit jakäsitteet) on monesti omintakeista ja epäteoreettista, arkipäivän toimintaympä-ristöstä nousevaa puhetta.

Tämän seurauksena järjestelmien määrittely ja konfigurointi on pk-yrityksissämonesti hankalaa. Suurten toiminnanohjausjärjestelmien toimintalogiikan taus-talla olevat liiketoiminnan prosessimallit sopivat harvoin sellaisenaan pk-yritysten tarpeisiin. Tämä johtuu yhtäältä siitä, että rajallisten resurssien johdostapk-yrityksen toiminta on pakosti epämuodollista ja työntekijät joutuvat teke-mään mitä erilaisimpia tehtäviä, jolloin määrämuotoisia prosesseja ei käytännös-sä ole tai niitä on vaikea hahmottaa. Toisaalta vain harvassa pk-yrityksessäomaa toimintaa analysoidaan toimintaprosessien mallintamisen näkökulmasta,joten koko ajattelutapa saattaa olla yrityksen työntekijöille vieras. Määrittely-työn tuloksena pitäisi kuitenkin päästä malliin, jonka kanssa dynaamisesti jadynaamisilla markkinoilla toimiva pienyritys voi elää.

Koska pk-yritykset elävät jatkuvassa muutoksen tilassa, muutosta ei useinkaannähdä erillisenä toimintana vaan se on osa operatiivista toimintaa: ongelmatratkaistaan sitä mukaa kun ne tulevat eteen. Tyypillisesti mm. tietotekniikkaanliittyvät asiat hoidetaan oman toimen ohella, tai vastaavat palvelut ostetaanulkoa. Tietojärjestelmien käyttöönotossa tämä kostautuu. Monessa artikkelissatodetaan, että pk-yrityksissä törmätään tietojärjestelmien käyttöönotossa resurs-siongelmiin, koska vähäiset henkilöresurssit on sidottu operatiiviseen toimin-taan. Pk-yritysten on myös vaikea kompensoida tätä vajetta esim. palkkaamallaulkopuolisia asiantuntijoita tietojärjestelmähankkeiden toteutukseen, sillä resurs-siongelmat koskettavat usein myös yritysten taloutta.

Monilla pk-yrityksillä on puutteita myös tietotekniikan osaamisen ja soveltami-sen suhteen. Teknologian kehitystä on vaikea seurata, ja erilaisten teknologioi-den soveltuvuutta yrityksen tarpeisiin on vaikea arvioida. Tämä tarkoittaa mm.sitä, että pk-yrityksen saattaa olla vaikea tunnistaa tietotekniikan tuomia mah-dollisuuksia liiketoiminnan näkökulmasta. Toisinaan tietojärjestelmän määritte-lyn ja liiketoiminnan suunnittelun välillä olevia kytkentöjä ei edes tiedosteta. Javaikka nämä usein tiedostetaankin, niin harvalla pk-yrityksellä on tarpeeksiosaamista tietojärjestelmän vaatimusmäärittelyn laatimiseksi yrityksen liiketoi-minnan tavoitteiden pohjalta. Tilanne avaa uusia mahdollisuuksia taitavillemarkkinamiehille, joiden puheessa jokaiseen mahdolliseen ja mahdottomaankin

223

ongelmaan löytyy aina tietotekninen ratkaisu. Tietojärjestelmän hankinnassatämä saattaa johtaa mm. epärealistisiin tavoitteisiin ja odotuksiin, kun kykyhankkeiden mahdollisuuksien ja riskien tasapainoiseen ja kriittiseen punnintaanpuuttuu.

Pk-yrityksen osaamisen rajallisuus näkyy myös itse käyttöönottoprosessissa.Tarvittavia voimavaroja on vaikea arvioida, osaavista tekijöistä on puutetta jayhteinen kieli järjestelmätoimittajan kanssa usein puuttuu. Yritys jää tällöinhelposti järjestelmätoimittajien ammattilaisten vietäväksi. Tuloksena tällaisessatapauksessa on teknispainotteinen toimitusprojekti, jossa toiminnan ja toiminta-prosessien kehittäminen jää suurella todennäköisyydellä teknisen järjestelmänasennuksen, konfiguroinnin ja testauksen jalkoihin. Ongelmat alkavat, kun jär-jestelmä pitää ajaa sisään yrityksen arkipäivän toimintaan: peruskäyttäjät pur-naavat, tietoja hukkuu ja prosessit ”tökkivät”.

Pk-yritysten toiminnan erikoispiirteiden vuoksi järjestelmätoimittajat ovat viimevuosina kehittäneet uusia toiminnanohjauksen ratkaisuja erityisesti pk-sektorintarpeisiin. Eräs realistinen tietojärjestelmäratkaisu pk-yritykselle on paketoitutuoteratkaisu, joka voi olla joko standardoitu vakiotuote tai vaihtoehtoisesti ns.esikonfiguroitu järjestelmäratkaisu. Ensimmäisessä tapauksessa yrityksen odo-tetaan ottavan järjestelmän käyttöön sellaisenaan (ohjelman toimintalogiikkaa eimuuteta), jälkimmäisessä taas osa järjestelmän toiminnallisista ominaisuuksistaon toimituksen nopeuttamiseksi määritelty valmiiksi ja osa määritellään yhdessäasiakasyrityksen kanssa. Kummassakin tapauksessa vaatimusmäärittelyssä kes-kitytään yrityksen tavoitteiden ja tarpeiden kartoitukseen sekä järjestelmän tär-keimpien vaatimusten määrittelyyn.

Paketoidun tuoteratkaisun houkuttelevuus pk-sektorilla perustuu nimenomaankustannussäästöihin: jos paketti sopii yrityksen tarpeisiin sellaisenaan tai pieninmuutoksin tarpeeksi hyvin, säästetään paljon työtä (konsultointia ja räätälöintiä)ja siten myös rahaa. Hankkeen onnistumisen kannalta keskeisessä asemassa onns. soveltuvuusanalyysi, jolla tutkitaan yrityksen vaatimusten sekä markkinoillaolevien ratkaisujen yhteensopivuutta. Soveltuvuusanalyysi tehdään usein järjes-telmätoimittajan toimesta, joka tuntee edustamansa järjestelmän ominaisuudethyvin. Järjestelmän valinnassa keskitytään muutamaan tärkeäksi koettuun omi-naisuuteen. Lopputulos ei voi tietenkään toimia yhtä hyvin kuin yrityksen tarpei-

224

siin sovitettu räätälöity järjestelmä mutta parhaimmillaan paketoidut tuoteratkai-sut tarjoavat paljon hyödyllisiä ominaisuuksia suhteellisen edulliseen hintaan.

Vaatimuksia ja onnistumisen edellytyksiä

Pk-sektorin haasteiden ja ongelmien lisäksi julkaisun artikkeleissa on nostettuesiin asioita – mm. toimintatapaideoita, malleja, menetelmiä ja vaatimuksia –joilla pk-yritys voisi paremmin hallita toiminnanohjausjärjestelmien käyttöön-ottoa. Seuraavassa nämä on ryhmitelty viiteen osa-alueeseen.

1. Yrityksen on ymmärrettävä järjestelmäinvestoinnin vaativuus ja vaikuttavuus.Laajan toiminnanohjausjärjestelmän kohdalla kysymys ei ole vain ohjelmistonhankinnasta ja asentamisesta. Käyttöönotto tuo mukanaan paljon työtä vaati-musmäärittelyn, järjestelmän konfiguroinnin, tietokantojen rakentamisen, hen-kilökunnan koulutuksen ja toimintatapojen muutoksen myötä. Näiden ns. piilo-kustannusten takia investoinnin vaatima kokonaispanos on merkittävästi suu-rempi kuin mitä laitteiden, ohjelmistolisenssien ja konsultoinnin hinnaksi muo-dostuu. Yrityksen olisi kyettävä muodostamaan realistinen mielikuva hankkeenvaativuudesta sekä varauduttava siihen joka suhteessa jo etukäteen. Toinenkeskeinen seikka on hankkeen vaikuttavuus. Usein tällaisen investoinnin kuo-lettaminen edellyttää suoria kustannussäästöjä laajempia liiketoiminnallisiahyötyjä. On ymmärrettävä tietotekniikan tuomia mahdollisuuksia ja arvioitavaniiden realisoimisen edellytyksiä. Liiketoiminnan tasolla asetettujen tavoitteidentulee merkittävällä tavalla ohjata tietojärjestelmän määrittelyä ja suunnitteluasekä käyttäjien koulutusta ja organisaation toiminnan kehittämistä.

2. Huolellinen vaatimusmäärittely on järjestelmähankkeen onnistumisen perus-edellytyksiä. Vaatimusmäärittelyn tärkeimpänä tehtävänä on täsmentää, millaisiatoiminnallisia ominaisuuksia hankittavalla tietojärjestelmällä tulee olla. Vaati-musmäärittelyn teko edellyttää ihmisten, organisaation ja liiketoiminnan tarpei-den tunnistamista, poimintaa ja kypsyttelyä ennen kuin niistä saadaan johdettuavalmiita ja oikeaan osuvia vaatimuksia. Vaatimusmäärittely tulee tehdä riippu-matta siitä, ollaanko hankkimassa standardijärjestelmää, esikonfiguroitua paket-tiratkaisua, täyden kokoluokan toiminnanohjausjärjestelmää vai yrityksen tarpei-siin täysin räätälöityä erikoissovellusta. Vaatimusmäärittely muodostaa pohjanmarkkinoilla olevien vaihtoehtojen tutkiskeluun ja vertailuun. Paketoitujentuoteratkaisujen kohdalla soveltuvuusanalyysi on tarpeellinen välivaihe ennen

225

hankintapäätöksen tekoa. On myös hyvä tehdä ero järjestelmävaihtoehtojen jatoimittajavaihtoehtojen välillä: luotettava ja ammattitaitoinen järjestelmätoimit-taja on avainasemassa järjestelmähankkeen onnistumisen kannalta.

3. Tietojärjestelmän käyttöönotossa konfiguroidaan järjestelmää ja kehitetäänorganisaatiota. Toiminnanohjausjärjestelmän käyttöönottoprosessissa edetäänkohti tavoitetilaa, jossa organisaation toiminta ja järjestelmän toiminnallisetominaisuudet kohtaavat. Ennen tavoitteen asetantaa yrityksellä tulisikin ollarealistinen kuva siitä, mihin järjestelmä ”taipuu” ja millaiset toimintatavat ja -prosessit se mahdollistaa. Kun tavoitetila on asetettu, edetään siihen yhtäältäjärjestelmää konfiguroimalla ja toisaalta henkilökuntaa kouluttamalla, prosessejamuokkaamalla ja vastuualueita täsmentämällä. Keskeistä on näiden kahdenpäälinjan vuorovaikutus, jonka merkitystä ei voi kylliksi korostaa. Vaikka useinpuhutaankin sen puolesta, että organisaation toimintaa tulisi suunnitella ja ke-hittää tietojärjestelmistä riippumatta (idea: tietojärjestelmät rakennetaan myö-hemmin valittua toimintatapaa tukeviksi), niin toiminnanohjausjärjestelmiensuhteen tämä ei ole käytännössä mahdollista. Syy: järjestelmien sisään raken-nettujen ominaisuuksien vuoksi joudutaan tekemään kompromisseja, koskakaikkea ei voi tai ei kannata muuttaa.

4. Tietojärjestelmän käyttöönotto on organisatorinen oppimisprosessi. Tietojär-jestelmän teknisen toteutuksen jälkeen - ja jo osittain sen aikana - alkaa ns.organisatorinen käyttöönotto, jossa organisaatio totuttelee elämään uuden jär-jestelmän kanssa. Yhtäältä järjestelmä asettaa uusia vaatimuksia, toisaalta seantaa uusia mahdollisuuksia. Näiden rajoitteiden ja mahdollisuuksien pohjaltakäyttäjille muodostuu vähitellen uusia toimintamalleja, ts. tapoja, joilla järjes-telmän kanssa operoidaan. Toimintamallien muodostumista voi kuvata myösoppimisprosessiksi, johon osallistuu vähintään kaksi organisaatiota: järjestelmänhankkija ja toimittaja. Molemmilla on oma roolinsa prosessissa ja molemmillaon mahdollisuus oppia uutta. Järjestelmätoimittajan kohdalla tämä tarkoittaamm. toimitusprojektista saatujen kokemusten ja järjestelmän käyttäjiltä saadunpalautteen prosessointia. Oppimisprosesseja pitää kuitenkin tukea. Eräs keinosiirtää tietoa organisaatiossa ja organisaatioiden välillä on muodostaa keskeistensidosryhmien edustajista koostuvia kehitysryhmiä. Kehitysryhmien ideana onsaattaa käyttöönoton aikana esiin nousevat asiat avoimen keskustelun ja syste-maattisen ongelmanratkaisun piiriin.

226

5. Pk-yrityksissä tarvitaan yksinkertaisia ja tehokkaita suunnittelumenetelmiä.Tietojärjestelmän suunnittelu- ja käyttöönottoprosessin tueksi tarvitaan erilaisiamenetelmiä. Menetelmiä tarvitaan mm. liiketoimintaprosessien mallintamiseen,vaatimusten kuvaamiseen sekä käyttöönoton organisoimiseen. Osa menetelmistätuottaa enemmän (esim. ER- ja oliomallit) ja osa vähemmän (esim. liiketoimin-taprosessien mallit) formaaleja malleja. Kokemus on osoittanut, että pk-yrityksissä ei ole järkevää pyrkiä käyttämään monimutkaisia menetelmäkokonai-suuksia. Pk-yrityksistä ei yleensä löydy menetelmien käyttöön perehtynyttähenkilökuntaa. Menetelmien tulee siten olla käsiterakenteeltaan yksinkertaisia jahelposti omaksuttavia, jotta yrityksen oma henkilöstö pystyisi itse tuottamaanhuomattavan osan tarvittavista kuvauksista ja malleista ilman mittavaa koulutus-rupeamaa. Suunnittelutyöhön osallistumista tulisi muutenkin rohkaista kaikinkeinoin. Tämä on tehokas keino kanavoida henkilöstön osaaminen suunnitteillaolevaan hankkeeseen.

Iteratiivisuus ja vuorovaikutteisuus käyttöönottoprosessien ominaisuutena

Toiminnanohjausjärjestelmän käyttöönottoprosessin pitäisi pk-yrityksessä ollakuvassa 1 esitetyn mallin kaltainen. Siinä keskustelut (esim. suunnittelupalave-rit) ja kuvaukset (esim. toimintaprosessien mallit) seuraavat toisiaan vuorovai-kutteisesti, ja koko prosessi etenee iteratiivisesti kohti tavoitetilaa. Tällä tavallavarmistetaan, että formaaleihin kuvaustapoihin ja analyyseihin ei takerruta liiak-si ja että riittävästi aineistoa syntyy organisatorisen käyttöönoton ja oppimispro-sessien tueksi.

Keskustelu

Kuvaus

Keskustelu

Kuvaus

Kuva 1. Suunnittelu- ja käyttöönottoprosessi keskustelun ja kuvausten vuorovai-kutuksena.

Hankkeen alussa on luontevaa keskustella karkealla tasolla tietojärjestelmästä jakoko hankkeen tavoitteista. Tämän pohjalta tehdään (vapaamuotoinen) kuvaus,

227

joka sisältää keskustelun keskeisimmät tulokset. Kuvauksen tarkoitus on toimiaseuraavan keskustelun lähtökohtana. Tällöin kuvauksen tehtävänä on palauttaaihmisten mieliin, mitä edellisessä keskustelussa käsiteltiin ja mihin siinä päädyt-tiin. Kuvauksen tulee perustua keskeisiin keskustelussa käytettyihin käsitteisiinja malleihin. Kuvauksen lähtökohtana voi olla myös jokin formaali tapa kuvatakyseisiä asioita, mikäli tätä pidetään tarkoituksenmukaisena. Tavoitetilan jälkeenedetään järjestelmän vaatimuksiin jne. Keskustelujen ja kuvausten muodostamaketju jatkuu läpi käyttöönoton kaikki vaiheet.

Iteratiivisuus ja vuorovaikutteisuus ovat melko yleisesti hyväksi tunnustettuja jatietojärjestelmien suunnittelussa ja toteutuksessa sovellettuja periaatteita. Neeivät kuitenkaan yksinään riitä. On hahmotettava käyttöönottoprosessin koko-naisuus, johon sekä loppukäyttäjäyritys että järjestelmätoimittaja tulevat omillamalleillaan ja maailmankatsomuksellaan. Millaisia vuorovaikutusprosessejaheidän välillään on – tai tulisi olla? Mikä on niiden lisäarvo eri toimijoidennäkökulmasta? Seuraavaksi pyrimme jalostamaan julkaisun artikkeleiden tulok-sia ja johtopäätöksiä viedä pidemmälle ja esittämään tietojärjestelmien käyt-töönoton kokonaismallin.

Kohti uutta mallia

Artikkelit ovat tuoneet selvästi esiin sen, että tietojärjestelmien käyttöönottopro-sessin ja siihen vaikuttavien teknologisten ja organisatoristen mekanismienymmärtäminen edesauttaa tietojärjestelmien käyttöönottoa ja järjestelmähank-keille asetettujen tavoitteiden saavuttamista. Pk-yritysten näkökulmasta tietojär-jestelmien käyttöönoton kokonaisuus näyttäytyy kuitenkin vaikeasti hahmotetta-vana asiana. Erityisesti toiminnanohjausjärjestelmät ovat monimutkaisia jalaajoja järjestelmiä. Niiden käyttöönotossa on aina kyse mutkikkaista strategi-sista kysymyksistä sekä teknisistä, taloudellisista ja organisatorisista ongelmista.

Tietojärjestelmien käyttöönottoprosessien dynamiikan ymmärtäminen edellyttääniiden tarkastelua useista eri näkökulmista. Tietojärjestelmien suunnittelussa jakäyttöönotossa on viime kädessä kyse organisaatioissa tapahtuvista tiedonluonti-ja oppimisprosesseista. Vasta näiden prosessien kautta organisaatio voi saavut-taa pysyviä tuloksia tietojärjestelmien hyödyntämisessä ja päästä siihen, ettätietojärjestelmät toimivat tukivälineinä jatkuvasti kehittyvässä toiminnassa (ks.Hyötyläinen 1998). Kehittämiseen suuntautuvan toimintatutkimuksen avulla

228

voidaan tavoittaa organisaatioiden ja tietojärjestelmien ongelmat ja arkikäytän-nöt sekä aktivoida toimijat kehitystyöhön.

Aikaisemmin todettiin, että pk-yritykset kaipaavat tehokkaita malleja ja mene-telmiä tietojärjestelmien suunnittelu- ja käyttöönottoprosessien hallintaan. Ta-vallisen pk-yrityksen on kuitenkin ilmeisen hankalaa tarkastella tietojärjestel-mien käyttöönottoprosessia kokonaisuutena – ts. käsitteellisellä tasolla – mikämerkitsisi oman toiminnan ja sen perusteiden reflektiivistä analyysiä ja mallin-tamista. Tähän ovat syynä rajalliset resurssit ja menetelmäosaamisen puutteet.Tarvitaan siis havainnollisia ja yksinkertaisia malleja ja ajattelun työkaluja,joiden avulla toimijat pääsevät näihin järjestelmähankkeiden kokonaisuudenhahmottamisen kannalta tärkeisiin ilmiöihin kiinni. Tämän pitäisi onnistua osanayrityksen arkipäivän toimintaa. Voidaan nähdä, että mille tahansa yritykselleuusien menetelmien ja järjestelmien käyttöönotto ja liittäminen osaksi jo käytös-sä olevia toimintoja on helpompaa, jos yritys pystyy ennakoimaan hankkeenkulun, eri vaiheet ja niihin liittyvät vaatimukset jo ennen varsinaisia käyttöönot-toon liittyviä konkreettisia toimenpiteitä.

Julkaisun ensimmäisessä artikkelissa nostettiin esiin tietojärjestelmien suunnit-telu- ja käyttöönottoprosessin elinkaarimallit. Mallit kuvaavat sekä loppukäyt-täjäyrityksen että järjestelmätoimittajan käyttöönottoprosessin perusvaiheita,jotka hahmotetaan toisiaan seuraavina sykleinä. Toisaalta tässä julkaisussa onkorostettu tiedonluonti- ja oppimisprosesseja edellytyksenä onnistuneelle tieto-järjestelmähankkeelle. Auki on jäänyt kuitenkin se, miten nämä tiedonluonti- jaoppimisprosessit voisivat liittyä tietojärjestelmien suunnittelu- ja käyttöönotto-prosessin eri vaiheisiin. Kuvassa 2 tästä on pyritty hahmottamaan kokonaismalli.Malli yhdistää tietojärjestelmän suunnittelu- ja käyttöönottoprosessin elinkaari-mallit ja vaihesyklit organisaatioiden tiedonluonti- ja oppimisprosessien välityk-sellä toisiinsa. Mallin tarkoituksena on toimia kokonaisuuksia hahmottavana,yksinkertaisena ajattelun työkaluna, joiden tarpeeseen edellisessä kohdassaviitattiin.

229

Työntekijät

JohtoJohto

Johto

Konversiot, koulutukset”koeajo”

Tavoitteet, vaatimuksettoiminnan suunnittelu

Vaatimusmäärittely Käyttöönotto Käyttö ja kehitysStrategiasuunnittelu

Keskijohto

Työntekijät

Keskijohto

Työntekijät

Johto

Keskijohto

Johto

Keskijohto

Työntekijät

Keskijohto

Työntekijät

Johto

Keskijohto

Työntekijät

Johto

Keskijohto

Työntekijät

Johto

Keskijohto

TyöntekijätMyyntiprosessit Käyttöönotto Käyttö ja kehitysKäyttöönotto Käyttö ja kehitysTuotekehitys

Toimialan erityispiirteet,”best practices”

Kehitys, ylläpito,paivitykset, neuvonta

Kokemukset ja kehittämistarpeet

Loppukäyttäjäyrityksenoppimissilmukat

Loppukäyttäjäyrityksenvaihesyklit

Organisaation toimintaja oppimisprosessit

Tietojärjestelmän käyttöönotto ja

organisaatioidenvuoropuheluprosessi

Toimittajanoppimissilmukat

Toimittajanvaihesyklit

Organisaation toimintaja oppimisprosessit

Kokemukset ja kehittämistarpeet

Kuva 2. Tietojärjestelmän suunnittelun ja käyttöönoton elinkaarimalleihin sido-tut oppimis- ja tiedonluontiprosessit.

Mallissa on yhdistetty sekä loppukäyttäjäyrityksen (yllä) että järjestelmätoimit-tajan (alla) elinkaarimallit ja niiden vaihesyklit. Tietojärjestelmän käyttöönotoneri vaiheissa tapahtuvaa organisaatioiden välistä vuoropuhelua ja tiedonvaihtoakuvataan elinkaarien väliin sijoitetuilla ympyröillä (ks. I artikkeli). Organisaa-tioiden sisäisiä oppimisprosesseja kuvataan vaihesyklien välisillä, kokemuksia jakehittämistarpeita välittävillä oppimissilmukoilla.

Malli kuvaa tietojärjestelmähankkeeseen osallistuvien yritysten organisaatiotkolmitasoisina: johto, keskijohto ja työntekijät. Tietojärjestelmän suunnittelu- jakäyttöönottoprosessin eri vaiheissa vastuut ja aktiviteetit painottuvat eri organi-saatiotasoille, mitä mallissa kuvataan tummennuksilla. Tekemisen vastuun siir-tyminen hierarkiatasolta toiselle luo lisähaasteita työn organisoinnille ja tiedon-välitykselle. Lisäksi hankkeen edetessä kertyvä oppi olisi saatava talteen jaedelleen hyötykäyttöön. Tätä kuitenkin vaikeuttaa se, että eri ihmiset ja eri orga-nisaatiot ovat usein kiinnostuneita eri asioista. Tämän vuoksi tarvitaan doku-mentoituja ja organisaation toimintaan sisään ajettuja tiedonluonti- ja oppimis-prosesseja.

230

Suuri osa ihmisten tiedoista ja taidoista (know-how) on usein ns. äänetöntä tietoa(tacit-knowledge). Äänetön tieto on tyypillisesti yksittäisen työntekijän henkilö-kohtaista osaamista, josta muut työntekijät ja koko organisaatio hyötyvät vainsilloin, kun asianomainen henkilö tekee työtään. Näin ollen on organisaationedun mukaista pyrkiä muuntamaan äänetöntä tietoa ns. julkiseksi tiedoksi (expli-cit knowledge) (Nonaka ja Takeuchi 1995). Kun tieto on julkista, sen hyödyntä-minen ei ole yksittäisistä erityisasiantuntijoista kiinni. Tämä ei kuitenkaan ta-pahdu itsestään ja siksi tiedonluonti- ja oppimisprosesseja täytyy koko ajankehittää ja tukea. Tietoa ei voi vain ”kerätä” ja ”vyöryttää”; sen sijaan sitä pitääetsiä, jalostaa ja viljellä. Ihmiset käyttävät uutta tietoa, kun se on saatavilla –toisaalta uutta tietoa syntyy, kun ihmiset luovuttavat omat tietonsa ja kokemuk-sensa yhteisön käyttöön.

Kun kontekstina on tietojärjestelmän käyttöönotto, tiedon siirtoa ja oppimistapitäisi tapahtua vaihesyklien sisällä ja välillä sekä eri organisaatioiden ja hie-rarkiatasojen välillä. Miten tämä organisoidaan tehokkaasti on keskeinen käyt-töönottoon liittyvä tutkimus- ja kehityskysymys. Keskeisimmän haasteen muo-dostaa yhtäältä tiedon ja toimijoiden määrä (kvantitatiivinen komponentti), toi-saalta tiedon erilaiset esitysmuodot ja toimijoiden erilaiset toimintatavat jaosaamisalueet (kvalitatiivinen komponentti). Esimerkiksi osa tietojärjestelmäntoimittajilta tulevasta tiedosta on loppukäyttäjäyritykselle usein vaikeasti tulkit-tavaa, mikä voi aiheuttaa väärinkäsityksiä ja sitä kautta tyytymättömyyttä yh-teistoimintaa kohtaan. Tämän kaltaisten ongelmien ratkaiseminen tuntuisi edel-lyttävän sitä, että organisaatioiden välisten vuorovaikutus- ja kommunikointi-prosessien tunnistaminen ja määrittely mielletään kiinteäksi osaksi tietojärjes-telmän käyttöönottoprosessia.

Oppimissilmukoiden ja organisaatioiden välisten vuoropuheluprosessien merki-tys on kasvamassa (vrt. Argyris ja Schön 1978; Argyris 1992). Loppukäyttäjä-yrityksen kannalta niiden tärkeys perustuu siihen, että tietojärjestelmillä onentistä keskeisempi rooli yritysten toiminnassa. Tätä kautta tiedon ja osaamisenhallinnasta tulee strateginen kilpailutekijä myös pk-yrityksille. Ohjelmistotalojenja järjestelmätoimittajien kannalta kysymys on liiketoiminnan kehittämisestä.Kokemusten ja asiakaspalautteen tehokas hyödyntäminen on keskeistä mm.ohjelmistotuotteiden, palvelukonseptien sekä käyttöönottomallien kehittämisenkannalta.

231

Jatkokysymyksiä

Tietojärjestelmien käyttöönottoprosessia ei ole laajemmin tarkasteltu tiedon-luonnin ja organisatoristen oppimisprosessien näkökulmista (Currie ja Galliers[toim.] 1999; vrt. Nonaka ja Takeuchi 1995). Tietojärjestelmän käyttöönottopro-sessiin osallistuu useita tahoja erilaisin intressein, tavoittein ja menetelmin, mikävoi jo sinänsä edesauttaa oppimisprosesseja. Kuitenkin eri toimijoiden ja näkö-kulmien olemassaolo itsessään ei takaa tiedonluonti- ja oppimisprosessien käyn-nistymistä organisaatioissa tai niiden välisessä yhteistyössä - haasteita sen sijaanvarmasti riittää. Tiedonluonti- ja oppimisprosessit edellyttävät tietoisia toimen-piteitä. Tältä pohjalta voidaan nostaa monia kysymyksiä jatkotutkimukselle:

1. Mikä merkitys on tietojärjestelmien suunnittelu- ja käyttöönottoprosessinelinkaarimalleilla ja niiden vaihesykleillä uudenlaisten suunnittelu- ja käyttöön-ottomallien ja menetelmien kehitystyössä?

2. Millaisia tiedonluonti- ja oppimisprosesseja organisaatioissa ja organisaatioi-den välillä on? Millaisia mikrotason ilmiöitä (tehtäviä, toimenpiteitä, välineitäjne.) niihin liittyy? Kuinka tehokkaita vallitsevat käytännöt ovat? Miten niitävoidaan edelleen kehittää?

3. Millaisia tietojärjestelmähankeen eri toimijoiden välisten vuorovaikutus- jakommunikointiprosessien tulisi olla, jotta ne tukisivat parhaalla mahdollisellatavalla sekä järjestelmän käyttöönottoa että eri organisaatioiden ja toimijoidenoppimisprosesseja?

4. Millaisia tietojärjestelmien suunnittelu- ja käyttöönottomenetelmien tulisi olla,jotta ne tukisivat parhaalla mahdollisella tavalla sekä järjestelmän käyttöönottoaettä eri organisaatioiden ja toimijoiden oppimisprosesseja?

5. Miten tietojärjestelmien käyttöönottoprosesseihin kohdistuvalla, kehittämi-seen suuntautuvalla toimintatutkimuksella (konstruktiivisella tutkimus- ja kehi-tystyöllä) voidaan tukea pk-yrityksiä niiden tietojärjestelmien määrittely-, suun-nittelu- ja käyttöönottoprosesseissa? Voiko tällainen tutkimus- ja kehitysotepalvella samalla tietojärjestelmien suunnittelu- ja käyttöönottoprosessia koske-vien uusien käsitteiden luonnissa ja määrittelyssä (ks. Lee 1999; Fryer ja Feather1994; Kuula 1999)?

232

Lähteet

Argyris, C. 1992. On Organizational Learning. Oxford: Blackwell Business.

Argyris, C. & Schön, D. A. 1978. Organizational Learning: A Theory of ActionPerspective. Reading, Massachusets – Menlo Park, California – London –Amsterdam – Don Mills, Ontario – Sydney: Addison-Wesley.


Fryer, D. & Feather, N. T.1994. Intervention Techniques. In: Cassell, C. &Symon, G. (Eds.), Qualitative Methods in Organizational Research. A PracticalGuide. London – Thousands Oak – New Delhi: Sage Publications. S. 230–247.

Hyötyläinen, R. 1998. Implementation of Technical Change as OrganizationalProblem-Solving Process. Management and User Activities. Espoo: VTTPublications 337. 238 s. + liitt. 12 s.

Kuula, A. 1999. Toimintatutkimus. Kenttätyötä ja muutospyrkimyksiä. Tam-pere: Vastapaino.

Lee, A. S. 1999. Researching MIS. In: Currie, W. L. & Galliers, B. (Eds.),Rethinking Management Information Systems. Oxford: Oxford University Press.S. 7–27.


JulkaisijaVuorimiehentie 5, PL 2000, 02044 VTTPuh. (09) 4561Faksi (09) 456 4374

Julkaisun sarja, numero jaraporttikoodi

VTT Julkaisuja 854VTT–JULK–854

Tekijä(t)Kettunen, Jari & Simons, Magnus

Nimeke

Toiminnanohjausjärjestelmän käyttöönottopk-yrityksessäTeknologialähtöisestä ajattelusta kohti tiedon ja osaamisen hallintaa

TiivistelmäJulkaisussa luodaan laaja-alainen katsaus tietojärjestelmien käyttöönoton problema-tiikkaan. Keskeisellä sijalla ovat pk-yritysten toiminta ja toiminnanohjaus, tietojärjes-telmien määrittely- ja käyttöönottoprosessit sekä erityisesti toiminnanohjausjärjestel-mät. Aihepiiriä lähestytään sekä menetelmälähtöisesti että toiminnan kehittämisen nä-kökulmasta. Julkaisu koostuu kahdeksasta itsenäisestä artikkelista. Artikkeleissa ku-vataan, mitä em. aihealueista tällä hetkellä tiedetään, millaisia haasteita ja ongelmiapk-yritysten tietojärjestelmähankkeisiin tyypillisesti liittyy ja mitä näiden haasteidenvoittaminen käytännössä edellyttää. Useissa artikkeleissa painotetaan, että pk-yrityksettarvitsevat yksinkertaisia ja helppokäyttöisiä menetelmiä järjestelmien määrittely- jakäyttöönottoprosessien tueksi. Lisäksi artikkeleissa todetaan, että tietojärjestelmiä tu-lee kehittää yrityksen liiketoiminnan tavoitteista lähtien ja että tietojärjestelmähank-keeseen kuuluu myös organisaation toiminnan kehittäminen. Julkaisun keskeinenjohtopäätös on, että tietojärjestelmän käyttöönotto on luonteeltaan organisatorinen op-pimisprosessi, jota tulee systemaattisesti tukea ja vahvistaa.

Avainsanatenterprices, SMEs, resource planning, organizational learning, ERP, implementation, information sys-tems, processes

ToimintayksikköVTT Automaatio, Teollisuusautomaatio, Tekniikantie 12, PL 1301, 02044 VTT

ISBN Projektinumero951–38–5881–2 (nid.)951–38–5882–0 (URL: http://www.inf.vtt.fi/pdf/)

Julkaisuaika Kieli Sivuja HintaLokakuu 2001 Suomi, engl. tiiv. 232 s. E

Projektin nimi Toimeksiantaja(t)HANSKA

Avainnimeke ja ISSN Myynti:VTT Julkaisuja – Publikationer1235–0613 (nid.)1455–0857 (URL: http://www.inf.vtt.fi/pdf/)

VTT TietopalveluPL 2000, 02044 VTTPuh. (09) 456 4404Faksi (09) 456 4374

Published byVuorimiehentie 5, P.O.Box 2000, FIN–02044 VTT, FinlandPhone internat. +358 9 4561Fax +358 9 456 4374

Series title, number andreport code of publication

VTT Julkaisuja 854VTT–JULK–854

Author(s)Kettunen, Jari & Simons, Magnus

Title

ERP implementation in small and medium-sized enterprisesFrom technology push to the management of knowledge andexpertise

AbstractThis publication is about the challenges and problems of information systems (IS) implementa-tion. The main topics of the publication are small and medium-sized enterprises (SMEs) andtheir production and operation management practices, IS specification and implementation pro-cesses, and especially enterprise resource planning systems (ERPs). Those issues are ap-proached from both systems engineering and organisational development points of view. Thepublication comprises eight independent articles. The articles concern themselves with theproblems that SMEs typically encounter in IS implementation projects. In addition, the potentialcauses of identified problems are analysed and a number of remedial actions are proposed in thearticles. Many authors underline the importance of having simple and easy-to-use methods tosupport systems specification and implementation in the SME context. They also state that sys-tems should be developed on the basis of the (business) objectives of the organisation concernedand that development of the functioning of the organisation is an integral part of any IS project.The main conclusion of the publication is that an IS implementation project is essentially an or-ganisational learning process that needs to be systematically supported and reinforced.

Keywordsenterprices, SMEs, resource planning, organizational learning, ERP, implementation, information systems,processes

Activity unitVTT Automation, Industrial Automation, Tekniikantie 12, P.O.Box 1301, FIN–02044 VTT, Finland

ISBN Project number951–38–5881–2 (soft back ed.)951–38–5882–0 (URL: http://www.inf.vtt.fi/pdf/)

Date Language Pages PriceOctober 2001 Finnish, engl. abstr. 232 p. E

Name of project Commissioned byHANSKA

Series title and ISSN Sold byVTT Julkaisuja – Publikationer1235–0613 (soft back ed.)1455–0857 (URL: http://www.inf.vtt.fi/pdf/)

VTT Information ServiceP.O.Box 2000, FIN–02044 VTT, FinlandPhone internat. +358 9 456 4404Fax +358 9 456 4374

Documents

käyttöönotto pk-yrityksessä Toiminnanohjausjärjestelmän · 2020-02-18 · 3 Toiminnanohjausjärjestelmän käyttöönotto pk-yrityksessä. Teknologialähtöisestä ajattelusta