OSALLISTAVAN SUUNNITTELUN LÄHESTYMIS-

TAVAT TIETOJÄRJESTELMIEN KÄYTTÖÖNOTON

TUKENA

Juho Jaatinen Pro gradu -tutkielma Tietojenkäsittelytiede Kuopion yliopiston tietojenkäsittelytieteen laitos Toukokuu 2007

KUOPION YLIOPISTO, informaatioteknologian ja kauppatieteiden tiedekunta Tietojenkäsittelytieteen koulutusohjelma JAATINEN JUHO, H.: Osallistavan suunnittelun lähestymistavat tietojärjestelmien käyttöönoton tukena Pro gradu -tutkielma, 87 s., 2 liitettä (2 s.) Pro gradu -tutkielman ohjaajat: KTT Anja Mursu ja FM Irmeli Luukkonen Toukokuu 2007 Avainsanat: Osallistava suunnittelu, Osallistavat menetelmät, ZipIT-tutkimushanke, tietojärjestelmän käyttöönotto, käyttäjäkeskeinen suunnittelu. Tietojärjestelmät eivät aina kohtaa käyttäjien niille asettamia tavoitteita. Syynä tähän on usein puutteellinen kommunikointi käyttäjien ja suunnittelijoiden välillä. Osallistava suunnittelu (participatory design) lähestyy suunnittelutyötä näkökulmasta, jossa käyttä-jät nähdään tärkeänä resurssina koko suunnitteluprosessin elinkaaren ajan. Osallistava suunnittelu ja siihen liittyvät osallistavat menetelmät helpottavat käyttäjien ja suunnitte-lijoiden välisen yhteistyön toteutumista.

Osallistava suunnittelu on perinteisesti sijoitettu tietojärjestelmäsuunnittelussa prosessin alkuvaiheisiin. Tässä tutkielmassa perehdytään osallistavan suunnittelun tarjoamiin lä-hestymistapoihin ja menetelmiin tietojärjestelmän käyttöönottoprosessin näkökulmasta. Tutkimusosiossa selvitettiin miten osallistavan suunnittelun menetelmiä voidaan hyö-dyntää tietojärjestelmien käyttöönoton tukena. Tutkielman tutkimusmenetelmä on luon-teeltaan tapaustutkimus (case study).

Tutkimus liittyy ZipIT-tutkimushankkeeseen, jossa tutkittiin työtoiminnan ja tietojärjes-telmien yhtäaikaista kehittämistä. Tutkimusosiossa tarkastellaan ZipIT-hankkeen yhtey-dessä tehtyä tietojärjestelmän käyttöönottoon liittyvää pilottia yhdessä Suomen viidestä yliopistollisesta sairaalasta. ZipIT-tutkimushanke toteutettiin Kuopion yliopiston ja Sa-vonia-ammattikorkeakoulun yhteisenä hankkeena. ZipIT-hankkeen rahoittavat Tekesin FinnWell-ohjelma, Työsuojelurahasto ja joukko terveydenhuollon ja ohjelmistoalan yrityksiä ja organisaatioita.

Esipuhe

Tämä tutkielma on tehty Kuopion yliopiston tietojenkäsittelytieteen laitokselle. Tut-kielman ohjaajina toimivat Anja Mursu ja Irmeli Luukkonen, joille haluan osoittaa eri-tyiskiitoksen.

Kuopiossa 30.5.2007

____________________________ Juho Jaatinen

Sisällysluettelo

1 JOHDANTO .............................................................................................................6

2 OSALLISTAVA SUUNNITTELU ..........................................................................8

2.1 Osallistavan suunnittelun teoreettinen tausta ....................................................9 2.2 Osallistavan suunnittelun keskeisiä käsitteitä .................................................11

2.2.1 Etnografia........................................................................................11 2.2.2 Konteksti .........................................................................................11 2.2.3 Vaatimusmäärittely .........................................................................12

2.3 Osallistavan suunnittelun toteuttaminen .........................................................13 2.3.1 Käyttäjien osallistaminen ja valinta ................................................14 2.3.2 Käyttäjä-suunnittelija vuorovaikutus ..............................................16 2.3.3 Viestinnälliset toimenpiteet.............................................................18 2.3.4 Menetelmät......................................................................................19

2.4 Osallistavan suunnittelun kohtaamat ongelmat ja kritiikki.............................21

3 LÄHESTYMISTAPOJA OSALLISTAVAAN SUUNNITTELUUN....................23

3.1 Contextual Design...........................................................................................24 3.2 MUST..............................................................................................................29

3.2.1 Periaatteet ........................................................................................30 3.2.2 Jako neljään vaiheeseen ..................................................................33

3.3 Muut tunnetut lähestymistavat ........................................................................35 3.3.1 SSM - Soft Systems Methodology..................................................35 3.3.2 JAD - Joint Application Development............................................36 3.3.3 ULRC - User-Led Requirements Construction...............................37

3.4 Keskeisimmät menetelmät ..............................................................................38 3.4.1 Havainnointi (Observation).............................................................39 3.4.2 Haastattelu (Interview)....................................................................40 3.4.3 Työpajat (workshops)......................................................................42 3.4.4 Prototyypit (prototypes) ..................................................................42 3.4.5 Työnkulun mallinnusmenetelmät....................................................43

3.5 Yhteenveto lähestymistavoista........................................................................44

4 TIETOJÄRJESTELMÄN KÄYTTÖÖNOTTO .....................................................46

4.1 Käyttöönottoprosessi.......................................................................................46 4.2 Terveydenhuollon näkökulma.........................................................................51 4.3 Elektronisen potilaskertomusjärjestelmän käyttöönotto .................................52

5 TUTKIMUSMENETELMÄT JA TOTEUTUS .....................................................54

5.1 Tutkimuksen lähtökohdat................................................................................55 5.2 ZipIT kehittämismalli......................................................................................56 5.3 Tutkimuksen toteutus ......................................................................................58

6 TUTKIMUKSEN TULOKSET ..............................................................................59

6.1 Havainnointi....................................................................................................60 6.2 Haastattelut......................................................................................................65 6.3 Työpajatyöskentely .........................................................................................69 6.4 Osallistavien menetelmien läpivienti ..............................................................73

7 YHTEENVETO JA POHDINTA ...........................................................................76

LÄHTEET.......................................................................................................................80

LIITTEET

LIITE 1: SEKVENSSIKAAVIO PILOTTIOSASTON OSASTONHOI-

TAJAN TYÖPÄIVÄSTÄ

LIITE 2: SAMANKALTAISUUSSEINÄ TUTKIMUSRYHMÄN TYÖ-

PAJASTA

6

1 JOHDANTO

Tietojärjestelmät eivät aina kohtaa käyttäjien niille asettamia tavoitteita. Syynä tähän on

usein puutteellinen kommunikointi käyttäjien ja suunnittelijoiden välillä. Kommuni-

koinnin puute korostuu vaatimusmäärittelyn kohdalla erityisesti vaatimustenkeräysvai-

heessa. Tietojärjestelmän suunnittelun lähtökohtana tulisi olla riittävän tarkka tietojen

selvittäminen käyttäjien työtavoista ja - prosesseista, mikä mahdollistaa käyttäjien to-

dellisten tarpeiden huomioimisen uuden tietojärjestelmän käyttöön liittyen. Tietojärjes-

telmällä tarkoitetaan ihmisistä, tietojenkäsittelylaitteista, datansiirtolaitteista ja ohjel-

mista koostuvaa järjestelmää, jonka tarkoitus on tietoja käsittelemällä tehostaa tai hel-

pottaa jotakin toimintaa tai tehdä toiminta mahdolliseksi [Tie04, s.242].

Osallistava suunnittelu (participatory design) lähestyy suunnittelutyötä näkökulmasta,

jossa käyttäjät nähdään voimavarana ja aktiivisena osallistujana koko suunnitteluproses-

sin elinkaaren ajan. Osallistava suunnittelu ja siihen liittyvät menetelmät ovat helpotta-

neet käyttäjien ja suunnittelijoiden välistä yhteistyötä. Menetelmiä voidaan soveltaa

ohjelmistoprojekteissa tukemalla käyttäjien osallistumista uuden järjestelmän tai toimin-

tatapojen suunnittelussa.

Tässä tutkielmassa käyttäjällä käsitetään kaikki ne henkilöt, jotka tulevat välittömästi

tai välillisesti käyttämään tuotettavia tietojärjestelmiä. Käyttäjäryhmään kuuluvat esi-

merkiksi asiakas ja työntekijä. Suunnittelijaksi määritellään kaikki ne henkilöt, jotka

osallistuvat toteutettavan tietojärjestelmän valmistamisen eri vaiheisiin, esimerkiksi

vaatimusmäärittelyyn, ohjelmistosuunnitteluun, ohjelmointiin ja käyttöönottoon.

Osallistavaan suunnitteluun liittyvät lähestymistavat ja menetelmät on pääasiallisesti

sijoitettu ohjelmistoprojektin elinkaaren alkuvaiheisiin kuten vaatimustenkeräykseen.

Tässä tutkielmassa osallistavaa suunnittelua tarkastellaan ensisijaisesti kahden tunne-

tuimman lähestymistavan Contextual Designin ja MUST-metodin sisältämien menetel-

mien kautta. Lähestymistapoja ja niiden sisältämiä menetelmiä on vertailtu tutkielman

kokeellisessa osassa saatuihin kokemuksiin.

Tässä tutkielmassa osallistavan suunnittelun menetelmiä tarkastellaan elektronisen poti-

laskertomusjärjestelmän käyttöönottoprosessiin liittyen. Tutkielman tutkimusongelmana

on selvittää, miten osallistavan suunnittelun eri lähestymistapojen sisältämiä menetel-

7

miä voidaan hyödyntää tietojärjestelmän käyttöönoton apuna. Näitä menetelmiä on tut-

kittu ZipIT-tutkimushankkeeseen liittyvässä pilotissa, joka toteutettiin eräässä yliopis-

tollisessa sairaalassa käyttöönotettavan elektronisen potilaskertomusjärjestelmän koh-

dalla. Tutkimuksen tavoitteena on arvioida osallistavaan suunnitteluun liittyvien mene-

telmien soveltuvuutta ja tarjota suosituksia menetelmien soveltamiseksi käyttöönotto-

projektien tueksi.

Tämä tutkielma koostuu kahdeksasta luvusta. Ensimmäisessä varsinaisessa luvussa kä-

sitellään osallistavan suunnittelun taustalla olevaa teoriaa, käydään läpi osallistavaan

suunnitteluun keskeisesti liittyvät käsitteet ja tarkastellaan osallistavan suunnittelun to-

teuttamiseen ja läpivientiin liittyviä vaiheita.

Kolmannessa luvussa käydään läpi osallistavaan ja käyttäjälähtöiseen suunnitteluun

liittyviä lähestymistapoja. Tässä tutkielmassa keskeisimmät lähestymistavat ovat Con-

textual Design ja MUST-metodi. Luvussa tarkastellaan myös muita osallistavan suun-

nittelun lähestymistapoja, joiden kohdalla huomio kiinnittyy yksittäisiin huomiokohtiin

lähestymistapoihin liittyen. Luvussa käydään läpi myös osallistavan suunnittelun mene-

telmiä ja eri lähestymistapojen eroja ja yhtäläisyyksiä.

Neljäs luku käsittelee tietojärjestelmän käyttöönottoon liittyviä toimenpiteitä. Luvussa

käydään läpi terveydenhuollon erikoispiirteitä ja esitellään tutkielman tutkimusosiossa

toteutetun elektronisen potilastietojärjestelmän käyttöönottoon liittyvää kontekstia.

Viidennessä luvussa kerrotaan käytetyistä tutkimusmenetelmistä ja toteutustavoista.

Luku sisältää myös kuvauksen kohdeorganisaatiosta, jossa pilotti toteutettiin.

Kuudes luku esittelee tutkimuksessa saatuja tuloksia ja kokoaa yhteen käytetyt osallis-

tavan suunnittelun menetelmät. Tutkimuksessa käytettyjä menetelmiä vertaillaan kirjal-

lisuudessa esitettyihin suosituksiin menetelmien käyttöön liittyen. Esille tuodaan myös

suosituksia, joita kohdeorganisaationa toimineesta yliopistollisesta sairaalasta saatiin

selville. Tutkielman seitsemännessä luvussa on tutkielman yhteenveto- ja pohdintaosio.

8

2 OSALLISTAVA SUUNNITTELU

Osallistava suunnittelu (Participatory Design, PD) on käyttäjälähtöisyyttä korostava

näkökulma erilaisiin ohjelmistoprojekteihin liittyen. Osallistavan suunnittelun keskei-

nen tavoite on käyttäjien mukaan ottaminen suunnittelussa ja yleisesti ottaen käyttäjä-

lähtöisyys [Cra98]. Käyttäjälähtöinen näkökulma osallistavaan suunnitteluun korostaa

käyttäjien aktiivista roolia ja osallistumista tietojärjestelmän suunnittelun eri vaiheissa.

Osallistavassa suunnittelussa käyttäjät nähdään voimavarana, jotka pystyvät tarjoamaan

elintärkeää tietoa tulevan tietojärjestelmän toimintaympäristöstä ja siihen keskeisesti

liittyvistä toimintatavoista [BKS04].

Osallistava suunnittelu keskittyy erityisesti työhön ja työtoimintaan kohdistuvien muu-

tosten huomioimiseen käyttäjien näkökulmasta. Bødkerin mukaan tätä näkökulmaa

hyödyntämällä saavutetaan läheisempi tarkastelukulma työn konkreettiseen tekemiseen

ja sitä kautta tarkempaan tietoon tietojärjestelmien suunnittelua silmällä pitäen

[BKS04]. Osallistavan ja käyttäjäkeskeisen suunnittelun kategoriaan kuuluviksi laske-

taan yleisesti ottaen kaikki toiminnan kehittämistarpeista lähtevät lähestymistavat

[SaK98].

Käyttäjien ymmärtäminen, tarpeiden tunnistaminen ja niiden työtapojen ymmärtäminen,

joilla työntekijät toimivat työympäristönsä kontekstissa parantavat erilaisten suunnitte-

luprojektien onnistumista huomattavasti [CoM02]. Kontekstin eri näkökulmat on esitel-

ty tarkemmin luvussa 2.2. Osallistavan suunnittelun lähestymistapojen avulla pyritään

selvittämään ja analysoimaan tarpeet, mahdollisuudet sekä alustavat ratkaisumallit tar-

kasteltavaan järjestelmään tai toimintaan liittyen [KSB98].

Luvussa 2.1 esitellään osallistavan suunnittelun syntyyn vaikuttaneita tekijöitä ja sen

kehittymistä eri puolilla maailmaa. Luvussa selvitetään osallistavaan suunnitteluun kes-

keisesti vaikuttavia teorioita ja niiden keskeinen sisältö. Luvussa 2.2 eritellään osallista-

van suunnittelun keskeiset termit ja käsitteet. Käsitteet ja niiden taustalla olevat ajatus-

mallit tarkentavat osaltaan osallistavan suunnittelun lähtökohtia ja tarkoitusta.

Luvussa 2.3 tarkastellaan osallistavan suunnittelun läpiviennin kannalta keskeiset vai-

heet ja niiden sisältö. Läpiviennin metodologia on jaettu neljään osaan, joista jokainen

esittelee yhden osallistavan suunnittelun läpiviennin kannalta keskeisen aihealueen.

9

Läpikäytävät vaiheet ovat käyttäjien osallistaminen ja valinta, käyttäjä-suunnittelija

vuorovaikutus, viestinnälliset toimenpiteet ja menetelmät. Luvussa 2.4 tarkastellaan

osallistavaan suunniteluun liittyviä käyttökokemuksia ja kyseisen suunnittelumenetel-

män kohtaamaa kritiikkiä.

2.1 Osallistavan suunnittelun teoreettinen tausta

Käyttäjäkeskeisen ajattelutavan ja suunnittelumenetelmien alku sijoittuu 1960-luvulle.

Tällöin käyttäjälähtöisyys tiedostettiin ensimmäistä kertaa tekniseen suunnitteluun lä-

heisesti liittyvänä näkökulmana. 1960- ja 1970-luvulla kognitiivisen psykologian lähes-

tymistapa ja 1970- ja 1980-luvun iteratiivinen tuotekehitys (määritelty luvussa 3.4) kul-

kivat käyttäjäkeskeisten suunnittelumenetelmien rinnalla. Muiden joukossa nämä suun-

taukset alkoivat ohjata käyttäjälähtöisen suunnittelun menetelmiä kohti nykyistä suun-

taansa. [Kuu03]

Käyttäjälähtöisten suunnittelumenetelmien taustalla on ajatus, jonka mukaan järjestel-

mien kehittäjät tarvitsevat tietoja käyttäjien työympäristöstä ja -tavoista [BeH95]. Käyt-

täjäkeskeiseen suunnittelun (Human-centered design, HCD) sisältö on koottu ISO

13407 standardiksi. HCD on tarkoitettu käytettävyyden mukaansaamiseksi ohjelmisto-

kehitysprosessissa, mutta vaiheiden sisältämät toimenpiteet ovat yhteneväisiä myös

osallistavan suunnittelun läpiviennin suhteen [Mag01].

Osallistavan suunnittelun juuret ulottuvat 1960- ja 1970-luvulle, jossa sen ensimmäiset

vaiheet syntyivät yhteistyössä teollisuuden ja ammattiyhdistysten (trade unions) välillä.

Tämän pohjalta 1980-luvulla Skandinaviassa tehtyjen toimintalähtöisyyttä käsittelevien

tutkimusten pohjalta osallistava suunnittelu jalostui edelleen. Näkökulma osallistavaan

suunnitteluun on kehittynyt tarpeesta luoda tiiviimpää yhteistyötä käyttäjien ja työpai-

koilla tapahtuvan kehitystyön välille [FFM06, KeM93].

Vaikkakin osallistava suunnittelu on sijoitettu alun perin käyttäjän mallintamiseen lä-

heisesti liittyväksi, ovat sen kehittäjät sittemmin sijoittaneet menetelmän käyttäjäläh-

töisten suunnittelumenetelmien kategoriaan [Kuu03]. Skandinaavinen suuntaus käyttä-

jälähtöiseen suunnitteluun korostaa erityisesti suunnitteluprojektin osapuolten, käyttäjän

ja suunnittelijan, jatkuvaa yhteistyötä [Kyn94].

10

Skandinaviassa kehittyneen osallistavan suunnittelun yhteydessä on käytetty myös ter-

miä Skandinaavinen haaste (Scandinavian Challenge). Se kuvataan erilaisten näkökul-

mien ja menetelmien joukkona, joka korostaa käyttäjien roolia ja merkitystä aktiivisena

osapuolena erilaisissa suunnittelu- ja kehitysprosesseissa. Nämä suunnittelu- ja kehitys-

prosessit koostuvat ihmisen tekemistä tietoteknisistä ratkaisuista, artefakteista, jotka

vaikuttavat sekä välillisesti että välittömästi käyttäjien työskentelyyn tietyssä työympä-

ristössä [MBJ91]. Osallistavan suunnittelun lähtökohtana on käyttäjien toimintaa tark-

kailemalla saatavien tietojen saattaminen erilaisten mallinnusmenetelmien avulla kohti

ensimmäisiä prototyyppejä ja kehitysversioita [Kuu01].

Osallistavan suunnittelun tarjoamien lähtökohtien pohjalta erilaiset näkökulmat ovat

muotoutuneet sosio-teknistä (sosio-technical) näkökulmaa seuraaviksi, käyttäjien roolia

suunnittelutyössä arvostaviksi suunnittelutyön toteutustavoiksi [CoM02]. Osallistavan

suunnittelun lähestymistapojen keskeinen piirre on käyttäjien mukana oleminen suun-

nitteluprosesseissa ja niiden elinkaaren eri vaiheissa [Vuo05, Bød04].

Lähestymistavoilla kuvataan tietojärjestelmien ja toiminnan suunnittelun eri vaiheissa,

erityisesti vaatimustenkeräyksessä, hyödynnettäviä kokonaisuuksia. Nämä osallistavan

suunnittelun toteuttamiseksi ja läpiviemiseksi hyvin muodostuneet ja selkeärakenteiset

kokonaisuudet yhdistävät suunnittelutyössä onnistuneesti sosiaalisen, organisatorisen ja

inhimillisen näkökulman suunnittelutyöhön [CoM02].

Osallistavan suunnittelun lähestymistavat ovat levinneet Skandinaviasta lähinnä Yhdys-

valtoihin ja Iso-Britanniaan. Skandinaviassa yhdeksi merkittävimmistä lähestymista-

voista on noussut Tanskassa kehitelty MUST-metodi, joka tarjoaa käyttäjälähtöisen vii-

tekehyksen suunnitteluprojektien läpiviennille [Bød04, KeS98]. MUST nimi on tans-

kankielinen akronyymi teorioille ja metodeille suunnittelutoimenpiteisiin liittyen.

MUST tuo esille useita osallistavan suunnittelun menetelmiä, joiden avulla tietojärjes-

telmän kokonaisvaltainen suunnitteluprosessi on mahdollista toteuttaa [CoM02].

Skandinavian ulkopuolella osallistava suunnittelu on saanut uusia näkökulmia ja sovel-

lusalueita. Tunnetuimmaksi lähestymistavaksi on noussut Yhdysvalloissa kehitetty Con-

textual Design. Contextual Design tarjoaa MUST-metodin tapaan kattavasti menetelmiä

käyttäjien osallistamiseksi suunnitteluprosessiin. Contextual Design lähestyy suunnitte-

luprosessia ajatuksesta, jonka mukaan asiakkaan tarpeet ja asiakkaan työstä nousevat

11

huomiot ohjaavat suunnitteluprosessia [BeH99]. Contextual Design ja MUST on esitel-

ty tässä tutkielmassa tarkemmin luvussa kolme.

2.2 Osallistavan suunnittelun keskeisiä käsitteitä

Osallistavan suunnittelun historialliseen taustaan ja toteuttamiseen liittyy keskeisesti

käsitteitä joiden ymmärtäminen voidaan katsoa eduksi ennen aihepiirin syvempää tar-

kastelua. Tässä luvussa on esitelty joitain osallistavan suunnittelun aihepiiriin kannalta

keskeisiä käsitteitä.

2.2.1 Etnografia

Etnografia (Ethnography) sana tarkoittaa ihmisen kuvaamista tai ihmisestä kirjoittamis-

ta. Etnografian avulla pyritään ymmärtämään ihmisen toimintaa tietyssä ympäristössä ja

pyritään pääsemään lähelle tarkkailtavaa kohdetta ja tutustumaan siihen havainnoimalla

ja oppimalla [Vuo05, And92].

Etnografian avulla pyritään huomioimaan tarkasti sosiaalisen organisaation nykytilaa ja

työkäytäntöjä [Cra98]. Etnografisen suuntauksen eräs tavoite Andersonin mukaan on

saada ymmärrys käyttäjien toiminnasta ja siihen liittyvistä sosiaalisista merkityksistä

tietyn kontekstin sisällä [And92].

2.2.2 Konteksti

Konteksti (Context) (asiayhteys, tausta) voidaan jakaa kolmeen eri osaan; projektikon-

teksti (project context), käyttökonteksti (usage context) ja tekninen konteksti (technical

context). Kontekstin kaikki eri osat voidaan Bødkerin mukaan jakaa edelleen kahteen

ulottuvuuteen. Nämä eri osat muodostavat viitekehyksen, jonka sisällä teot ja toteamuk-

set saavat merkityksensä. [BKS04]

Projektikontekstissa tietojärjestelmän kehittämisprosessi nähdään tietyn ajan kestävänä

prosessina. Kontekstin keskeinen osa käsittää projektiin kuuluvien henkilöiden suhteita

ja vastuita. Projektikontekstin (käyttäjäpuolen kontekstin) kaksi ulottuvuutta ovat:

1. Suunnitteluprojekti (design project) - Konteksti sisältää asianomaisten suhteet

muihin meneillä oleviin projekteihin, joissa he ovat mukana. Tämä vaati johta-

misen, aikataulutuksen ja suunnittelun kannalta tarkkaa huomioimista.

12

2. Toteutusprojekti (implementation project) - Konteksti käsittelee toisiaan seuraa-

vien toteutusvaiheiden kulkua. Visiot, joita suunnitteluprojektiin halutaan sijoit-

taa, tulee pohtia käytössä olevien resurssien ja muiden samanaikaisesti toteutuk-

sessa olevien projektien asettamien vaatimusten pohjalta.

Käyttökontekstissa tarkastelun kohteena on suunnitteluprojektissa mukana olevan koh-

deorganisaation konteksti. Käyttökontekstin kaksi ulottuvuutta Bødkerin mukaan ovat:

1. Liiketoimintastrategia (Business strategy) - Liiketoimintastrategia sisältää yri-

tyksen tavoitteet ja suunnitelmat tavoitteiden saavuttamiseksi. Yhteinen näke-

mys osapuolten välillä tulee saavuttaa kontekstissa, jossa liiketoimintastrategia

ja sitä tukeva tietojärjestelmä kohtaavat.

2. Työkäytännöt (Work practice) - Työkäytännöt sisältävät kaikkea käyttäjien työ-

hön liittyvää kuten prosessit, tehtävät ja työn tarkoituksen. Tietojärjestelmää tu-

lisi tarkastella siinä työympäristön ja -käytäntöjen kontekstissa, jossa sitä tullaan

käyttämään. Organisaatiotasolla päätettäviä asioita ovat esimerkiksi jaetut vas-

tuualueet, työtavat ja tuotettujen palveluiden ja tuotteiden kuvaukset.

Teknisen kontekstin keskeisin kohta on uuden tietojärjestelmän integroimiseen vaadit-

tavien asioiden huomioiminen olemassa olevien teknisten valmiuksien ja vaatimusten

näkökulmasta. Huomioitavat tekniset pääkohdat ovat:

1. Tietojärjestelmät (Information systems) - Näkökulmassa tulee huomioida ole-

massa olevat tietojärjestelmät, organisaation tekniset strategiat ja muut visioidut

tietojärjestelmän osat.

2. Järjestelmäalustat (IT platforms) - Näkökulma tulee rajata järjestelmäalustan

kohdalla koskemaan organisaation strategioissa määriteltyjen, tietyn käyttökoh-

teen vaikutusaluetta. [BKS04]

Tutkielman tutkimusosassa kohdeorganisaationa on yliopistollinen sairaala ja konteksti-

na terveydenhuollon konteksti.

2.2.3 Vaatimusmäärittely

Vaatimusmäärittelyn (requirements specification) tarkoituksena on analysoida asiak-

kailta kerätyt vaatimukset muotoon, joiden pohjalta tietojärjestelmää lähdetään toteut-

13

tamaan. Määrittelyprosessin avulla pyritään selvittämään projektin tarpeellisuus ja to-

teuttamiskelpoisuus, sekä laatimaan ratkaisumallit.

Vaatimusmäärittelyn rakenne voidaan jakaa Haikalan ja Märijärven [HaM06] mukaan

kahteen vaiheeseen, asiakasvaatimusten kartoittamiseen (esitutkimus) ja järjestelmän

määrittelyyn (ohjelmistovaatimusten määrittely). Tutkielman yhteydessä suoritetussa

pilotissa pääpaino on vaatimusmäärittelyn näkökulmasta esitutkimuksessa (require-

ments analysis). Varsinaista tietojärjestelmää ei lähdetty toteuttamaan vaan tarkoitukse-

na oli kohdeorganisaation toiminnan ja työympäristön keskeisten prosessiketjujen hah-

mottaminen ennen käyttöönottoa.

2.3 Osallistavan suunnittelun toteuttaminen

Osallistava suunnittelu nähdään epäyhtenäisenä viitekehyksenä, joka tarjoaa laajan

skaalan käytännönläheisiä menetelmiä aktiivisen, käyttäjän merkitystä korostavan,

suunnittelun toteuttamiselle [Cra98]. Crabtreen mukaan näitä erilaisia menetelmiä voi-

daan käyttää joko yksitellen osallistavan suunnittelun eri vaiheissa tai vaihtoehtoisesti

tiiviisti yhteistyössä läpi suunnitteluvaiheen.

Osallistavan suunnittelun läpivienti vaatii usein tilanteeseen mukautuvia työskentely-

menetelmiä läpiviennin toteuttajilta. Jeanette L. Blombergin mukaan Skandinaavinen

näkökulma korostaa, että jokainen suunnittelutilanne on yksilöllinen tapahtuma

[MBJ91]. Kehittämisprosessin aikana tapahtuvan vaatimusten keräämisen vaiheita käyt-

täjien osallistamiseksi voidaan kuvata Coughlanin ja muiden esittämällä neliulotteisella

metodologialla [CoM02].

14

Kuva 1. Neliulotteinen metodologia osallistamiseen, mukaillen [CoM02]

Kuvan 1 metodologia esittelee eri lähestymistapojen sisältämät teemat, jotka suunnitte-

luprojektin vaatimustenkeräysvaihe sisältää. Metodologian sisältämät teemat toimivat

myös käyttäjien ja suunnittelijoiden välisten toimenpiteiden ohjaajana [CoM02].

Coughlanin esittelemät teemat on esitelty tarkemmin seuraavissa luvuissa.

2.3.1 Käyttäjien osallistaminen ja valinta

Jokainen suunnitteluprojekti alkaa osallistujien valitsemisella. Oikeiden henkilöiden

saaminen osalliseksi vaatimustenkeräysvaiheessa on tärkeää. Osallistavan suunnittelun

näkökulmasta paras mahdollinen tulos saadaan, jos osallistuvat henkilöt edustavat orga-

nisaatiota mahdollisimman monipuolisesti työtehtävien, vastuiden ja koulutuksen osalta.

[BeH98]

Valittavat henkilöt tulee Bødkerin [BKS04] mukaan valita seuraavien ominaisuuksien

mukaan:

1. Osallistujalla tulee olla laaja osaaminen ja kokemus tarkastelun alla olevasta alu-

eesta. Hänen pitää olla keskeisessä asemassa tarkasteltavan työn piirissä ja hä-

nen tulee omata näkemys kaikkiin prosessiketjun osiin. Myös uuden tietojärjes-

telmän tarjoamien mahdollisuuksien ymmärtäminen työn kehittäjänä tulee hah-

mottaa.

15

2. Osallistujan tulee olla muun henkilöstön puolelta arvostettu ja luotettu henkilö.

Hyvät suhteet muuhun henkilöstöön ovat edellytys tiedon liikkumiselle.

3. Osallistujan tulee olla sitoutunut suunnitteluprojektiin. Ketään asianomaista ei

tule pakottaa osalliseksi projektiin. Jos valittu henkilö kokee tulleensa pakote-

tuksi, ei sitoutumista pääse syntymään.

4. Valittujen käyttäjien ei tule olla teknologian tehokäyttäjiä eikä päinvastoin tek-

nologian vastustajia.

Käyttäjien ja suunnittelijoiden välisen yhteistyön onnistumisen taustalla on kuitenkin

johdon sitoutuminen toteutettavaan suunnitteluprojektiin [BKS04]. Johdon sitoutumista

esimerkiksi laadunhallintajärjestelmän kehittämiseen määritellään ISO 9000 standardis-

sa seuraavasti:

"Johdon tulee osoittaa sitoutumisensa laadunhallintajärjestelmän kehittämiseen ja to-

teuttamiseen sekä sen vaikuttavuuden jatkuvaan parantamiseen seuraavasti:

1. Viestimällä organisaatiolle asiakasvaatimusten ja lakisääteisten vaatimusten

tärkeydestä

2. Määrittelemällä laatupolitiikkaa.

3. Varmistamalla, että laatutavoitteet asetetaan.

4. Suorittamalla johdon katselmukset.

5. Varmistamalla, että tarvittavat resurssit ovat käytössä". [SFS01]

Johdon tulee antaa osapuolille tarvittava aika osallistavan suunnittelun läpiviemiseksi.

Johdon tuki osapuolten välisen yhteistyön toteuttamiseksi voi toteutua esimerkiksi käyt-

täjien vapauttamisella omasta arkityöstään suunnitteluprojektin ajaksi. Näin käyttäjät

voivat osallistua täysipainoisesti uuden tietojärjestelmän tuomien haasteiden selvitys-

työhön. Mahdolliset aikataulujen ylitykset aiheuttavat kuitenkin usein poikkeamia ky-

seiseen järjestelyyn; käyttäjät palaavat tekemään normaalia päivätyötään ja ajan järjes-

täminen osallistavan suunnittelun toteuttamiselle hankaloituu. [BKS04]

Käyttäjien osallistuminen suunnitteluprojektiin voidaan jakaa kahdelle tasolle: makro-

ja mikrotasolle. Makrotasolla käyttäjän osallistumista tarkastellaan näkökulmasta, joka

16

korostaa käyttäjän tuoman tiedon hyödyllisyyttä ja saadun tiedon hyödynnettävyyttä

tavoitellun lopputuloksen (valmiin tietojärjestelmän) saavuttamiseksi. Keil ja Carmel

[KeC95] toteavat osallistavan suunnittelun olevan käyttäjien suhteen makrotasolla toi-

mivaa. Mikrotasolla tarkastelu kiinnittyy johonkin tiettyyn menetelmään vaatimusten

keräämiseksi. Keskeisimmät menetelmät on esitelty tutkielman kolmannessa luvussa.

Makro - ja mikrotason ominaisuuksia yhdistelemällä pystytään hyödyntämään molem-

pien tasojen vahvuuksia ja tuloksena saadaan käyttäjien osallistamiseksi paras mahdol-

linen lopputulos. [KeC95]

2.3.2 Käyttäjä-suunnittelija vuorovaikutus

Käyttäjän ja suunnittelijan välisen yhteistyön onnistumisesta riippuu, kuinka hyvin ja

yksityiskohtaisesti haluttuja tietoja pystyään keräämään. Kohdealueen konteksti tulee

käydä yksityiskohtaisesti läpi jokaisen käyttäjän kohdalta [BeH95]. Käyttäjän ja suunnit-

telijan välisen vuorovaikutuksen tärkein vaatimus on molempien puolien tasa-arvoisuus

vaatimustenkeräysvaiheessa, sillä vain tämä mahdollistaa molempia osapuolia tyydyttä-

vän lopputuloksen [CoM02].

Käyttäjän ja suunnittelijan välisen vuorovaikutuksen muodot jaetaan suoriin (direct

links) ja epäsuoriin. Suorassa vuorovaikutuksessa kommunikoinnin muoto osapuolten

välillä tarjoaa tarkemman kuvauksen välitettävästä tiedosta, sillä vääristymiä ei pääse

syntymään kolmannen osapuolen kautta. Suora, kasvotusten tapahtuva yhteys mahdol-

listaa myös sanattoman viestinnän (äänenpainot, ilmeet, eleet) välittymisen osapuolten

välillä. [KeC95]

Epäsuorassa vuorovaikutuksessa yhteys tapahtuu osapuolten välissä olevan ryhmän (in-

termediaries) tai yksittäisen henkilön, joka toimii sijaiskäyttäjänä (customer surrogate),

kautta. Osapuolten välisen vuorovaikutuksen muodoksi suositellaan käytettäväksi suo-

raa yhteyttä, erityisesti kun kyseessä on tulkinnanvaraisuutta sisältäviä asioita, esimerk-

kinä tietojärjestelmään haluttavien vaatimusten keräys. [KeC95]

Osapuolten välinen vuorovaikutus voidaan nähdä asetelmana, jossa suunnittelija toimii

käyttäjän oppipoikana. Erityisesti Contextual Design lähestyy suunnitteluprosessia isän-

tä-oppipoika näkökulmasta [BeH98]. Tämän ajattelutavan mukaan käyttäjä nähdään

oman työnsä ammattilaisena, joka jakaa tietoaan ja osaamistaan suunnittelijalle

[BeH95].

17

Käyttäjän ei tarvitse opettaa suunnittelijaa perinteisillä menetelmillä, vaan oppiminen

tapahtuu tarkkailemalla käyttäjän työtä. Työnteon ohessa syntyvä keskustelu ja toteutet-

tavien toimenpiteiden tarkoituksen kertominen ovat isäntä-oppipoika menetelmän op-

pimiskeinoja [BeH98]. Omat haasteensa erilaisten roolien asettamiselle luovat molem-

pien osapuolten oma erikoisosaaminen, jota ei ole helppo jättää taka-alalle. Oman näkö-

kulman muuttaminen saatetaan kokea hankalaksi [CoM02].

Käyttäjien osallistamiseksi voidaan käyttää Kensingin ja muiden esittämää mallia (Tau-

lukko 1). Malli tarjoaa käyttäjien ja suunnittelijoiden välille erilaisia keskusteluaihioita.

Kolme aluetta, joilta tietoa tulee kartuttaa, ovat käyttäjien nykyinen työ, uuden järjes-

telmän mahdollisuudet ja tekniset mahdollisuudet [BKS04].

Taulukko 1. Tiedon kuusi ulottuvuutta käyttäjä-suunnittelija vuorovaikutuksessa, mukaillen [BKS04]

Käyttäjien nykyinen työ Uusi järjestelmä Tekniset mahdollisuudet

Abstrakti tieto Keskeiset rakenteet käyttäjien

nykyisessä työssä

Visiot ja kehitys-

ehdotukset

Yleiskuva teknisistä

vaihtoehdoista

Konkretian tunte-

mus

Kokemus käyttäjien nykyises-

tä työstä

Kokemus uudesta

järjestelmästä

Kokemus teknisistä

vaihtoehdoista

Malli vaatii tuekseen kahta erilaista tietämyksen tyyppiä. Abstrakti tieto tarjoaa yleisku-

van aihepiiristä ja konkreettinen näkökulma vaaditaan tukemaan abstraktiolla saavutetun

tiedon selvittämistä [KeM93]. Abstraktin tiedon hankkiminen tapahtuu erilaisten työtä

koskevien kuvausten ja mallinnuksien avulla.

Käyttäjien nykyinen työ sisältää tietoa tuotteista ja palveluista, sekä syyt ja menetelmät

tiettyjen toimenpiteiden toteuttamiseen. Osallistavassa suunnittelussa on tärkeää, että

suunnittelijat, jotka ovat suunnittelutyötä toteuttamassa, ymmärtävät ja kunnioittavat

kohdeorganisaatiossa vallitsevia toimintatapoja. Nykytilanteen kartoituksessa on tärkeää

ymmärtää vallitsevan käytännön tarkoitus ja syyt sen taustalla. [KSB98] Työntekijöiden

keskinäiset suhteet ovat myös keskeisiä selvitystyön kohteita kohdeorganisaation toi-

mintatapoja selvitettäessä.[BKS04].

18

Uusi järjestelmä käsittelee työn uudelleensuunnittelun näkökulmasta työtoimintaan ja -

tapoihin kohdistuvia muutoksia [KeM93]. Kensing ja muut tarjoavat erityisesti työtoi-

minnan kehittämiseen menetelmiä, kuten seinätaulutekniikkaa, tulevaisuustyöpajoja ja

tietovirtakaavioita. Tässä tutkielmassa kyseisiä menetelmiä esitellään tarkemmin luvus-

sa 3. Selvityksen apuna käytettävät abstraktit menetelmät (esimerkiksi skenaariot) eivät

aina tarjoa riittävän tarkkaa tietoa ehdotettujen ideoiden toteuttamiskelpoisuudesta. Täl-

löin avuksi tulee ottaa lähempänä reaalimaailma olevia menetelmiä, kuten prototyypit.

Tekniset mahdollisuudet kytkevät aikaisemmat kokemukset tietojärjestelmien käytöstä

uuteen tilanteeseen ja teknologisten järjestelmien käyttöön [BKS04]. Bødker ja muut

huomauttavat, että joitain ilmiöitä ja asioita voidaan ymmärtää ja huomata pelkästään

silloin, kun niihin kohdistetaan muutoksia.

2.3.3 Viestinnälliset toimenpiteet

Tilanteissa, joissa osallistava suunnittelu ei ole tuottanut toivottua tulosta, on epäonnis-

tumisen syiksi usein esitetty esimerkiksi käyttäjien ja suunnittelijoiden eriävät näke-

mykset ja osapuolten välinen ymmärtämättömyys projektin aikana. Kyseisten ongelmi-

en ratkaisuun pyritään tarjoamaan usein jotain tiettyä menetelmää, jolla ongelmat pys-

tyttäisiin karsimaan pois. Mikään yksittäinen menetelmä ei kuitenkaan poista tosiasiaa,

jossa kommunikoinnin ja viestinnän puute toimii alustana ongelmien synnylle.

[KeM93]

Hartwick ja Barki liittävät viestinnälliset toimenpiteet tärkeäksi osaksi osallistavaa

suunnittelua ja kehitystyötä. He kuvaavat näitä toimenpiteinä, jotka sisältävät virallisen

(formal) ja epävirallisen (informal) tiedon liikkumista kaikkien projektissa olevien asi-

anomaisten välillä [HaB98]. Waltz [WEC93] esittelee tärkeimmät vaiheet viestinnälli-

sille toimenpiteille:

1. Tiedonhankinta (Knowledge acquisition) - Käyttäjien ja suunnittelijoiden "maa-

ilman" välille tulee rakentaa yhteyksiä, jotta yhteistyö on mahdollista. Yhteydet

voidaan muodostaa esimerkiksi kohteen kontekstin molemminpuolisella ymmär-

tämisellä ja käytettävien osallistavien työskentelytapojen molemminpuolisella

hyväksynnällä.

19

2. Tiedon jakaminen (Knowledge negotiating, sharing) - Vaatimuksista ja kerätyis-

tä tiedoista tulee neuvotella osapuolten välillä aktiivisesti. Tiedon tulee kulkea

osapuolten välillä saumattomasti, jotta käyttäjien ja suunnittelijoiden välillä ta-

pahtuva tiedon liikkuminen on mahdollista toteuttaa.

3. Käyttäjän hyväksyntä (User acceptance) - Käyttäjän ja suunnittelijan välinen yh-

teistyö tähtää molempia osapuolia tyydyttävään lopputulokseen rajoitteiden puit-

teissa. [CoM02]

Suurimmat ongelmat käyttäjien kanssa kommunikoinnissa liittyvät todellisten käyttäjien

tunnistamiseen ja työhön keskeisesti liittyvän tiedon esille tuomiseen [CoM02]. Tarkas-

teltava tieto voidaan jakaa kahteen pääkategoriaan: hiljainen - (tacit) ja eksplisiittinen

tieto (explicit) [Smi01]. Hiljainen tieto käsitetään tiettyyn paikkaan ja ympäristöön si-

toutuvaksi. Sitä ei voi selvittää oppaista, kirjoista eikä tietokannoista [Smi01].

Käyttäjien omaama hiljainen tieto on kehittäjille ensiarvoisen tärkeää, sillä se sisältää

suoria kokemuksia käyttäjien suhteesta työympäristöönsä [Com02]. Eksplisiittinen tieto

käsittää esimerkiksi muodollisesti kirjoitetut akateemiset julkaisut ja patentit [Smi01].

Eksplisiittisen tiedon yksi tärkeimmistä ominaisuuksista on sen sisältämä tiedon vahva

perustelu [CoM02].

2.3.4 Menetelmät

Suunnitteluprojektit eivät koskaan ole keskenään samanlaisia ja niiden toteutumiseen

vaikuttavat tekijät ovat hyvin organisaatiosidonnaisia [BKS04]. Käyttäjien osallistami-

seen ei ole olemassa yhtä "parasta" menetelmää, vaan parhaat vaihtoehdot tulevat esille

vasta suunnitteluprosessin aikana [Ber01]. Keskeisimmistä osallistavan suunnittelun

menetelmistä ja sisällöstä kerrotaan tarkemmin luvussa 3.4. Menetelmät joiden avulla

vaatimuksia lähdetään selvittämään, riippuvat prosessiin käytettävissä olevasta ajasta,

resursseista ja selvitettävien vaatimusten luonteesta. Käyttäjien osallistamiseksi käytet-

tävät menetelmät luokitellaan seuraavasti [NuE00].

1. Perinteiset menetelmät (Traditional tecniques) ovat yleispäteviä menetelmiä

vaatimusten keräämiseen. Menetelminä ovat kyselyt, haastattelut ja olemassa

olevien dokumenttien analysointi.

20

2. Ryhmätyöskentelyssä (Group elicitation tecniques) pyritään osallistamaan asian-

omaiset vaatimusten selvitysvaiheessa. Menetelminä ovat työpajat ja ideapalave-

rit (brainstorming).

3. Protoilua (Prototyping) käytetään erityisesti tilanteissa, joissa vaatimuksista on

epäselvyyttä tai tilanteissa joissa tarvitaan asianomaisten palautetta suunnitte-

lunprosessin alkuvaiheessa. Menetelminä ovat prototyypin kehittämiseen liitty-

vät kyselyt sekä ryhmäkeskustelut, joissa prototyyppi toimii keskustelun ohjaa-

jana.

4. Mallinnusmenetelmien (Model-driven tecniques) tarkoituksena on luoda suun-

nittelua ohjaava tarkennettu malli. Menetelminä ovat erilaiset tulevaisuuden

skenaariot. Suunnittelun apuna voidaan käyttää esimerkiksi sekvenssikaavioita,

joita on hyödynnetty esimerkiksi tutkielman tutkimusosion yhteydessä.

5. Kognitiiviset menetelmät (Cognitive techniques) ovat menetelmien joukko, jolla

alun perin pyrittiin kehittämään menetelmiä tiedon löytämiselle erityisesti eri-

koisjärjestelmille (Knowledge based system). Menetelminä ovat protokollan

analysointi (Protocol analysis), missä ammattilainen tuo esille asioita tehdessään

kohteen työtä. Myös Card Sorting on yleisesti käytetty menetelmä erilaisten työ-

tä koskevien tehtävien ryhmittelyyn ja priorisointiin.

6. Kontekstuaaliset menetelmät (Contextual techniques) ovat 1990-luvulla kehitty-

nyt vaihtoehtoinen menetelmä perinteisille ja kognitiivisille menetelmille. Me-

netelmät sisältävät etnografisia näkökulmia määrittelyvaiheen suorittamiselle,

esimerkkinä käyttäjien havainnointi.

Erilaiset menetelmät tarjoavat hyödyllisiä vaihtoehtoja vaatimustenkeräämiseen käyttä-

jien ja suunnittelijoiden välisessä yhteistyössä. Jokaiseen vaatimustenkeräysprosessiin

tulee löytää paras mahdollinen menetelmä, jonka avulla saavutetaan parhaat tulokset.

Esimerkiksi kontekstuaaliset menetelmät paljastavat käyttäjillä olevan hiljaisen tiedon

(luku 2.3.3) paremmin kuin perinteisemmät menetelmät kuten haastattelut. [CoM02]

Vaatimustenkeräysprosessissa huomio tulisi tiettyjen menetelmien sanatarkan seuraami-

sen sijaan kiinnittää osallistavan suunnittelun alkuperäiseen tarkoitukseen: suunnittelu-

projektin kohteena olevien käyttäjien työympäristön ja työmenetelmien parantamiseen,

21

käyttäjien aktiiviseen osallistamiseen ja yhteistyöhön uusien teknologioiden suunnitte-

lussa, sekä jatkuvan kehittymisen mahdollistavien toimenpiteiden synnyttämiseen.

[MBJ91]

2.4 Osallistavan suunnittelun kohtaamat ongelmat ja kritiikki

Osallistava suunnittelu ei ole saavuttanut suosiota akateemisen maailman ulkopuolella

[Kuu01]. Osallistavan suunnittelun menetelmät ovat erityisesti tuotekehityksessä olleet

vain pienessä roolissa. Tuotekehityksessä suurin paino käyttäjien osalta ovat olleet

suunnitteluprosessin viimeiset vaiheet ennen tuotteen lopullista valmistumista. Kehitys-

kaaren loppuvaiheessa käyttäjät eivät enää pysty vaikuttamaan mielipiteillään ja näke-

myksillään, sillä tässä vaiheessa tuote on jo saavuttanut lähes lopullisen muotonsa

[Kyn94].

Osallistavan suunnittelun menetelmät ovat kuitenkin saaneet kannatusta erityisesti

yleispätevien suunnittelutekniikoiden parissa, jotka tukevat työyhteisöjen demokraattis-

ten toimintatapojen kehittämistä [Cra98]. Korpelan ja muiden mukaan osallistava suun-

nittelu tarjoaa kattavasti kokemuksia ja menetelmiä vapaaseen ja emansipatoriseen tie-

tojärjestelmien kehitykseen, mutta se ei tarjoa menetelmille juurikaan teoreettista taus-

taa. Emansipatorisella tietojärjestelmän suunnittelulla tarkoitetaan työntekijöiden roolin

korostamista käyttämiensä tietojärjestelmien suunnittelutyössä [KMS04].

Muller tuo esille näkökulmia osallistavan suunnittelun leviämiselle Yhdysvaltoihin ja

Iso-Britanniaan. Osallistavan suunnittelun leviämisen esteenä esimerkiksi eri maihin ja

erilaisiin toimintaympäristöihin ovat mahdolliset eroavuudet työntekijöissä, lainsäädän-

nössä, sekä työympäristöissä ja -kulttuureissa [MBJ91]. Wynn ja Nowick [WyN95]

esittelevät koko osallistavan suunnittelun keskeiseen ajatukseen, käyttäjien huomioimi-

seen, liittyvän ongelman. Ongelmaksi voi nousta kysymys, miten voidaan varmistaa

kaikkien käyttäjien osallistuneen ja antaneen kaiken tarpeellisen tietonsa suunnittelupro-

jektia ajatellen.

Wynn ja Nowick esittävät suunnittelijan kohdealueen vahvan tuntemisen ja sosiaaliset

ominaisuudet tärkeänä osana mahdollisimman onnistuneelle osallistavan suunnittelun

läpiviennille [WyN95]. Myös Farrel tuo esille ongelmia osallistavan suunnittelun toteut-

22

tamiseen liittyen. Käyttäjien keskinäiset suhteet ja mielipiteiden esiin saaminen tasapuo-

lisesti voi tuottaa ongelmia. Farrel esittelee esimerkkinä tilanteen, jossa käyttäjät joutui-

vat huutamaan toisilleen, jotta saisivat sanoa oman mielipiteensä käyttöliittymän ulko-

asusta [FFM06].

Osallistava suunnittelu ei itsessään tarjoa vaatimustenkeräämisen ja käyttäjien ja suun-

nittelijoiden väliseen yhteistyöhön tarkkoja ohjeita. Osallistava suunnittelu toimii erään-

laisena viitekehyksenä, jonka avulla osapuolten välistä yhteistyötä voidaan toteuttaa.

Seuraavassa luvussa käsitellään osallistavan suunnittelun ajatusta hyödyntäviä lähesty-

mistapoja, jotka tarjoavat selkeät ohjeet läpiviennille ja käytettäville menetelmille.

23

3 LÄHESTYMISTAPOJA OSALLISTAVAAN SUUNNIT-

TELUUN

Käyttäjäkeskeisten suunnittelumenetelmien pohjalta 1980-luvulla syntyneet osallistavan

suunnittelun lähestymistavat ovat saaneet vuosikymmenten aikana useita eri muotoja ja

näkökulmia. Kaikkia lähestymistapoja yhdistää käyttäjän ja suunnittelijan vuorovaiku-

tus ja suunnitteluprosessin käyttäjälähtöisyys. Osallistavan suunnittelun ideologiaan

keskeisesti nykypäivänä liittyvät lähestymistavat, Contextual Design ja MUST-metodi,

tarjoavat kattavan kuvan osallistavan suunnittelun sisällöstä ja sen eri vaiheista.

Contextual Design ja MUST-metodi ovat tässä tutkielmassa kaksi pääsuuntausta, joiden

avulla osallistavan suunnittelun sisältöä on lähdetty tarkastelemaan. Molemmat valituis-

ta lähestymistavoista sisältävät keskenään hyvin paljon yhtäläisiä menetelmiä ja vaiheita

käyttäjien osallistamiseksi suunnitteluprosessin eri vaiheissa, vaikkakin lähestymistavat

korostavat ja painottavat toisistaan eroavia ajatusmalleja. Tutkielman tutkimusosiossa

esiteltävässä pilotissa käytettyjen menetelmien kohdalla on selkeitä yhtäläisyyksiä ohei-

siin lähestymistapoihin. Yhtäläisyyksiä käsitellään tarkemmin luvussa kuusi. Näiden

lähestymistapojen lisäksi on olemassa useita muitakin lähestymistapoja, kuten JAD,

SSM ja ULRC, joita esitellään lyhyesti tässä luvussa.

Ensimmäisessä luvussa käydään läpi Contextual Designin keskeiset piirteet ja lähesty-

mistavan läpiviennin keskeisimmät vaiheet ja sisältö. Contextual Designia käsittelevä

luku perustuu suurimmaksi osaksi sen kehittäjien, Hugh Beyerin ja Karen Holzblattin,

kirjaan Contextual design: defining customer-centered systems [BeH98]. Contextual

Design on tällä hetkellä ehkä tunnetuin osallistavan suunnittelun lähestymistavoista ja

sen kehittäjät ovat saaneet menestystä myös InContext yrityksensä kautta. Toisessa lu-

vussa käsitellään etnografista ja skandinaavista tyylisuuntaa esikuvanaan pitävää

MUST-metodia. MUST-metodin osuus tutkielmassa perustuu sen kehittäjien, Keld

Bødker, Finn Kensing ja Jesper Simonsen, julkaisemaan teokseen Participatory IT de-

sign: designing for business and workplace realities [BKS04].

Kolmannessa luvussa tarkastellaan Contextual Designin ja MUST-metodin rinnalla ole-

via muita osallistavaan suunnitteluun ja käyttäjäkeskeiseen ajatusmaailmaan pohjautu-

via lähestymistapoja. Näiden lähestymistapojen kohdalla huomio kiinnittyy niiden sisäl-

24

tämiin mahdollisiin erikoispiirteisiin ja käyttökokemuksiin, joihin tämän tutkielman

kaksi pääsuuntausta eivät ota kantaa yhtä tarkasti. Neljäs luku käsittelee esiteltyjen lä-

hestymistapojen sisältämiä menetelmiä osallistavan suunnittelun toteuttamiseksi. Esitel-

tävät menetelmät ovat keskeisimpiä osallistavaan suunnitteluun yhdistettäviä menetel-

miä.

Viimeisessä luvussa esitellyistä lähestymistavoista tehdään yhteenveto ja vertaillaan

esiteltyjä lähestymistapoja sekä tarkastellaan niiden sisältämiä eroja, yhtäläisyyksiä ja

rakennetta myös esiteltyjen menetelmien osalta. Vertailua tehdään toteutuneiden suun-

nitteluprojektien pohjalta, joiden läpiviennin apuna on käytetty kyseisiä osallistavan

suunnittelun näkökulmaa.

3.1 Contextual Design

Contextual Design on lähestymistapa tietojärjestelmien ja laitteistojen suunnitteluun, se

kokoaa suunnittelun avuksi useita käyttäjälähtöisiä menetelmiä yhtenäiseksi ryhmäksi.

Contextual Designin ovat kehittäneet 1990-luvun alussa Hugh Beyer ja Karen Holzblatt.

Contextual Design on kehitetty Yhdysvalloissa ja sen perustana on osallistavan suunnit-

telun viitekehys, joka on alun perin muotoutunut Skandinaavisen suuntauksen pohjalta.

Skandinaavisesta suuntauksesta on kerrottu tarkemmin luvussa 2.1. [BeH98, Kuu03]

Contextual Designin suhtautuminen suunnittelu- ja kehitysprosessiin lähtee liikkeelle

käsityksestä, jonka mukaan kaikki tietojärjestelmät kuvaavat jotain tiettyä tapaa tehdä

työtä. Lähestymistapa tarjoaa tietojärjestelmien suunnittelijoille menetelmiä, joiden

avulla pystytään muodostamaan yhteinen näkemys käyttäjien tarpeista ja suunnittelu-

menetelmistä tietojärjestelmän toteuttamiseksi. [BeH99]

Erityinen painoarvo on ensimmäisillä vaiheilla, sillä sieltä saadut tulokset heijastuvat

läpi koko suunnitteluprosessin. Contextual Designin sisältämät seitsemän eri vaihetta on

esitelty kuvassa 2. Vaiheiden läpiviennistä saadaan paras mahdollinen tulos käyttämällä

mahdollisimman suurta osaa osallistavista menetelmistä. Contextual Design soveltuu

myös kevyemmissä esiselvityksissä käytettäväksi, joissa voidaan käyttää vain osaa esi-

teltävistä vaiheista ja menetelmistä. Kevyempiin osallistavan suunnittelun projekteihin

suositellaan käytettäväksi esimerkiksi havainnointia. [Kuu03]

25

Contextual designin vaiheita voidaan tarvittaessa lyhentää ja sovittaa kohdeorganisaa-

tion tarpeisiin sopiviksi. Esimerkkinä Beyer ja Holtzblatt antavat erilaisten menetelmien

soveltamisen kuhunkin tilanteeseen sopiviksi. Jokaisella vaiheella on asetettu tietty ta-

voite ja näiden tavoitteiden kautta myös vaiheita tulisi lähestyä. [BeH99]

Kuva 2. Contextual Designin vaiheittainen eteneminen, mukaillen [Kuu03]

Contextual Designin vaiheet ja keskeinen sisältö [BeH98, BeH99, Kuu03]:

1. Kontekstuaalisessa haastattelussa (Contextual Inquiry) käyttäjiä haastatellaan ja

tarkkaillaan heidän omassa työympäristössään. Käyttäjiä tarkkaillaan tekemässä työ-

tään ja heiltä kysytään tapahtuvasta työnteosta. Selvitettäviä asioita ovat esimerkiksi

työn tarkoitus, keinot työtehtävien toteuttamisessa ja työn tekemiseen liittyvät vai-

keudet.

Haastattelutilanteessa suunnittelijoiden ei ole varsinaisesti tarkoitus oppia tekemään

käyttäjien työtä vaan heidän tehtävänään on suunnitella millä apuvälineillä (esimer-

kiksi teknologiaan liittyvät apuvälineet) työtä voitaisiin tukea. Kontekstuaalisen

haastattelun jälkeen suunnitteluryhmä yhdistää tehdyt havainnot ja luo suunnittelu-

ryhmälle yhtenäisen näkemyksen tarkkaillusta kohteesta. Yhteinen näkemys tarjoaa

tietoa suunniteltavan tietojärjestelmän toteuttamiseen. Havaintojen yhdistämisen

apuna käytetään vaiheessa kaksi esiteltäviä menetelmiä. [BeH98, BeH99]

26

2. Työn mallintamisen (Work Modeling) tavoitteena on konkreettisten mallien luomi-

nen käyttäjien työstä. Työnkulun mallintamisella pyritään saamaan selkeä ja yhte-

näinen kokonaiskuva keskeisimmistä työprosesseista ja niissä käytettävistä välineis-

tä ja liikkuvasta tiedosta.

Contextual Designin tarjoamista malleista tunnetuimpia ovat työvirtakaavio (work

flow), sekvenssikaaviot (sequence model) ja artifaktimalli (artifact model). Malleja

esitellään tarkemmin tutkimusosion tuloksissa, joissa kuvataan miten yliopistollisen

sairaalan työtä kuvattiin pilottiosastoilla.

3. Mallien yhteensovittamisen (Consolidation) tarkoituksena on koota ja yhdistää käyt-

täjiltä kerättyä tietoa. Koonnin avulla voidaan alkaa rakentamaan kaikkia käyttäjiä ja

heidän työtään koskevia malleja ja kokonaisuuksia. Yhteensovittamisvaiheen suurin

haaste on suunnitella mallit koskemaan koko käyttäjäkuntaa, kun toisaalta yksittäi-

sen käyttäjän tarpeet tulisi huomioida mahdollisimman hyvin. Tietojärjestelmän

suunnittelussa käyttäjien tarpeiden riittävän tarkan huomioimisen edellytyksenä on

huomion kiinnittäminen käyttäjän tekemään työhön. Esimerkiksi motivaatio tietyn,

yksittäisen työtoimenpiteen suorittamiselle on tämän vaiheen selvityskohteena.

Mallien yhteensovittamisessa hyödynnetään menetelmiä, joiden avulla yleisiä ra-

kenteita ja yksittäisen käyttäjän työstä löydettäviä yleistyksiä pystytään tekemään.

Yksi yleisten rakenteiden selvittämiseen tarkoitettu tunnettu menetelmä on saman-

kaltaisuusseinä (Affinity diagram).

Samankaltaisuusseinä sisältää kaikista käyttäjistä (toimijat) ja heidän suorittamis-

taan työtoiminnoista muodostetun koosteen. Havaitut työtoimenpiteiden ketjut jae-

taan edelleen pienempiin osiin, jotka tarkentavat kunkin käyttäjän tekemiä yksittäi-

siä tehtäviä. Samankaltaisuusseinä antaa tietoa myös keskeisten työtapojen vaatimis-

ta välineistä ja toimenpiteistä. Luvussa kuusi samankaltaisuusseinää esitellään tar-

kemmin myös pilotin näkökulmasta.

4. Työn uudelleensuunnittelulla (Work redesign) tähdätään tilanteeseen, jossa uusi

tietojärjestelmä mahdollistaa käyttäjille uuden ja paremman tavan tehdä työtä. Ehto-

na työn uudelleensuunnittelulle on saada ymmärrys käyttäjien työn rakenteesta ja

siihen suoraan vaikuttavista tekijöistä sekä työn tarkoituksesta.

27

Vain riittävän kattava esiselvitys tarjoaa suunnittelijoille tarvittavan tiedon tär-

keimmistä kehityskohdista. Työn ja työtapojen kokonaisvaltainen uudelleensuunnit-

telu vaatii luovaa ajattelua kehityksen synnyttämiseksi. Esimerkiksi tietojärjestel-

män vaatimat laiterajoitukset eivät saisi nousta hallitsevaksi ajatusten ohjaajaksi

suunnitteluprosessin tässä vaiheessa. Suunnittelu- ja toteutusprosessin tekijöiksi

voidaan käyttää eri henkilöitä. Tällä tavalla vältytään toteuttajien tekemältä suunnit-

teluprosessilta, joka tähtää vain ja ainoastaan mahdollisimman helppoon toteutusta-

paan. [Kuu03]

Työn uudelleensuunnittelun keskeisenä menetelmänä toimii työpajatyöskentely.

Työn uudelleensuunnittelun tuloksena voidaan tehdä myös toimintatarinoita (story-

boards). Toimintatarinat tarjoavat vision, siitä mitä tulevan järjestelmän tulisi olla ja

miten sitä tullaan käyttämään ja missä ympäristössä. Toimintatarinan ei kuitenkaan

tule ottaa kantaa siihen, miten uusi järjestelmä tulisi tehdä.

Menetelmän vahvuus on sen työkontekstiin liittyvässä näkökulmassa, jossa työ on

kaiken lähtökohtana. Toimintatarina (katso [Min04]) voi olla esimerkiksi piirros tie-

tyn toiminnan käyttöliittymästä tai järjestelmän kanssa tekemisissä olevan henkilön

tarina järjestelmän käyttöön liittyen.

5. Käyttäjäympäristön suunnittelun (User environment design) tarkoitus on saada tie-

tojärjestelmän käyttö liittymään mahdollisimman sujuvasti luonnolliseen työnkul-

kuun. Tässä vaiheessa olennaisempaa on tietää, mitä järjestelmä tekee, kuin esimer-

kiksi käyttöliittymän toteutukseen liittyvien vaatimusten selvittäminen.

Jokaisella tietojärjestelmällä on omat ominaisuudet ja käyttäjäympäristönsä. Käyttä-

jäympäristön suunnittelu paljastaa järjestelmän kaikki osat ja käyttäjän saamaan

hyödyn järjestelmän kunkin osan käyttämisestä. Kaikista järjestelmän osista selvite-

tään myös kunkin osan tarjoamat toiminnot ja miten näitä toimintoja voidaan käyt-

tää [Kuu03].

Käyttäjäympäristön suunnitteluun liittyvä menetelmä, käyttöympäristön takaisin-

mallinnus (Reverse User Environment Design), antaa hyviä tuloksia erityisesti ny-

kyisessä järjestelmässä esiintyvien käytettävyysongelmien löytymiselle. Menetelmä

soveltuu myös erilaisten järjestelmien vertailuun uuden hankkimista suunniteltaessa.

Peruuttava käyttäjäympäristön suunnittelu on myös hyvä lähtökohta uuden järjes-

28

telmän kehitystyölle, sillä se paljastaa edellisen version heikkoudet ja vahvuudet.

Apuna voidaan käyttää edellisessä vaiheessa esiteltyjen toimintatarinoiden kaltaisia

tilannekuvauksia.

6. Prototyyppien valmistus ja testaus (Mock-up and test with customers) on tärkeä osa

kaikkien järjestelmien kehitystä. Testaus tulisi aloittaa mahdollisimman aikaisessa

vaiheessa, jotta kehityksen kannalta tärkeitä kehityskierroksia päästäisiin toteutta-

maan nopeammin. Iteraation avulla tavoiteltavat ominaisuudet tarkentuvat ja tulevat

selkeämmin esille. Vaiheen tarkoituksena on löytää ja korjata uuteen järjestelmään

mahdollisesti liittyviä virheitä ennen kuin varsinaista ohjelmaa aletaan ohjelmoida.

Testaus osallistaa myös käyttäjiä suunnitteluprosessissa ja tekee heistä tärkeän osan

suunnittelutiimiä.

Paperiprototyypit ovat hyvä keino esimerkiksi käyttöliittymien mallintamiseen. Pro-

totyyppejä suositellaan tehtäväksi paperiversioina, sillä ne ovat nopeita ja helppoja

valmistaa. Paperiprototyypit koetaan helposti lähestyttäviksi ja käyttäjät uskaltavat

tuoda mielipiteitään julki helpommin paperiversioihin, kuin valmiiksi tehtyyn, hie-

noon ja uuteen sähköiseen versioon. Paperiversioiden nopea päivitettävyys ja helppo

hallittavuus koetaan myös menetelmän eduksi.

7. Toimeenpano (Putting into practice) on viimeinen vaihe järjestelmän toteuttamises-

sa, jossa hyödynnetään aikaisemmissa vaiheissa saatuja tuloksia ja tietoja. Konteks-

tuaalisen suunnittelun näkökulma suosittaa suunnittelun ja toteutuksen jakamista eri

tahoille, joten mahdolliset epäselvyydet osapuolten välillä tulee selvittää tarkasti.

Beyerin ja Holtzblattin [BeH99] mukaan Contextual Design lähestyy suunnitteluproses-

sia front end näkökulmasta. Front end korostaa käyttäjiltä saatavia tietoja ja kokemuksia

suunniteltavan tietojärjestelmän pohjana. Tämä antaa suunnitteluprojekteille mahdolli-

suuden mukautua jokaiseen suunnitteluprosessiin sopivaksi. Myös muut osallistavan

suunnittelun lähestymistavat voidaan katsoa edustavan käyttäjät huomioivaa front end -

näkökulmaa.

29

3.2 MUST

Etnografinen ja Skandinaavinen näkökulma osallistavaan suunnitteluun ovat olleet suu-

rilta osin vaikuttamassa pääosin 1990-luvulla kehitetyn MUST-metodin syntyyn.

MUST-metodi on kehittynyt nykyiseen muotoonsa kymmenien tanskalaisissa ja yhdys-

valtalaisissa organisaatioissa tehtyjen projektien pohjalta. MUST-metodin keskeinen

ajatus on tarjota käsitteellinen viitekehys suunnitteluprojektin tueksi.

Kensingin ja muiden mukaan tämä ajatusmalli laajentaa aikaisempia näkökulmia, kuten

käynnissä olevan ohjelmiston ominaisuuksiin keskittymistä tai pelkästään yksittäisen

käyttäjän huomioimiseen kohdistuvia toimenpiteitä [KSB98]. Bødker ja muut korosta-

vat, että MUST-metodin osa-alueet tulisi nähdä tietojärjestelmien suunnittelua ja läpi-

vientiä tukevina toimenpiteinä, ei erillisenä prosessina [BKS04].

MUST-metodi tarjoaa johdonmukaisen lähestymistavan osallistavan suunnittelun to-

teuttamiseksi. Useimpien osallistavan suunnittelun lähestymistapojen tapaan MUST

keskittyy suunnitteluprosessin alkuvaiheeseen liittyviin tehtäviin. MUST-metodin sisäl-

tämät menetelmät tulisi nähdä vapaamuotoisina, erityisesti käyttäjiin kohdistuvissa sel-

vitystöissä. Esimerkkeinä vapaamuotoisista menetelmistä voidaan antaa vapaalla kädel-

lä piirrettävät hahmotelmat sekä helppoa ja yksinkertaista tekstiä sisältävät kuvaukset.

Tarkoituksena on tuottaa kuvauksia, joiden toteuttamiseen myös käyttäjien on vaivaton-

ta osallistua. MUST-metodi korostaa suhteiden luomista ja ylläpitämistä toimivaan joh-

toon tärkeänä, erityisesti suunnittelun tapahtuessa organisaation kontekstissa. [KSB98]

MUST-metodin sisältämät näkökulmat, jotka ohjaavat projektiryhmää tietojärjestelmän

suunnittelun ja toteutuksen aikana on esitetty kuvassa 3.

30

Kuva 3. MUST-metodin neljä näkökulmaa IT suunnittelun tueksi, mukaillen [BKS04].

MUST-metodin sisältämät käsitteet tarjoavat tarkat määrittelyt projektin etenemisestä,

suunnitteluprojektista ja sen tuloksista sekä nykyiseen tietojärjestelmään liittyvistä sei-

koista. Kohdealueen tarkentaminen sekä keskeisten käyttäjien selvittäminen liittyvät

MUST-metodin käsite osaan.

MUST-metodin sisältämien menetelmien ja työkalujen sisältö on suurimmaksi osaksi

yhteneviä esimerkiksi Contextual Designin kanssa. Keskeisimmiksi menetelmiksi nou-

sevat haastattelut, havainnoinnit ja työpajat.

Käsitteet sekä menetelmät ja työkalut tarjoavat edellytyksiä lähestymistavan toteuttami-

selle [BKS04]. MUST-metodin toteuttamiseen liittyvät keskeiset periaatteet ja läpivien-

nin neljä vaihetta on esitelty tarkemmin seuraavissa aliluvuissa.

3.2.1 Periaatteet

MUST-metodi rakentuu neljän periaatteen ympärille, jotka tukevat tietojärjestelmän

suunnittelu- ja käyttöönottovaiheen prosesseja. Periaatteiden tulisi olla koko suunnitte-

luprojektille suunnannäyttäjiä, sillä ne heijastuvat projektin kaikissa vaiheissa niin käyt-

täjille kuin suunnittelijoille.

31

1. Yhteinen näkemys - Uuden tietojärjestelmän käyttöönotossa organisaatiossa synty-

vän muutoksen hallitsemiseksi voidaan apuna käyttää yhteisen näkemyksen mallia.

Yhteisen näkemyksen näkökulman tulisi huomioida tekninen, organisatorinen ja

hyödynnettävyyden näkökulma. MUST menetelmän vaiheet ohjaavat suunnittelijoi-

ta pitkin prosessia tarkistamaan, ollaanko menossa oikeaan suuntaan.

Yhteinen näkemys muodostuu tietojärjestelmän, organisaation ja käyttäjien suhtees-

ta (Kuva 4), jossa kaikkiin tekijöihin kohdistuvia muutoksia tulee tarkkailla. Yhtei-

sen näkemyksen seuraamisella voidaan pystyä vähentämään esimerkiksi budjetti- ja

aikatauluylityksiä. [BKS04]

Kuva 4. Yhteisen näkemyksen kolme ulottuvuutta, mukaillen [BKS04].

Yhteisen näkemyksen saavuttamiseksi osapuolten tulee pystyä keskustelemaan

avoimesti ja mahdolliset virheet tulisi huomioida ja tarjota niihin korjausehdotuksia.

Yhteisen näkemyksen muodostumiseksi käytettäviä menetelmiä ovat esimerkiksi

skenaariot, prototyypit, työpajat tai tietojärjestelmän testaaminen todellisessa käyt-

töympäristössä. [BKS04]

2. Aito käyttäjien osallistaminen - Kaikkien asianomaisten saaminen mukaan kehitys-

työhön on osallistamisen näkökulmasta tärkeää [BKS04]. Bødker jakaa osallistami-

sen lähtökohdat pragmaattiseen (Pragmatic) ja poliittiseen (Political). Pragmaatti-

nen näkökulma korostaa käytännönläheistä vuorovaikutusta käyttäjien ja suunnitteli-

joiden välillä. Suunnittelijat saavat tietoa käyttäjien työympäristöstä ja sen tuomista

mahdollisista rajoitteista. Käyttäjät vastaavasti saavat mahdollisuuden nähdä erilais-

ten teknologisten mahdollisuuksien tarjoamia etuja. Tämänkaltainen molemminpuo-

linen oppiminen on osallistavan suunnittelen keskeinen voimavara. Poliittinen läh-

tökohta osallistavaan suunnitteluun korostaa käyttäjien oikeutta päästä osallistumaan

heitä ja heidän työtään keskeisesti koskevien muutoksien suunnitteluun.

32

3. Omakohtaiset kokemukset työkäytännöistä - Uusien, projektin kannalta tärkeiden

näkemyksien hankkimiseksi MUST esittelee kolme tapaa [BKS04]: Kohteen opiske-

lu, asianomaisten näkemykset ja omakohtainen oppiminen. MUST metodi korostaa

erityisesti omakohtaista oppimista tiedon hankkimisessa. Kahta ensiksi mainittua ta-

paa käytetään MUST-metodissa erityisesti menetelmien kohdalla. Kaikkia tapoja

yhdistää niiden toteuttamisen jälkeen tapahtuva hankitun tiedon analysointi ja esit-

täminen.

Bødkerin mukaan dokumenttien ja haastattelun kautta oppiminen tulisi käsitellä eril-

lisenä muista osallistavista menetelmistä. Havainnointien, paikan päällä tapahtuvan

haastattelun ja avoimen keskustelun erottamiselle edellisistä menetelmistä Bødker

antaa esimerkkinä tilanteen, jossa käyttäjä "sanoo yhtä ja tekee toista" (say-do prob-

lem). Käyttäjä saattaa kertoa tekevänsä asiat tietyllä tavalla, mutta vasta kyseisen

toimenpiteen konkreettisen toteuttamisen näkeminen paikan päällä vahvistaa käyttä-

jän kertomat asiat. [BKS04]

4. Visioiden yhtenäistäminen - Visioiden yhtenäistämisessä keskeistä on kohderyhmäl-

le suuntautuva tiedottaminen projektin tilanteeseen, visioihin ja suunnitelmiin liitty-

en. Visioiden yhtenäistäminen tulisi nähdä koko projektia ohjaavana mallina. Tässä

kohderyhmällä tarkoitetaan kaikkia niitä, jotka pystyvät tarjoamaan suunnittelupro-

jektille lisäarvoa ja joita toteutus koskee. Visioiden yhtenäistämisen vaihe selvittää

projektiryhmän suhdetta käyttäjiin suunnitteluprojektin eri vaiheissa. [BKS04]

Bødkerin mukaan ehdotetut muutokset tulee huomioida erityisesti päättävän toimi-

kunnan, henkilökunnan ja johdossa olevien henkilöiden näkökulmasta. Eri ryhmiä

ovat:

1. Päättävä toimikunta ja muu hallinto, jolla on päätöksentekoon vaadittavaa

kompetenssia, osallistuu suositusten ja tuloksien käsittelyyn.

2. Henkilökunta ja asianomaiset, jotka tulevat käyttämään kuviteltua järjestel-

mää tai ovat siihen välittömästi tai välillisesti yhteydessä.

3. Johdossa olevat henkilöt, jotka ovat vastuussa teknisestä ja organisatorisesta

muutoksesta suunnitteluprojektiin liittyen.

33

Yleisesti ottaen MUST-metodin periaatteet antavat suuntaa kohdista, joihin huomiota

tulisi kiinnittää suunnitteluprosessissa. Bødker ottaa listauksessa huomioon myös käyt-

töönottoon liittyviä seikkoja, mikä tuo MUST-metodin lähemmäksi tutkimusosiossa

käsiteltävää pilottia. Käyttöönoton kannalta huomion kohteena ovat esimerkiksi käyt-

töön otettavan tietojärjestelmän eri käyttäjäryhmien tarpeiden tunnistaminen.

3.2.2 Jako neljään vaiheeseen

MUST-metodin läpivienti jaetaan neljään vaiheeseen, jotka sisältävät suosituksia siitä,

miten organisaatio pystyy mahdollisimman kokonaisvaltaisesti osallistumaan suunnitte-

luprojektin läpivientiin. Vaiheet ovat aloitusvaihe, in-line analyysi, in-depth analyysi ja

innovaatiovaihe (Kuva 5). Vaiheita ei nähdä samanlaisina, selkeästi rajattuina ja itsenäi-

sinä vaiheina, kuten perinteisessä ohjelmistoprojektin läpiviennissä (Kuva 11), vaan

toisiinsa tiiviisti linkittyvänä kokonaisuutena. MUST metodissa vaihe esitellään ajan-

jaksona, joka sijaitsee kahden tilan välillä. Tila määritellään seuraavasti:

" todellinen tai kuviteltu paikka tai avaruus, esimerkiksi fyysinen paikka

jotakin toimintaa varten, alue muistissa tai tietovälineessä, tai kuviteltu

paikka tai alue lumetodellisuudessa" [Tie04, s. 254].

Esimerkkinä tilasta voidaan kuvata vaatimustenkeräysvaiheen ja vaatimusmäärittely-

dokumentin kirjoittamisen välinen hetki. Kyseisessä tilassa kerätty tieto analysoidaan ja

se pyritään jalostamaan mahdollisimman selkeärakenteiseksi kirjoitetuksi dokumentiksi.

MUST-metodin läpiviennissä siirtyminen edellisestä tilasta seuraavaan tapahtuu näiden

neljän vaiheen kautta. Kyseistä ajatusmallia nimitetään lähtökohtaisen suunnittelun me-

netelmäksi (baseline plannning), joka on esitetty kuvassa viisi. [BKS04]

34

Kuva 5. Lähtökohtaisen suunnittelun menetelmä, mukaillen [BKS04]

Lähtökohtaisen suunnittelun menetelmän sisältämät vaiheet etenevät kronologisesti va-

semmalta oikealle. Jokainen vaihe sisältää päätösten tekemistä suunnitteluprojektiin

liittyen. Jokainen tila määrittelee kullekin vaiheelle välitavoitteet ja tarkat lopputulokset.

Jokaiseen tilaan ja tavoitteeseen päästään kuvassa esiteltyjen vaiheiden kautta. Seuraa-

vaksi esitellään näiden vaiheiden tarkempi sisältö ja tärkeimmät tavoitteet. [BKS04]

1. Aloitusvaihe (Initiation phase) - Projektin aloitusvaiheessa perustetaan sopimus ja

suunnitelma projektin läpiviemiseksi. Näiden avulla projektin lähtökohtia ja rajoja

voidaan tarkastella sekä tehdä projektin etenemiseen vaikuttavia päätöksiä. Päätettä-

vien asioiden piiriin kuuluvat esimerkiksi osallistuvat henkilöt, sisältö ja rahoitus.

2. In-line analyysi (In-line analysis) - Vaiheen aikana tehdään selvitys projektin tueksi.

Selvityksen avulla tarkennetaan suunnitteluprojektin päämäärää ja suhdetta asiak-

kaan liiketoimintaan ja informaatioteknologiaan liittyviin strategioihin. Selonteon

avulla saadaan selville myös ne keskeiset työtoiminnan alueet, joihin projektissa tu-

lee keskittyä.

3. In-depth analyysi (In-depth analysis) - Vaiheen tueksi tehdään erittelyraportti (ana-

lysis report). Laadittu raportti tukee ratkaisuja tilanteissa, joissa joudutaan ratkaise-

maan priorisoitavat päämäärät, ongelmakohdat ja tarpeet. Myös järjestelmän kannal-

ta yksityiskohtaisempaa suunnittelua vaativia osia pystytään erottamaan. Erittelyra-

porttia voidaan täydentää keskeisiä työtoimintoja tutkimalla ja kuvaamalla.

4. Innovaatiovaihe (innovation phase) - Innovaatiovaiheessa laaditaan lopullinen

suunnitteluprojektin raportti. Raportissa selvitetään ne kohdat, joihin huomio tulisi

35

kiinnittää ja se miten nämä kohdat pystytään havaitsemaan. Lopullista suunnittelu-

projektin raporttia voidaan täydentää erilaisilla malleilla ja prototyypeillä. [BKS04]

3.3 Muut tunnetut lähestymistavat

Muiden tunnettujen lähestymistapojen kohdalla on pyritty valitsemaan edellä esiteltyjen

Contextual designia ja MUST-metodia täydentäviä menetelmiä. Valituilla lähestymista-

voilla on myös pyritty kuvaamaan niiden tiettyä erityispiirrettä, joka erityisesti osallis-

tavan suunnittelun kohdalla on selkeästi käyttäjät suunnitteluprosessissa huomioivaa.

3.3.1 SSM - Soft Systems Methodology

SSM on lähestymistapa osallistavaan suunnitteluun, jossa kohdeorganisaatiota tarkastel-

laan laaja-alaisesti. Organisaatio nähdään järjestelmänä, jonka keskeisiä osia ihmiset ja

tekniikka ovat. SSM keskittyy erityisesti tarkasteltavan tuotteen käyttökontekstiin ja

tuotteen käytöstä aiheutuviin vaikutuksiin [Kuu03]. Kuvassa 6 on esitelty SSM lähes-

tymistavan rakenne.

Kuva 6. SSM lähestymistavan rakenne, mukaillen [ChS90]

Checklandin esittämän mallin rakenne kuvaa SSM-lähestymistavan ajatusta iteratiivisen

oppimisen kehänä. Reaalimaailmasta saadut havainnot jalostetaan tarkemman tason

toimenpiteiksi iteratiivisen kehityksen kautta [ChS90].

Lähestymistavan ensimmäisessä vaiheessa pyritään selvittämään tarkasteltavaan järjes-

telmään liittyviä ratkaisumalleja. Tarkastelu tehdään rikaskuvien (Rich picture) avulla.

Kuvien avulla esitetään kaikkien asianomaisten keskeiset tehtävät, organisaation raken-

36

ne, prosessit ja työryhmät, joihin henkilöt kuuluvat [Kuu03]. Checkland esittää kuville

ehdon, jonka mukaan kuvien piirtämiseen ei ole olemassa virallista tekniikkaa ja kuvien

piirtämiseen ei tule asettaa piirtämistä ohjaavia ja rajoittavia sääntöjä [ChS90].

SSM-lähestymistavan läpiviennin toisessa vaiheessa muodostetaan kohdetta koskevat

perusmääritykset CATWOE-mallin avulla. CATWOE-mallin avulla pyritään muodos-

tamaan kuvaukset seuraaviin kohtin:

1. Käyttäjät (Clients) ovat henkilöitä, jotka saavat järjestelmää käyttämällä lisäar-

voa omaan työhönsä.

2. Toimijat (Actors) ovat henkilöitä, jotka toteuttavat järjestelmään liittyviä toi-

menpiteitä.

3. Muunnokset (Transformations) ovat toimenpidesarjoja, jossa järjestelmä saa

syötteen, suorittaa muunnoksen ja antaa lopulta tuloksen.

4. Konteksti (World view) kuvaa sitä, mistä näkökulmasta järjestelmää tarkastel-

laan.

5. Omistaja (Owner) on henkilö, jolle järjestelmä on vastuussa, joka voi määrätä

muutoksia järjestelmään ja omistaa järjestelmän.

6. Ympäristö (Environment) tarjoaa järjestelmälle toimintaympäristön ja olosuh-

teet, jossa se toimii.

Perusmääritysten pohjalta laaditaan malli toteutettavasta tuotteesta kuvassa 6 esitellyn

iteratiivisen prosessin avulla. Ehdotettavia malleja peilataan reaalimaailmaan ja lopuksi

tarkastellaan mahdollisesti esille nousseita organisaatiotason toimintaan liittyviä muu-

tostarpeita. [Kuu03]

3.3.2 JAD - Joint Application Development

JAD on alun perin kehitelty 1970-luvulla IBM-yhtiön toimesta. JADia hyödynnetään

erityisesti käyttäjien ja suunnittelijoiden välisten tapaamisten järjestämisessä. JAD on-

kin muotoutunut viitekehykseksi tavalle, jolla osallistavaan suunnitteluun läheisesti liit-

37

tyvät tapaamiset tulisi toteuttaa. JAD on saavuttanut suosiota erityisesti Yhdysvalloissa,

jossa on ymmärretty osallistavan suunnittelun mahdollisuudet parempien tietojärjestel-

mien kehittämistyössä. [CWG93]

JAD tapaamisten läpiviennissä huomio tulee kiinnittää erityisesti neljään kohtaan:

1. Johtaminen - Tapaamisilla tulee olla selkeä vetäjä, joka ohjaa keskustelua osa-

puolten välillä.

2. Agenda - JAD tapaamisilla tulee olla selkeä ja yksityiskohtainen toimintasuunni-

telma, jotta tapaamisesta saataisiin mahdollisimman suuri hyöty.

3. Dokumentointi - Tehtävään erikseen valitut henkilöt kirjaavat tapaamisissa ylös

kaikki läpikäytävät asiat ja päätökset.

4. Ryhmän yhteistyö - Osapuolten välisen yhteistyön parantamiseksi voidaan käyt-

tää erilaisia menetelmiä, esimerkiksi aivoriihi (brainstorming). [CWG93]

JADin käyttämisestä on raportoitu esimerkiksi Texas Instrumentsin taholta 500000 dol-

larin säästöjä eräässä toteutuneessa projektissa [WoS89]. JAD on selkeyttänyt käyttäjil-

le kuvaa toteutettavasta järjestelmästä ja kiinnostus menetelmän käyttämiseen uudestaan

on ollut myös merkittävää [CWG93].

3.3.3 ULRC - User-Led Requirements Construction

ULRC on sosiaalinen prosessi, joka keskittyy käyttäjien ja suunnittelijoiden työhön liit-

tyvien toimintatapojen ja työn tekemiseen liittyvien kulttuurierojen parantamiseen.

Huomion kohteena on erityisesti vaatimusten keräysvaihe. Käyttäjien ja suunnittelijoi-

den välistä kulttuurieroa pyritään kaventamaan kouluttamalla käyttäjät rakentamaan

itsenäisesti malleja toteutettavan järjestelmään vaatimuksiin liittyen.

Käyttäjien osallistamiseksi vaatimustenkeräysvaiheeseen ULRC lähestymistapa esitte-

lee kolmivaiheisesti etenevän mallin kuvan 7 mukaisesti, jolla käyttäjät saadaan toteut-

tamaan vaatimusprosessin osia itsenäisesti. [CoM02]

38

1. Vaihe

Käyttäjien koulutus

2. Vaihe

Nykytilan mallinnus

3. Vaihe

Tavoitetilan mallinnus

Kuva 7. Käyttäjät vaatimusten mallintajina [CoM02]

Ensimmäisessä vaiheessa käyttäjät koulutetaan itsenäiseen vaatimusten mallinnukseen

ja käsittelyyn. Suunnittelijat tarjoavat käyttäjille tarvittavat tiedot ja tekniset taidot vaa-

timusten mallinnukseen. Toinen vaihe sisältää nykytilan mallinnuksen. Saatua kuvausta

nykytilasta käytetään kolmannessa vaiheessa mallinnettavan tavoitetilan pohjana. Toi-

sen ja kolmannen vaiheen välillä siirtyminen on iteratiivista. Iteraation avulla vaatimus-

ten laatua ja tarkkuutta saadaan luotua paremmaksi. [CoM02]

3.4 Keskeisimmät menetelmät

Osallistavan suunnittelun sisältämien menetelmien tarkoitus on tuoda käyttäjän ja suun-

nittelijan väliseen yhteistyöhön keinoja tulevaan tietojärjestelmään haluttujen vaatimus-

ten selvittämiseksi [CoM02]. Esiteltävät menetelmät ovat olleet keskeisimmin esiteltyi-

nä osallistavaan suunnitteluun liittyvässä kirjallisuudessa esimerkiksi [BKS04, BeH98,

Kuu03, ChS90] ja julkaisuissa esimerkiksi [CWG93, CoM02, Mag01].

Esiteltävät menetelmät osallistavan suunnittelun toteuttamiseksi toimivat edellä esitelty-

jen lähestymistapojen läpiviennin runkona. Osallistavan suunnittelun menetelmät ja

niiden soveltaminen erityisesti tietojärjestelmän käyttöönottoon liittyen ovat tämän tut-

kielman tärkein osa-alue. Seuraavaksi esiteltävät menetelmät ovat kirjallisuudessa laa-

jasti käsiteltyjä ja edustavat keskeisimpiä toimenpiteitä osallistavan suunnittelun läpi-

viemiseksi.

39

3.4.1 Havainnointi (Observation)

Havainnointi on todellisessa työympäristössä tapahtuvaa käyttäjien tekemän työn seu-

raamista ja tarkkailua. Havainnoinnin avulla pyritään paljastamaan suunnittelijaosapuo-

lelle käyttäjien tekemiä valintoja ja toimenpiteitä työhön liittyen. Havainnointi tarjoaa

myös ratkaisun yleiseen ongelmaan, jossa käyttäjä ei osaa sanoin kuvailla itselleen ru-

tiininomaisia työprosesseja. Näin pystytään luomaan suunnittelijaosapuolelle selkeä

kuva todellisista työtehtävistä. Esimerkiksi Contextual Designissa havainnointi esitel-

lään ensisijaisena menetelmänä osallistavan suunnittelun toteuttamiselle sen tarjoaman

laajan ja suunnittelutyön kannalta olennaisen tiedon tarjoajana. [BeH99]

Havainnoinnin toteuttamiselle on olemassa useita käytäntöjä ja näkökulmia. Havain-

nointi voidaan toteuttaa tarkkailemalla henkilöitä työssään mahdollisimman etäältä ja

osallistumatta tapahtumiin. Toinen, ja osallistavaan suunnitteluun tarkemmin liittyvä

menetelmä, osallistuva havainnointi, on edellistä aktiivisempi ja vuorovaikutteisuus on

yleisesti ottaen isommassa roolissa. [BKS04]

Osallistavan havainnoinnin keskeinen tavoite on saada työntekijät ja havainnoitsija kes-

kustelemaan työskentelyn aikana esille nousevista asioista. Havainnoitsijan on tärkeää

päästä tekemään samaa työtä, jota on tutkimassa. Useimmissa tapauksissa tämä on kui-

tenkin hankalaa toteuttaa [BKS04]. Havainnoinnin toteuttaminen voidaan jakaa kol-

meen osaan: Valmistelu, toteutus ja tulosten käsittely.

Valmisteluvaiheen ensimmäinen kriittinen päätös koskee havainnoinnin tarkoitukseen

liittyviä näkökulmia. Kaikkien havainnoitsijoiden tulee olla selvillä siitä, mitä ollaan

havainnoimassa ja miksi havainnointi ylipäätään tehdään. Havainnointiin liittyvät vas-

tuut tulee myös selvittää asianomaisille tarkalla tasolla. Työtavat, henkilöt, ympäristö ja

käytettävät työvälineet ovat keskeisiä tarkastelun kohteita, jotka vaativat jokainen oman

tarkkailijansa.

Toteutusvaiheessa kaikkien tarkkailtavien henkilöiden tulee olla selvillä havainnoinnin

tarkoituksesta ja erityisesti saatavien tietojen luottamuksellisuutta tulee korostaa. Ha-

vainnoitsijoiden tulee myös muistaa, että havainnoinnin kohteena olevilla ihmisillä kes-

tää jonkin aikaa tottua outoihin ihmisiin. Toteutusvaiheessa apuvälineinä toimivat muis-

40

tiinpanot ja joissain tapauksissa kamera, videokamera ja ääninauhuri. Havainnoinnin

kulun niin salliessa voidaan välillä esittää lyhyitä ja tarkentavia kysymyksiä esille nou-

sevista asioista. Henkilökunnalta voidaan myös pyytää kopioita heidän työhönsä keskei-

sesti liittyvistä dokumenteista ja lomakkeista.

Tulosten käsittelyssä muistiinpanot, täydennettynä saaduilla lomakkeilla liittyen työnte-

kijöiden työhön, tarjoavat merkittävimmät tulokset. Välittömästi havainnoinnin jälkeen

tulisi tehdä ainakin lyhyt tiivistelmä ja analyysi havainnoinnin tuloksista, sillä havain-

noidut yksityiskohdat unohtuvat nopeasti. [BKS04]

Havainnoinnin tärkeys korostuu erityisesti ensitiedon hankkimisessa. Työympäristössä

kulkee paljon kriittistä tietoa työntekijöiden välillä, joka liikkuu piilotettuna jokapäiväi-

sessä työssä [CoM02]. Havainnointi mahdollistaa käytännön työn tutkimisen, jolloin

nähdään tehtävien vaatimat todelliset toimenpiteet, sekä miten havainnoinnin kohteena

olevan henkilökunnan yhteistyö toteutuu.

Bødkerin ja muiden mukaan eräs keskeisimmistä esille nousevista asioista on tutkia

miten henkilökunnan työstään aikaisemmin kertomat asiat toteutuvat havainnoinnin

yhteydessä. Havainnointia voidaan näin ollen pitää eräänlaisena varmistuksena aiemmin

saaduille tiedoille työhön liittyen. [BKS04]

3.4.2 Haastattelu (Interview)

Haastattelua voidaan kuvailla keskusteluna haastattelijan ja haastateltavan välillä, jossa

tarkoituksena on saada selville jotain tiettyä informaatiota haastateltavalta [Jär04].

Haastattelut ovat eräs useimmin käytetyistä menetelmistä tietojärjestelmien suunnitte-

lussa ja erityisesti vaatimusten keräämisen apuna.

Haastattelu tarjoaa tehokkaan ja systemaattisen tavan tiedon hankkimiseen henkilökun-

nalta, johdolta, asiakkailta ja muilta asianomaisilta. Haastattelujen tulisi olla mahdolli-

simman avoimia tilanteita, joissa haastattelija voi kysyä kaikkea haastattelun aikana

esille tulevaa, mitä ei ymmärrä. Haastattelut voidaan pääsääntöisesti jakaa kahteen eri

kategoriaan, strukturoituun ja avoimeen. [BKS04]

Strukturoitu haastattelu (structured interview) eli muodollinen haastattelu rakentuu

tarkkaan valmisteltujen kysymysten varaan. Strukturoitu haastattelu on koettu hyväksi

erityisesti suurille joukoille suunnatuissa kyselyissä. Kyselyissä, joissa haastateltaville

41

annetaan muutamia vastausvaihtoehtoja, mahdollistetaan saatujen tulosten pohjalta teh-

tävä määrällinen (quantitative) analysointi.

Avoin haastattelu (unstructured interview) muodostuu laajoista kysymyksistä, joihin ei

odoteta kovin tarkkoja vastauksia. Haastattelu on luonteeltaan ohjautuvaa ja haastatteli-

joiden tehtävänä on johdatella keskustelua tarkempien vastausten saamiseksi. Tämän-

kaltaista, subjektiivisiin kysymyksiin keskittyvää menetelmää kutsutaan myös kvalita-

tiivisen haastattelun menetelmäksi (qualitative interview). [BKS04]

Teemahaastattelu (thematic interview) liittyy läheisesti avoimeen haastatteluun. Tee-

mahaastattelun keskeinen ominaisuus on Hirsjärven ja Hurmeen mukaan haastattelun

rajatut aihepiirit. Vaikka aihepiiri on suhteellisen tiukkaan ennalta määrätty, eivät esitet-

tävät kysymykset ole kuitenkaan tarkkaan muotoiltuja eikä niillä ei ole tarkkaan mietit-

tyä järjestystä. Teemahaastattelu sopii erityisesti tilanteisiin, joissa käsitellään aihepiiriä,

joka on haastattelijoille vieras. [HiH80]

MUST suosii haastatteluissaan kvalitatiivista haastattelumenetelmää. Kvalitatiivinen

menetelmä toimii parhaiten suhteellisen yksityiskohtaista tietoa hankittaessa tai tiettyyn

teemaan keskityttäessä. Haastattelu voidaan viedä läpi eri tilassa kuin käyttäjä työsken-

telee tai käyttäjän työympäristössä (in-situ interview). Käyttäjän työympäristössä suori-

tettava haastattelu etenee esimerkiksi haastateltavan käyttämien erilaisten työvälineiden

esittelyllä.

Työympäristössä tapahtuva haastattelu tarjoaa tietoa siitä miten käyttäjä tekee työtään ja

mitä toimenpiteitä se sisältää (vertaa osallistava havainnointi). Onnistuneen haastattelun

rakenne on lähempänä keskustelua, kuin kysymys-vastaus -tyyppistä mallia. Keskustelu

tuo myös ilmi käyttäjää ja hänen työhönsä liittyviä kehitysehdotuksia. [BKS04]

Haastatteluiden tukena voidaan käyttää kyselylomakkeita (questionnaire). Kyselylo-

makkeet ovat paperille tai sähköiseen muotoon tehtyjä muodollisia tai epämuodollisia

(vertaa haastattelu) kysymyksiä, joihin odotetaan vastauksia tietyltä ryhmältä. Kuten

haastatteluakin, käytetään kyselylomakkeita usein menetelmänä erilaisilta käyttäjiltä

saatavan tiedon keräämiseen. [Jär04]

42

3.4.3 Työpajat (workshops)

Osallistavassa suunnittelussa työpajat ovat useimmiten käyttäjien ja suunnittelijoiden

välisiä tapaamisia. Työpajan tarkoituksena on selvittää ja tuoda esille ongelmakohtia

työtoiminnasta ja vaihtoehtoisista työskentelytavoista ja -menetelmistä [Cra98].

Työpajojen hyödyllisyys korostuu tilanteissa, joissa suunnittelijoiden täytyy muodostaa

yhtenäinen käsitys käyttäjien työstä ja siihen liittyvästä suunnittelusta. Esimerkiksi ha-

vainnointien tai haastatteluiden jälkeen suunnittelijoiden tulisi keskustella tehdyistä ha-

vainnoista ja selvittää tärkeimmät tarkkailtuun työhön liittyvät kohdat. Näin pystytään

luomaan yhteistä näkemystä suunnittelijaosapuolen kesken ja valmistautumaan työpa-

joihin. Työpajoihin osallistuu sekä käyttäjiä että suunnittelijoita. Työpajoihin varattava

aika on usein vain muutamia tunteja, joten työpajan valmistelu nousee erittäin tärkeäksi

asiaksi [BKS04].

Työpajoissa käytettävien menetelmien avulla pyritään kuvaamaan kohdeorganisaation

työnkulun eri näkökulmia ja sen suhdetta eri tietojärjestelmiin. Contextual Designista

tutussa mallien yhteensovittamisvaiheessa (katso kpl 3.1) hyödynnettyä samankaltai-

suusseinää voidaan käyttää myös työpajoissa uudelleensuunnittelun apuna [BeH98].

Toinen työpajojen toimintaa ohjaava tekijä voivat olla tulevaisuustyöpajat (future

workshop), jotka tarjoavat perinteiseen työpajaan verrattuna näkökulman, jossa tarkoi-

tuksena on luoda suunnittelijoiden keskuudessa yhteinen ehdotus havaittujen epäkohtien

parantamiseksi. Tulevaisuustyöpajan hyödyllisyys korostuu erityisesti suuren suunnitte-

luryhmän työskentelyssä, jolloin kaikkien osapuolten näkemykset saadaan tuotua te-

hokkaasti esille. [BKS04]

3.4.4 Prototyypit (prototypes)

Tietotekniikan liitto ry:n sanastotoimikunta määrittelee prototyypin seuraavasti: "uuden

tuotteen kuten atk-laitteen tai ohjelmiston ensimmäinen tai koetoteutus, jota käytetään

tuotteen ominaisuuksien ja sille asetettavien vaatimusten arviointiin" [Tie04, s.181].

Prototyypit antavat konkreettisuutta ohjelmistolle ja ne paljastavat tulevan tietojärjes-

telmän sisältämiä suuntaviivoja. Käyttäjät pääsevät prototyyppien avulla kokeilemaan

esimerkiksi tulevan järjestelmän tarjoamaa toiminnallisuutta ja käyttöliittymää.

43

Prototyyppien käytön päämääränä ovat käyttäjien antaman palautteen pohjalta heidän

työnsä sisällön oppiminen ja prototyyppien edelleen kehittäminen. Silloin kun proto-

tyyppejä käytetään suunnittelun apuna, on tärkeää saada käyttäjät aktiivisesti osallistu-

maan palauteprosessiin. Tämä on ehto prototyyppien käytön onnistumiselle [KeM93].

Prototyyppien kiertoon liittyvät vaiheet on esitelty kuvassa 8.

Kuva 8. Prototyypin iteratiivinen kierto, mukaillen [BKS04]

Prototyyppien elinkaaren prosessi on iteratiivinen ja se jatkuu kunnes lopullinen tuote

on valmis [Cra98]. Prototyyppeihin liittyy läheisesti myös erilaisten kuvausmenetelmien

käyttö. Eräs keskeisimmistä on skenaarioiden käyttö.

Skenaariot ovat tarkkailun ja kehitysmallien pohdinnan kautta syntyviä mahdollisia

tuotteita tai toimintamalleja. Skenaariot jalostuvat käyttäjien ja kehittäjien aktiivisessa

yhteistyössä prototyyppien avulla [KeM93]. Skenaarioiden tueksi syntyvien prototyyp-

pien luomisen vahvuus on myös niiden heikkous. Iteratiivinen prosessi kehittää mallia

"tunnelimaisesti" kohti tiettyä päämäärää, jolloin saatetaan keskittyä liian tarkasti yksi-

tyiskohtiin, sen sijaan että kyseenalaistettaisiin mallin alkuperäinen tila [Mor94].

3.4.5 Työnkulun mallinnusmenetelmät

Työnkulkua kuvaavia kaavioita on olemassa useita erilaisia. Tunnettuja mallinnusmene-

telmiä työnkulun kuvaamiseen ovat esimerkiksi sekvenssikaavio, käyttötapauskaavio ja

aktiviteettikaavio. Eri mallinnusmenetelmien avulla kuvataan käyttäjien suorittamien

työtehtävien kulkua ja eri vaiheissa tapahtuvia toimenpiteitä. Tässä tutkielmassa eniten

käytetty mallinnusmenetelmä oli sekvenssikaavio.

44

Käyttäjien työtehtävät tapahtuvat yleensä tietyn järjestyksen mukaan. Järjestys paljastaa

käyttäjien strategian tehtävän toteuttamiselle, tehtävien tarkoituksen ja käyttäjien työn

kannalta merkitsevien asioiden sisällön. Näiden asioiden huomioonottaminen ja tiedos-

taminen on toimivan tietojärjestelmän kannalta tärkeää. [BeH98]

Sekvenssikaavion avulla kuvataan askeleet jotka käyttäjä käy läpi tehdessään työtä. He-

räte toimii koko prosessin käynnistäjänä ja tavoitteen avulla kuvataan päämäärä johon

käyttäjä työllään tähtää. Esimerkki sekvenssikaaviosta on esitetty liitteessä 1. Liitteenä

oleva sekvenssikaavio liittyy yliopistollisessa sairaalassa toteutettuun potilaskertomus-

järjestelmän käyttöönottoon.

Sekvenssikaaviolla on kuvattu eräällä osastolla haastatellun käyttäjän työpäivää. Sek-

venssikaavion avulla selvitettiin käyttäjän työn suhdetta muun osaston toimintaan. Kaa-

violla kuvattiin myös käyttäjän tekemiä kirjauksia ja tiedon hakuja erilaisiin järjestel-

miin. Sekvenssikaavio on piirretty nauhoitetun haastattelun pohjalta.

3.5 Yhteenveto lähestymistavoista

Osallistavien lähestymistapojen avulla pyritään saavuttamaan laaja näkökulma tietojär-

jestelmän vaatimusten keräämiseksi. Edellä esitellyt lähestymistavat tuovat tarkkaa tie-

toa perinteisten teknisten ominaisuuksien lisäksi. Osallistava näkökulma tarjoaa tietoa

sosiaalisista, organisaation sisäisistä ja käyttäjälähtöisistä näkökulmista. [CoM02]

Määrittelyt ovat yksityiskohtaisia malleja järjestelmän toiminnallisuudesta ja rakentees-

ta. MUST-metodi erottaa tarkkojen määritelmien selvittämisen erilliseksi muusta suun-

nitteluprosessista. Tämä mahdollistaa, että tarkkoja suunnitelmia ei tehdä, ennen kuin

on päätetty, mitä tehdään ja millä resursseilla.

MUST-metodin tapa erottaa tarkan tason toiminnallisuuteen ja rakenteeseen liittyvät

suunnitelmat muusta suunnittelusta mahdollistaa näkökulman, jossa kaikkien järjestel-

mien toteutus ei aina lähde alusta. MUSTin tapa toteuttaa suunnittelun tekninen osio

erillään mahdollistaa myös toteutusprosessin toteuttamisen ulkopuolisilla ohjelmistoke-

hittäjillä. Contextual Designin vahvuus on tilanteessa, jossa sama ryhmä tekee myös

järjestelmän teknisen toteutuksen [BKS04].

45

MUST ja Contextual Design lähestyvät suunnitteluprosessia samasta näkökulmasta.

Molemmat lähestymistavat ovat (front-end) suuntauksen kannattajia [BKS04]. Contex-

tual Design on raskas ja vaatii suuren määrän resursseja toimiakseen. Contextual Desig-

nin sovellettu käyttö kuhunkin tilanteeseen sopivia osia painottaen mahdollistaa, että

lähestymistapaa voidaan käyttää myös kevyemmillä resursseilla [Kuu03].

Osallistavan suunnittelun kannalta keskeistä on käyttäjän ja suunnittelijan vuorovaiku-

tus ja sen onnistuminen [BeH95]. Kuvassa 9 on esitelty tässä tutkielmassa esiteltyjen

lähestymistapoihin liittyvää käyttäjän ja suunnittelijan suhdetta. Kuvassa on esitetty

kunkin lähestymistavan kohdalla kategoria, mihin vuorovaikutus-suhde osapuolten vä-

lillä painottuu. Kategoriat ovat käyttäjä-, käyttäjä-suunnittelija- tai suunnittelija painot-

teisia.

Kuva 9. Käyttäjän ja suunnittelijan vuorovaikutus eri lähestymistavoilla [BKS04, CoM02]

MUST keskittyy käsitellyistä lähestymistavoista eniten käyttäjien ja suunnittelijoiden

väliseen yhteistyöhön. MUSTin ohella myös SSM korostaa käyttäjien ja suunnittelijoi-

den välisen yhteistyön jatkuvaa kehittämistä suunnitteluprojektin aikana. Edellisiin ver-

rattuna JAD käyttää tiukkoja määritelmiä asetettujen roolien välillä.

MUSTissa osapuolten yhteistyön vetäjän rooli korostuu projektin johtamisessa kohti

haluttua päämäärää. Contextual Designissa projektin johtaminen jää täysin suunnittelija

osapuolen vastuulle. MUSTiin ja Contextual Designiin verrattuna ULRC toimii täysin

käyttäjä osapuolen johtamana ja kaikki vastuu suunnittelun etenemisestä on käyttäjillä.

[BKS04, CoM02]

46

4 TIETOJÄRJESTELMÄN KÄYTTÖÖNOTTO

Uuden tietojärjestelmän käyttöönotto voidaan nähdä prosessina, joka sisältää eri vaiheet

ennen käyttöönottohetkeä, käyttöönoton aikana ja sen jälkeen [Alt80]. Käyttöönottoa on

myös kuvailtu prosessina, joka alkaa ensimmäisestä ehdotuksesta uuden tietojärjestel-

män hankkimiseksi ja päättyy tilanteeseen, jolloin uudet käyttäjät käyttävät järjestelmää.

Onnistuneen käyttöönoton kriteerinä voidaan pitää esimerkiksi järjestelmän tuomaa

sujuvuutta yrityksen jokapäiväisiin toimenpiteisiin tai tietojärjestelmän korkeaa käyttö-

astetta kohdeorganisaatiossa [LGS90].

Marc Bergin mukaan onnistumisella on kuitenkin useita ulottuvuuksia, esimerkiksi ter-

veydenhuollossa hoitohenkilöstön ja potilaiden näkemykset käyttöönoton onnistumises-

ta saattavat olla hyvinkin erilaisia [Ber01]. Erityisesti terveydenhuollossa on tärkeää

muistaa, että olipa kyseessä olevan käyttöönoton laajuus suuri tai pieni, on uuden tieto-

järjestelmän käyttöönoton teknisen näkökulman lisäksi tärkeää kehittää myös potilaiden

hoitotyöhön kohdistuvia moniammatillisia toimintaprosesseja ja projektityömenetelmi-

en hallintaa [SaK99].

Seuraavissa luvuissa käsitellään tietojärjestelmän käyttöönottoprosessia yleisellä tasolla

ja perehdytään lisäksi terveydenhuollon erityispiirteisiin ja työn uudelleensuunnitteluun.

Käyttöönottoprosessin käsittely perustuu tässä tutkielmassa suurilta osin Kaija Sarannon

ja Mikko Korpelan toimittamaan kirjaan [SaK99] ja erityisesti sen viidenteen lukuun,

jonka on kirjoittanut Sinikka Ripatti. Ripatti on käsitellyt tietojärjestelmän käyttöönot-

toa erityisesti terveydenhuollon organisaation näkökulmasta. Luvun lopussa on kerrottu

pilottikohteessa tapahtuvasta elektronisen potilaskertomusjärjestelmän käyttöönottopro-

sessista.

4.1 Käyttöönottoprosessi

Tietojärjestelmähankinnat käsitetään usein tietokoneiden, tietoliikenneyhteyksien ja

ohjelmistojen muodostamaksi joukoksi sekä niiden asentamiseen liittyväksi työproses-

siksi. Tietojärjestelmän käyttöönotto on kyseisen hankintaprosessin viimeinen vaihe ja

sen onnistuminen vaatii huolellista valmistelua [Sak99].

47

Käyttöönotto voidaan jakaa vaiheisiin ja sen toteutus on mahdollista suorittaa kohdeor-

ganisaatiossa esimerkiksi toimipiste kerrallaan, kertasiirtymisenä (vanha järjestelmä

korvataan kerralla) tai rinnakkain suoritettavana, jolloin kahta tai useampaa järjestelmää

käytetään jonkin aikaa rinnakkain [Rou98].

Lucas [Luc85] jakaa käyttöönottoprosessin kahdeksaan eri vaiheeseen: Ohjelmien kehi-

tykseen, suunnitelmien tarkentamiseen, sovellusten testaukseen, käyttäjien koulutuk-

seen, järjestelmän testaukseen, muunnoksiin, lopullisen ohjelman asennukseen ja käyt-

töönottovaiheeseen. Käyttöönottoprosessin vaiheet Lucasin mallissa ovat suurelta osin

yhteneväisiä kirjallisuudessa laajemminkin esillä oleviin näkökulmiin.

Lucasia mukaillen käyttöönottoa lähestyy esimerkiksi Eason, [Eas88] joka luettelee

käyttöönottovaiheen läpiviennin vaihtoehdot seuraavasti:

1. Big Bang - Käyttöönotto toteutetaan kerralla ennalta sovitun aikataulun mukai-

sesti.

2. Rinnakkainen käyttöönotto - Järjestelmiä käytetään rinnakkain tarpeellinen aika.

3. Vaiheittainen toteutus - Käyttöönotto tapahtuu vaiheittain ja käyttöönotto toteu-

tetaan osajärjestelmä - tai alue kerrallaan.

4. Kokeilu - Käyttöönotto toteutetaan ensin pienimuotoisesti ja jos kokemukset

ovat positiivisia, käyttöönottoa jatketaan kohdeorganisaation muissa osissa.

5. Yhdistelmästrategia - Käyttäjälähtöinen suunnittelunäkökulma, jossa suunnittelu

tähtää räätälöityihin sovelluksiin.

Käyttöönottoprojektin läpivienti voidaan esittää Sinikka Ripatin esittämällä mallilla,

joka on esitelty kuvassa 10 [Sak99]. Sinikka Ripatin esittämä malli on valittu lähemmän

tarkastelun kohteeksi sen tarjoamien terveydenhuoltoon kontekstiin liittyvien näkökul-

mien johdosta.

48

Järjestelmän hankinta

Tuotantokäyttö

Kuva 10. Käyttöönottoprojektin etenemisvaiheet, mukaillen [SaK99]

Ripatin esittämän näkökulman keskeiset osat ovat: toiminnan suunnittelu, perustietotek-

niikan hankinta ja käyttöönotto, järjestelmän asennus ja toimintaympäristön suunnittelu,

tiedottaminen ja koulutus sekä käyttöönotto.

1. Toiminnan suunnittelu - Terveydenhuollon organisaatiot ovat toimintatavoiltaan

monimutkaisia ja toimivat toimintalähtöisesti (funktionaalisesti). Esiehtona pro-

sessien uudistamiselle ovat nykyisten toimintatapojen kokonaisvaltainen hah-

mottaminen. Kaikki palveluprosessit ja työskentelytavat, joita ei aikaisemmin

ole kuvattu, tulee käydä läpi ja kuvata riittävän tarkalla tasolla [SaK99].

Tarkastelua ei tarvitse aina suorittaa yksilötasolla, vaan tarkastelu koko organi-

saatiota koskevien ydinprosessien avulla saattaa paljastaa tärkeitä ongelmakohtia

ja kehitystarpeita. Erityistä huomiota tulee kiinnittää toimintojen rajapintoihin.

Rajapinnalla voidaan kuvata kahden fyysisen tai abstraktin olion välinen raja tai

ne yhdistävä aine, laite, ohjelma tai käytäntö [Tie04, s.188].

Käyttöönoton yhteydessä on tärkeää huomioida, että käyttöönotto on rinnakkai-

nen tapahtuma organisaation toimintatavoissa tapahtuvan muutoksen kanssa.

Onkin huomioitava, että tietojärjestelmän käyttöönotto voi johtaa suuriinkin

49

muutoksiin usein kohdeorganisaation liiketoimintaprosessien tasolla [Eas88].

Käyttöönotossa nykytoiminnan tuntemus ja käyttöön tulevan tietojärjestelmän

tarjoamien mahdollisuuksien ja rajoitusten ymmärtäminen ovat uusien toiminta-

tapojen suunnittelun lähtökohta.

Uusien toimintatapojen ja työprosessien suunnittelulla pyritään Sinikka Ripatin

mukaan vastaamaan kysymykseen: "Miten käyttöön otettava tietojärjestelmä tu-

kee parhaiten hoitoa ja potilaspalvelua kaikissa niissä tilanteissa, joissa eri am-

mattiryhmät hoitavat potilasta tai käsittelevät hoitoon liittyviä tietoja?". [SaK99,

s.127] Työprosessien suunnitteluvaiheessa yksityiskohtaisesti läpikäytäviä asioi-

ta ovat Ripatin mukaan esimerkiksi seuraavien kohtien huomioiminen: missä

palveluprosessin vaiheessa tiedot syntyvät, missä tilanteissa ja kuka tallentaa

tiedon sekä miten varmistetaan tietojen oikeellisuus [SaK99].

2. Perustietotekniikan hankinta ja käyttöönotto - Käyttöönottoprojekteissa laite-

hankinnat ovat riippuvuussuhteessa tulevan tietojärjestelmän laajuuteen ja orga-

nisaation perustietotekniikan tilaan. Käyttöönottoprojektissa määriteltäviä asioi-

ta Ripatin mukaan ovat tulevien käyttäjien määrä, käytettävien työasemien mää-

rä, yhtäaikaisten järjestelmien käyttäjien määrä sekä tapahtumien määrä.

Nämä tiedot vaikuttavat hankittavan tekniikan määrään ja suunnitteluun. Ripatti

esittää perustietotekniikkaan kuuluviksi esimerkiksi työasemat, kirjoittimet, tie-

toverkot ja käyttöjärjestelmät. Tarvittavien laitehankintojen kartoittaminen aset-

tuu toiminnallisen suunnittelun yhteyteen.

Ennen varsinaista käyttöönottoa huomioitavia asioita ovat myös järjestelmän

suorituskyky ja tietoturva. Järjestelmän suorituskykyä tutkitaan tietyillä käyttäji-

en toteuttamilla testeillä. Näin saadaan selville järjestelmän suoriutumiskyky

päivittäisissä rutiinitoimenpiteissä.

Tietoturvanäkökulma korostuu erityisesti terveydenhuollossa, jossa asiakkaan

yksityisyyden suojaaminen ja vaitiolovelvollisuus ovat kriittisiä asioita. Huomi-

oitaviksi asioiksi nousevat myös tietojärjestelmän käytön periaatteiden doku-

mentointi niin normaali, kuin poikkeustiloissa. [SaK99]

50

3. Järjestelmän asennus ja toimintaympäristön suunnittelu - Uusiin ohjelmistoihin,

jotka usein ovat valmisohjelmia, on Sinikka Ripatin mukaan harvoin mahdolli-

suuksia tehdä muutoksia. Esimerkiksi terveydenhuoltoalalta mahdollisesta muu-

toksesta annetaan osastokohtaisesti muokattavat ohjelmiston piirteet.

Yleisin mahdollisuus järjestelmän kehittämiseen on toiminnan suunnitteluvai-

heessa esille nousevien kehityskohtien kokoaminen ja niiden mahdollinen huo-

mioiminen seuraavissa ohjelmistoversioissa. Toimintaympäristön määrittelyllä

tarkoitetaan Ripatin mukaan, "kaikkia niitä toimenpiteitä, joilla tietojärjestelmä

viritetään vastaamaan organisaation toiminnan tarpeita" [SaK99, s. 131].

4. Tiedottaminen ja koulutus – Eason esittää kaikkien käyttäjien kouluttamisen

eräänä käyttöönoton onnistumisen kannalta kriittisimpänä toimenpiteenä. Myös

koulutuksen tueksi toteuttavan koulutusmateriaalin tulee olla laadukasta.

[Eas88] Roukala [Rou98] esittää eräänä koulutuksen tärkeimmistä tuloksista

käyttäjien kyvyn ja halun toimia uudella tavalla.

Kuten tietojärjestelmän suunnitteluvaiheessa, on käyttöönotonkin onnistumisen

kannalta tärkeää, että organisaation eri osapuolten välinen kommunikointi ja tie-

dottaminen on aktiivista. Käyttöönoton tueksi Ripatti tuo esille tiedotussuunni-

telman, jonka laatiminen on projektiryhmän vastuulla. Tiedotussuunnitelma si-

sältää tiedot eri organisaatiotasojen ja ammattiryhmien tiedotustilaisuuksista.

Eräs haastavimmista vaiheista tietojärjestelmän käyttöönotossa on järjestelmän

käyttäjien kouluttaminen ja koulutuksen suunnittelu. Ripatti esittää suunnitte-

luun vaikuttaviksi tekijöiksi tietojärjestelmän laajuuden, käyttäjien määrän, käyt-

täjien ammatillisen jakauman ja käytettävissä olevien koulutustilojen määrän.

[SaK99 ]

5. Käyttöönotto - Tietojärjestelmän käyttöönoton lähtökohtana on Ripatin mukaan

"toimiva ja testattu tekninen käyttöympäristö ja koulutettu osaava henkilökunta"

[SaK99, 133]. Terveydenhuollossa käyttöönoton ajankohtaan vaikuttaa erityises-

ti se, miten potilastiedot saadaan siirrettyä vanhasta järjestelmästä uuden järjes-

telmän käyttöön.

51

Ripatti korostaa suunnittelussa huomioitaviksi ja dokumentoitaviksi asioiksi seu-

raavia: etenemisaikataulu käyttökatkoineen, tarvittavat työvaiheet, järjestys ja

vastuuhenkilöt, henkilöstön toiminta ja mahdollisiin poikkeustilanteisiin valmis-

tautuminen. Käyttöönottoprosessin tulisi edetä tehtyjen suunnitelmien mukaises-

ti. Kahden järjestelmän, vanhan ja uuden, rinnakkainen käyttö on Ripatin mu-

kaan usein todellinen, vallitseva tilanne. [SaK99]

Laudonin ja Laudonin [LaL98] mukaan käyttöönottoprosessin onnistumiseen vaikutta-

vat merkittävimmin käyttäjän rooli, ylemmän johdon tuen määrä, tietojärjestelmän mo-

nimutkaisuus ja käyttöönottoprojektin johdon tuen laatu. Käyttöönoton onnistumiselle

on myös muita ulottuvuuksia. Attewell [LaL98] määrittelee käyttöönoton onnistumisen

tueksi organisaation kokonaisvaltaisen oppimisen ja muutosvastarinnan voittamisen.

Tietojärjestelmien käyttöönottoprosessin kohdalla tulee kuitenkin muistaa, että saman

tietojärjestelmän käyttöönotto voi onnistua toisessa - ja epäonnistua toisessa organisaa-

tiossa [DaO85].

4.2 Terveydenhuollon näkökulma

Terveydenhuollon tietojärjestelmät tukevat henkilökunnan työtä ja tarjoavat nopean

pääsyn hoitotyön kannalta keskeiseen tietoon. Uusille tietojärjestelmille eräänä tavoit-

teena pidetäänkin nopeaa pääsyä potilaan hoitoa koskevaan tietoon [BAP01]. Tietojär-

jestelmien merkitys terveydenhuollolle tulee koko ajan tärkeämmäksi ja tietojärjestel-

millä pyritään tehostamaan ensisijaisesti potilaan hoitoprosessia.

Käyttöönoton yhteydessä hoitoprosesseissa tapahtuu sisäisiä ja ulkoisia muutoksia. Si-

säisiin muutoksiin kuuluvat muutokset esimerkiksi osastojen rakenteessa ja uusissa ta-

voissa tehdä potilaan hoitoa koskevia tehtäviä. Ulkoiset muutokset voivat sisältää esi-

merkiksi uuden tietojärjestelmän tuomia rajapintoja ulkoisiin järjestelmiin. [LeK04]

Yrjö Engeströmin [Eng04] mukaan sosiaali- ja terveydenhuollon toimintatapojen ja

organisaatioiden uudistamisprosessi on vaikea toteuttaa. Engeström esittää toteutukseen

liittyvien vaikeuksien syiksi esimerkiksi organisaation sisältä tulevan muutosvastarin-

nan ja lainsäädännön mukanaan tuomien uudistustoimenpiteiden aiheuttamat ongelmat.

Engeström esittää toteutettavien muutosten onnistumiselle seuraavan ohjeen:

52

"..on löydettävä työn pohjimmaiseen tarkoitukseen liittyvät, terveyden

huollon organisaatioiden sisällä kehkeytyvät jännitteet ja käytettävä niitä

hyväksi muutoksen pitkäjänteisenä motiivina ja energiana." [Eng04, s.72].

Engeström korostaa näkemystä, jonka mukaan muutos on pysyvintä tapauksissa, joissa

lähtökohtana on organisaation sisältäpäin tuleva halukkuus ja motivaatio muutosta koh-

taan. Terveydenhuollossa tämä sisältäpäin tuleva muutoksen vaatima heräte on potilaan

hoito ja sen kehittäminen. [Eng04]

Berg ja Toussaint [BeT03] varoittavat uuden tietojärjestelmän äkillisestä ja nopeassa

tahdissa tapahtuvasta käyttöönotosta. Terveydenhuollossa työkäytännöt (work practices)

ovat muovautuneet nykyiseen muotoonsa vuosikymmenien aikana ja tukevat nykyisel-

lään terveydenhuollon ammattilaisten työtä. Äkillinen muutos saattaa aiheuttaa muutok-

sia työkäytännöissä ja tämä näkökulma tulee huomioida käyttöönoton yhteydessä. Kes-

keinen asia terveydenhuollossa onkin selvittää, miten uudet tietojärjestelmät saataisiin

kohtaamaan nykyiset työprosessit, kuitenkaan vaarantamatta olemassa olevien työpro-

sessien toimintaa [LeK04].

4.3 Elektronisen potilaskertomusjärjestelmän käyttöönotto

Tutkielman tutkimusosiossa selvitetään, miten uuden tietojärjestelmän käyttöönottoa

voidaan helpottaa osallistavan suunnittelun menetelmien avulla. Tutkimusosio keskittyy

käyttöönottoon valmistautumiseen valittujen pilottiosastojen kanssa. Pilottiosastojen

kanssa käyttöönottoon valmistautuminen tähtää tietojärjestelmän vaiheittaiseen käyt-

töönottoon koko organisaation tasolla tulevien vuosien aikana.

Luvussa 4.1 esiteltyjen käyttöönottoprosessin läpiviennin eri vaihtoehdoista [Eas88]

kohdeorganisaatiossa käyttöönottoa lähestyttiin vaiheittain etenevällä käyttöönotolla.

Vaiheittain etenevää käyttöönottoa toteutettiin osasto kerrallaan, jolloin käyttöönoton

aiheuttamat muutokset eivät vaikuta heti koko organisaation toimintaan.

Käyttöönoton kohdeorganisaationa oleva yliopistollinen sairaala on yksi Suomen vii-

destä yliopistosairaalasta. Se tarjoaa erikoissairaanhoidon palveluita 23 omistajakunnan

asukkaille. Yhteensä sairaanhoitopiirin alueella asuu noin 860 000 ihmistä. Sairaalassa

on 800 vuodepaikkaa ja 4200 työntekijää. Lääkärit vastaanottavat vuodessa 300 000

53

potilaskäyntiä ja vuodeosastoilla potilaille kertyy yhteensä 240 000 hoitopäivää.

[www01]

Käyttöönotettava elektroninen potilaskertomusjärjestelmä on ohjelmistotalo Medici

Data Oy:n valmistama. Elektronisen potilaskertomusjärjestelmän avulla voidaan tuottaa,

hyödyntää ja säilyttää hoitoon liittyviä dokumentteja. Potilaskertomus tallennetaan

CDA-dokumentteina (Clinical Document Architecture) elektroniseen arkistoon, jonka

toteutuksessa on hyödynnetty rakenteisen toteutuksen omaavaa XML-arkistotyyppiä.

[www03]

Elektronisen potilaskertomusjärjestelmän käyttöönottovaiheen tueksi yliopistosairaalan

sisällä toteutetaan erilaisia toimenpiteitä henkilöstön oppimisen tueksi. Oppimista tuke-

vina toimenpiteinä toimivat esimerkiksi tietojärjestelmän käyttökoulutukset. Käyttöön-

oton alkuvaiheessa erikseen valittujen pilottiosastojen koulutukset elektronisen potilas-

kertomusjärjestelmään aloitettiin vuoden 2006 syksyllä.

Koulutuksesta vastaavat neljä kouluttajaa, jotka kaikki tulevat kohdeorganisaation tieto-

hallinnosta. Koulutuksen avulla pyritään turvaamaan potilaiden hyvä hoito sekä hoidon

jatkuvuus. Koulutettu henkilökunta osaa koulutuksen avulla käyttää sähköistä potilas-

kertomusta ja potilaiden turvallisuuden kannalta tärkeät tiedot löytyvät kaikissa tilan-

teissa. Koulutuksen tärkein tehtävä onkin varmistaa tietojärjestelmän käytön riittävä

osaaminen varsinaiseen käyttöönottopäivään mennessä.

Elektronisen potilaskertomusjärjestelmän käyttöönoton tueksi toteutettuja toimenpiteitä

tehtiin kohdeorganisaatiossa valituilla pilottiosastoilla. Pilottiosastoina toimivat keuhko-

sairauksien sekä urologian osastot. Pilottiosastojen kohdalla tarkoituksena oli tutkia

elektronisen potilaskertomusjärjestelmän käyttöönottoa ja suunnitella, miten järjestel-

män käyttöönotto olisi mahdollisimman sujuvaa.

Henkilökunnan moniammatillista osallistumista käyttöönottojen suunniteluun pyrittiin

tukemaan laaja-alaisesti. Suunnittelun apuna käytettiin aikaisemmissa luvuissa esiteltyjä

osallistavan suunnittelun menetelmiä. Seuraavissa luvuissa tarkennetaan mitä menetel-

miä on käytetty ja minkälaisia tuloksia näillä saavutettiin.

54

5 TUTKIMUSMENETELMÄT JA TOTEUTUS

Tähän pro gradu tutkielmaan liittyvä tutkimus on luonteeltaan tapaustutkimus (case stu-

dy). Tapaustutkimuksen piirteiksi määritellään esimerkiksi seuraavia asioita: kohteena

yksilö, ryhmä tai yhteisö, kiinnostuksen kohteena prosessit ja yksittäistapausta tutkitaan

yhteydessä ympäristöönsä. Tapaustutkimuksessa aineiston kerääminen tapahtuu useita,

tässäkin tutkielmassa esiteltyjä, osallistavia menetelmiä käyttämällä. [HRS97]

Tähän tutkielmaan liittyvässä tutkimuksessa käytetty materiaali liittyy ZipIT-

tutkimushankkeen yhteydessä tehtyyn pilottiin. Pilotti keskittyi uuden elektronisen poti-

laskertomusjärjestelmän käyttöönoton tukemiseen ZipIT-kehittämismallin ja osallistavi-

en suunnittelumenetelmien avulla. ZipIT-kehittämismalli on toiminnan teoriaan perus-

tuva työn ja tietojärjestelmän kehittämismalli. Tämän tutkielman pääpaino on osallista-

vien suunnittelumenetelmien analysoinnissa eikä ZipIT-kehittämismallin analysoinnis-

sa.

Tämän tutkielman tarkoituksena on tutkia osallistavien suunnittelumenetelmien käyttöä

uuden tietojärjestelmän käyttöönottoon tukena. Tuloksena kuvataan pilotin aikana toteu-

tettuja toimenpiteitä kohdeorganisaation käyttäjien osallistamiseen ja osallistavan suun-

nittelun toimenpiteiden soveltuvuutta käyttöönottovaiheen tueksi. Tutkimuksessa huo-

mion kohteena ovat myös osallistaviin suunnittelumenetelmiin liittyvässä kirjallisuudes-

sa ja tieteellisissä julkaisuissa esitetyt kokemukset ja pilotista saatujen kokemusten ver-

tailu niihin.

Tässä luvussa esitellään tutkimuksessa käytettyjä tutkimusmenetelmiä ja lähtökohdat

tutkimuksen läpiviennille. Luvun alussa tarkastellaan tutkimuksen lähtökohdat ja kes-

keinen tutkimusongelma. Luvussa 5.1 käydään läpi tavoitteet joita tutkimukselle on

asetettu. Luvussa 5.2 esitellään ZipIT-kehittämismallin taustalla olevaa historiaa ja kes-

keinen sisältö. Luku sisältää myös yleiskuvauksen toimintamallista ja toimintamallin

läpiviennin keskeisimmät vaiheet ja niiden sisällön. Luvun lopussa käsitellään ZipIT-

kehittämismallin suhdetta pilottiin. Luku 5.3 esittelee tutkimuksen kohteena olleen or-

ganisaation käyttäjiä ja työympäristöön liittyviä erikoispiirteitä. Viimeisessä Luvussa

5.4 käydään läpi tutkimuksen toteutusta ja erityisesti tutkimuksessa käytettyjä osallista-

van suunnittelun menetelmiä.

55

5.1 Tutkimuksen lähtökohdat

Elektronisen potilaskertomusjärjestelmän käyttöönotto oli perinteisestä osallistavaa

suunnittelua hyödyntävästä suunnitteluprojektista poikkeavaa. Perinteisesti osallistavaa

suunnittelua hyödynnetään suunnitteluprojekteissa vaatimusten keräämisen tukena, eri-

tyisesti suunnittelun alkuvaiheessa [BeH98, BKS04]. Käyttöönotto sijoittuu perinteisen

ohjelmistosuunnittelun (kuva 11) näkökulmasta sen viimeisimpiin vaiheisiin [Som04].

Kuva 11. Ohjelmiston elinkaari, mukaillen [Som04]

Kuvassa on esitelty ohjelmistosuunnitteluprojektin perinteinen eteneminen ja sen kes-

keisimmät vaiheet. Osallistavan suunnittelun suhde suunnitteluprosessiin on perinteises-

ti ollut vaatimusten määrittelyssä ja keräämisessä. Tässä tutkielmassa selvitetään miten

osallistavan suunnittelun tarjoamia menetelmiä pystytään hyödyntämään tietojärjestel-

mien käyttöönottovaiheen tukena.

Käyttöönottovaiheessa järjestelmään ei enää voida juurikaan vaikuttaa, ja tärkeimmäksi

tehtäväksi nousee käyttöönoton sujuva läpivieminen. Koska järjestelmää ei pystytä enää

muokkaamaan kohdeorganisaation tarpeisiin sopivaksi on muutoksen tapahduttava or-

ganisaation työtoiminnassa ja -tavoissa.

Tähän tutkielmaan liittyvä tutkimus on toteutettu ZipIT-tutkimushankkeen yhteydessä

tehdyssä pilotissa. Pilotti elektronisen potilaskertomusjärjestelmän käyttöönottoon on

56

toteutettu vuoden 2006 aikana. Tutkielman tekijä osallitui pilottiin 1.4.- 30.9.2006 väli-

senä aikana. Tutkielman tutkimusosion toteutuksessa käytettiin apuna niitä osallistavan

suunnittelun menetelmiä, joita myös ZipIT-tutkimushankkeessa toteutettava kehittä-

mismalli osittain käsittelee.

5.2 ZipIT kehittämismalli

ZipIt-tutkimushanke toteutetaan Kuopion yliopiston ja Savonia-ammattikorkeakoulun

yhteisenä hankkeena. ZipIT-hankkeen rahoittavat Tekesin FinnWell-ohjelma, Työsuoje-

lurahasto ja joukko terveydenhuoltoalan yrityksiä ja organisaatioita [www02]. Tutkiel-

massa sovellettava kehittämismalli pohjautuu ZipIT-tutkimushankkeen työpaperiin

[Zip05], jonka tässä tutkielmassa käytettävä versio on tehty 17.11.2005. Tämän tutkiel-

man valmistumiseen mennessä lopullinen versio kehitysmallista ei ole vielä julkinen.

ZipIT-tutkimushankkeen kehittämismalli pyrkii yhdistämään tietojärjestelmän ja toi-

minnan yhtäaikaisen ja rinnakkain tapahtuvan kehittämisen. Yhtäaikaisuudella pyritään

varmistamaan saavutettujen tulosten ja kuvausten molemminpuolinen (käyttäjät ja

suunnittelijat) hyödyntäminen [Zip05]. Tietoteknisissä hankkeissa lähtökohta tulisikin

olla työtoiminnan kehittäminen, jossa tuloksena syntyy parempia palveluja [SaK98].

ZipIt tutkimushankkeessa kehitettävän kehittämismallin pohjana ovat aikaisempien tut-

kimusten, kuten valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke Plug-

IT, tulokset ja niissä sovellettu ActAD-malli. ActAD-mallin (Activity Analysis and De-

velopment) avulla kuvataan työtoimintaa yksilön, työryhmän ja organisaation tasoilla

[Mur02]. ZipIT-kehittämismallin sovelluskohteena ovat ensisijaisesti terveydenhuollon

tietojärjestelmien kehittämishankkeet. [KMS04, www02, Zip05]

Tutkielman tuloksissa itse kehittämismalliin ei keskitytä, vaan ensisijainen tavoite on

käytettyjen osallistavan suunnittelun menetelmiin liittyvät huomiot. ZipIT-

kehittämismallin merkitys tässä pro gradu tutkielmassa liittyykin ensisijaisesti pilotin

toteutuksen läpivientiin. Tehtyjä kuvauksia lähdettiin pilotissa laajentamaan yksilön

tasolta kohti organisaatiotasoa.

Kehittämismallin mukaan kohdealueen toimintaa tarkastellaan kolmessa peräkkäisessä

vaiheessa. Kaikilla vaiheilla on tietty tavoite, joka pyritään saavuttamaan esitellyillä,

osallistavaan suunnitteluun läheisesti liittyvillä menetelmillä. Jokaisella vaiheella on

57

sisällöstä erotettavissa kolme selkeää kohtaa. Tavoite ohjaa jokaista vaihetta ja selkeyt-

tää vaiheen päämäärän. Tulos on jokaisen vaiheen kohdalla tehtävä selvitys asetettuun

tavoitteeseen nähden. Menetelmät kertovat tavan, jolla asetettu tavoite on täytetty ja

tulos saavutettu [Zip05].

Ensimmäisen vaiheen tavoitteena on saavuttaa yhteinen käsitys kuvattavan työtoimin-

nan nykytilasta ja siihen liittyvistä kehitystarpeista. Tuloksena ensimmäisestä vaiheesta

pyritään saamaan nykytilan kuvaus. Kehittämismallissa nykytilan kuvauksesta saadaan

selville esimerkiksi työtoiminnan tarvittavat tiedot, työprosessikuvaukset, toiminnassa

tarvittavat tiedot ja mahdolliset kehityskohteet. Ensimmäisessä vaiheessa hyödynnettä-

viä menetelmiä ovat esimerkiksi tutustumiskäynnit kohdeorganisaatioon, haastattelut,

työpajat ja kirjallisuuskatsaus.

Toisen vaiheen tavoitteena on saavuttaa yhteinen käsitys työtoiminnan tavoitetilasta.

Tuloksena toisesta vaiheesta saadaan kuvauksia havaituista kehitystarpeista ja tavoiteti-

lan prosesseista. Kyseisiä kuvauksia hyödynnetään kolmannessa vaiheessa. Menetelmiä

yhteisen käsityksen saavuttamiseksi ovat esimerkiksi tulevaisuustyöpajat ja haastattelut.

Kolmannen vaiheen tavoitteena on suunnitella toimenpiteet, joiden avulla päästään ny-

kytilasta tavoitetilaan. Toimenpiteet keskittyvät toimintaan, ohjelmistoihin ja laitteisiin

kohdistuviin muutoksiin. Tuloksena pyritään saamaan esimerkiksi asiakasvaatimuksia

ja työtoiminnan muutokseen liittyviä suunnitelmia. [Zip05]

ZipIT-kehittämismallin läpiviennissä toimintaa tarkastellaan kolmella eri tarkkuustasol-

la. Tarkastelun taso lähtee organisaatiotasolta, kohti yksityiskohtaisempaa tarkastelu-

kulmaa. ZipIT-kehittämismallin eri tarkastelutasot mahdollistavat tarkemmalla tasolla

saatujen tulosten peilaamista ylempiin tarkasteluntasoihin. Tämän avulla voidaan ha-

vainnollistaa jonkin tietyn työprosessin sijoittuminen toimintakokonaisuuteen ja kysei-

sen prosessin suhdetta muihin tarkasteltaviin prosesseihin.

Ylimmällä tasolla tarkasteltavan näkökulman ohjaava tekijä on konteksti, jossa toimin-

takokonaisuuden yleiskuvaa tarkastellaan. Tarkastelun kohteena ovat organisaatiotason

toiminnot. Toisella tasolla näkökulmaa tarkennetaan toiminnan sisältämien työnkulku-

jen tasolle ja tarkastelun kohteena ovat ryhmät. Tarkimmalla tasolla tarkastelu keskittyy

aikaisemmin havaittujen työnkulkujen sisältämiin välineisiin ja tekoihin yhä tarkemmal-

la tasolla ja tarkastelun kohteena ovat yksittäiset käyttäjät. [Zip05] ZipIT-

58

kehittämismallin vaiheet ja niiden sisältämät menetelmät toimivat eräänlaisena viiteke-

hyksenä pilottiosastoilla tehdyille toimenpiteille.

5.3 Tutkimuksen toteutus

Tutkimuksen ensimmäisessä vaiheessa selvitettiin yksittäisen työntekijän työtoimintoja

nykytilanteen kartoittamiseksi. Nykytilan riittävä tunnistaminen on edellytys kaiken

uuden, esimerkiksi prototyyppien, kehittämiselle. Nyky- ja tavoitetilan suhde voidaan

nähdä molemminpuolisena ja vastavuoroisena prosessina, joka kehittyy yksityiskohtai-

semmaksi iteraatiossa ja vuorovaikutuksessa tutkimuksen ja suunnittelun avulla

[Cra98].

Osallistavan suunnittelun toteuttamiseksi pilottiosastolta valittiin työntekijöitä mahdol-

lisimman monipuolisesti eri ammattiryhmistä: sairaanhoitaja, fysioterapeutti, lääkäri ja

osastosihteeri. Yksittäisiä työntekijöitä tarkasteltaessa käytettiin menetelminä haastatte-

luja ja havainnointia. Haastattelut nauhoitettiin ja havainnoinnit myös valokuvattiin.

Työntekijöiden suorittamia työtehtäviä kuvattiin esimerkiksi työvirtakaavioiden avulla.

Tutkimuksen seuraavassa vaiheessa tarkastelun kohteena olivat edellisessä vaiheessa

kuvattujen henkilöiden keskinäiset suhteet ja kaikkien yhteistyössä ketjumaisesti toteu-

tetut työtehtävät. Eri työtehtävien suhde koko pilottiosaston toimintaan kuvattiin ZipIT -

tutkijoiden toimesta. Koko osaston toimintaa tutkittiin havainnoimalla, haastatteluilla ja

työpajoilla. Kuvausmenetelmänä käytettiin samankaltaisuusseinää. Pilottiosastoilla teh-

dyn tutkimuksen viimeisessä vaiheessa kuvattiin laajempaa organisaatiotason kokonai-

suutta, jolla luotiin opas uuden potilaskertomusjärjestelmän käyttöönoton tueksi.

Pilotin toteuttamiseen osallistui vaihtelevasti 2-4 tutkimushankkeen henkilöä. Kaikki

henkilöt osallistuivat kerättyjen tietojen analysointiin. Tämän pro gradu -tutkielman

toteutus liittyy pilottiin, mutta tutkielman tavoite eroaa ZipIt-tutkimushankkeen yhtey-

dessä tehdyn pilotin tavoitteista. Pilotin avulla haluttiin selvittää miten kohdeorganisaa-

tion työtoimintaa pystytään tukemaan uuden tietojärjestelmän käyttöönoton yhteydessä

ja miten käyttöönotto olisi mahdollisimman sujuvaa. Tässä pro gradu tutkielmassa ha-

luttiin selvittää pilotissa käytettyjen osallistavan suunnittelun menetelmien hyödyntämi-

nen uuden tietojärjestelmän käyttöönoton tukena. Tutkielmassa esitettävät tulokset no-

jaavat toteutetun pilotin aikana saatuihin kokemuksiin.

59

6 TUTKIMUKSEN TULOKSET

Tässä luvussa tarkastellaan tutkielmaan sisältyvän tutkimuksen tuloksia. Tutkimuksen

tärkeimpänä tuloksena ovat kokemukset ja havainnot osallistavien menetelmien käytös-

tä uuden potilaskertomusjärjestelmän käyttöönottoon liittyen. Pilotin aikana käytetyt

osallistavat menetelmät mahdollistivat kohdeorganisaation käyttäjien osallistamisen

käyttöönottoon suunnitteluun ja valmistautumiseen.

Pilotin toteutus ja menetelmät pohjautuivat ZipIT-kehittämismalliin, joka on esitelty

tarkemmin luvussa viisi. Pilottiin osallistui tilanteesta riippuen kahdesta neljään ZipIT-

tutkimushankkeen jäsentä, mutta tässä tutkielmassa esitettävät havainnot ja toteamukset

tuloksien osalta ovat kuitenkin tutkielman tekijän omia mielipiteitä.

Luvun alussa tarkastellaan osallistavien menetelmien käytöstä saatuja kokemuksia ja

menetelmien hyödynnettävyyttä uuden tietojärjestelmän käyttöönottovaiheen tukena.

Tarkasteltavat menetelmät ovat havainnointi, haastattelu ja työpajat.

Ensimmäisenä menetelmänä käytettiin havainnointia, jonka avulla pyrittiin saamaan

yleiskuva kohdeorganisaation osaston toiminnasta yksittäisten käyttäjien rooleista. Ha-

vainnoinnin jälkeen osaston keskeisimpiä työntekijöitä haastateltiin ja tarkennettiin hei-

dän suhdettaan eri tietovälineisiin ja osaston työprosesseihin. Kolmannessa vaiheessa

toteutettiin erilaisia työpajoja, joiden avulla havainnointien ja haastattelujen tarjoamat

tiedot pyrittiin koostamaan yhtenäiseksi kokonaisuudeksi.

Luvun lopussa tarkastellaan pilotin läpivientiä, joka noudatti ZipIT-kehittämismallin

esittelemää tapaa, ja peilataan sitä muihin tässä tutkielmassa esiteltyihin lähestymista-

poihin. Myös tutkimuksen aikana esille tulleet rajoitteet esitellään luvun lopussa.

60

6.1 Havainnointi

Ensimmäisenä osallistavan suunnittelun menetelmänä pilottiosastolla käytettiin havain-

nointia. Havainnoinnin avulla pyrittiin selvittämään osaston nykytilaa ja hahmottamaan

keskeisten työprosessien kulkua. Tavoitteena oli saada selville yleiskuva osaston toi-

minnasta ja selvittää eri käyttäjien tehtäviä osana osaston toimintoja. Työtehtävien to-

teuttamiseen tarvittavien tietovälineiden listaaminen oli nykytilankuvauksen kannalta

myös havainnoinnin keskeinen tehtävä.

Havainnointiin käytettiin yhteensä aikaa noin kaksi tuntia. Luvussa 3.4 esiteltyjen ha-

vainnoinnin yleispiirteiden mukaan havainnointi oli lajityypiltään osallistava havain-

nointi. Havainnointi oli samalla aktiivista keskustelua osapuolten, kohdeorganisaation

työntekijöiden ja havainnoijien, välillä. Havainnointi tarjosi tietoa eri käyttäjien työteh-

tävistä ja esille nousi paljon piilotettua ja hiljaista tietoa, joka selviää vain näkemällä

henkilöt työskentelemässä oikeassa työympäristössään.

Havainnoinnin aikana ei ollut vielä tarkoitus selvittää eri tietovälineiden yksityiskohtai-

sia ominaisuuksia, vaan saada selville keskeisimmät nykyisen tietojärjestelmän osat.

Elektronisen potilaskertomusjärjestelmän käyttöönoton kannalta nykyisiin paperiversi-

oiden käyttöön liittyvät toimenpiteet olivat huomion kohteena, erityisesti niiden sisäl-

tämät tiedonkäsittelyyn, kirjauksiin ja lukemiseen, liittyvät vaiheet. Käyttöönottoon

liittyen myös tiedon kulkuun liittyvien reittien tunnistaminen oli tärkeää.

Esivalmisteluina havainnointiin pilotin henkilöt päättivät kunkin roolit havainnointiti-

lanteessa. Kaikki henkilöt kirjasivat muistiinpanoja havainnoinnin yhteydessä ja yksi

henkilö toimi lisäksi kuvaajana. Havainnoinnin yhteydessä yksi henkilö käytti nauhuria.

Kameran ja nauhurin käytöstä sovittiin osaston henkilöiden kanssa ennen havainnoinnin

aloittamista. Erityisesti kameran käytöstä tulee sopia tarkasti, mitä saa kuvata, koska

terveydenhuollossa käsiteltävä tieto sisältää kriittistä potilastietoa. Tarkempaa työnjakoa

havainnoinnin painopisteestä ei tehty. Esimerkiksi käyttäjiä ei jaettu siten, että jokaisel-

la suunnitteluosapuolen jäsenellä olisi ollut oma seurantakohteensa. Tämän avulla pyrit-

tiin varmistamaan, että jokaiselle muodostuisi mahdollisimman laaja yleiskuva osaston

toiminnasta.

Havainnointi tehtiin lääkärinkierron yhteydessä. Lääkärinkierron aikana osastolla tar-

kastetaan päivystyspotilaat ja tutkitaan tapauskohtaisesti esimerkiksi jatkohoidon tarve

61

ja tehdään kotiuttamispäätökset. Lääkärinkierrolle osallistuivat kaksi osaston lääkäriä,

osastonhoitaja sekä kaksi muuta sairaanhoitajaa. ZipIT-tutkimushankkeen jäsenistä ha-

vainnointiin osallistui neljä henkilöä. Tiedon keräämisen apuna kierrolla ollut digitaali-

nen nauhuri annettiin aluksi osastonhoitajalle, mutta siirrettiin myöhemmin kiertoa joh-

taneelle lääkärille. Vaihdon syynä oli osastonhoitajan liikkuminen eri puolilla osastoa

tarkistamaan lääkärin huomioimia asioita potilaiden hoitoon liittyen. Nauhurin vaihdok-

sella haluttiin varmistaa, että lääkärinkierron keskeiset päätökset saadaan varmasti nau-

hurille. Havainnointia tehtäessä onkin tarkkaan mietittävä, kenen käyttäjän tarjoama

tieto on tärkeintä saada dokumentoitua.

Kameralla kuvattiin kierron aikana keskeisesti esillä olleita tietojärjestelmän osia. Uu-

den tietojärjestelmän käyttöönoton myötä lääkärinkierron yksi merkittävimmistä muu-

toksista koskee mukana kulkevaa potilastietokansiota. Nykytilassa potilastieto kulkee

lääkärinkierrolla mukana olevan kiertokärryn (kuva 12) paperikansioissa. Mukana ol-

leelta kannettavalta tietokoneelta katseltiin ensisijaisesti röntgenkuvia.

Kuva 12. Lääkärinkierron kiertokärry

Tulevaisuudessa uuden elektronisen potilaskertomusjärjestelmän ollessa käytössä kir-

jaaminen ja potilastietojen tarkastelu tapahtuu suoraan tietokoneelta. Tämän seuraukse-

na osaston käyttäjien työtehtävät muuttuvat ja entisten tehtävien tilalle tulee uusia. Ha-

vainnoinnin yhteydessä kävi ilmi, että osastonhoitaja valmistelee paperiset potilaskansi-

ot lääkäreille valmiiksi ennen lääkärinkiertoa. Tulevaisuudessa tämän tehtävän tilalle

voi tulla esimerkiksi kannettavan tietokoneen valmistelu. Näiden muuttuvien työtehtä-

62

vien huomioimisessa havainnointi toimi hyvänä keskustelun herättäjänä. Myös se, että

kyseessä oli eräs osastontoimintaa keskeisimmin kuvaava toimenpide, auttoi hahmotta-

maan nykytilaan kohdistuvia muutoksia laajasti.

Havainnoinnin yhteydessä käytiin myös alustavaa keskustelua tulevista muutoksista,

esimerkiksi laitekartoituksesta, joita osastolle joudutaan hankkimaan. Lääkärinkierron

yhteydessä kävi ilmi, että kaikkiin potilashuoneisiin ei liikuteltavaa kiertokärryä saa

viedä, koska tilan tulee säilyä täysin steriilinä. Mietittäväksi nousee sijoitetaanko huo-

neiden lähelle kiinteitä työpisteitä, joista voidaan tarkastella potilaan tietoja, vai voi-

daanko samaa kiertokärryä käyttää myös näiden kohdalla.

Toisena esimerkkinä tulevista muutoksista voidaan mainita röntgenkuvien katsominen

tietokoneen ruudulta. Havainnointi herätti kysymyksiä esimerkiksi siitä, tarvitaanko

lääkärinkierrolle mukaan kaksi tietokonetta. Toinen tietokone tulisi röntgenkuvien kat-

somiseen ja toinen potilaiden kertomustekstien kirjaamiseen. Havainnointi toimiikin

hyvin myös valmistelevana tapahtumana varsinaiseen laitekartoitukseen liittyen, mikä

on yksi keskeinen osa uuden tietojärjestelmän käyttöönottoa. Vastaavanlaisten muutos-

kohtien löytäminen onnistuu hyvin aktiivisen havainnoinnin avulla, jossa mahdollisista

tulevaisuuden työskentelytavoista keskustellaan todellisessa työympäristössä.

Kaikki ZipIT-osapuolen edustajat osallistuivat kysymyksien esittämiseen esille nous-

seista asioista ja tekivät muistiinpanoja tärkeiksi näkemistään kohdista. Havainnoinnin

näkökulmaa muokkasi havainnoinnin toteuttajien erilaiset näkemykset ja ennakkotiedot

kohteesta. Yksi neljästä ZipIT-osapuolen henkilöstä on aikaisemmalta koulutukseltaan

sairaanhoitaja. Kyseisen henkilön tietämys kohdeorganisaation toiminnasta mahdollisti

tarkkojen kysymysten esittämisen liittyen tiettyihin sairaalamaailman käytäntöihin ja

terminologiaan. Muiden havainnointiin osallistuneiden tietämys kohteen työtavoista ja

merkityksestä ei ollut yhtä laajaa. Toisaalta näillä henkilöillä ei ollut ennakko-odotuksia

ja -asennetta kohteessa tapahtuvaan työtoimintaan ja kaikki epäselvyydet pyrittiin sel-

vittämään kysymällä.

Kokemus kuitenkin osoitti, että havainnoinnissa on hyvä olla mukana henkilö, joka pys-

tyy tarkentamaan niitä toimintoja, jotka tulevat muuttumaan uuden tietojärjestelmän

käyttöönoton myötä. Henkilö, jolla on kohdealueen toiminnasta yksityiskohtaista tietoa

saattaa toimia usein keskustelun avaajana, minkä jälkeen myös muiden havainnointiin

osallistuvien on mahdollista laajentaa keskustelua eri suuntiin ja yleisemmälle tasolle.

63

Elektronisen potilaskertomusjärjestelmän käyttöönoton kannalta havainnointi tarjosi

hyötyjä erityisesti kohdeorganisaation nykytilan kokonaiskuvaan liittyen. Havainnoin-

nin kohteena olleiden henkilöiden konkreettisen työn seuraaminen tarjosi myös pinta-

puolisia kokemuksia nykyisten tietojärjestelmien käytöstä. Havainnointi tarjosi lääkä-

rinkierron yhteydessä tietoja aina kierron esivalmisteluista sen päättymiseen asti.

Työtoiminnassa tapahtuvat muutokset ovat eräs keskeisimmistä huomioitavista asioista

uuden tietojärjestelmän käyttöönotossa [SaK99]. Havainnointien ja muiden osallistavien

suunnittelumenetelmien aikana kohdeorganisaation käyttäjien tietoisuuteen pyrittiin

tuomaan uuden tietojärjestelmän mukana tulevien muutosten vaikutusten laajuus. Työ-

toiminnan kohtaamien muutosten suunnittelutoimenpiteet mahdollistavat osaston työn-

tekijöiden osallistumisen oman työnsä kehittämiseen.

Havainnoinnin avulla pystyttiin löytämään kehityskohtia, joiden vaikutus koskee useaa

osaston työntekijää. Havaitut asiat tarkentuivat haastattelujen sekä työpajojen yhteydes-

sä. Esimerkkinä koko yliopistosairaalan tasolla tapahtuvasta muutoksesta on potilastie-

tojen tuleva kirjaaja. Havainnoinnin yhteydessä kävi esimerkiksi ilmi, että osa lääkäreis-

tä ei kirjaa lääkärinkierron yhteydessä tietoja, vaan tietojen kirjoittaminen jää hoitajan

tehtäväksi. Havainnoinnin yhteydessä käydyssä keskustelussa nousikin esille asioita,

joiden kohdalla tarvitaan koko organisaatiota koskevia yleisiä toimintaohjeita käyttöön-

oton helpottamiseksi. Näitä organisaatiotasolla yleistettäviä asioita pohdittiin tarkemmin

sitten haastatteluissa ja työpajoissa.

Osaston nykytilaan keskeisesti liittyvien tietovälineiden huomioiminen havainnoinnin

yhteydessä on tärkeää. Havainnoinnin aikana huomattiin osastonhoitajan tekevän muis-

tiinpanoja lääkäreiden kommenttien pohjalta (kuva 13).

64

Kuva 13. Osastolla olevien potilaiden tietolomake, Kuva: Susanna Martikainen

Kysyttäessä osastonhoitajalta muistiinpanovälineestä selvisi, että osastolle on rakennet-

tu räätälöity järjestelmä käsittelemään osastolla olevien potilaiden tietoja. Kyseisestä

järjestelmästä voidaan tulostaa paperiversio käytettäväksi esimerkiksi lääkärinkierron

yhteydessä ja tehdyt muistiinpanot päivitetään järjestelmään jälkikäteen. Järjestelmä on

käyttäjille tärkeä ja sen huomioiminen potilaskertomusjärjestelmän käyttöönottoa ajatel-

len on ensiarvoisen tärkeää. Havainnoinnin yhteydessä havainnoijien tulee seurata tar-

kasti, mihin tietoa kirjataan ja mistä tietoa haetaan.

Havainnoinnin läpiviennin Bødker suosittelee yhden henkilön vastuulle ja perustelee

kantansa sillä, että havainnoinnin toteuttajat eivät aiheuttaisi tarkkailtavissa työnteki-

jöissä hämmennystä läsnäolollaan [BKS04]. Bødker ja muut eivät kuitenkaan ota kantaa

havainnoitavan joukon koon vaikutuksesta havainnoijien määrään. Pilotissa havain-

noinnin kohteena oli viisi henkilöä ja yhden henkilön olisi vaikea tarkkailla kerralla

kaikkien henkilöiden työtehtäviä. Määrään vaikuttaa myös tarkkailijoiden aikaisempi

suhde kohdeorganisaation toimintatapoihin ja se, kuinka tuttuja tarkasteltavat työproses-

sit ovat.

Pilotin neljä henkilöä pystyivät toimimaan havainnoinnin aikana aktiivisena osapuolena

ja herättämään keskustelua pilottiosastolla työntekijöiden kanssa. Neljän henkilön mu-

kanaolo mahdollisti huomion keskittämisen kaikkiin mukana olleisiin käyttäjiin. Neljän

henkilön mukanaolo mahdollisti myös yhden pilotin jäsenen keskittymisen ajoittain

valokuvien ottamiseen tietojärjestelmän keskeisistä osista.

65

Havainnoinnin alkuperäisenä tavoitteena ollut yleiskuvan muodostaminen osaston toi-

minnasta ja keskeisistä toimijoista tarjosi tulevien osallistavien menetelmien toteutta-

mista ajatellen riittävästi tietoa. Havainnoinnista saatujen tietojen avulla pystyttiin myös

muodostamaan pilotin jäsenten kesken yhtenäinen käsitys lääkärinkierron läpiviennistä.

Keskeisten käyttäjien kohdalla havainnointi toimi eräänlaisena esiehtona haastatteluun

valmistautumiselle. Osaston toiminnasta vastaavat käyttäjäryhmät pystyttiin löytämään

onnistuneesti. Havainnoinnin yhteydessä huomion kohteena olleet tietojärjestelmän osat

nykytilassa pystyttiin listaamaan riittävän tarkalla tasolla, jotta niistä saatuja tietoja pys-

tyttiin hyödyntämään tulevien haastatteluiden yhteydessä.

6.2 Haastattelut

Pilotin läpiviennissä haastattelut tehtiin havainnointien jälkeen. Haastatteluiden tavoit-

teena oli saada tarkennettua havainnointivaiheessa tunnistettujen keskeisten käyttäjä-

ryhmien rooleja osaston kokonaistoimintaan liittyen. Elektronisen potilaskertomusjär-

jestelmän käyttöönoton tuomat muutokset työtoimintaan pyrittiin ottamaan tässä vai-

heessa mukaan keskusteluun yksittäisen käyttäjän näkökulmasta. Haastatteluiden avulla

pyrittiin myös tuomaan esille kehityskohtia käyttäjien työtoimintaan liittyen. Työtoi-

minnan muutosten toteuttaminen tietojärjestelmän käyttöönoton yhteydessä voi olla

mahdollista ja tietyiltä osin välttämätöntä. Tietojärjestelmän käyttöönotto voidaan nähdä

tietynlaisena herätteenä, jonka aikana pyritään tehostamaan myös tietojärjestelmää ym-

päröivää toimintaa.

Haastattelut pidettiin kohdeorganisaation tiloissa ja haastateltavat henkilöt pyrittiin va-

litsemaan pilottiosaston henkilöstöstä mahdollisimman monipuolisesti. Beyerin mukaan

osallistavan suunnittelun näkökulmasta paras mahdollinen tulos saadaan, jos osallistuvat

henkilöt edustavat mahdollisimman monipuolisesti (työtehtävät, vastuut, koulutus) osal-

listuvaa organisaatiota [BeH98]. Tavoitteena oli saada haastateltavaksi edustaja pilotti-

osaston kaikista käyttäjäryhmistä, jotka havainnointivaiheessa oli tunnistettu. Haastatte-

luun valittiin pilottiosastolta osastosihteeri, fysioterapeutti ja osastonhoitaja. Lääkärin

haastattelua ei saatu järjestettyä aikataulujen johdosta. Haastatteluiden aikataulut ja

haastatteluun tarvittavat tilat tuleekin suunnitella etukäteen tarkalla tasolla. Erityisesti

sairaalaympäristössä henkilöstö on hyvin kiireistä ja yhden tunnin järjestäminen kesken

työpäivän ei ole itsestäänselvyys.

66

Haastatteluihin osallistui ZipIT-tutkimushankkeen jäsenistä vaihtelevasti 2-4 henkilöä.

Koska haastateltavia oli vain yksi kerrallaan ja haastattelut nauhoitettiin, olisi kaksi

henkilöä haastattelun suorittamiseen riittänyt. Toisaalta tämä olisi vaatinut aina, että

toinen haastattelija olisi terveydenhuollon ammattilainen. Kuten havainnoinnissa, myös

haastatteluissa tutkimushankkeen jäsenistä sairaanhoitajataustan omaava henkilö pystyi

toimimaan keskustelun avaajana ja estämään hiljaiset hetket haastattelun aikana tervey-

denhuollon kokonaisvaltaisen toiminnan tuntemuksellaan. Haastatteluja oli yhteensä

neljä.

Esivalmisteluina haastatteluille pilotin jäsenet suunnittelivat kysymysrunkoa, jonka mu-

kaan haastattelut etenivät. Havainnoinnin kohteena ollut lääkärinkierto antoi viitteitä

tulevan haastattelun sisällöstä. Haastattelun alussa käyttäjiä pyydettiin kertomaan konk-

reettisesti, mitä tehtäviä he tekevät työvuoron mukaisessa järjestyksessä ja mitä eri tie-

tovälineitä he käyttävät. Vastauksista saatiin kattavat listat, joiden avulla käyttäjien väli-

seen vuorovaikutukseen liittyvät asiat ja keskeisimmät tietojärjestelmän osat saatiin

selville. Osaston päivärytmi ja jokaisen käyttäjän työtehtävät tiettynä ajankohtana mah-

dollistivat työtehtävien liittymiset toisiinsa.

Tiedonkäsittelyyn liittyvät toimenpiteet ovat uuden potilaskertomusjärjestelmän käyt-

töönoton tuoman muutoksen kannalta tärkeää saada selville. Uuden tietojärjestelmän

käyttöönoton yhteydessä vastuut tiedon välittämisestä saattavat muuttua ja näiden kes-

keisimpien muutoskohtien tunnistamisessa haastattelut tarjoavat yksityiskohtaista tietoa

nykyisistä toimintatavoista, minkä kautta niitä voidaan peilata tavoitetilaan. Esimerkki-

nä voidaan mainita havainnointivaiheessa esille nousseet lääkärinkierron valmisteluun

liittyvät työt, joiden sisältö tulevaisuudessa tulee muuttumaan.

Haastattelun onnistumisen kannalta keskeiseksi asiaksi nousee oikeiden henkilöiden

valinta. Luvussa 2.3 mainituista seikoista haastateltavien ominaisuuksiin liittyen, toteu-

tetun pilotin aikana esille nousi erityisesti käyttäjän kyky nähdä osaston työprosessiket-

ju kokonaisvaltaisesti. Haastatteluissa tuli ilmi osastosihteerin rooli osaston keskeisenä

toimijana. Haastattelu paljasti osastosihteerin olevan vuorovaikutuksessa osaston mui-

hin käyttäjiin erityisesti tiedon kirjauksessa ja lähettämisessä eteenpäin. Keskeisten

käyttäjien kanssa keskustelua voidaan viedä organisatoriselle tasolle ja pystytään näin

esimerkiksi keräämään tärkeää esitietoa henkilöiden rooleista osaston toiminnassa.

67

Valitut haastateltavat haastateltiin yhden kerran, mutta keskeisten käyttäjien kanssa olisi

suositeltavaa tehdä useampia haastatteluita jos se ajallisesti on mahdollista. Tarkastelua

ei tarvitse aina pitää yksilötasolla, vaan koko organisaatiota koskevien ydinprosessien

analysointi saattaa paljastaa tärkeitä ongelmakohtia ja kehitystarpeita. Erityistä huomio-

ta tulee kiinnittää toimintojen rajapintoihin [SaK99]. Näiden asioiden selvitystyössä

keskeisten käyttäjien, pilotin tapauksessa osastosihteerin, rooli korostuu tiedon lähteenä.

Havainnointi auttoi valitsemaan oikeat henkilöt haastateltaviksi. Havainnoinnin antamat

tiedot osaston toiminnasta voivat parhaassa tapauksessa kertoa haluttujen käyttäjäryh-

mien lisäksi ryhmien sisältä aktiivisimmat ja motivoituneimmat haastateltavat. Haastat-

teluista saatavien tulosten hyödyllisyyden kannalta on tärkeää saada mukaan henkilöt,

jotka pystyvät tuomaan esille mahdollisimman paljon tietoa myös omien työtehtäviensä

ulkopuolelta.

Tehdyissä haastatteluissa tuli vastaan myös haastateltavia, jotka eivät osanneet kertoa

osaston toiminnasta lainkaan lisätietoa oman työnsä ulkopuolelta. Haastateltavat eivät

kertoneet juuri mitään oma-aloitteisesti ja näiden henkilöiden kohdalla oli tärkeää, että

haastattelutilanne oli valmisteltu riittävän tarkalla tasolla kysymyslistojen muodossa.

Näin henkilöltä saatiin kerättyä ainakin perustiedot.

Haastattelutilanteet nauhoitettiin digitaaliselle nauhurille ja nauhoitettu haastattelu jaet-

tiin digitaalisena kaikille ZipIT-tutkimushankkeesta pilottiin osallistuneille. Haastatte-

luiden nauhoittaminen helpotti haastattelun seuraamista ja mahdollisten muistiinpanojen

tekeminen ei vienyt huomiota pois haastateltavasta. Nauhoitetun haastattelun läpikäy-

minen jälkeenpäin selkeytti tehtyä haastattelua ja mahdollisti tärkeiden kohtien läpi-

käymisen uudelleen. Bødker korostaa juuri nauhoituksen tarjoamaa varmistuskeinoa

haastatteluiden tueksi. Bødker korostaa myös nauhoituksen käytön hyödyntämistä haas-

tatteluiden purkamisessa erilaisten kuvausten ja tiivistelmien tekemisen tukena

[BKS04].

Haastatteluiden kohdalla olisi nauhoitusten hyödyntämiseksi ollut hyvä tehdä Bødkerin

ehdottamia aikaleimoja tärkeiden kohtien tunnistamisen helpottamiseksi [BKS04].

Nauhoitukset olivat usein yli tunnin pituisia ja tietyn kohdan löytäminen oli suhteellisen

työlästä. Pilotissa uuden tietojärjestelmän käyttöönottoon liittyen olisi ollut tärkeää ko-

rostaa aikaleimalla esimerkiksi käyttöönoton kannalta keskeiset kohdat.

68

Haastatteluiden pohjalta muodostettiin osaston toimijoiden työpäivästä sekvenssikaavi-

oita. Sekvenssikaavioissa kuvattiin työtehtävien lisäksi kaikki tietojärjestelmän osat,

joihin kyseinen käyttäjä on yhteydessä päivän aikana. Listaamalla kaikki järjestelmät

saadaan yleiskuva kriittisimmistä järjestelmistä ja järjestelmän osista kyseisellä osastol-

la. Tärkeimpien tietojärjestelmän osien esille saaminen helpottaa tulevaisuudessa mah-

dollisesti tehtäviä integraatioita olemassa olevien ja tulevien järjestelmien välille. Haas-

tatteluiden runko noudatti edellä esitellyn mukaisesti käyttäjien päivärytmiä osastolla,

joten sekvenssikaavioiden muodostaminen vastaavalla tavalla oli helppoa.

Haastatteluissa saatiin selville tietojärjestelmien ja niiden osien merkitys ja tarpeellisuus

yksittäisen käyttäjän, osaston ja lopulta koko organisaation tasolla. Havainnointivai-

heessa tunnistettu tietojärjestelmän osa, esimerkiksi osastolla olevien potilaiden tiedot

sisältävä lista, osoittautui osaston toiminnan kannalta tärkeäksi osaksi. Haastatteluiden

pohjalta pystyttiin toteamaan, että kyseinen tietojärjestelmän osa oli keskeisesti osaston

kaikkien haastateltujen toimijoiden käytössä. Lista osaston potilaista (katso kuva 13)

tarjoaa selkeän ja joustavan esitystavan osastolla kyseisellä hetkellä olevista potilaista.

Tämän tietojärjestelmän osan merkitystä korostaa tieto, että uusi elektroninen potilas-

kertomusjärjestelmä ei alkuvaiheessa tarjoa kyseistä ominaisuutta.

Vastaavanlaisten pysyvien osien tunnistaminen on havainnointien ja haastattelujen poh-

jalta eräs tärkeimmistä asioista. Näihin pysyviin osiin liittyy pohdintaa käyttöönoton

näkökulmasta. Esimerkiksi havaittua osaston potilaiden listaa, joka on itsenäinen ohjel-

ma, joudutaan päivittämään usein ja tämä tehtävä saattaa vaihtua tulevaisuudessa toisel-

le käyttäjälle vastuiden uudelleenjärjestelyn vaiheessa.

Työn mallintamisen apuna käytettävät sekvenssikaaviot tarjoavat työn tarkkailuun laa-

jan näkökulman. Beyer ja Holtzblatt kuvaavat sen keinona "lintuperspektiivistä" tapah-

tuvaan tarkkailuun. Menetelmä tarjoaa hyvän yleiskuvan työpaikan toimijoista, heidän

vastuistaan ja toimijoiden väliseen kommunikointiin käytettävistä menetelmistä ja tieto-

järjestelmän osista [BeH98]. Esimerkki pilotin yhteydessä toteutetusta sekvenssikaavi-

osta on esitetty liitteessä 1.

Elektronisen potilaskertomusjärjestelmän käyttöönottoon liittyen haastattelut tarjosivat

tärkeää esitietoa osaston eri käyttäjien työtehtävistä. Ensiarvoisen tärkeää oli saada sel-

ville nykytilan kuvaus osaston käyttäjien toiminnasta. Haastattelut tarjosivat jokaisen

käyttäjän kohdalla samanaikaisesti kuvauksen sekä nykytilasta että tavoitetilasta yksit-

69

täisen käyttäjän työprosesseihin liittyen. Enemmän tietoa saatiin kerättyä nykytilaan

liittyvistä työprosesseista. Haastattelut tarjosivat kattavan yleiskuvan pilottiosaston yk-

sittäisen toimijan työpäivästä. Haastattelujen runko rakennettiin kuvaamaan käyttäjien

työpäivän kulkua ja näin haastatteluille saatiin muodostettua selkeä rakenne. Kaikkien

haastateltujen toimijoiden kohdalla työpäivää edettiin yhteneväisesti.

Haastattelun onnistunut toteuttaminen vaatii perehtymistä kysymysten ja haastattelun

rungon suunnitteluun. Näin pystytään varmistamaan, että kaikilta haastateltavilta saa-

daan tarvittava tieto jatkotyöskentelyä ajatellen. Haastattelut tarjosivat paljon hyödyn-

nettävää tietoa, koska haastatteluiden runko pidettiin samanlaisena. Tämän ansiosta eri

käyttäjäryhmien sijoittaminen osaksi osaston yleiskuvaa ja nykytilan kuvausta oli help-

poa. Havainnoinnin tarjoamat esitiedot osaston toiminnasta ja käyttäjistä antavat hyvän

pohjan valmistautua haastatteluihin. Havainnointien ja haastatteluiden pohjalta pilotti-

osaston toimintaa lähdettiin kuvaamaan koko osaston tasolla. Osallistavista menetelmis-

tä seuraavaksi käytettiin työpajatyöskentelyä.

6.3 Työpajatyöskentely

Elektronisen potilaskertomusjärjestelmän käyttöönottoon liittyvistä toimenpiteistä kes-

kusteleminen ja tärkeimpien työtoimintojen tunnistaminen on tärkeää, jotta niitä voi-

daan peilata tulevan järjestelmän kannalta toimivammaksi. Aikaisemmin tehdyt havain-

noinnit ja haastattelut loivat pohjan koko osaston toiminnan kuvaamiselle mahdolli-

simman tarkalla tasolla.

Pilotin aikana toteutettiin kahdenlaisia työpajoja: käyttäjätyöpajoja ja tutkimusryhmän

työpajoja. Tutkimusryhmän työpajoissa tarkoituksena oli koostaa havainnointien ja

haastatteluiden avulla kerätyt tiedot yhtenäiseksi esitykseksi pilottiosaston toiminnasta.

Tutkimusryhmän työpajoja pyrittiin järjestämään jokaisen kohdeorganisaatiossa käyn-

nin jälkeen. Muodostetun koosteen avulla pyrittiin ohjaamaan käyttäjätyöpajojen kes-

kustelua. Käyttäjätyöpajoissa, joita pidettiin kolme kappaletta, tarkoituksena oli saattaa

yhteen osaston henkilökuntaa kaikista ammattiryhmistä keskustelemaan ja pohtimaan

heidän työssään tekemiä hoitotoimenpiteitä ja elektronisen potilaskertomusjärjestelmän

tuomia muutoksia. Käyttäjätyöpajaan voidaan laskea kuuluvaksi myös käyttöönottoon

liittyvä laitekartoituspalaveri, jonka varsinaisena järjestäjänä toimi kohdeorganisaation

laitehankinnoista vastaava yksikkö.

70

Erityisen tärkeää työpajavaiheessa oli tunnistaa osaston työn sisältämät ydintoiminnot ja

pohtia niitä käyttöönoton näkökulmasta. Ydintoiminnoilla tarkoitetaan osaston toimin-

nan keskeisiä toimenpidesarjoja, joihin toteuttamiseen osaston toiminta suurilta osin

perustuu. Havaittuja ydintoimintoja olivat esimerkiksi lääkärinkierto, potilaan osastolle

ilmoittautuminen ja lääkärin potilaalle suorittama tulotarkastus. Tekniikka, jonka avulla

koko osaston toimintaa kuvattiin, oli samankaltaisuusseinä (affinity wall).

Samankaltaisuusseinä rakennettiin tutkimusryhmän työpajoissa ja sen pohjana käytettiin

havainnointien ja haastatteluiden yhteydessä saatuja kokemuksia. Samankaltaisuussei-

nän rakentaminen oli pilotin jäsenten yhteisen käsityksen varmistamisen kannalta tärke-

ää. Yhteisen käsityksen varmistaminen toi esiin uusia asioita, joita ei oltu dokumentoitu

tarkasti havainnoinnin tai haastattelun yhteydessä, mutta jotka olivat tärkeitä asioita

kokonaiskuvan muodostumisen kannalta. Työpajoissa tapahtuva aktiivinen keskustelu

tarjosi hyvän keinon tarkentaa pilotin aikaisemmissa vaiheissa kerättyjä havaintoja tar-

kemmalle tasolle.

Samankaltaisuusseinä rakennettiin kattamaan pilottiosaston toimintaa ja sen avulla py-

rittiin kuvaamaan osaston käyttäjien suhdetta hoitotyön sisältämiin ydintoimintoihin.

Samankaltaisuusseinän avulla saatiin rakennettua yleiskuva osaston toimijoiden työs-

sään käyttämistä tietojärjestelmän osista. Kuvassa 14 on esitetty pilotin yhteydessä tehty

samankaltaisuusseinä. Sama kuva löytyy isompana liitteestä 2.

Kuva 14. Samankaltaisuusseinä ZipIT-tutkimusryhmän työpajasta, kuva: Liisa Klemola

71

Kuvassa on esitelty kaikkien osaston toimintaan liittyvien käyttäjien päivän aikana ta-

pahtuva työ ja käytettävät tietojärjestelmän osat. Kuvan yläreunassa on esitetty osaston

kaikki toimijat (käyttäjät). Toimijoiden alapuolella on listattu kaikki tietojärjestelmän

osat, joita pilottiosaston toiminnassa tunnistettiin. Tietojärjestelmän osien kohdalla

huomio kiinnitettiin erityisesti niihin kohtiin, joissa elektronisen potilaskertomusjärjes-

telmän käyttöönotto muuttaa toimintatapoja. Nämä muuttuvat tietojärjestelmän osat

merkittiin muista erottuvaksi punaisella post-it lapulla, jotta niiden hahmottaminen ko-

konaisuudesta olisi helpompaa. Elektronisen potilaskertomusjärjestelmän käyttöönoton

aiheuttamat muutokset yksittäisen toimijan työtehtävissä voidaan hahmottaa selkeästi

muodostetun samankaltaisuusseinän avulla. Näiden keskeisten muutoskohtien tunnista-

minen ohjasi käyttöönoton valmistelua jatkossa yhä tarkemmalle tasolle käyttäjätyöpa-

joissa.

Kuvan oikeaan reunaan on poimittu pilottiosaston toiminnasta esille nousseet ydintoi-

minnot, joihin tulee kiinnittää erityistä huomiota uuden potilaskertomusjärjestelmän

käyttöönoton yhteydessä. Esille nostettujen osaston hoitotyöhön liittyvien ydintoiminto-

jen tarkoitus oli ohjata tulevien työpajojen työskentelyä. Ydintoimintojen avulla oli tar-

koitus saada pilottiosaston käyttäjät pohtimaan, miten uusi elektroninen potilaskerto-

musjärjestelmä tulee muuttamaan olemassa olevia työskentelytapoja.

Kohdeorganisaatio järjesti pilottiosastolle työpajan, jossa aiheena oli osastoa koskeva

laitekartoitus. Luvussa 4.1 esiteltyjen tietojärjestelmän käyttöönottoprojektin yhteydessä

tehtävän laitekartoituksen keskeisiä asioita ovat Sinikka Ripatin mukaan tulevien käyt-

täjien määrä, käytettävien työasemien määrä, yhtäaikaisten järjestelmien käyttäjien mää-

rä sekä tapahtumien määrä [SaK98]. Laitekartoituksessa käsiteltiin esimerkiksi osastolle

tulevien tietokoneiden määrää, hankintojen kustannuksia, langattoman verkon kanta-

vuuteen liittyviä näkökulmia ja työasemien sijoittelua. Aikaisemmin tehty havainnointi

tarjosi esimerkiksi työasemien sijoitteluun vaikuttavien asioiden tunnistamista.

Laitekartoitustyöpajan kulku sujui tiiviisti laitehankintojen ympärillä ja oli selkeää.

Työpajan sujuvuuteen vaikuttava seikka oli esimerkiksi, että laitekartoituksen vetäjät

tulivat kohdeorganisaation sisältä. Myös työpajan rakenne noudatteli kohdeorganisaa-

tiossa omaksuttua rakennetta ja käyttäjien oli mahdollisesti helpompi mukautua työpa-

jan kulkuun.

72

Yksi käyttäjätyöpajoista eteni osaston käyttäjien itsenäisesti valmistaman asialistan mu-

kaan. Asialista käsitteli yleistettävien asioiden listaa, joka sisälsi kohtia joihin käyttäjien

tulee saada ohjeistusta käyttöönoton yhteydessä. Tutkimushankkeen jäsenien suunnitte-

lema ydintoimintojen kautta etenevä työpaja ei näin ollen täysin toteutunut. Ydintoimin-

tojen kautta oli tarkoitus saada käyttäjät pohtimaan kohtia, joissa heidän työnsä osastol-

la käyttöönoton yhteydessä tulee muuttumaan. Tärkeimmäksi tulokseksi työpajoista

nousi ohjeistusta vaativien kohtien pohdinta, joihin kohdeorganisaation ylemmiltä ta-

hoilta odotetaan neuvoja.

Löydetyt ydintoiminnot eivät ohjanneet käyttäjätyöpajan kulkua, mutta työpajaan osal-

listuneet käyttäjät tunnistivat niiden kautta asiayhteyksiä, joihin tulee kiinnittää erityistä

huomiota osastolla uuden potilaskertomusjärjestelmän käyttöönoton yhteydessä. Työpa-

jan yksi tärkeimmistä tuloksista oli huomata, että käyttäjät alkoivat hahmottaa edessä

olevia muutoksia käyttöönoton yhteydessä ja keskustelu vaadittavista toimenpiteistä

saatiin käyntiin. Suunnittelijaosapuolen tuleekin tarvittaessa mukautua työpajan kul-

kuun. Toteutetussa työpajassa olikin tärkeää, että suunnittelijaosapuoli ei torjunut käyt-

täjien itse laatimaa asialistaa työpajan läpiviennille. Käyttäjien tuoma oma panostus

käyttöönottoprojektiin liittyen on tärkeää ja osallistavan suunnittelun kannalta keskei-

nen asia.

Laitekartoitustyöpajan ja käyttäjätyöpajan välillä eroa syntyi siinä, miten käyttäjät osal-

listuivat keskustelun. Laitekartoitukseen osallistui osaston lääkäreitä, jotka keskustelivat

muuta osaston henkilökuntaa enemmän. Laitekartoituksessa osaston muu henkilökunta

ei ollut yhtä aktiivisena kuin pilotin puolelta järjestetyssä käyttäjätyöpajassa, johon ei

osallistunut osaston lääkäreitä ja keskustelu eteni vapaammin. Tuleviin työpajoihin olisi

mahdollista ottaa mukaan kysymyskierroksia, jotta kaikki mukana olevat käyttäjät sai-

sivat mahdollisuuden kertoa mielipiteensä.

Työpajoissa mukana olleiden käyttäjien osallistumiseen vaikutti suurelta osin osaston

työaikataulut. Työpajoja tulisikin suunnitella pidettäväksi mahdollisimman usein, jotta

kaikilla käyttäjillä olisi mahdollisuus osallistua edes johonkin työpajaan. Erityisesti ter-

veydenhuollon organisaatioissa kiireellisyys ja aikatauluongelmat tulivat esille koko

pilotin ajan. Työpajan läpivienti tulisi suunnitella tarkasti ja mahdollisten muutoksien

varalle esimerkiksi Bødker suosittelee nauhurin käyttöä, jotta mahdolliset muutokset

eivät aiheuta työpajan pitäjälle ongelmia [BKS04].

73

6.4 Osallistavien menetelmien läpivienti

Käyttöönottopilotissa edettiin ZipIT-kehittämismallin mukaisesti, joka tarjoaa lähesty-

mistavan osallistavan suunnittelun toteuttamiseen. Pilotin etenemisessä on havaittavissa

yhtäläisyyksiä erityisesti luvussa 3.1 esiteltyyn Contextual Design lähestymistapaan.

Contextual Design lähestyy suunnitteluprosessia front end näkökulmasta, jossa suunnit-

telun lähtökohtana pidetään käyttäjien työstä saatavaa tietoa [BeH99]. Contextual De-

signin vaiheittainen eteneminen muistuttaa myös pilotissa toteutettuja tapoja. Yhtenä

esimerkkinä voidaan mainita havainnoinnin pohjalta toteutettava yleiskuvan mallinta-

minen, joka on hyvin lähellä pilotin yhteydessä toteutettua mallia.

Contextual Design lähestymistapa ei suosittele tehtäväksi pelkkiä haastatteluita ilman,

että samalla havainnoitaisiin käyttäjää tekemässä työtään [BeH98]. Pilotin kohdalla

huomattiin, että pelkkä haastattelu ennalta sovitulla rungolla saattaa tarjota parempia

tuloksia tiettyjen käyttäjien kohdalla kuin havainnointi. Haastatteluiden onnistumiseksi

huomio tuleekin kiinnittää käyttäjien aktiivisuuteen ja arvioida tapauskohtaisesti mikä

menetelmä tarjoaa parhaat tulokset.

Terveydenhuollon organisaatiossa tehtävä työ ei etene aina saman kaavan mukaisesti ja

havainnointi ei tarjoa koko työn kattavaa kuvaa käyttäjien työstä. Pilotin aikana havait-

tiin, että käytettävissä oleva aika, työntekijöiden ominaisuudet ja menetelmälle asetetta-

vat tavoitteet vaikuttavat siihen käytetäänkö tiedon keräämisessä havainnointia vai haas-

tattelua. Pilotissa haastattelun tekeminen keskeisille työntekijöille samanlaisen kysy-

mysrungon mukaisesti tarjosi selkeän kuvaustavan läpi pilottiosaston. Pilotissa havain-

nointi ja haastattelu oli erotettu erillisiksi toimenpiteiksi ja se tarjosi hyvät valmiudet

käyttöönottoprosessin jatkosuunnittelulle.

Contextual Designin neljännessä vaiheessa tapahtuva työn uudelleensuunnittelu tarjoaa

vastaavia työpajoja suunnittelun tueksi kuin pilotissa käytettiin. Contextual Design on

lähtökohdiltaan kuitenkin suunnittelijapainotteinen (katso luku 3.5) ja pilotin tapa vas-

taavasti sisälsi aktiivista käyttäjä-suunnittelija yhteistyötä sekä oli osittain myös käyttä-

jävetoista.

74

Tutkielmassa esiteltävistä lähestymistavoista MUST-metodi toimii toisena pääsuunta-

uksena osallistavan suunnittelun läpiviemiseksi. MUST painottaa kohdeorganisaation

käyttäjien roolia suunnitteluprosessin keskeisenä tekijänä. Lähestymistapa tuo käyttäji-

en rooliin poliittisen näkökulman, joka korostaa käyttäjien oikeutta päästä osalliseksi

omaan työhön liittyvien muutosten hallintaan. Tämä näkökulma olisi tärkeää tuoda esil-

le ennen varsinaisten osallistavien menetelmien aloittamista.

Varsinaisen suunnitteluprojektin läpiviemiseksi MUST esittelee neljä vaihetta (aloitus,

in-line analyysi, in-depth analyysi ja innovaatio). Pilotin ja MUST-metodin läpiviennis-

tä pystytään tunnistamaan yhtäläisyyksiä tehtyjen vaiheiden kohdalta. In-line analyysi-

vaiheessa MUST kuvaa keskeisten työtoimintojen tunnistamista ennen In-depth ana-

lyysivaiheessa toteutettavaa työtoimintaan liittyvän tiedon keräämistä, analysointia ja

esittämistä [BKS04]. Pilotissa saatujen kokemusten mukaan esitiedot keskeisimmistä

käyttäjäryhmistä ovat esiehtoja haastateltavien valitsemisessa.

MUST-metodin innovaatiovaiheessa korostetaan rajoitusten huomioimista suunnittelu-

projektin toteutuksessa. Pilotissa esille nousseet rajoitukset liittyivät esimerkiksi koulu-

tukseen varattaviin tiloihin ja aikatauluihin, joita käyttäjien työ suunnitteluprojektille

asettaa. Pilotin läpiviennissä eräs keskeinen havainto oli, että ULRC:n (katso luku 3.3.3)

ja ZipIT-kehittämismallin tavoitteet ovat lähellä toisiaan. Molempien tavoitteena on

kaventaa käyttäjien ja suunnittelijoiden työhön liittyvää kulttuurieroa. ULRC:n mukai-

sesti toteutetun pilotin tavoitteena oli saada kohdeorganisaation käyttäjät toimimaan

itsenäisesti oman työnsä kehittämisessä. Pilotissa käyttäjät suunnittelivat itsenäisesti

yhden työpajan kulkua näkökulmasta, jonka käyttäjät itse kokivat tärkeäksi tulevaan

tietojärjestelmän käyttöönottoon liittyen.

ULRC sisältää (katso kuva 7.) kolmivaiheisen mallin käyttäjien itsenäiseen työskente-

lyyn vaatimusten mallintajana. ULRC:n sisältämät vaiheet ovat käyttäjien koulutus,

nykytilan mallinnus ja tavoitetilan mallinnus. Pilotin yhteydessä kohdeorganisaation

käyttäjien itsenäisen suunnittelutyön avuksi tehtiin eräänlainen koulutusopas, jonka

avulla käyttäjät pystyvät kehittämään omaa työtään ja valmistautumaan uuden potilas-

kertomusjärjestelmän käyttöönottoon. Käyttäjien itsenäisen työskentelyn tueksi tehty

opas pyrittiin pitämään riittävän selkeällä tasolla, jotta käyttäjien olisi mahdollisimman

helppo toteuttaa esiteltyjä tehtäviä. Tämän tutkielman tuloksiin ei ole liitetty havaintoja

toteutetun koulutusoppaan käytöstä saatuja tuloksia kohdeorganisaatiossa.

75

Yleisesti ottaen lähestymistapana käytetty ZipIT-kehittämismalli tarjosi selkeän rungon

osallistaville menetelmille ja niiden soveltamiselle. Kokonaisuutena käyttäjien osallis-

tamisessa esille nousi nykytilan tunnistaminen esiehtona tarkempien kuvauksien toteut-

tamiselle kohdeorganisaation käyttäjien työstä. Tämä toistuu lähes kaikkien esiteltyjen

lähestymistapojen kohdalla.

Osallistavan suunnittelun toteuttamiseen terveydenhuollon organisaatiossa liittyy lähei-

sesti pilotin kokemusten perusteella havaittu resurssipula käyttäjien käytettävissä ole-

vasta ajasta. Tämä aiheuttaa osallistavan suunnittelun läpiviennille omat haasteensa.

Käytettävissä olevan ajan rajallisuus korostaa tarkkojen suunnitelmien tekemistä osallis-

taville menetelmille. Suunnittelijoiden tulee pohtia tarkasti esimerkiksi keitä havainnoi-

daan ja haastatellaan, mikä on havainnoinnin tavoite ja kuinka monta työpajaa on tar-

peellista järjestää.

Pilotissa läpivienti onnistui hyvin, suurelta osin onnistuneen havainnoinnin johdosta.

Havainnoinnin avulla saatiin tavoitteena ollut yleiskuva muodostettua osaston toimin-

nasta riittävän tarkalla tasolla. Havainnoinnin onnistumiseen vaikutti myös se, että ha-

vainnointi suoritettiin osaston toimintaa keskeisesti kuvaavan prosessin, lääkärinkierron,

yhteydessä. Yleisesti voidaankin todeta, että alkuvaiheessa käytettävien menetelmien

merkitys korostuu siirryttäessä tarkemman tason kuvauksiin pyrkiviin menetelmiin.

76

7 YHTEENVETO JA POHDINTA

Osallistava suunnittelu pyrkii tuomaan tietojärjestelmien käyttäjät ja suunnittelijat lä-

hemmäksi toisiaan, jotta tuloksena saataisiin asiakkaiden tarpeisiin mahdollisimman

onnistuneita tietojärjestelmiä. Osallistavan suunnittelun menetelmiä käyttäjien osallis-

tamiseksi voidaan hyödyntää ohjelmistotuotantoprosessin elinkaaren eri vaiheissa. Pää-

asiallisesti osallistavan suunnittelun menetelmiä on hyödynnetty ohjelmistotuotantopro-

sessin alussa asiakasvaatimusten keräämisen yhteydessä. Tutkielman tutkimusosiossa

kuitenkin tutkittiin miten osallistavan suunnittelun menetelmiä pystytään hyödyntämään

tietojärjestelmän käyttöönottovaiheen tukena.

Tutkielmassa käsitellyistä osallistavan suunnittelun lähestymistavoista tarkasteltiin ensi-

sijaisesti Contextual Designia ja MUST-metodia. Näiden lähestymistapojen sisältämät

suositukset osallistavan suunnittelun läpiviennille ja käytettäville menetelmille ovat

suurilta osin yhteneviä ja tarjoavat hyvän yleiskuvan osallistavan suunnittelun toteutta-

misesta. Tutkielmassa käsiteltiin myös muita osallistavan suunnittelun lähestymistapoja,

joiden avulla käyttäjät voidaan huomioida suunnitteluprojektin aikana. Tutkielmassa

käsitellyt lähestymistavat tarjosivat hyvän läpileikkauksen osallistavan suunnittelun

toteuttamiselle.

Tutkielman tutkimusosiossa lähestymistapana käytettiin ZipIT-tutkimushankkeessa ke-

hitettävää kehittämismallia. ZipIt-tutkimushankkeen yhteydessä tehty pilotti mahdollisti

osallistavan suunnittelun konkreettista soveltamista lähes Contextual Designin ja

MUST-metodin esittämillä tavoilla. Erityisesti yhtymäkohtia löytyi Contextual Desig-

nin kanssa. Sekä ZipIT-kehittämismalli että Contextual Design korostavat osallistavan

suunnittelun toteutuksessa ensimmäisten vaiheiden merkitystä. Suunnitteluprosessin

ensimmäisissä vaiheissa nämä lähestymistavat korostavat kohdeorganisaatiossa tapah-

tuvan työtoiminnan nykytilan kartoittamisen tärkeyttä.

Nykytilan hahmottamisen merkitys huomattiin myös pilotin yhteydessä. Käyttäjien

kanssa käytävä keskustelu kohteessa tapahtuvista muutoksista täytyy pystyä perustele-

maan nykytilan kautta. Nykytilassa tapahtuvien työprosessien suhteuttaminen tavoiteti-

laan, tietojärjestelmän käyttöönottohetkeen, oli jatkuvasti taustalla käyttäjien kanssa

käydyissä keskusteluissa. Voidaankin todeta, että nykytilan riittävä tunnistaminen toimii

esiehtona osallistavan suunnittelun sujuvalle etenemiselle.

77

Osallistavaa suunnittelua toteutetaan erilaisten osallistavien menetelmien avulla. Mene-

telmät, joita tutkielmassa keskeisesti tarkasteltiin olivat havainnointi, haastattelu ja työ-

pajatyöskentely. Kohdeorganisaation toimintaa selvitettiin osallistavien menetelmien

avulla, joista ensimmäisenä käytettiin havainnointia.

Havainnointi tarjosi kattavan yleiskuvan pilotissa kohteena olleen yliopistosairaalan

osaston toiminnasta. Havainnointi toimi pohjana muiden osallistavien menetelmien to-

teuttamiselle. Havainnointiin tulee panostaa, ja esimerkiksi tiukkojen aikataulujen ym-

päröimässä tilanteessa havainnoinnin osuutta ei tule lähteä ensimmäisenä vähentämään.

Havainnoinnin tarjoama yleiskuva osaston eri toimijoiden roolista sairaalan toimintaa

keskeisesti ohjaavien ydinprosessien parissa on käyttöönotonkin näkökulmasta kriittistä

informaatiota. Pilotissa havainnointi tehtiin lääkärinkierron yhteydessä. Lääkärinkierto

valittiin havainnoitavaksi ydinprosessiksi, sillä siihen liittyy useita toimenpiteitä joiden

huomioimiseen käyttöönoton kannalta tulisi keskittyä. Havainnoitava prosessi tulee

miettiä etukäteen hyvin tarkasti, jotta havainnoinnista saatava hyöty on paras mahdolli-

nen.

Ydinprosessin valinta osaston keskeisenä prosessina toimi alustana havainnoinnin on-

nistumiselle. Yleisesti ottaen pilotissa toteutettu havainnointi onnistui hyvin ja siitä saa-

dut tulokset mahdollistivat siirtymisen osallistavien suunnittelumenetelmien käytössä

seuraaviin vaiheisiin, joissa kohdeorganisaatioin käyttäjien toimintaa lähdettiin tarkaste-

lemaan yksittäisen resurssin tasolta.

Yksittäinen merkittävä tekijä havainnoinnin onnistumiselle oli, että yksi pilotin jäsenistä

on aikaisemmalta koulutukseltaan sairaanhoitaja ja työskennellyt kohdeorganisaationa

olleessa yliopistosairaalassa. Kyseisen henkilön kokemus mahdollisti yksityiskohtaisten

kysymysten esittämisen havainnoitavana olleilta käyttäjiltä. Henkilö toimi useissa tilan-

teissa läpi pilotin keskustelun aloittajana, mikä helpotti asioiden aktiivista käsittelyä.

Havainnoinnin yhteydessä valittiin osaston toimintaan keskeisesti liittyvät käyttäjät

haastateltavaksi pilotin seuraavaan vaiheeseen.

Haastatteluiden avulla lähdettiin tarkentamaan havainnointivaiheessa tunnistettujen kes-

keisten käyttäjien suhdetta osaston kokonaistoimintaan. Käyttöönoton kannalta haastat-

telut tarjosivat tärkeää tietoa käyttäjien työssään tarvitsemista tietojärjestelmän osista,

joihin käyttöönotto tulee aiheuttamaan muutoksia. Haastatteluiden onnistumista voidaan

parantaa tekemällä kysymyslistoja, joiden avulla haastatteluiden kulkua voidaan ohjata.

78

Yksittäisen käyttäjän kohdalla keskeiseksi tulokseksi nousi käyttäjän työstään tarjoaman

tiedon liittyminen osaston muiden käyttäjien työpäivän kulkuun. Haastatteluiden etene-

minen vaihteli eri käyttäjien kohdalla, ja suunnittelijaosapuolen tuleekin osata mukautua

eri haastattelutilanteisiin ja niiden aikana tapahtuviin muutoksiin. Haastatteluiden tulok-

sena tulisi pystyä saamaan käyttäjältä tietoa ainakin haastattelulle asetettujen vähim-

mäistavoitteiden osalta. Tavoitteen asettaminen haastattelulle onkin haastatteluidenon-

nistumisen edellytys. Havainnointien ja haastatteluiden pohjalta pilottiosaston toimintaa

lähdettiin kuvaamaan koko osaston tasolla. Osallistavista menetelmistä käytettiin seu-

raavaksi työpajatyöskentelyä.

Työpajatyöskentelyn tuoma hyöty käyttöönottoprojektin näkökulmasta oli osaston toi-

minnassa vaadittavien muutoskohtien konkretisoituminen. Tutkimusryhmän työpajassa

koostettu samankaltaisuusseinä kokosi yhteen havainnoinnin ja haastatteluiden yhtey-

dessä kerätyt tiedot osaston toiminnasta. Samankaltaisuusseinän avulla pystyttiin muo-

dostamaan yhtenäinen kuva nykyisistä tietojärjestelmistä ja eri käyttäjien rooleista osas-

ton toiminnassa. Yksi samankaltaisuusseinän tuloksista oli löytää ne tietojärjestelmän

osat, joihin käyttöönoton yhteydessä tulee tapahtumaan muutoksia. Työpajalle asetettu

tavoite ydintoimintojen löytämiseksi ohjasi samankaltaisuusseinän rakentamista ja tar-

josi käyttäjätyöpajoihin konkreettista tietoa niistä ydintoiminnoista, joihin kohdeorgani-

saatiossa tulee käyttöönoton yhteydessä varautua.

Käyttäjätyöpajaan valmistautuminen tapahtui edellä tunnistettujen ydintoimintojen ja

tutkimusryhmän työpajassa kerättyjen osaston toimintaa keskeisesti kuvaavien prosessi-

ketjujen, ydintoimintoja avulla. Käyttäjätyöpaja eteni kuitenkin osaston käyttäjien itse-

näisesti valmistaman asialistan mukaan ja suunnittelijaosapuolen tekemä. Ydintoimin-

not toimivat lähinnä keskustelun herättäjänä.

Onnistuneen käyttäjätyöpajan taustalla oli keskustelun liikkuminen konkreettisten asioi-

den ympärillä. Käyttäjien oli helppo puhua omaan työhönsä kohdistuvista muutoksista

ja yksittäisten työtehtävien käsittelyn kautta keskustelu saatiin liikkumaan riittävän tar-

kalla tasolla työpajan tulosta ajatellen.

Osallistavan suunnittelun yhdistäminen tietojärjestelmän käyttöönoton yhteyteen toi

esille tosiasian, kuinka laajat vaikutukset uudella tietojärjestelmällä organisaatioissa on.

Tämä korostui erityisesti pilotissa olleessa terveydenhuollon organisaatiossa, jossa käsi-

teltävä potilastieto on kriittistä ja tiedon saatavuus on varmistettava kaikissa tilanteissa.

79

Käyttöönoton tuomiin haasteisiin liittyi myös siirtyminen perinteisestä paperille kirjat-

tavista prosesseista elektroniseen kirjaukseen. Osallistavan suunnittelun menetelmät

tarjosivat keinot näiden keskeisimpien muutoskohtien tunnistamisessa.

Osallistavan suunnittelun käyttö tarjosi hyviä tuloksia myös kohdeorganisaation käyttä-

jien asenteiden muokkaamisessa käyttöönoton valmistautumiseen liittyen. Osallistavan

suunnittelun menetelmillä kohdeorganisaation käyttäjät saivat konkreettisen kuvan siitä,

miten heidän tekemänsä työ voi tulla muuttumaan ja miten siihen pystytään valmistau-

tumaan. Yksi esimerkki oli tilanne, jossa yksi käyttöönoton suunnitteluun liittyvä työpa-

ja toteutettiin ennakkosuunnitelmista poiketen osaston käyttäjien itse tärkeiksi näkemil-

lään asioilla käyttöönottoon liittyen. Osaston käyttäjät olivat oma-aloitteisesti listanneet

ylös asioita, joihin heidän mielestään tulisi saada ohjeistusta organisaation korkeammal-

ta tasolta, jotta käyttöönoton onnistumista voitaisiin parantaa. Osallistavan suunnittelun

toteuttajaosapuoli toimiikin suurilta osin kohdeorganisaation käyttäjien motivoijana ja

keskustelun herättäjänä. Lopullinen hyväksyntä käyttöönottoprosessiin valmistautumi-

selle täytyy tulla käyttäjiltä itseltään.

Kokonaisuudessaan osallistava suunnittelu tarjosi mielenkiintoisen lähestymisnäkökul-

man tietojärjestelmän käyttöönottoprosessin ja osallistavien menetelmien käytöllä saa-

tiin selkeästi positiivisia tuloksia. Osallistavan suunnittelun merkitys käyttöönottopro-

sessiin valmistautuessa korostui erityisesti yksittäisen käyttäjän näkökulmaa tarkastelta-

essa, sillä osastolla tapahtuvat muutokset heijastuvat lopulta yksittäisen käyttäjän työ-

tehtävään. Havainnointi, haastattelu ja työpajat tarjosivat kattavan läpileikkauksen tule-

viin muutoskohtiin ja yksittäisen käyttäjän suorittamat työtoimenpiteet saatiin muodos-

tettua selkeäksi kokonaiskuvaksi osaston toiminnasta. Osallistavan suunnittelun mene-

telmät paljastivat myös ne osaston toiminnan kriittiset kohdat, joihin käyttäjät tarvitse-

vat selkeitä ohjeita käyttöönoton aikana.

80

LÄHTEET

[Alt80] Alter, S.: Decision Support Systems: Current Practice and Continuing

Challenges, Addison-Wesley Publishing Company, Philippines, 1980

[And92] Anderson, R.J.: Representations and requirements: The value of ethno

graphy insystem Design. Human-Computer Interaction, 9, 152–182, 1992

[BAP01] Bürkle, T., Ammenwerth, E., Prokosch, H. and Dudeck, J.: Evaluation of

clinical information systems. What can be evaluated and what cannot?,

Journal of Evaluation in Clinical Practice, 7, 4, 373-385, 2001

[BeH95] Beyer, H., Holzblatt, K.: Apprenticing with the customer, Commununica

tions of the ACM, 1993:36(4):78-85.

[BeH98] Beyer, H., Holzblatt, K.: Contextual design: defining customer-centered

systems, Morgan Kaufman, CA, 1998

[BeH99] Beyer, H., Holtzblatt, K.: Contextual design, Interactions, v.6 n.1, p.32-

42, Jan./Feb. 1999

[Ber01] Berg, M.: Implementing information systems in health care organizations:

myths and challenges, International Journal of Medical Informatics,

2001;64:143-156.

[BeT03] Berg, M., Toussaint, P.: The Mantra of modeling and rhe forgotten powers

of paper: a sociotechincal view on the development of process-oriented

ICT in health care, International Journal of Medical Informatics, 69 (2/3)

(2003) 223-234.

[BKS04] Bødker, K., Kensing, F., and Simonsen, J.: Participatory IT design: desig

ning for business and workplace realities, The MIT press, 2004

[ChS90] Checkland, Peter, Scholes, Jim: Soft Systems Methodology in Action,

Wiley, 1990

81

[CoM02] Coughlan, J., and Macredie, R. D.: Effective Communication in Require

ments Elicitation: A Comparison of Methodologies, Requirements En

gineering, 7 (2002), pp. 47–60.

[Cra98] Crabtree, A.: Ethnography in participatory design, Proceedings of the

1998 Participatory Design Conference, 1998, November 12-14, pp. 93-

105.

[CWG93] Carmel, Erran, Whitaker, Randall D., George, Joey F.: PD and Joint Ap

plication Design: A Transatlantic Comparison, Communications of the

ACM, Volume 36, No. 4, 1993, s. 40-48

[DaO85] Davis, G. and Olson, M.: Management information systems: Conceptual

foundations, structure and development, Mc-Graw-Hill Book Company,

New York, 1985

[Eas88] Eason, K.: Information Technology and Organizational Change, Taylor &

Francis 107-222, London, 1988

[Eng04] Engeström, Yrjö: Ekspansiivinen oppiminen ja yhteistyökehittely työssä,

Vastapaino, Tampere 2004

[FFM06] Vivienne Farrell, Graham Farrell, Kon Mouzakis, Chris Pilgrim, Pauline

Byrt.: PICTIOL: a case study in participatory design, ACM Press, New

York, NY, USA, 2006

[HaB98] Hartwick, J., Barki, H.: Communication as a dimension of user participati

on, IEEE Transactions, 2001;44(1): 21-36

[HaM06] Haikala, Ilkka, Märijärvi, Jukka: Ohjelmistotuotanto, Talentum, Helsinki,

2006

[HiH80] Hirsjärvi, Sirkka, Hurme, Helena: Teemahaastattelu, Gaudeamus, Helsin

ki, 1980

[HRS97] Hirsjärvi, Sirkka, Remes, Pirkko, ja Sajavaara, Paula: Tutki ja Kirjoita,

Kirjayhtymä, Helsinki, 1997

82

[Jär04] Järvinen, Pertti: On research methods, Opinpajan kirja, Tampere, Finland,

2004

[KeC95] Keil, Mark, Carmel, Erran: Customer-Developer Links in SOftware Deve

lopment, Communication of the ACM, May 1995/vol. 38. No. 5

[KeM93] Kensing, F., Munk-Madsen, F.: PD: structure in the toolbox, Communica-

tion of the ACM 1993;36(4):78-85.

[KMS04] Korpela, M., Mursu, A., Soriyan, A., Eerola, A., Häkkinen, H. and Toiva

nen, M.: IS research and development by activity analysis and develop

ment: Dead Horse or the next wave? In: Relevant Theory and Informed

Practice: Looking Forward from a 20-Year Perspective on IS Research,

Manchester, 15-17July 2004, Amsterdam: Kluwer Academic, 2004.

[Kuu01] Kuutti, Wille: Contextual Design -menetelmän soveltaminen kuntotestaus

sovelluksen suunnittelussa, Diplomityö, TTKK Ohjelmistotekniikan laitos,

2001

[Kuu03] Kuutti, Wille: Käytettävyys, suunnittelu ja arviointi, Talentum media Oy,

2003

[KSB98] Kensing, F., Simonsen, J., and Bødker, K.: MUST: A Method for Partici

patory Design, Human-Computer Interaction, 13(2), 167-198. 1998

[Kyn94] Kyng, Morten: Scandinavian Design: Users in Product Development, Pro

ceedings of the SIGCHI conference on Human factors in computing sys

tems: celebrating interdependence, p.3-9, April 24-28, 1994, Boston,

Massachusetts, United States

[LaL98] Laudon, K. C. & Laudon, J. P.: Management Information Systems, 5th

ed., Prentice-Hall Int, New Jersey, 1998.

[LeK04] Lenz, R., Kuhn, K. A.: Towards a continuous evolution and adatation of

information systems in healthcare, International Journal of Medical Infor

matics (2004) 73, 75-89.

83

[Luc85] Lucas, H..C. Jr.: The Analysis, Design, and Implementation of Information

Systems, McGraw-Hill Book Company, Singapore, 1985.

[LGS90] Lucas, H.C. Jr., Ginzberg, M.J. And Sxhultz, R.L: Information Systems

Implementation: Testing a Structural Model, Ablex Publishing Corpora

tion, Nordwood, New Jersey, 1990.

[Mag01] Maguire, Martin: Methods to support human-centered design, Interna

tional Journal of Human-Computer Studies, 55, 2001, s.587-634

[MBJ91] Muller, Michael J., Blomberg, Jeanette L., Carter, Kathleen A., Dykstra

Elizabeth A., Halskov Madsen, Kim, Greenbaum, Joan: Participatory de

sign in Britain and North America: responses to the “Scandinavian Chal

lenge”, Proceedings of the SIGCHI conference on Human factors in

computing systems: Reaching through technology, p.389-392, April 27-

May 02, 1991, New Orleans, Louisiana, United States

[Mor94] Mogensen, P.: (1994) Challenging Practice: An Approach to Cooperative

Analysis, Ph.D. Thesis, Århus University.

[Min04] Minkkinen, I.: Vaatimusmäärittelymenetelmät komponenttituotannon tu

kena - Havaintoja soveltamisesta, Pro gradu tutkielma, Kuopion yliopisto,

2004.

[Mor94] Mogensen, P.: (1994) Challenging Practice: An Approach to Cooperative

Analysis, Ph.D. thesis, Computer Science Dept., Århus University.

[Mur02] Mursu, Anja: Information Systems Development in Developing Countries:

Risk Management and Sustainability Analysis in Nigerian Software Com

panies, Academic Dissertation, Department of Computer Science and In

formation Systems, University of Jyväskylä, 2002.

[NuE00] Nuseibeh, B., Easterbook, S.: Requirements Engineering: a roadmap, Pro

ceedings of the Conference on The Future of Software Engineering, p.35-

46, June 04-11, 2000, Limerick, Ireland

[Rou98] Roukala, V.: Toiminnan muutoksen toteutus, Suomen ATK-kustannus, Es

poo, 1998.

84

[SaK99] Saranto, K., Korpela, M.: Tietotekniikka ja tiedonhallinta sosiaali- ja ter

veydenhuollossa, WSOY, 1999.

[SFS01] ISO 9001: Laadunhallintajärjestelmät. Vaatimukset., Suomen Standar

disointiliitto SFS, 2001.

[Smi01] Smith, E.A. (2001), "The role of tacit and explicit knowledge in the work-

place", Journal of Knowledge Management, Vol. 5 No.4, pp.311-21.

[Som04] Sommerville, I.: Software engineering, Pearson Education Limited, 2004.

[Tie04] Tietotekniikan liitto ry:n sanastotoimikunta: ATK-sanakirja, Talentum,

Helsinki 2004

[Vuo05] Vuorinen, K.: Etnografia, Käytettävyystutkimuksen menetelmät, 63–78.

Tampereen yliopisto, Tietojenkäsittelytieteiden laitos, 2005

[WEC93] Waltz, D. B., Elam, J. J., Curtis, B.: Inside a Software design team: know

ledge acquisition, sharing, and integration, Communication of the ACM

1993;36(10):63-77.

[WoS89] Wood, J., Silver, D.: Joint Application Design: How to Design Quality

Systems in 40% Less Time, Wiley, New York, 1989.

[Zip05] ZipIT -työpaperi: Luonnos kehitysmallista <17.112005>.

[www01] Kuopion yliopistollinen sairaala, PDF-esite

<http://www.psshp.fi/documentindex.asp?id=2406&type=1&show=

1>, viitattu 10.7.2006

[www02] ZipIT -hankkeen www-sivut <http://www.uku.fi/zipit/>, viitattu

25.7.2006

[www03] Elektroninen potilaskertomus, Medici Data Oy, 2004 <URL:

http://www.medicidata.com/pdf/MDMIRANDA_www.pdf>, viitattu

10.7.2006

85

[WyN95] Wynn, Eleanor, Novick, David G.: Conversationa, Conventions and Par-

ticipation in Cross-Functional Design Teams, ACM Press, New York,

NY, USA, 1995

1

LIITE 1: SEKVENSSIKAAVIO PILOTTIOSASTON OSAS-TONHOITAJAN TYÖPÄIVÄSTÄ

2

LIITE 2: SAMANKALTAISUUSSEINÄ TUTKIMUSRYH-MÄN TYÖPAJASTA