Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11 STUDIES AND REPORTS OF THE PLUGIT PROJECT 11 Marika Toivanen, Heidi Häkkinen, Irmeli Minkkinen, Annamari Riekkinen, Pauliina Ikävalko, Päivi Röppänen Toimintalähtöisyys tiedon tarpeiden, tiedonkulun ja ohjelmistovaatimusten selvittämisessä KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Marika Toivanen (luvut 1 ja 2) Irmeli Minkkinen (luvut 1 ja 2) Tietojenkäsittelytieteen laitos Kuopion yliopisto Heidi Häkkinen (luvut 1 ja 3) Shiftec, Terveyshallinnon ja -talouden laitos Kuopion yliopisto Annamari Riekkinen (luvut 1 ja 4) Pauliina Ikävalko (luvut 1 ja 4) HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Päivi Röppänen (luvut 1 ja 2) Savonia Business Savonia-ammattikorkeakoulu Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh tike@uku.fi ISBN (koko teos) ISBN (osa 11) ISBN (PDF) Kopijyvä OY Kuopio 2004

3 Toivanen Marika, Häkkinen Heidi, Minkkinen Irmeli, Riekkinen Annamari, Ikävalko Pauliina, Röpp äne n Päivi. Toimintalähtöisyys tiedo n tarpeiden, tiedon kulun ja ohjelmistovaatimusten selvittämisessä. 1 Painos. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 11) ISBN (PDF) T I I V I S T E L M Ä Tähän raporttiin on koottu kuvaukset PlugIT-hankkeessa ( ) kehitetyistä ja kokeilluista toimintalähtöisistä esiselvitys- ja vaatimusmäärittelymenetelmistä. PlugIT oli valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuotti avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena oli tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla. Toimintalähtöisyys on näkökulma, jossa yhteiskuntaa, toimialaa, organisaatiota tai tietojärjestelmää tarkastellaan toiminnasta lähtien. Toimintalähtöisyyden teoreettisena viitekehyksenä on toiminnan teoria ja työtoiminnan malli. Raportissa esitellään viitekehys sekä kolme tapaa soveltaa sitä. Ensimmäinen sovelluskohde on palveluverkoston mallintaminen ja tiedon tarpeiden löytäminen. Toiseksi viitekehystä käytetään systemaattiseen ja nopeaan toiminnan esiselvitykseen. Kolmannessa viitekehyksen sovelluskohteessa tavoitteena on määritellä vaatimukset työtä tukevalle ja käytettävälle ohjelmistolle. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): tiedonhallinta, tietojärjestelmät, systeemityö, tietohallinto, terveydenhuolto, terveyspalvelut, työtoiminta, kehittäminen, palvelun tuottajat, verkostot, yhteistyö, koordinointi, tiedon kulku, viestintätekniikka, toiminnan teoria Medical Subject Headings (MeSH): medical informatics, information systems, information management, software design, health care sector, medical records, coordination, communication, electronic information resources, computer communication networks, communication barriers, interdisciplinary communication

4

5 E S I P U H E Tämä selvitys on tehty PlugIT-hankkeessa vuosina Tässä raportissa esitellään toimintalähtöisyyttä erilaisissa selvityskohteissa. Raportista on hyötyä erilaisille selvitystyön tekijöille ja tilaajille. Raportista saa vinkkejä ja ohjeita siihen, kuinka selvitystyötä tulisi tehdä, jos halutaan ottaa huomioon tietojärjestelmien kehittämisen lisäksi myös toiminnan tarpeet. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Kiitämme projektiin osallistuneiden yritysten, kuntien ja muiden organisaatioiden edustajia hedelmällisestä yhteistyöstä sekä hyvistä ideoista ja näkökulmista. Kuopiossa 30. elokuuta 2004 Tekijät

6

7 SISÄLLYS 1 JOHDANTO Taustaa Teoreettinen tausta Esiteltävät menetelmät PALVELUVERKOSTON TIEDON TARPEIDEN SELVITTÄMINEN Edellytykset menetelmän käytölle Menetelmä Vaihe 1: Kohdealueen jäsentäminen ja mallintaminen Vaihe 2: Tarkastelun kohdistaminen ja syventäminen Vaihe 3: Keskittyminen ohjelmistovaatimuksiin Tuotokset Yhteenveto TOIMINTAYKSIKÖN TIEDONKULUN KEHITTÄMISTARPEIDEN SELVITTÄMINEN Tavoite Edellytykset menetelmän käytölle Menetelmän kuvaus vaiheittain Yhteenveto ja pohdinta TAVOITTEENA OHJELMISTOVAATIMUKSET Ohjelmistovaatimusten toimintalähtöinen määritteleminen Menetelmä vaiheittain Yhteenveto LÄHTEET LIITTEET Liite 1: Esimerkkejä malllintamisessa käytetyistä apukuvista (Luku 2) Liite 2: Esimerkki toimintatarinasta (Luku 2) Liite 3: Esimerkki toimintakokonaisuudesta (Luku 2) Liite 4: Esimerkki työpajan esimateriaalista (Luku 2) Liite 5: Esimerkki toimintakokonaisuudesta: käyttäjätunnusten hallinta (Luku 4) Liite 6: Esimerkki monen toimijan prosessista: käyttäjätunnuksen luonti (Luku 4) Liite 7: Esimerkki tallentajan työtehtävästä: käyttäjätunnuksen luonti (Luku 4) Liite 8: Esimerkki toiminnan käsitemallista ja ohjelmiston käsitemallista (Luku 4) Liite 9: Esimerkki ohjelmiston käsitemallista johdetusta tietomallista (Luku 4)

8 8 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

9 1 J O H D A N T O 1.1 Taustaa Tiedon ja tiedonkäsittelyn määrä ja merkitys on nyky-yhteiskunnassa lisääntynyt räjähdysmäisesti. Kaikilla elämän aloilla tarvitaan tietojärjestelmiä. Tietojärjestelmällä tarkoitetaan ihmisistä, tietojenkäsittelylaitteista, tiedonsiirtolaitteista ja ohjelmistoista koostuvaa järjestelmää, jonka tarkoitus on tietojen käsittelyn avulla tehostaa tai helpottaa jotakin toimintaa tai tehdä toiminta mahdolliseksi. Tietojärjestelmien käyttö on arkipäivää yhä useammille ihmisille. Tietojärjestelmien suunnittelussa ja tuotannossa onkin entistä tärkeämpää kiinnittää huomiota ohjelmistojen luotettavuuteen, käytettävyyteen, toimivuuteen, joustavuuteen ja integroitavuuteen. Erityisesti on kiinnitettävä huomiota siihen, että tietojärjestelmä todella tukee tehtävää työtä. Nykyään näin ei aina ole, vaan joskus tietotekniikan koetaan jopa hankaloittavan varsinaista tehtävää työtä. PlugIT-hankkeen menetelmäkehityksen lähtökohtana on toimintalähtöisyys. Kaikkien tiedonkäsittelyssä käytettävien välineiden ja käytäntöjen tulisi tukea käyttäjänsä työtä. Tämä ei merkitse yksittäisten tiedon hakuun tai siirtoon liittyvien tehtävien nopeampaa suorittamista vaan kokonaisuuden parempaa hallintaa. Tämän saavuttamiseksi tarvitaan pohjaksi toimintaverkoston kokonaisvaltaista ymmärtämistä ja kuvaamista. Tarvitaan myös tietoa siitä, missä osissa verkostoa parannuksia tarvitaan ja minkä tyyppisiä tarpeet ovat. Toimintakokonaisuudet ovat usein monimutkaisia ja ulkopuolisen näkökulmasta on vaikea arvioida ratkaisujen toimivuutta käytännössä. Vastauksia on siis luontevinta lähteä hakemaan järjestelmässä toimivilta henkilöiltä itseltään. Koska kehitettävä toiminta tapahtuu usean tahon yhteistyönä, on tärkeää myös selvittää kokonaisuus useasta näkökulmasta. Teoreettisena viitekehyksenä käytetään toiminnan teoriaa ja työtoiminnan mallia. Toimintalähtöisen ajattelutavan mukaan kaikki (työ)toiminta on verkostomaisesti järjestäytynyttä. Melko yksinkertaisiltakin tuntuvat toimintakokonaisuudet muodostuvat lukemattomista toisiinsa vaikuttavista osatekijöistä: työtä tekevistä ihmisistä ja heidän osaamisestaan, toiminnan kohteesta ja tavoitteista joihin sillä pyritään, vallalla olevista ohjeista ja säännöistä (sekä sosiaalisista että varsinaisista) seurannan ja koordinoinnin menetelmistä, välineistä, rakennuksista jne. Vain osa näistä tekijöistä tukee kulloinkin kokonaisuutta, sillä ympäröivä maailma muuttuu jatkuvasti ja tiedon tarpeet sen mukana. Aikanaan sopivaksi rakennettu ja koettu tietojärjestelmä ei välttämättä vastaakaan enää nykyisiä tarpeita. Tiedon käsittelyyn käytettävät taidot, välineet ja menettelytavat käyvät epäkäytännöllisiksi, ja niitä pitää uudistaa. Monimutkaisen todellisuuden jäsentämistä tarvitaan, jotta tarpeet löytyvät, konkretisoituvat ja priorisoituvat. Toimintalähtöisiä menetelmiä kehitetään tukemaan myös ohjelmistotarpeiden tunnistamista ja ohjelmistovaatimusten kuvaamista. Kohdealueen nykyinen toiminta, tiedot ja tiedon tarpeet selvitetään ja kuvataan. Kuvauksista löydetään sekä työtoiminnan että tietojärjestelmän kehityskohteita. Tietojärjestelmän kehityskohteista valitaan keskeisimmät ja tunnistetaan ohjelmistotarpeita, joista voidaan johtaa ohjelmistovaatimukset. 1.2 Teoreettinen tausta Toiminnan teorian juuret ulottuvat 1800-luvulle. Sen filosofisena taustana on se, että ihmisyksilön ja lajin tajunta kehittyy käytännön toiminnassa ja yhteisön osana. Ihmisen vaste ärsykkeisiin ei ole TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 9

10 suora, vaan välittynyt. Ihminen voi kontrolloida toimintaansa ja käyttää apuna esimerkiksi merkkejä tai muita apuvälineitä (Vygotsky 1978). Yksilön teot voidaan ymmärtää vain sen toiminnan kautta, jonka osia ne ovat. Teoista muodostuu kollektiivinen toiminta, jolla on kohde ja motiivi (Leontiev 1978). Useat kollektiiviset toiminnat muodostavat yhdessä toimintojen verkon (Engeström 1987). Toiminnan teoriaa on käytetty apuna tietojärjestelmien suunnittelussa 1990-luvun alusta. Toimintalähtöiseen ajattelutapaan kuuluu, että tietojärjestelmien suunnittelussa analysoidaan kohdealueen tietojärjestelmän sijasta kohdealueen toimintajärjestelmää (Kuutti 1991) ja tietokone ja sovellukset voidaan ajatella toiminnan välineiksi ja keinoiksi (Bødker 1991) ja 2000-luvuilla toiminnan teoriaa on sovellettu erityisesti tutkittaessa ihmisen ja tietokoneen vuorovaikutusta (Human Computer Interaction, HCI) ja tietokoneavusteista yhteistyötä (Computer-Supported Cooperative Work, CSCW) sekä kehittävässä työntutkimuksessa (Engeström: Developmental Work Research, DRW) ja työtoiminnan tutkimisessa ja kehittämisessä (Korpela ym.: Activity Analysis and Development, ActAD) ActAD-mallin kuvaustapa ja notaatio Työtoiminta tai toimintajärjestelmä ymmärretään kokonaisuutena, jossa joukko ihmisiä työskentelee jonkin yhteisen kohteen parissa järjestäytyneellä tavalla. Tavoitteena on tuottaa jokin yhteinen lopputulos. Kaikkien ihmisten toiminta ei välttämättä tapahdu samassa paikassa ja yhtä aikaa, eivätkä kaikki toimijat ehkä ole edes tietoisia toisistaan (Korpela ym., 2003). Työtoiminnan mallista käytetään lyhennettä ActAD-malli (Activity Analysis and Development). Työtoiminnan elementit on esitetty kuvassa 1. Suhteet muihin toimintoihin, välittäjinä verkottumisen keinot Toimintatapa, kehityshistorian vaiheet Kollektiivinen toimija: ryhmä, tiimi, Ristiriidat toimiyhteisö Kommunikoinnin ja koordinaation keinot: Yksittäinen teko Työnjako, säännöt, ym. Tekijät: subjektit Tarkastelun kohteena oleva toiminta Työprosessi: Teon keinot: henkiset, välineet, rakenteet, ym. Edeltävä toiminta Kohde muuttuu: Tulos Seuraava toiminta Kuva 1. Työtoiminnan elementit, ActAD-malli (Korpela ym., 2003) Työtoiminnan kehittäminen lähtee aina liikkeelle epätasapainosta tai ristiriidasta toiminnassa. Kun yksi toiminnan elementeistä muuttuu, aiheuttaa se muutoksentarvetta myös muissa. Usein tietotekniikan käyttöönotto on tällainen muutos (Korpela ym., 2003). Työtoiminnan ja tietotekniikan yhtäaikaisella kehittämisellä pyritään saamaan aikaan tietojärjestelmiä, jotka todella tukevat ky- 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

11 seessä olevaa työtoimintaa. Joskus ratkaisu tietojärjestelmän ongelmaan on uusi tietokonesovellus, joskus työtavan muutos tai työn uudelleen organisointi (Toivanen ym., 2004a). Toiminta (activity) on kollektiivinen, systeeminen kokonaisuus pienempien tekojen (actions) joukko jolla on kohde ja tavoite (kuva 1). Toiminta kokonaisuutena on kuvattu soikiona. Toiminnan ulkopuolella on toisia toimintoja, joilla on yhteyksiä tarkastelun kohteena olevaan toimintaan. Yhdessä nämä muodostavat toimintojen verkon. Yhteys voi olla toimintojen keskinäistä kommunikointia. Yhteys voi olla myös toisesta toiminnasta toiseen siirtyvää materiaalia, eli toisen toiminnan tulosta tarvitaan toisessa. Yhteyksissä toisiin toimintoihin tarvitaan kommunikoinnin ja verkottumisen välineitä. Suhteet kuvataan moniosaisilla nuolilla. Nuolen avulla voidaan kuvata, mistä tieto tulee, millä välineellä, mitä tietoa välittyy ja mihin (kuva 2). mitä mistä väline mihin Kuva 2. ActAD-mallin moniosainen nuoli Toiminnalla on ajallinen perspektiivi suhteessa toisiin toimintoihin: toiminnalla on edeltäviä ja seuraavia toimintoja. Toiminnalla on myös oma historiallinen perspektiivi: ajan myötä toimintakokonaisuus voi muuttua esimerkiksi uusien välineiden tai sääntöjen vaikutuksesta. Tätä kuvataan päällekkäisillä soikioilla, joista tämänhetkinen toimintatapa tai tavoitetila on päällimmäisenä näkyvillä. Toiminta on monen ihmisen erillisistä teoista koostuva yhteiseen päämäärään tähtäävä kokonaisuus. Eri toimijat eivät aina toimi samanaikaisesti, eivätkä välttämättä ole edes tietoisia toistensa teoista tai rooleista. Toiminnan sisällä kollektiivinen toimija on kuvattu ympyräjoukolla soikion yläosassa (kuva 1). Kollektiivisella toimijalla tarkoitetaan sitä ihmisjoukkoa, joka tarvitaan toiminnan tavoitteen saavuttamiseksi. Kollektiivinen toimija voi olla tarkoin määritelty tiimi, työyhteisö tai myös löyhemmin sidoksissa oleva ryhmä ihmisiä. Eri toimijoiden teot eivät ole vain satunnainen joukko toisistaan riippumattomia tekoja, vaan niitä ohjaa erilaiset koordinoinnin keinot. Jotta yhteinen tavoite saavutettaisiin, on toimijoiden kommunikoitava keskenään, kun kyseessä on toimintakokonaisuus. Kommunikaation ja koordinaation keinot ja välineet voivat vaikuttaa yhteisen tavoitteen saavuttamiseen joko auttaen tai hankaloittaen. Keinoja voivat olla esimerkiksi kokous, puhelin, tietokonesovellus, työvuorolistat tai säännöt. Kommunikaation ja koordinoinnin välineet on kuvattu kollektiivisen toimijan alapuolelle kaarevilla nuolilla (kuva 1). Toiminnasta voidaan havaita yksittäisten toimijoiden suorittamia tekoja. Yksittäiset toimijat on kuvattu ympyröillä soikion keskivaiheilla (kuva 1). Yksittäiset toimijat tarvitsevat tekojen suorittamiseen työvälineitä ja -keinoja, jotka voivat olla materiaalisia, esimerkiksi koneita ja laitteita, tai ei-materiaalisia, kuten ammattitaitoa ja työkokemusta. Nämä on kuvattu nuolilla, jotka osoittavat tekijöistä työprosessiin kuvassa 1. Toiminnalla on aina kohde ja tavoite. Toiminnan prosessin tuloksena kohteessa tapahtuu muutos tavoitteen suuntaan. Toiminnan kohde, tulos ja työprosessi kuvataan soikion alalaidassa suorakaiteilla (kuva 1). Kun toiminnan kokonaiskuva on saavutettu, voidaan analysointia jatkaa tarkemmalle tasolle prosessikuvauksilla. Työprosessin kuvauksessa käytetään ohjelmistotuotannosta tuttua UML:n aktiviteettikaaviota muistuttavaa kuvaustapaa (kuva 3). Erona UML:n, Unified Modelling Language aktiviteettikaavioihin on se, että tässä kuvataan myös prosessin edetessä tarvittavat, puuttuvat ja tuotettavat tiedot sekä käytettävät tietovälineet (Fowler, 2000). Jos prosessi tapahtuu fyysisesti eri paikoissa, voidaan myös tapahtumapaikat kirjata kaavioon. Kuvauksen notaatio on osin sama kuin soikiomallissa: käytetään ympyröitä kuvaamaan toimijoita, kaarevia nuolia kuvaamaan koordinoinnin keinoja ja välineitä jne. Työprosessikuvauksista saadaan muodostettua käyttötapauksia ohjelmisto- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 11

12 suunnittelua varten. Mikäli jokin teko halutaan suorittaa tietotekniikan avulla, on se teko silloin ohjelmiston käyttötapaus. Toimija A Toimija B Toimija C Teon keinot ja välineet Puuttuvat keinot ja välineet Teko Koordinoinnin keinot eri tekojen välillä Aika Verkottumisen keinot toimintojen välillä Kuva 3. Työprosessikuvaus (Korpela ym., 2004) ActAD-mallin käyttö Mallia voi käyttää apuvälineenä kohdealueen toiminnan jäsentämisessä ja mallintamisessa. Varsinkin, kun halutaan selvittää, mitä tietoa tarvitaan, mistä ja keneltä sitä voidaan saada. ActAD-mallia voidaan käyttää apuvälineenä, kun hahmotetaan kohdealueen palveluverkostoa organisaatioineen ja toimijoineen. Näin voidaan löytää potentiaaliset tietolähteet mahdollisimman kattavasti. ActADmalli ohjaa ajattelua myös silloin, kun päätetään, mitä tietoa kohdealueesta tarvitaan. Palveluverkoston sekä nyky- että tavoitetila voidaan selvittää ja kuvata mallia käyttäen. Palveluverkostosta löydetään toimijat, tiedot ja tiedonkulun rajapinnat. Kuvaustapa mahdollistaa sekä toiminnan että tietojärjestelmän kehityskohteiden tunnistamisen ja ratkaisujen ideoimisen. Kuvaustavan avulla on mahdollista kohdistaa tarkastelu valittuun kehityskohteeseen tai yksittäisen palveluun palveluverkostossa. Tarkennetulla tasolla voidaan edetä prosessikuvausten kautta käyttötapauksiin, tietoarkkitehtuurikuvaukseen ja komponenttien suunnitteluun. Erityisesti ohjelmistoratkaisujen kuvaamisessa päästään vaatimusmäärittelytasolle. ActAD-mallin kuvaustapa mahdollistaa myös havainnollisten kuvien käytön symboleina. Esimerkiksi kaarevat nuolet kommunikaatiovälineitä kuvaamassa voidaan korvata kuvilla (puhelin, paperi, tietokone) tai käyttää myös tekstejä. Kuvaustapa on helposti omaksuttavissa, ja kuvaukset toimivat keskustelun apuvälineenä tietotekniikan ja kohdealueen ammattilaisten välillä. 1.3 Esiteltävät menetelmät ActAD-mallin soveltuvuutta kohdealueen kartoitukseen, kehityskohteiden löytämiseen ja ohjelmistovaatimusten määrittelemiseen on kokeiltu PlugIT-hankkeen kolmessa osaprojektissa. Projektit erosivat toisistaan niin tavoitteidensa kuin kohdealueidensa perusteella. Luvussa 2 esitellään Kotihoidon tiedon tarpeet -projektissa kehitetty ja käytetty menetelmä. Menetelmällä voidaan kuvata kattavasti kohdealueen nykytila ja tiedon tarpeet sekä tukea etenemistä tietoarkkitehtuurikuvauksen ja prosessikuvausten kautta komponenttisuunnitteluun. Tämä menetelmä on hyödyllinen, kun kohdealue on ennen tuntematon, laaja tai monitoimijainen palveluverkosto. Luvussa 3 esitellään Äitiysneuvola-projektissa kehitetty ja testattu kevyt ja nopea menetelmä tiedonkulun kehittämistarpeiden esiselvitykseen. Tämä menetelmä on sopiva esimerkiksi silloin, kun kohdealueena on yksittäi- 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

13 nen osa laajaa toimintaverkkoa. Luvussa 4 esitellään Pakkanen-projektin kokemusten perusteella luonnosteltu menetelmä ohjelmistovaatimusten toimintalähtöiseen määrittelyyn. Tämän projektin lähtökohtana oli ohjelmistovaatimusten löytäminen uudistettavaan ohjelmistoon toimintalähtöisesti. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 13

14

15 2 PA LV E L U V E R K O S T O N T I E D O N TA R P E I D E N S E LV I T T Ä M I N E N Tässä luvussa kuvattu menetelmä soveltuu käytettäväksi, kun halutaan kartoittaa laaja, monimutkainen tai ennalta tuntematon kohdealue. Menetelmää voi käyttää myös palveluverkoston toiminnan tai tietojärjestelmän mahdollisten kehityskohteiden löytämiseksi. Erityisesti silloin, kun tiedonkulussa on havaittu ongelmia tai puutteita, joita halutaan tarkentaa ja joihin halutaan etsiä ratkaisuja, menetelmä on hyödyllinen. Vaikka menetelmää on kokeiltu nimenomaan palveluverkoston tiedon tarpeiden selvittämiseen, se luultavasti toimii myös muissa toimintaverkoissa. Menetelmä sisältää useita perättäisiä vaiheita. Aina ei ole tarkoituksenmukaista tehdä kaikkia tässä kuvattuja asioita, vaan menetelmästä voidaan poimia käytettäväksi kulloinkin soveltuvia osia. Menetelmän käyttöön kuluu aikaa riippuen kohdealueen laajuudesta ja siitä, mitkä menetelmän vaiheet käydään läpi. Tuloksena saadaan nykytilakuvaus palveluverkoston toiminnoista ja tiedoista kokonaisuutena. Tarkemmalla tasolla saadaan prosessikuvaukset keskeisimpien toimintojen osalta ja kuvaus keskeisimmistä tietokokonaisuuksista (koostumus, yhteydet). Samalla löydetään kehityskohteita ja ratkaisuehdotuksia ongelmiin ja voidaan laatia tavoitetilan kuvaus. Ohjelmistotuotannon käyttöön saadaan käyttötapauksia ja alustava arkkitehtuurikuvaus. Menetelmäkuvaus painottuu ensimmäiseen vaiheeseen eli kohdealueen jäsentämiseen ja mallintamiseen. Eteneminen toiseen vaiheeseen eli prosessikuvauksiin ja tietoarkkitehtuuriin on varsin selvä. Kolmas vaihe eli käyttötapausten ja komponenttien suunnittelu on esitetty lyhyesti, koska tätä vaihetta ei ole testattu kokonaisuutena, vaan ainoastaan kokeiltu osittain. Menetelmän käyttöä havainnollistetaan kotihoidon tutkimiseen liittyvällä esimerkillä. Esimerkki perustuu Kotihoidon tiedon tarpeet -projektiin, jossa ActAD-mallia sovellettiin palveluverkoston tiedontarpeiden selvittämiseen harmaalta alueelta. Kotihoidolla tarkoitetaan asiakkaan kotona annettavia hoito- ja hoivapalveluja. Kotihoidon pääasiallinen kohderyhmä on vanhukset, joiden kotihoidon tiedon tarpeita projektissa tutkittiin. Kotihoitoon osallistuu toimijoita useista eri organisaatioista. Siksi työssä tarvittava tietokin voi sijoita useissa tietojärjestelmissä. Kotihoitoa toimintaverkostona esittelevät tulokset on julkaistu raportissa: Kotihoidon tiedon tarpeet, PlugIT-hankkeen selvityksiä ja raportteja Edellytykset menetelmän käytölle Menetelmän käytön edellytyksenä on tarve laajan kohdealueen, esimerkiksi palveluverkoston, selvittämiselle. Nykyisessä palveluverkostossa tai sen toiminnassa on huomattu puutteita tai ongelmia, ja toimintaa halutaan kehittää käyttäen mahdollisesti myös tietoteknisiä ratkaisuja. Tarvitaan myös päätös selvitystyön tekemisestä ja tekijästä. Palveluverkoston tiedon tarpeiden selvittäminen tätä menetelmää käyttäen edellyttää ryhmätyötä. Menetelmän käyttö edellyttää erityisesti kohdealueen toimijoiden osallistumista ja kiinnostusta oman työnsä kehittämiseen. Tekijöiden erilaiset taustat ovat eduksi selvitykselle. Selvitystyön tekijänä eli menetelmän käyttäjänä voi olla kohdealueen toimija, toiminnan kehittäjä, ohjelmistoammattilainen (vaatimusmäärittelijä tai tietojärjestelmän suunnittelija) tai ulkopuolinen konsultti. Hänellä pitää olla käsitys ActAD-mallista ja sen elementeistä sekä käyttötavoista. ActAD-malli on helppo omaksua, eikä sen käyttö vaadi erikoiskoulutusta, vaan jo lukemalla tämän dokumentin voi saada hyvän käsityksen siitä, miten mallia voi käyttää. Menetelmän luontee- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 15

16 seen kuuluu olennaisena osana kohdealueen visualisoiminen esimerkiksi erilaisilla kuvilla ja kaavioilla. Selvityksen tekijöiden lisäksi tarvitaan toimijoita kohdealueen jokaisesta keskeisestä osatoiminnasta. Heiltä edellytetään haastatteluihin ja työpajoihin osallistumista ja heillä tulee olla omasta työstään kohtalainen työkokemus. Yleensä tarvitaan myös kohdealueen johdon ja hallinnon näkökulma. Myös tietohallinnon tai palvelun asiakkaan näkökulma voi olla tarpeellinen. Menetelmän käyttö ei edellytä mitään erikoisvälineitä, esim. tiettyjä ohjelmistoja, vaan voidaan käyttää tavallisia toimistotyökaluja. Tarvittavan ajan määrä riippuu mm. kohdealueen laajuudesta ja siitä, mitkä menetelmän vaiheet on tarpeellista käydä läpi. 2.2 Menetelmä Vaihe 1 Tietovaraston kerääminen Haastattelut - haastateltavien valinta - kysymysten laadinta - haastattelu - haastattelun purku - haastattelujen analysointi Tulosten tarkastus työpajassa - seinätaulu Apuvälineet - kaaviot - kuvat - taulukot Työtoiminnan malli Kohdealueen jäsentäminen ja mallintaminen Toiminnat ja tiedot -dokumentti Vaihe 2 Kohteen valintaperusteet Kohdealueen toiminnan tavoite Havainnointi Tietovarasto Työtoiminnan malli Tarkastelun kohdistaminen ja syventäminen Prosessit ja tietoarkkitehtuuri Vaihe 3 Ohjelmistotuotannon menetelmät Komponenttipohjainen tietojärjestelmäsuunnittelu Keskittyminen ohjelmistovaatimuksiin Käyttötapaukset ja ohjelmistokomponentit Vaatimusmäärittely Kuva 1. Menetelmän vaiheet 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

17 Menetelmä jakautuu kolmeen vaiheeseen (kuva 1): 1. Kohdealueen jäsentäminen ja mallintaminen 2. Tarkastelun kohdistaminen ja syventäminen 3. Keskittyminen ohjelmistovaatimuksiin Ensimmäisessä vaiheessa tehdään esitutkimusta kohdealueesta, aloitetaan tietovaraston kerääminen, suunnitellaan ja toteutetaan haastattelut, analysoidaan haastattelujen tulokset ja tarkastetaan ne yhdessä toimijoiden kanssa työpajoissa. Kohdealueesta tunnistetaan mahdollisia kehityskohteita. ActAD-malli ohjaa tiedon keräämistä ja analysointia sekä dokumentointia. Ensimmäisessä vaiheessa kuvataan kohdealueen toimintaverkko, toiminnat ja tietokokonaisuudet sekä tunnistetut kehityskohteet Toiminnat ja tiedot -dokumentiksi. Joissakin tapauksissa saadaan jo ensimmäisen vaiheen tuloksista riittävä määrä tietoa palveluverkoston toiminnoista ja tiedoista. Mikäli tarkastelua on tarpeen jatkaa tarkemmalle tasolle, voidaan kuvausten avulla selvitystyön tilaajan kanssa priorisoida ja valita toiminnoista keskeisimmät, joita työstetään edelleen vaiheessa 2. Toisessa vaiheessa valitaan perustellusti ne kehityskohteet, joita aletaan tarkastella syvemmällä tasolla. Tietolähteinä ovat Toiminnat ja tiedot -dokumentti sekä kerätty tietovarasto. Tavoitteena on selvittää työprosessit tarkemmalla tasolla sekä toiminnassa tarvittavien tietokokonaisuuksien sijainti ja liikkuminen tietoarkkitehtuurin avulla. Vaiheen tulokset kootaan Prosessit ja tietoarkkitehtuuri -dokumentiksi. Joskus kehityskohdan ongelma ratkeaa esimerkiksi työprosesseja kehittämällä, jolloin voidaan menetelmässä pysähtyä vaiheeseen 2. Mikäli ratkaisu kehityskohdan ongelmaan on uusi toimintaa tukeva tietokoneohjelmisto, edetään vaiheeseen 3. Kolmannessa vaiheessa keskitytään ohjelmistovaatimusten laatimiseen. Edellisen vaiheen Prosessit ja tietoarkkitehtuuri -dokumenttia tarkennetaan ja laaditaan tarvittavat käyttötapauskuvaukset sekä suunnitellaan ohjelmistoarkkitehtuuri ja komponentit abstraktilla tasolla. Jos uusi ohjelmisto päätetään toteuttaa ja ottaa käyttöön, on sen sijoittuminen työprosesseihin ja toimintojen verkkoon syytä tarkastella erikseen. 2.3 Vaihe 1: Kohdealueen jäsentäminen ja mallintaminen Menetelmän käyttö voi alkaa vaiheesta 1. Tässä vaiheessa on siis huomattu tarve monimutkaisen ja laajan kohdealueen toiminnan selvittämiselle sekä tehty päätös selvitystyön tekemisestä, hankittu selvityksen tekemiseen vastuuhenkilö ja työryhmä. Lisäksi voi olla tarpeellista informoida kohdealueen organisaatioita tehtävästä selvityksestä ja luoda yhteyksiä. Myötämielinen ja motivoitunut asenne selvitykselle ja sen tavoitteille edistää selvitystyön sujuvuutta ja onnistumisen mahdollisuuksia Tietovarasto Esitutkimusvaiheessa on tarpeen etsiä tietoa kohdealueeseen kuuluvista ja sitä sivuavista asioista. Tällaisia ovat kohdealuetta koskevat muut samankaltaiset projektit, tutkimukset, selonteot ja raportit, sanastot, standardit yms. Heti projektin alusta lähtien on hyödyllistä kerätä näitä asioita tietovarastoon. Kun projektin kannalta kiinnostavaa tietoa löytyy, tietolähde lisätään tietovarastoon, josta se on helposti kaikkien tietoa tarvitsevien käytössä. Tietovarasto voidaan toteuttaa esimerkiksi Internet-sivulle luotavana linkkilistana, jota päivitetään projektin kuluessa. On hyödyllistä, jos listassa on linkin lisäksi lyhyt kuvaus kohteesta. Tietovaraston päivittämisestä kannattaa sopia projektikohtaisesti. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 17

18 2.3.2 Esitutkimus Kirjallisuuskatsaus ja tietovaraston kerääminen antavat alkutietoja kohdealueesta. Alkutietoja jäsennetään ActADin toiminnan rakennemallin avulla. Jäsentämisellä tarkoitetaan toiminnan rakenneosien tunnistamista ja nimeämistä kohdealueelta. Aluksi tunnistetaan ja määritellään kohdealueen keskeinen toiminta, jolla on aina kohde ja tavoite. ActAD-mallin avulla kohdealueelta löydetään erilaisia toimijoita ja organisaatioita, joista he tulevat. Tämä helpottaa löytämään ja valitsemaan konkreettisia haastateltavia, joilta voidaan saada lisää tietoa. Ympäröivistä organisaatioista voi kohdealueelle tulla myös tietoa ja erilaisia välineitä. Kuvaustapa mahdollistaa havainnollisen esityksen siitä, mitä työtoiminnan elementtejä kohdealueelta löytyy ja mistä elementit tulevat. Kohdealueen keskeinen toiminta voi olla esimerkiksi kotihoito, kuten Kotihoidon tiedon tarpeet -projektissa. Kotihoidon kohteena on asiakas ja tavoitteena asiakkaan kotona asumisen mahdollisuus. Toimijoina on joukko kotihoitoon osallistuvia henkilöitä, esimerkiksi kotisairaanhoitaja ja kodinhoitaja. Kotihoitoa ympäröi suuri joukko erilaisia organisaatioita, joista kotihoitoon voi tulla toimijoita, tietoa tai välineitä (kuva 2). On hyödyllistä tarkastella kokonaisuutta, jotta voidaan rajata kohdealue ja päättää, mikä kuuluu kohdealueen sisälle ja mikä ulkopuolelle. apteekki Suomen laki perusterveydenhuolto pankki siivous ystäväpalvelu kauppa seurakunnat siivooja m o p p i a v u s t a j a l ääk e tietosuoja Kotihoito Asiakas kotona l ääk är i s a ir a a n h o it a ja Asiakas voi hyvin t i e t o j ä r j e s t e l m ä k o d i n h o i t a j a s a i r a u s t i e t o j a kunnan sosiaalitoimi erikoissairaanhoito kuntoutuslaitos turvapalvelu vanhainkoti KELA vakuutusyhtiöt kuljetuspalvelu eläkelaitokset tapaturmavirasto Kuva 2. Osa kotihoitoa ympäröivistä organisaatioista, joista kotihoitoon voi tulla toimijoita tai välineitä Kohdealueen toiminnasta selvitetään, onko kyseessä yksi työtoiminnan kokonaisuus vai toimintojen verkko. Kohdealue voi olla liian suuri käsiteltäväksi yhtenä toimintakokonaisuutena, jolloin se voidaan jakaa pienempiin palasiin. Prosessi yleensäkin voidaan jakaa peräkkäisiin vaiheisiin (usein suunnittelu, toteutus ja arviointi). Toiminta voidaan jakaa osatoiminnoiksi, jotka voivat muodostaa myös toimintojen verkon. Eri osatoimintojen ja vaiheiden välillä on erilaisia yhteyksiä, esimerkiksi tiedon siirtoa, joita ei tässä vaiheessa vielä tarkkaan tunneta (Toivanen, 2003b). Esimerkiksi kotihoitotoiminta jaettiin neljään peräkkäiseen vaiheeseen: tarvekartoitus, suunnittelu, toteutus ja arviointi. Suunnitteluvaihe erotetaan omaksi osatoiminnakseen, koska se sisältää paljon tiedon hankkimista, käsittelyä ja tallentamista. Kotihoidon suunnitelma on perusta toteutusvaiheen toiminnoille. Toteutusvaihe on monien osatoimintojen summa. Kotihoidon toteuttamisen osatoiminnoiksi tunnistetaan esimerkiksi kotisairaanhoito, kotipalvelu, turvapalvelu ja ateriapalvelu. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

19 Osatoiminnot tarvitsevat sekä keskinäisiä yhteyksiä, että yhteyksiä ympäröiviin organisaatioihin, jotta asiakas saisi parhaan mahdollisen tarvettaan vastaavan palvelun. Kotihoidon vaiheita ja osatoimintoja on esitetty kuvassa 3. Tarpeen määritys Suunnittelu Toteutus Arviointi Tarve kartoitettu Asiakkaan kokonaistilanne Asiakkaan tarve Palvelusuunnitelma Asiakas kotona Asiakas hyvinvoiva Palvelun toteutuma Arvio/ päätös Tehdään yleensä yhden kerran Tehdään useammin kuin kerran Arviointi voi liittyä eri toimintoihin ja olla luonteeltaan - jatkuvaa - säännöllisin väliajoin tehtävää - tarvittaessa tehtävää Jatkuva, päivittäinen toiminta koostuu osatoiminnoista. Tarvitaan yhteyksiä eri organisaatioihin. Kuva 3. Korkean abstraktiotason kuva kotihoidosta toimintaketjuna Haastattelut HAASTATELTAVIEN VALINTA Kohdealueelta löydetyistä osatoiminnoista valitaan tarkastelun kohteeksi keskeisimmät. Näistä toiminnoista löydetään potentiaaliset haastateltavat. Tarvitaan myös hallinnon, johdon sekä kohdealueella toimivan tietotekniikan ammattilaisen näkökulmaa. Joskus on tarpeen saada esille myös kohdealueen palveluverkoston asiakkaan näkökulma. Haastateltavien kanssa sovitaan haastattelusta henkilökohtaisesti. Kohdealueesta saadaan esille monipuolinen kokonaiskuva, kun kukin kuvaa kohdealuetta omasta näkökulmastaan. Toisaalta saadaan esille myös eri syvyystasolla olevia näkökulmia: kunkin osatoiminnan yhteinen näkökulma ja toisaalta erilaisten toimijoiden näkökulmat kunkin osatoiminnan sisällä. Kotihoito-projektin haastateltavien valintaan vaikutti esimerkiksi se, että esitietojen perusteella tiedettiin, että kotisairaanhoitoon osallistuvia ammattilaisia ovat ainakin sairaanhoitaja, lähihoitaja ja lääkäri, ja että organisaatio, josta he tulevat on kaupungin terveystoimi. Heidän työtehtävänsä ovat keskenään erilaisia, joten oli perusteltua valita haastateltavaksi yksi kunkin ammatin edustaja. Lisäksi haastateltaviksi valittiin kotihoidon hallinnon ja johdon edustajat sekä tietojärjestelmän vastuukäyttäjät. Myös kotihoidon asiakasta haastateltiin, vaikka asiakkaan haastattelu ei tässä tapauksessa ollut avainasemassa. Kotihoidon kohteena asiakkaalla ei ehkä ole sellaista kotihoidon tietojärjestelmän suunnitteluun tarvittavaa tietoa, jota kotihoidon toimijoilta ei voi saada. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 19

20 HAASTATTELUKYSYMYSTEN LAADINTA Kohdealueelta saadaan tietoa haastattelemalla erilaisia toimijoita. Haastattelu tehdään teemahaastatteluna, jonka teemat saadaan toiminnan teoriasta. Teemahaastattelu on puolistrukturoitu haastattelumenetelmä, jonka avulla saadaan aikaan melko vapaamuotoinen ja luonteva haastattelutilanne, joka etenee kuitenkin valittujen aiheiden ympärillä. Teemahaastattelun käyttäminen edellyttää jonkin asteista kohdealueen tuntemusta, jotta haastatteluteemat ja -kysymykset voidaan suunnitella (Hirsjärvi ym., 1988). Toiminnan teoria ohjaa kysymysten laadintaa. Kysymyksiä laaditaan toiminnan rakenneosien (tulos, kohde ja prosessi, välineet, tekijät sekä sosiaaliset suhteet ja välineet) sekä toimintaverkon muodostumisen ja rakenteen etsimiseen (Mursu, 2002). Haastatteluteemat ovat: työ toimintana, kollektiivinen toimija, tieto työn välineenä ja yhteistyön ja kommunikoinnin välineet. Teemoista laaditaan kysymyksiä, ja teoriatason abstraktit käsitteet korvataan kohdealueen ammattilaisille tutuilla termeillä. Kysymykset voivat olla kaikille toimijoille samat. Työ toimintana -teeman avulla laadittavien kysymysten avulla löydetään toiminnan kohde, tavoite sekä keinot ja välineet, osatoimintoja ja prosesseja sekä toimintaa edeltäviä ja seuraavia toimintoja. Abstraktin tason kysymykset voivat olla seuraavan kaltaisia: Mikä tai kuka on toiminnan kohteena? Onko toiminnalla erilaisia kohteita? Mikä on toiminnan tavoite? Kuka määrittelee tavoitteen ja miten? Keiden tulee olla tietoisia tavoitteesta? Mistä raaka-aineista tai edellytyksistä toiminta alkaa? Mitä tietoja aloittamisessa saadaan ja tarvitaan? Mitä osa-alueita toimintaan kuuluu? Miten toiminta toteutetaan? Mitä palveluita tai tuotteita toiminnassa tuotetaan? Kuka tarvitsee tuotosta ja mihin? Mitä välineitä ja keinoja toiminnassa tarvitaan? Mistä ne tulevat? Tieto työn välineenä -teema selvittää, mitä tietoja toiminnan toteuttamiseksi tarvitaan, mistä tarvittavat tiedot saadaan ja missä muodossa. Näin löydetään toiminnassa tarvittavia tietokokonaisuuksia, joita voidaan myöhemmin täsmentää. Kollektiivinen toimija -teeman avulla selvitetään, ketkä kaikki osallistuvat toimintaan, mistä organisaatioista he tulevat ja millaisia yhteistyötahoja toiminnalla on. Näin voidaan löytää yksittäisiä toimijoita, toimintojen verkko ja yhteyksiä ympäröiviin organisaatioihin. Yhteistyöverkon avulla voidaan hahmottaa, mitkä eri osatoiminnat ovat paljon yhteistyössä, mitkä vähemmän. Yhteistyön ja kommunikaation välineet -teema sisältää kysymyksiä työnjaosta, säännöistä, toimintatavoista sekä konkreettisista välineistä, joita toiminnassa tarvittavan tiedon välityksessä käytetään. Näiden kysymysten avulla löydetään niin tiedonkulun välineet ja rajoitteet, kuin myös ongelmakohdat, joissa tieto ei kulje niin kuin pitäisi. Kysymykset ryhmitellään siten, että haastattelu voi edetä loogisesti ja sujuvasti. Haastattelija voi lisätä kysymyksen yhteyteen haastattelutilannetta varten täsmennyksiä siitä, mitä kysymyksellä tarkoitetaan. Liiallista haastateltavan johdattelua on kuitenkin vältettävä. Ennen varsinaisia haastatteluja haastattelukysymykset on hyvä testata suorittamalla koehaastattelu. Saatujen tulosten avulla arvioidaan, onko kysymyksillä saatu halutun kaltaista tietoa esille. Tarvittaessa kysymyksiä muokataan. Kotihoito-projektissa haastattelulomakkeella oli n. 40 kysymystä ryhmiteltynä edellä mainittujen teemojen alle. Esimerkiksi Työ toimintana -teemasta saatiin seuraavia kotihoitoa koskevia kysymyksiä: Ketkä ovat kotihoidon asiakkaita? Määritelläänkö asiakkaan kotihoidolle tavoite? Miten ja miksi se määritellään? Ketkä määrittelevät tavoitteen ja missä yhteydessä? Mitä tietoja tarvitaan tavoitteen 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

21 määrittelyssä ja miten tarvittavat tiedot saadaan? Kenelle määritelty tavoite ilmaistaan ja miten? Mitä palveluja kotihoidossa tuotetaan? Mistä ja miten saadaan tarvittavat resurssit? Miten asiakkaat tulevat kotihoidon palvelujen piiriin? Onko eroja siinä, miten eri asiakasryhmät tulevat kotihoidon asiakkaiksi? Mitä tietoa saadaan ensimmäisessä yhteydenotossa? Onko tämä tieto riittävää palvelun käynnistämiseksi? Mitä muuta tietoa tarvitaan ja mistä sitä saadaan? Kysymykset testattiin haastattelemalla opiskelijaa, jolla oli työkokemusta kotihoidosta. Koehaastattelun avulla arvioitiin, saako kysymyksillä halutun kaltaista tietoa. Lisäksi pystyttiin arvioimaan haastattelun kestoaika. Haastattelukysymykset olivat kaikille kotihoidon toimijoille samat. Kotihoito-projektissa haluttiin haastatella myös kotihoidon asiakasta, ja kysymyksiä muokattiin vastaamaan paremmin asiakkaan näkökulmaa HAASTATTELUT SEKÄ NIIDEN PURKAMINEN Toimijoita haastatellaan yhtä kerrallaan. Haastattelutulosten kannalta on edullista, jos haastattelut voidaan tehdä haastateltavan omassa työympäristössä. Tällöin haastateltava ei jännitä haastattelutilannetta, eikä hänen tarvitse nähdä ylimääräistä vaivaa tullakseen haastatteluun. Haastattelijoita on hyvä olla useampi. Työtapana voi olla esimerkiksi se, että yksi haastattelija pääsääntöisesti kyselee ja muut tekevät muistiinpanoja. Haastattelutilanne on onnistuessaan haastattelijan ja haastateltavan välillä käytävä hyvin informatiivinen keskustelu, jossa on vapautunut tunnelma. Haastateltava ei aina vastaa pelkästään esitettyihin kysymyksiin, vaan hän voi kertoa lisäksi täsmentäviä esimerkkejä tai vastata etukäteen myöhempänä tuleviin kysymyksiin. Muistiinpanoihin kirjataan mahdollisimman tarkkaan haastateltavan vastaukset, mutta ei pyritä kuitenkaan sanatarkkaan kirjaukseen. Kirjaajalla pitää olla etukäteen käsitys siitä, mitä asioita kysymyksillä pyritään selvittämään pystyäkseen kirjaamaan olennaisen. Haastattelu kannattaa myös nauhoittaa siltä varalta, että joku asia jää kuulematta tai kaikkea ei ehditä kirjoittaa haastattelutilanteessa ylös. Haastattelijat kirjoittavat haastattelun puhtaaksi ryhmätyönä mahdollisimman pian haastattelun jälkeen. Tällöin varmistetaan se, etteivät asiat unohdu. Keskustelu ryhmän kanssa auttaa muistamaan ja tulkitsemaan saadut vastaukset oikein. Haastatteluvastaukset koostetaan kaikkien ryhmän jäsenten muistiinpanoista ja kirjataan haastattelulomakkeelle. Kotihoito-projektissa yhteen haastatteluun kului aikaa noin 1,5 tuntia. Haastattelijoita oli pääsääntöisesti kolme. Tämä tuntui sopivalta määrältä, sillä työnjaoksi muodostui se, että yksi haastattelija kyseli, toinen teki muistiinpanoja ja kolmas teki muistiinpanoja ja lisäksi auttoi tarvittaessa apukysymyksillä kyselijää. Kuitenkin on hyvä, jos kirjoittajia on useampi, sillä eri ihmiset havaitsevat kuulemastaan eri asioita. Kaikki haastattelut nauhoitettiin. Haastattelut purettiin ryhmä- tai parityönä, jolloin voitiin keskustella haastattelutuloksista ja saada aikaan mahdollisimman kattavasti halutut tiedot ylös. Keskustelu heti haastattelun jälkeen auttoi löytämään olennaiset tiedot haastattelusta ilman nauhoitusten kuuntelemista. Käytännössä haastattelulomakkeelle kirjoitettiin kaikki haastatellun mainitsemat asiat (vastaukset kysymyksiin, esimerkit, aiheeseen liittyvät muut asiat, jotka haastateltava otti oma-aloitteisesti esille). Kunkin haastattelun purkamiseen kului aikaa n. 3 tuntia. Haastattelun purkumenetelmä koettiin hedelmälliseksi ja oletettavasti huomattavasti nopeammaksi kuin litterointi nauhaa kuuntelemalla. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 21

22 HAASTATTELUJEN ANALYSOINTI Haastattelutulosten analysointi alkaa jo haastattelujen purkuvaiheessa. Haastattelujen purkamismenetelmä mahdollistaa analysoivan keskustelun aloittamisen jo tiedonkeruun varhaisessa vaiheessa. Analyysissä tieto pilkotaan osiin ja järjestellään uudelleen. Analysoinnin alkuvaiheessa on hyödyllistä piirtää kaavioita ja kuvia kerätyn aineiston perusteella. Mallinnettavia asioita ovat esimerkiksi toiminnassa havaitut erilaiset tietosisällöt, tietojen sijainti ja siirtyminen sekä erilaiset prosessit. Käyttökelpoisia kaavioita ovat esimerkiksi aktiviteettikaaviot, joiden avulla voidaan kuvata toimintaprosesseja, tai taulukot, joihin voidaan kerätä erityyppisiä tietoja. Kuvissa ja kaavioissa on havainnollista käyttää erilaisia symboleita. Kaaviot ja kuvat auttavat hahmottamaan ja ymmärtämään kohdealuetta ja sen toimintoja. Myös toimintatarinoita voi käyttää lisäämään ymmärrystä kohdealueesta. Toimintatarina on kuvitteellinen, kohdealueen toimintaa kuvaava tarina (ks. liite 2). Tarinan laatiminen tuo esille kohtia, joista täytyy hankkia lisää tietoa. Toimintatarina tuo kohdealueen toiminnan konkreettisemmaksi ja siten helpommin ymmärrettäväksi. Toimintatarinan avulla voidaan miettiä erilaisia tiedonkulkuja ja vastuuhenkilöitä. Samalla voi löytää solmukohtia, joissa tieto ei kulje niin kuin pitäisi. Tieto voi tulla myöhässä tai hävitä kokonaan, olla puutteellista, vanhentunutta, ristiriitaista tai virheellistä. Myöhemmin toimintatarinaa voidaan käyttää keskustelun herättäjänä, kun tarkastetaan analysoinnin tuloksia kohdealueen toimijoiden kanssa. Toimintatarinoista on apua myös menetelmän vaiheessa 2 prosessikuvauksia laadittaessa. Analysointivaiheessa ActAD-malli ohjaa kerätyn toimintoja koskevan tiedon jäsentämistä kahdella tasolla. Ensinnäkin etsitään ja mallinnetaan kunkin toiminnan sisäinen rakenne. Toiseksi tunnistetaan eri toiminnoista muodostuva verkko yhteyksineen. Lisäksi analysoidaan toiminnoissa tarvittavat tiedot. Esimerkkejä Kotihoito-projektissa laadituista apukuvista on liitteessä 1. Erilaiset kuvat ja kaaviot havaittiin hyödyllisiksi, sillä kuvasta voi saada käsityksen kuvatusta asiasta nopeammin kuin kirjoitetusta tekstistä. Niitä käytettiin keskustelun apuvälineinä ja muistilistoina. Liitteessä 2 on esimerkki toimintatarinasta, jota käytettiin lisäämään ymmärrystä kotihoidon järjestämisestä lyhytaikaista ja tilapäistä kotihoitoa tarvitsevalle asiakkaalle TARKASTELUN KOHDISTAMINEN Yksittäisen toiminnan sisäisen rakenteen selvittämiseksi haastatteluista kerätyt tiedot jäsennellään toiminnan teorian mukaisiin palasiin. Saman osatoiminnan kaikkien toimijoiden haastattelut kootaan yhteen. Tiedot ryhmitellään seuraavien toiminnan rakennemallista saatavien otsikoiden alle: Kollektiivinen toimija on toiminnan sisällä vaikuttavista toimijoista muodostuva ihmisryhmä, joka tarvitaan toiminnan toteuttamiseen. Kollektiivinen toimija voi olla tarkoin määritelty tiimi, työyhteisö tai myös löyhemmin sidoksissa oleva ryhmä ihmisiä. Joskus voidaan löytää useita kollektiivisia toimijoita. Yhteistyö. Koska kyseessä on usean toimijan yhteistyönä tapahtuva systemaattinen toiminta, tarvitaan toiminnan koordinointiin ja toimijoiden väliseen yhteistyöhön erilaisia välineitä ja keinoja. Tällaisia ovat fyysisten laitteiden, kuten puhelin ja tietokone, lisäksi myös yhteiset säännöt ja toiminnassa noudatettavat työtavat. Toiminnan yhteistyön, kommunikaation ja koordinoinnin välineet ja keinot voidaan jakaa toiminnan sisäisiin ja eri toimintojen välisiin. Toimijat. Tässä luetellaan kaikki toimintaan osallistuvat erilaiset toimijat, joilla on erilaisia rooleja esimerkiksi ammattiryhmästä tai toimenkuvasta johtuen. Välineet. Tarvittavat työvälineet voivat olla materiaalisia (esim. koneet ja laitteet) tai eimateriaalisia (esim. työkokemus ja ammattitaito). Kohde. Tässä kuvataan toiminnan kohde. Tavoite. Toiminnalla voi olla useamman tasoisia tavoitteita, jotka kuvataan tässä. 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

23 Tuotos. Toiminnan tuotos voi olla fyysisesti havaittava (esim. tuote tai merkintä raporttiin) tai abstrakti tuotos (esim. tiedon lisääntyminen). Lisäksi kuvataan yksittäisen toiminnan suhteet muihin toimintoihin seuraavien otsikoiden alle: Edeltävät tai vaikuttavat toiminnat. Tässä kuvataan ne toiminnat, jotka suoraan edeltävät käsiteltävää toimintaa, tai vaikuttavat siihen. Edeltävien toimintojen tuotoksia tarvitaan käsiteltävässä toiminnassa. Seuraavat toiminnat. Käsiteltävää toimintaa voi suoraan seurata jokin toinen toiminta, jossa saatetaan tarvita käsiteltävän toiminnan tuotosta syötteenä. Jokainen esitetyistä kohdista voidaan kyseenalaistaa ja muuttaa kehityskohteeksi, varsinkin jos useampi haastateltava tarttuu samaan asiaan, esimerkiksi johonkin yhteistyön välineeseen, joka ei toimi. Liitteessä 3 on esitetty esimerkki kotihoidon arviointikäynnistä toimintana. Arviointikäynnistä saatu tieto on jäsennelty edellisen mallin mukaisesti. Samalla kaavalla on mallinnettu kaikki keskeiset toiminnat ja koottu yhteen Toiminnat ja tiedot -dokumenttiin, joka on osa Kotihoidon tiedon tarpeet -julkaisua (Toivanen, ym., 2004b: PlugIT-hankkeen selvityksiä ja raportteja 12) TARKASTELUN LAAJENTAMINEN Yksittäisten toimintojen sisäisen rakenteen lisäksi mallinnetaan toimintojen verkko. Tätä varten tunnistetaan haastattelutiedoista yhteyksiä toimijoiden ja toimintojen välillä. Selvitetään, ketkä kommunikoivat keskenään, miksi ja milloin. Toimintojen verkottumiseen vaikuttavia asioita löytyy yksittäisten toimintojen kuvauksista otsikoiden Yhteistyö, Tuotos, Edeltävät tai vaikuttavat toiminnat ja Seuraavat toiminnat alta. Toiminnassa tarvittavien tietojen sisältö selvitetään. Myös tiedon siirtyminen toimijoiden välisessä viestinnässä tutkitaan ja tunnistetaan, mitä välineitä viestinnässä käytetään. On tärkeää tunnistaa kriittiset pisteet, joissa tiedon kululla on hyvin tärkeä merkitys, ja kehityskohteet, joissa tieto ei kulje niin hyvin kuin pitäisi tai voisi. Toimintoihin liittyvien tietojen analysoimiseksi haastatteluaineistosta etsitään keskeisiä pienemmistä tietoyksiköistä koostuvia tietokokonaisuuksia, jotka kuvataan. Esimerkiksi kotisairaanhoidolla on yhteyksiä moniin kotihoidon osatoimintoihin, eniten kotipalveluun. Yksinkertaistettu toimintojen verkko on esitetty kuvassa 4. Kuopiossa pääasiallisin viestintäväline kotipalveluun päin on matkapuhelin, jonka avulla vaihdetaan asiakkaan vointiin liittyvää tietoa. Myös hoito- ja palvelusuunnitelma on tärkeä viestinnän väline, sillä siihen on kirjattu asiakkaan kotihoitoon vaikuttavat tiedot mahdollisimman kattavasti. Kotisairaanhoidolla on myös paljon yhteyksiä ympäröiviin sairaanhoidon organisaatioihin. Kaupungin perusterveydenhuollon järjestelmä on tietolähteenä tärkeä, sillä kotisairaanhoito kuuluu samaan organisaatioon, ja voi siten tutkia järjestelmään tallennettuja asiakkaan terveys- ja sairaustietoja. Erikoissairaanhoidon puolelle viestintävälineenä ovat epikriisit, hoitajan ja lääkärinlähetteet, sekä kiireellisissä asioissa, esimerkiksi kotiutustilanteessa usein puhelin. Kotihoidossa keskeisiksi tietokokonaisuuksiksi nousivat haastatteluista hoito- ja palvelusuunnitelma, hoito- ja palvelusuunnitelmakansio, lääkelista, kotiutustiedot sekä asiakkaan kotona oleva viestivihko (Kotihoito-projektin Toiminnat ja tiedot, ks. Toivanen ym., 2004b). TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 23

24 2.3.4 Tarkistuttaminen työpajassa Haastattelutulokset kootaan yhdeksi johdonmukaiseksi dokumentiksi, jossa kuvataan kohdealueen toiminnat ja tietokokonaisuudet, toimintojen väliset yhteydet, tietojen sijainti ja saatavuus sekä havaitut kehityskohteet. Toimintojen dokumentoinnissa käytetään hyväksi edellä kuvattua ActADmallin mukaista toiminnan rakennetta. Keskeisistä tietokokonaisuuksista on hyödyllistä selvittää mm. määritelmä, vaaditut tietoyksiköt, kuka tarvitsee ja tuottaa, mistä tieto tulee ja minne sen pitää mennä sekä tietokokonaisuuden elinkaari. (Kotihoito-projektin Toiminnat ja tiedot, ks. Toivanen ym., 2004b). Jotta voidaan varmistaa, että haastatteluilla kerätyt tiedot on ymmärretty oikein ja että niistä ei puutu mitään olennaista, tiedot tarkistetaan yhdessä kohdealueen toimijoiden kanssa. Tarkistukseen soveltuu hyvin työpajaistunto, johon kutsutaan osa haastatelluista, mielellään yksi jokaisesta osatoiminnasta. Kutsutuille toimijoille lähetetään pelkistetty kuva toimintojen verkosta, jotta he voivat tutustua siihen etukäteen. Toimintojen verkko voi olla esimerkiksi kuvan 4 kaltainen tai liitteessä 4 esitetyn kaltainen. HALLINTO lainsäädäntö TARVEKAR- TOITUS TIIMIT KSH/KH INTER- VALLI SAIRAALA HOITO KOTIUTUS kpo,ksh, omahoitaja, omainen, edunvalv.,asiakas ARVIOINTI- KÄYNTI ruuanvalm. +kulj. ATERIA- PALVELU ksh,kp,fys.ter,. siivous YKSITYISEN TUOTTAMA KOTIHOITO omaishoitaja ERIKOIS- SAIR.HOITO (KYS) kh KOTI- PALVELU TURVA- PALVELU OMAISHOITO TK-KÄYNTI ksh, lääkäri KOTI- SAIRAAN- HOITO APU- VÄLINEIDEN JÄRJESTÄ- MINEN sostyöntek., ksh OHJAUS- JA NEUVONTA- TYÖ SAS- TYÖRYHMÄ KOTIHOITO taksi,pali KULJETUS PALVELU fys.ter., toimintater., kuntohoitaja KUNTOUTUS apuväl.yksikön hlökunta, rakennusmies KODIN MUUTOSTÖIDEN SUUNNITTELU JA TOTEUTUS vapaaehtoinen ystäväpalvelu, naapuri, omainen HUOLENPITO PALVELU- ASUMINEN KOTONA TAPAHTUVA HOIVA Kuva 4. Kotihoidon toimintojen verkko yksinkertaistettuna TYÖPAJAN ESIVALMISTELUT Työpajan esivalmisteluihin kuuluvat aikatauluista sopiminen, tilan varaus, kutsut toimijoille, esimateriaalin valmistelu sekä työnjaosta sopiminen selvitysryhmän kesken. 24 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

25 Työpajaan kutsutaan jokaisesta keskeisestä osatoiminnasta ainakin yksi haastatelluista toimijoista. Kutsuttavien kanssa keskustellaan ajankohdasta henkilökohtaisesti, jotta voidaan varmistaa mahdollisimman kattava osallistuminen. Työpajaa varten varataan riittävän iso tila. Esimateriaaliksi työpajaan valmistetaan seinätaulu (kuva 5). Seinätekniikassa huoneen seinälle asetettuun isoon pohjapaperiin kootaan irrallisista symboleista halutun mallin mukaisia ryhmittymiä (Saaren-Seppälä, 1987). Seinätauluelementit piirretään ja tulostetaan valmiiksi ennen työpajaa. Tietovälineiden symboleina käytetään havainnollisia kuvia, kuten puhelin ja tietokone. Toiminnat kuvataan soikioilla, joiden sisään kirjoitetaan toiminnan rakenne. Kohdealueen rajat merkitään, ja rajojen sisäpuolelle sijoitetaan toiminnat sekä tietolähteet. Yhteydet toimintojen välillä merkitään. Ulkopuolelle sijoitetaan suorakaiteina kuvatut organisaatiot tai rakennukset, joista toimijat tulevat sekä ne ympäröivät yhteisöt, joihin toimijoilla on yhteyksiä. Seinätaululle kootaan valmiiksi mahdollisimman paljon haastatteluista saatua tietoa. Dokumentiksi kootut toimintojen kuvaukset jaetaan työpajassa osallistujille työpajan seuraamisen avuksi. Seinätekniikalla esitetty seinätaulu (kuva 5) kuvaa toimintojen verkkoa (kuva 4) ja on työpajan keskeinen työväline. Se toimii keskustelun apuvälineenä sekä työpajan jälkeen muistin apuna TYÖPAJA Työpajassa on läsnä kaikkien keskeisten toimintojen toimijoita sekä selvitystyön tekijät. Aikaa varataan kohdealueen laajuudesta riippuen. Työpajassa esitellään käytetty kuvaustekniikka ja symbolit ensin yleisellä tasolla. Sen jälkeen kukin toiminta esitellään tarkemmin, jolloin syntyy keskustelua toimijoiden kesken tai vaihtoehtoisesti kysymyksiä voidaan kohdentaa kunkin osatoiminnan asiantuntijalle. Keskustelun edetessä seinätaulua täydennetään ja korjataan. Seinätaulu on muistiinpanoväline, josta on hyötyä myöhemmissä vaiheissa. Työpajan keskusteluista kirjataan ylös olennaiset asiat, erityisesti uudet asiat ja ne, jotka tarvitsee muuttaa. Käytännössä tämä onnistuu parhaiten, jos toimintojen esittelyt suunnitellaan ja jaetaan etukäteen tutkimusryhmän jäsenille ja muistiinpanoja tekemässä on useampi kuin yksi henkilö. Keskustelut voidaan myös nauhoittaa tai videoida. Kuva 5. Seinätaulu, Kotihoito-projektin työpaja TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 25

26 Kotihoidon työpajaistuntoon käytettiin yksi työpäivä. Mukana oli yksi tai useampi toimija kaikista keskeisistä toiminnoista. Osallistujille jaettiin toimintojen kuvaukset työpajan alussa. Seinätekniikka ja käytetyt symbolit esiteltiin ensin ja sen jälkeen esiteltiin kukin yksittäinen toiminta Toiminnat ja tiedot -dokumentin toimintakuvausten mukaisesti. Keskustelua syntyi sekä toimijoiden kesken että toimijoiden ja tutkijoiden välillä runsaasti. Seinätaulu koettiin selkeäksi ja sen avulla oli helppo edetä keskustelussa (kuva 5). Toimijat tekivät tarkennuksia aikaisemmin saatuihin tietoihin ja joitakin selviä kehityskohteita nousi esille. Esimerkiksi kaivattiin uutta kotiuttaja-toimijaa, jonka tehtävänä olisi huolehtia mm. tiedonkulusta asiakkaan kotiutustilanteessa. Tarkennukset merkittiin seinätauluun ja lisäksi tutkijaryhmän jäsenet tekivät muistiinpanoja. Ennen työpajaa oli sovittu työnjaosta, esim. kuka esittelee eri toimintojen tiedot, muistiinpanotehtävät, seinätauluelementeistä huolehtiminen ym. Tämä teki työskentelystä sujuvaa ja loi osaltaan työpajaan hyvän ilmapiirin TYÖPAJAN JÄLKIPUINTI JA TARVITTAVIEN KORJAUSTEN TEKO JA NIIDEN ANALYSOINTI Kaikki selvitystyön tekijät laativat muistion kokemuksistaan ja havainnoistaan työpajasta mahdollisimman pian työpajan jälkeen. Tämä auttaa muistamista ja on apuna tulosten työstämisessä. Työpajan jälkeen tehdään tarvittavat muutokset toimintojen ja tietojen kuvaukseen ryhmätyönä työpajatulosten perusteella. Korjattu dokumentti lähetetään työpajaan osallistuneille, jotka tarkistavat muutokset. Tässä vaiheessa on saatu selvitettyä kohdealueen yksittäiset toiminnat ja toimintojen verkko sekä tarvittavat tietoyksiköt ja niiden liikkuminen toimintojen ja organisaatioiden välillä. Näitä tuloksia voidaan käyttää hyväksi sekä työtoiminnan kehittämisessä organisaatio- tai yhteisötasolla että tietojärjestelmän kehittämisessä Kehityskohteet Kun kohdealue on mallinnettu, voidaan toimintojen verkkoa tarkastelemalla löytää mahdollisia tiedonkulkuun liittyviä kehityskohteita. Kehityskohteita ovat esimerkiksi ne tilanteet, joissa toiminnassa tarvittava tieto ei kulje riittävän hyvin tai lainkaan. Kehityskohteita löydetään jo haastattelutuloksia analysoitaessa, mutta erityisesti työpajassa syntyvissä keskusteluissa. Kun tiedonkulun ongelmakohdat ja syitä niihin on havaittu, voidaan työtoiminnan kehittämistä jatkaa esimerkiksi suunnittelemalla työn organisointia. Tämä on kohdealueen toimijaorganisaation tehtävä. Tietojärjestelmän kehittämistä voidaan jatkaa menetelmän vaiheessa Vaiheen 1 tulokset Vaiheen 1 tuloksena on saavutettu ymmärrys toimintaverkoston toiminnasta kokonaisuutena ja selvitetty yksittäisten toimintojen sisäistä rakennetta, yhteyksiä toisiin toimintoihin sekä ympäröiviin organisaatioihin. Toiminnassa tarvittavat tietokokonaisuudet on tunnistettu, paikallistettu niiden sijainti sekä tiedonkulku. Tiedonkulun rajapintoja ja ongelmakohtia sekä toiminnan kehittämiskohteita on löydetty. Tunnistettiin keskeiset toiminnat, selvitettiin yksittäisen toiminnan rakenne sekä kuvattiin toimintojen verkosto. Jokainen tunnistettu toiminta on kuvattu annettujen teemojen avulla: edeltävät/vaikuttavat toiminnat, kollektiivinen toimija, yhteistyö, toimijat, välineet, kohde, tavoite, tuotos ja seuraavat 26 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

27 toiminnat. Näin on selvitetty tiedon kulkua, toimijoiden välisiä yhteyksiä sekä mahdollisia tiedonkulun ongelmakohtia. Ensimmäisessä vaiheessa selvitettiin, mitä tietoa työssä tarvitaan, ketkä tietoa tarvitsevat, missä tieto syntyy ja on varastoituna, miten tieto saadaan sinne missä sitä tarvitaan ja mitkä seikat rajoittavat tiedon kulkua. Keskeisistä tietokokonaisuuksista on tarvittaessa kuvattu elinkaari, toisin sanoen milloin ja missä tietoa syntyy, milloin sitä tarvitaan ja mihin tieto on varastoitu. Näiden tietojen pohjalta on kirjoitettu kuvaus kohdealueen toiminnoista (palvelu)verkostona sekä kuvaus toimintojen tarvitsemista tietokokonaisuuksista (esim. Kotihoito-projektin Toiminnat ja tiedot, ks. Toivanen ym., 2004b). Tätä dokumenttia voidaan käyttää vaiheen 2 pohjana, kun tarkastelua kohdistetaan ja valitaan ne kohteet, joita aletaan työstää tarkemmalla tasolla. 2.4 Vaihe 2: Tarkastelun kohdistaminen ja syventäminen Jotta menetelmän toiseen vaiheeseen voidaan siirtyä, on tunnettava kohdealueena oleva palveluverkosto: Siitä on tunnistettu keskeiset toiminnot, niiden sisäiset rakenteet ja niiden väliset yhteydet, nimetty toimijat, keskeiset tietokokonaisuudet ja tiedonkulun rajapinnat. Vaiheen yksi tuloksena syntyvä, ActAD-mallin mukainen kuvaus antaa näitä tietoja selkeänä kokonaisuutena. Kuvauksesta on myös tunnistettu palveluverkoston kehittämistarpeita, jotka voivat liittyä työtoiminnan kehittämiseen, tiedonkulun ongelmiin, jne. Ensimmäisessä vaiheessa käytetty kuvaustapa mahdollistaa sekä toiminnan että tietojärjestelmien kehityskohteiden (ohjelmistotarpeiden) tunnistamisen ja alustavien ratkaisujen ideoimisen. Tunnistetuista toiminnoista, tietokokonaisuuksista ja niihin liittyvistä kehityskohteista valitaan halutut tarkempaan määrittelyyn menetelmän toiseen vaiheeseen. Tässä vaiheessa valituista toiminnoista muodostetaan työprosessikuvauksia, hahmotellaan tietokokonaisuuksiin liittyvää arkkitehtuuria sekä tuodaan esiin näkökulmia kehittämisen suhteen. Valintaan vaikuttaa esimerkiksi se, kuinka keskeisiä havaitut kehittämistarpeet ovat palveluverkoston toiminnan kannalta ja mihin toimintoihin ne liittyvät. Lisäksi on otettava huomioon ympäristö. Onko samansuuntaisia kehityshankkeita meneillään tai tulossa. Varsinkin tietojärjestelmähankkeissa on otettava huomioon se, millaisia yhteyksiä pitää luoda suunniteltavan systeemin ja ympäristön välille. Esimerkiksi sähköisen hoito- ja palvelusuunnitelman kehittämisessä on otettava huomioon myös työtoiminnan kehittäminen: mitä laitteita tarvitaan työssä ja kuka sitoutuu ne hankkimaan, työnjako ja vastuukysymykset hoito- ja palvelusuunnitelman päivityksessä sekä tiedon omatoimisessa hakemisessa ja miten koulutus järjestetään. On otettava huomioon myös se, mitä tietokoneen mukaan ottaminen merkitsee toimijalle ja miten asiakas siihen suhtautuu Työprosessit Toiminnan tai tietojärjestelmän kehittämistä varten edetään toimintojen ja tietojen kuvauksessa tarkemmalle tasolle. Edellisessä vaiheessa työprosessi on kuvattu yleisellä tasolla, monen toimijan yhteistyönä tapahtuvana toimintana, jonka seurauksena kohteessa tapahtuu muutos tavoitteen suuntaan. Toisessa vaiheessa prosessikuvausta tarkennetaan yksittäisiä työnkulkuja kuvaaviksi. Keskeisistä toiminnoista muodostetaan UML:n aktiviteettikaavioita muistuttavia työprosessikuvauksia, esimerkkejä työnkuluista, jotka koostuvat yksittäisistä teoista (kuva 6). TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 27

28 Työprosessi: Kohde muuttuu: Tulos Kuva 6. Yhteys vaiheen 1 ja 2 välillä Työprosessikuvaus kuvaa yhden mahdollisen työnkulun, sillä työprosessilla on usein monta erilaista tapaa edetä. Kaavion lisäksi laaditaan sanallinen kuvaus prosessista. Työprosessikuvausten muodostamisessa apuna voidaan käyttää toimintatarinoita, kuvitteellisia esimerkkejä siitä, miten tietty työvaihe käytännössä tehdään. Kuvauksia voidaan tehdä myös havainnoimalla kyseistä prosessia tai kysymällä toimijoilta tarkennuksia. Työprosessikaaviossa kuvataan eri toimijoiden suorittamat teot, teon keinot ja välineet, prosessin sisällä olevien tekojen koordinointikeinot ja -välineet, sekä eri toimintojen verkottumisen keinot. Erona UML:n aktiviteettikaavioihin on se, että tässä kuvataan myös prosessin edetessä tarvittavat tai tuotettavat tiedot ja käytettävät tietovälineet. Jos prosessi tapahtuu fyysisesti eri paikoissa, voidaan myös tapahtumapaikat kirjata kaavioon. Tästä voidaan edetä ohjelmistovaatimusten suuntaan laatimalla tarvittavat käyttötapaukset. Kotihoito-projektissa ensimmäisessä vaiheessa keskeiseksi kotihoidon toimintakokonaisuudeksi nousi mm. arviointikäynti. Arviointikäynnistä tuotettiin toisessa vaiheessa työprosessikuvaus, joka on esimerkki siitä, miten hoito- ja palvelusuunnitelma voidaan tehdä asiakkaalle kotihoidon arviointikäynnillä (kuva 7). Kaaviossa on symboleilla (matkapuhelin, paperi, kynä jne.) kuvattu työprosessissa tarvittavia tietovälineitä. 28 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

29 Kpo Asiakas Oma -hoit. Tilaus Tarkistaa perustiedot Kertoo tiedot Kirjaa tiedot Hoitojaksojen tiedot Tarkistaa sairaus- ja lääkitystiedot Näyttää epikriisin ja reseptit Ksh Pegasos Kirjaa tiedot Kartoittaa tarpeet & toiveet Avuntarve aam u- toim issa Kirjaa tarpeet & toiveet Lisää käynnin listalleen HOPASU HOPASU HOPASU Allekirjoittaa HOPASUn Kuva 7. Kotihoidon prosessi arviointikäynti HOPASUn jakelu eri tahoille Tietoarkkitehtuuri Työtoiminnassa tieto on tärkeä työ- ja yhteistyöväline. Edellisessä vaiheessa selvitettiin, mitä tietoa työssä tarvitaan, ketkä tietoa tarvitsevat, missä tieto syntyy ja on varastoituna, miten tieto saadaan sinne missä sitä tarvitaan ja mitkä seikat rajoittavat tiedon kulkua. Keskeisistä tietokokonaisuuksista on tarvittaessa kuvattu elinkaari, toisin sanoen milloin ja missä tietoa syntyy, milloin sitä tarvitaan ja mihin tieto on varastoitu. Menetelmän toisessa vaiheessa tietojen analysointia jatketaan tarkemmalle tasolle kuvaamalla tietoarkkitehtuuria. Tietokokonaisuudet jaetaan pienempiin tietoyksiköihin. On erityisen tärkeää selvittää, mitkä tietoyksiköt ovat yhteisiä eri tietokokonaisuuksissa. (ks. Kotihoito-projektin Prosessit ja tietoarkkitehtuuri, Toivanen ym., 2004b). Tietoarkkitehtuurin hahmottamisessa on hyödyllistä miettiä, miten kohdealueelta tunnistettuja tietokokonaisuuksia ja -yksiköitä voisi luokitella erilaisin perustein. Apuna tiedon luokittelussa voidaan käyttää esimerkiksi taulukoita. Tilanteesta riippuu, tehdäänkö luokittelu yhdellä perusteella vai käytetäänkö jotakin luokittelujen yhdistelmää. Tietojen luokittelun perusteena voisi olla esimerkiksi se, missä tieto syntyy. Tällöin tiedot voidaan luokitella esimerkiksi seuraavasti: toiminnan sisällä syntyvät ja tarvittavat tiedot, eri toimintojen välillä kulkevat tiedot sekä toimintaverkon ulkopuolelta haettavat tiedot. Näin luokittelemalla voidaan tarkastella tiedon saatavuutta, johon taas vaikuttavat tietosuoja, käytettävissä olevat välineet, keinot ja käytännöt sekä tiedon tallennusmuoto ja säilytyspaikka. Muita luokitteluperusteita ovat esimerkiksi tiedon kohde sekä tiedon pysyvyys ja TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 29

30 käyttöaika. Tietoarkkitehtuurikuvauksessa kuvataan niitä tietokokonaisuuksia ja -yksiköitä, jotka toimivat lähtökohtana komponenttisuunnittelussa vaiheessa 3. Esimerkiksi kotihoito-projektissa havaittiin hoito- ja palvelusuunnitelman sisältävän paljon sellaisia tietoyksiköitä, joita syntyy ja tarvitaan ympäröivissä organisaatioissa ja toiminnoissa (kuva 8). Hoito- ja palvelusuunnitelmaan kerätään paljon tietoa eri tietolähteistä (esim. erikoissairaanhoito, perusterveydenhuolto, yksityiset palvelut), koska tarvittavia tietoja ei muilla keinoin saada kaikkien kotihoidon toimijoiden käyttöön. Kun samaa tietoa tallennetaan moneen eri paikkaan erilaisin välinein, seurauksena on turhaa työtä, tiedon ristiriitaisuutta ja ongelmia tiedon pitämisessä ajan tasalla. Olisi hyödyllistä, mikäli hoito- ja palvelusuunnitelma voitaisiin tehdä sähköiseen muotoon, ja sen tietoja voisivat eri tahot hyödyntää omilla laitteillaan ja järjestelmillään. Havaittiin, että hoitoja palvelusuunnitelman määrittelemistä tarkemmalle tasolle ohjelmistoksi tai ohjelmiston osaksi kannattaa jatkaa. Potilas/asiak asrek isteri Potilask ertomus Fysio- ja toimintaterapialomak k eet Henk ilök untarek isteri Hoito- ja palvelusuunnitelma Korjausavustus asumistiedot Toimeentulotuki asumistiedot Veteraanik untoutus sairaus-,apuväline-, toimintakykytiedot Kela Asumistuk i asumistiedot Kela Hoitotuki apuv äline-, toimintakykytiedot Kuva 8. Hoito- ja palvelusuunnitelmassa tarvittavia ja siitä saatavia tietoja Kohdealueen kehittämisessä huomioitavat asiat Aikaisemmassa vaiheessa on mallinnettu ja jäsennetty kohdealuetta. Sen toimintaa ja toimintaverkkoa tarkasteltaessa on noussut esille kehityskohteita. Seuraavaksi on laajennettava näkökulmaa ja tarkasteltava kohdealuetta osana ympäröivää yhteiskuntaa. On selvitettävä esimerkiksi kehityshankkeita, lakeja, standardeja, jotka vaikuttavat kohdealueen toimintaan nyt tai tulevaisuudessa. Varsinkin tietovarastosta on apua tässä vaiheessa. Tietovarastosta löytyy tietoa esimerkiksi ympäröivistä ja samankaltaisista kehityshankkeista, toimijoiden koulutuksen kehittämisestä, työnkuvaan, tietoturvaan yms. liittyviä lakeja ja sääntöjä sekä valtakunnallisia ja paikallisia tavoitteita. Tietovarastoa voidaan hyödyntää arvioitaessa, mitä ja millaista kehitystyötä kohdealueella tarvitaan. Kohdealueelta saatuja tietoja voidaan arvioida myös suhteessa muihin selvityksiin (esim. tietojen kattavuus, ajankohtaisuus). 30 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

31 Esimerkiksi Kotihoito-projektissa havaittiin, että hoito- ja palvelusuunnitelman kehittämisessä on otettava huomioon esimerkiksi suositukset siitä, miten asiakkaan suostumus vaikuttaa tietojen käyttöön, tietoturvalait, aluetietojärjestelmähankkeet yms. Näistä tekijöistä löytyi paljon tietoa tietovarastoon aiemmin kerätyistä tietolähteistä. Tietovaraston toteutus Internet-sivulla olevana linkkilistana koettiin onnistuneeksi, sillä se oli helposti käytettävissä ja päivitettävissä Vaiheen 2 tulokset Vaiheen 2 tuloksena saadaan tarkennettu kuvaus kohdealueen toiminnoista ja tiedoista. Keskeisimpien toimintojen työprosessit on kuvattu työprosessikaavioina sekä sanallisina esimerkkeinä työnkuluista. Työn sujumisen kannalta keskeisimpien tietokokonaisuuksien koostumus, sijainti, liikkuminen ja hyödynnettävyys kuvataan tietoarkkitehtuurikuvauksessa. Näistä kuvauksista voidaan osoittaa kehittämistarpeita sekä toimintaan että ohjelmistoon tai sen osaan. Kuvaukset kootaan yhdeksi loogiseksi dokumentiksi (esim. Kotihoito-projektin Prosessit ja tietoarkkitehtuuri, Toivanen ym., 2004b). Tietovaraston hyödyntäminen näkyy konkreettisesti siinä, että saadaan kokonaiskuva kohdealueesta ympäröivässä kontekstissaan (muut kehityshankkeet, lakialoitteet, koulutukset jne.). 2.5 Vaihe 3: Keskittyminen ohjelmistovaatimuksiin Kun menetelmän toisessa vaiheessa on havaittu tarvetta tietojärjestelmän kehittämiseen, kolmannessa vaiheessa esille nousseet kehityskohteet tai osa niistä valitaan jatkokäsittelyyn. Valintaan vaikuttaa erityisesti se, mikä on keskeistä ja mistä on eniten hyötyä kaikille tahoille. Tilaajan mielipide, projektin resurssit ja kehityskohdan toteutettavuus vaikuttavat myös valintaan. Lisäksi on otettava huomioon ympäristö, ts. millaisia yhteyksiä on luotava suunniteltavan systeemin ja ympäristön välille sekä se, onko ympäristössä tähän liittyviä kehityshankkeita meneillään tai tulossa. Ohjelmistovaatimukset voidaan jakaa toiminnallisiin ja ei-toiminnallisiin vaatimuksiin. Toiminnalliset vaatimukset kuvaavat sitä, mitä toimintoja tuotettavan järjestelmän tulee toteuttaa. Ei-toiminnalliset vaatimukset liittyvät järjestelmän laadullisiin ominaisuuksiin, kuten käytettävyyteen, tietoturvaan, suorituskykyyn ja ylläpidettävyyteen. Toiminnallisia vaatimuksia kuvataan ohjelmistotuotannossa yleisesti käyttötapauksilla. Käyttötapauksissa kuvataan järjestelmän toiminnallisuus joukkona järjestelmän käyttäjän suorittamia tapahtumaketjuja (Jacobson ym., 1992). Niissä kuvataan nimenomaan siis käyttäjän ja ohjelmiston vuorovaikutusta. Käyttötapaukset ja käyttötapauskuvaukset johdetaan menetelmän toisessa vaiheessa luoduista työprosessikuvauksista. Käyttötapausten lisäksi tarvitaan myös aikaisemmin luotuja kuvauksia kohdealueesta, sillä ilman yhteyttä kokonaisuuteen käyttötapaukset jäävät irrallisiksi ja epävakaiksi. Tavoitetilan käyttötapaukset on hyvä sijoittaa toisessa vaiheessa tehtyihin työprosessikuvauksiin ja nämä työprosessikuvaukset ensimmäisessä vaiheessa tehtyihin toimintakokonaisuuksiin ja toimintojen verkkoon. Näin varmistetaan uuden ohjelmiston todellinen vaikutus toimintaan. Asiasta on syytä keskustella myös tulevien käyttäjien kanssa. Kun halutaan käyttää ohjelmiston rakentamisessa komponentteja, on otettava huomioon myös komponenttiteknologian ja -markkinoiden aiheuttamat vaatimukset. Komponenttien löytämisen ja suunnittelun perusteena ovat kohdealueelta löydetyt tietokokonaisuudet. Komponenttisuunnittelussa on huomioitava myös integroitavuus ympärillä oleviin eri järjestelmiin. Integrointi on hyödyllistä, jos esimerkiksi tarvittavaa tietoa on valmiiksi tallennettuna toiseen järjestelmään. Eri käyttäjäryhmillä on erilaiset tarpeet tietojärjestelmän käytölle. Siksi on kiinnitettävä huomiota erilaisiin käyttöoikeuksiin ja -vastuisiin sekä erilaisten käyttöliittymien tarpeeseen. Tietoturvaan (turvalliset yhteydet, tietojen säilyvyys, yksityisyyden suoja, erilaiset käyttäjäoikeudet jne.) on myös kiinnitettävä huomiota. Edellä luetellut asiat käsitellään aluksi abstraktilla tasolla ja kun aletaan tarkentaa komponenttisuunnittelua, edetään ensin rajapintoihin, suunniteltavan komponentin ja ympä- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 31

32 ristön suhteisiin ja riippuvuuksiin ja sitä kautta komponentin tarjoamiin palveluihin (Toivanen ym., 2003a). Ohjelmistovaatimusten näkökulmaa käsitellään lisää luvussa Tuotokset Tietovarastoa kerätään koko projektin ajan. Se sisältää aiheeseen liittyvää tietoa, jota voidaan hyödyntää sekä ohjelmistosuunnittelussa että työtoiminnan kehittämisessä. Olennaista on, että tietolähteet on kerätty yhteen paikkaan, josta ne ovat kaikkien tietoja tarvitsevien helposti löydettävissä ja saatavissa. Erilaisia kaavioita, kuvia ja kuvauksia tuotetaan projektin edetessä. Ne toimivat ajattelun, analysoinnin ja kommunikoinnin apuvälineinä. Usein monimutkaisten asiayhteyksien, prosessien tms. kuvaaminen pelkkänä tekstinä on vaikeaa, jolloin kuvien käyttö havainnollistaa asiaa. Myös nämä tuotokset on hyvä kerätä tiimin yhteiseen hakemistoon myöhempää käyttöä varten. Ensimmäisen vaiheen tuotoksia ovat haastattelumateriaali, seinätaulu, toimintatarinat sekä Toiminnat ja tiedot -dokumentti. Haastattelumateriaaliin kuuluvat haastattelukysymykset, vastatut haastattelulomakkeet, haastattelujen koosteet sekä mahdolliset nauhat haastattelutilanteista. Haastattelukysymyksiä voidaan mahdollisesti käyttää muokattuna hyödyksi muissakin vastaavissa projekteissa. Vastatut haastattelulomakkeet ja haastattelutilanteiden nauhat ovat vaitiolovelvollisuuden suojaamia, ja ne hävitetään sopimuksen mukaisesti. Haastattelujen koosteet toimivat pohjana toimintojen ja tietojen kuvaukselle sekä seinätaululle. Toiminnat ja tiedot -dokumentissa kuvataan kohdealueen palveluverkko kokonaisuutena ja osatoiminnat sekä toiminnassa tarpeelliset tietokokonaisuudet. Lisäksi kuvataan havaittuja kehityskohteita. Dokumentti laaditaan loogisesti järjestyneeksi kokonaisuudeksi, jolloin se on helppolukuinen ja käytettävissä niin kohdealueen kuin tietotekniikankin asiantuntijoille, kehittäjille ja työntekijöille. Seinätaulussa visualisoidaan kerätyt tiedot. Seinätaulu toimii kokonaiskuvan havainnollistajana ja keskustelun apuna työpajassa ja muistilistana työpajan jälkeen. Toimintatarinoiden avulla konkretisoidaan kohdealueen toimintaa, tietoja ja tiedon tarpeita. Tarinoita voidaan käyttää myös keskustelun herättäjänä työpajassa, esimerkiksi haluttaessa havainnollistaa jotakin tiettyä tilannetta, josta halutaan enemmän tietoa. Toimintatarinoita käytetään apuna myös menetelmän toisessa vaiheessa prosessikuvauksia laadittaessa. Toisen vaiheen tuotoksia ovat prosessikuvaukset ja tietoarkkitehtuurikuvaus. Prosessikuvauksissa kuvataan toimintaan kuuluvat keskeisimmät työprosessit työprosessikaavioina ja sanallisesti. Prosessikuvauksista nähdään kunkin prosessin yksittäiset teot, prosesseissa tuotettavat ja tarvittavat tiedot sekä käytettävät tietovälineet. Kaavion kuvaustapa mahdollistaa havainnollisten kuvien käytön. Prosessikuvauksia tutkimalla voidaan nähdä niitä kohtia, joissa apuna voisi käyttää tietotekniikkaa. Prosessikuvauksista nähdään myös työtoiminnan kehittämiskohtia, jolloin työtoimintaa voidaan kehittää prosesseja kehittämällä. Tietoarkkitehtuuri kuvaa toiminnan keskeiset tietokokonaisuudet ja niiden sijainnin. Tietoarkkitehtuurikuvausta voidaan käyttää lähtökohtana ohjelmistoarkkitehtuurille (integrointi ympäristöön, komponentit ja niiden vuorovaikutus, käyttäjäryhmien suunnittelu). Kolmannessa vaiheessa tuotetaan ohjelmistosuunnittelun kohteeksi valitusta osasta käyttötapaukset ja komponenttisuunnitelma. tai komponenttikuvaus. Käyttötapaukset sopivat suoraan vaatimusmäärittelyyn. Komponenttikuvaukset ja tietoarkkitehtuurikuvaus ovat lähtötietoina ohjelmistoarkkitehtuuria hahmoteltaessa ja komponenttien suunnittelussa. 32 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

33 2.7 Yhteenveto Tässä luvussa kuvatulla menetelmällä voidaan kartoittaa kohdealueena olevan palveluverkoston nykytila ja tiedon tarpeet sekä tukea etenemistä tietoarkkitehtuurikuvauksen ja prosessikuvausten kautta komponenttisuunnitteluun. Menetelmää voidaan käyttää soveltaen ja siitä voidaan poimia käytettäväksi kussakin tilanteessa tarvittavat vaiheet tai osat. Menetelmää kehitettiin laajan ja ennestään tuntemattoman kohdealueen kartoittamiseen ja kuvaamiseen toimintalähtöisesti sekä tukemaan ohjelmistotuotantoa. Menetelmän painopiste on kohdealueen nykytilan ja tiedontarpeiden selvittämisessä ja kuvaamisessa. Tarvitaan kuitenkin jatkotutkimusta erityisesti menetelmän kolmanteen vaiheeseen. Lisäksi mukaan tulisi ottaa käyttöliittymäsuunnittelu ja käytettävyyden huomioiminen jo vaatimusmäärittelyvaiheessa. Menetelmän eri vaiheissa kohdealueen toimijat tarkastelevat omaa työtään uudesta näkökulmasta, jolloin havaitaan ohjelmistotarve tai tarve muuttaa toimintatapoja. Tulevaisuudessa menetelmää voidaan kehittää tukemaan paremmin työtoiminnan ja tietojärjestelmän yhtäaikaista tarkastelua. Kotihoito-projektissa saatujen kokemusten mukaan toimialan toimijoiden on helppo omaksua ja ymmärtää menetelmässä käytetty kuvaustapa. Tämä mahdollistaa yhteisen ymmärryksen syntymisen ohjelmistosuunnittelun ja kohdealueen ammattilasten välille. Kuvausmenetelmä mahdollistaa kokonaisuuden ja sen osien tarkastelun eri näkökulmista, esimerkiksi yhden toimijan, yhden asiakkaan, palveluketjun, yhden hallinnonalan näkökulma ja niin edelleen. Näkökulman lisäksi voidaan tarkastelun syvyyttä muunnella. Eri näkökulmista ja eri etäisyydeltä tarkastelemalla saadaan esille erilaisia asioita. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 33

34

35 3 T O I M I N TAY K S I K Ö N T I E D O N K U L U N K E H I T T Ä M I S TA R P E I D E N S E LV I T T Ä M I N E N Tässä luvussa kuvataan PlugIT-projektissa kehitettyä menetelmää tiedonkulun kehittämistarpeiden nopeaan ja kevyeen esiselvittämiseen. Menetelmä on tarkoitettu apuvälineeksi tilanteeseen, jossa halutaan kehittää toimintajärjestelmän tiedonhallintaa nimenomaan toimintayksikön näkökulmasta. Menetelmällä voidaan arvioida tiedonhallinnassa käytettyjen välineiden soveltuvuus suhteessa työn keskeisiin tavoitteisiin, kumppaneihin ja toimintakokonaisuuteen. Keskeistä on tiedonhankinnan filosofia: esiin pyritään saamaan työtä tekevien hallussa oleva, osittain ns. hiljainen tieto, ja tarkastelemaan asioita kokonaisuuden ja yhteisön kokemusten näkökulmasta. Näkökulma on toimintayksikkökeskeinen eikä niinkään organisaation toimintaan laajemmin keskittyvä. Toimintayksiköllä tarkoitetaan tässä toimipaikkaa tai työpistettä, joka on osa laajempaa toimintakokonaisuutta ja jossa työskentelee useita ihmisiä. Yksiköllä on yleensä emo- tai sisarorganisaation kanssa yhteisiä tavoitteita ja suuntaviivoja (esimerkiksi toimintaa ohjaavat säännöt tai budjetti), ja sen lisäksi omia erityisalueita. Toimintayksikkö saattaa olla melko itsenäinen tai se on keskittynyt toisenlaiseen toimintaan kuin muut osat organisaatiosta. Se saattaa mahdollisesti sijaita erillään muista toimipisteistä. Esimerkkejä tällaisista toimipisteistä eri toimialoilla ovat mm. liikeketjun myymälä, konserniyhtiön toimipaikka, sairaalan osasto, sivukirjasto ja oppilaitoksen tutkimusyksikkö. Esimerkkiprojektissamme tutkimuskohteena oli äitiysneuvolan tietojärjestelmä ja sen integraatiotarpeet suhteessa neuvolan ulkopuoliseen maailmaan. Kokemustemme perusteella menetelmä on sovellettavissa vastaaviin tarpeisiin myös muilla toimialoilla. Tämä menetelmä eroaa muista tässä julkaisussa esiteltävistä pääasiassa seuraavilla tavoilla: Kohteena on toimintayksikkö, jonka toimintaa tunnetaan jonkin verran entuudestaan. Tavoitteena on saada karkean tason yleiskuva toimintayksikön tiedonkulun kehittämiskohteista. Tietoa hankitaan mahdollisimman pienellä haastateltavien henkilöiden työpanoksella ja melko nopealla aikataululla. Tulosten perusteella voidaan nähdä, onko toimintayksikön tiedonkäsittelyssä tai tietojärjestelmässä tarvetta kehitystyölle ja minkä tyyppisiä tarpeet ovat. Menetelmä toimii esiselvityksenä jatkokehityshankkeille, esim. tietojärjestelmän hankinnalle, mikäli tarvetta sellaiseen havaitaan. Tiedot kootaan pääasiassa kahdella ryhmähaastattelulla. Ryhmä koostuu toimialan ja toimintayksikön parhaiten tuntevista asiantuntijoista eli sen parissa päivittäin työskentelevistä henkilöistä. Haastattelijoiden eli selvityksen tekijöiden roolina tapaamisissa on rajata keskustelun aiheet käsiteltävään alueeseen, tehdä tarkentavia kysymyksiä sekä kirjata tuotokset kaikkien ymmärtämään sanalliseen ja kuvalliseen muotoon. Tapaamisissa käydään läpi toimintaverkoston rakenne eli kaikki olennaiset toimintakokonaisuuteen kuuluvat tahot sekä niiden välillä käytettävät tiedonkäsittelyn ja keskinäisen viestinnän keinot. Samalla kartoitetaan niissä ilmenevät pienet ja suuret hankaluudet eli kehittämistarpeet. Sen jälkeen ryhmä yhteistoiminnallisesti pohtii ja kuvaa geneerisiä eli yleisluonteisia, toimintaa parhaalla mahdollisella tavalla tukevia ratkaisuja löydettyihin haasteisiin. Täten selvityksen tärkeimpänä tuloksena on lista toimintaa eniten vaikeuttavista käytännön ongelmista, ongelmien kuvaukset sekä suuntaviivat työtoiminnan kokonaisuuteen parhaiten soveltuvista ratkaisutyypeistä. Listan ja tarkempien kuvausten perusteella voidaan tarvittaessa hahmotella jatkotoimenpiteitä tiedonkulun ongelmien ratkomiseksi. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 35

36 Tarkastelun keskeisenä kohteena on toiminnassa tarvittava tietojärjestelmä. Kokonaisjärjestelmä koostuu useista osista, joista osa on tekniikkaa (tieto- ja viestintäteknisiä sovelluksia ja niiden käyttöön tarvittavia laitteita) ja osa perinteisiä viestinnän muotoja ja menetelmiä (paperikirjanpitoa, kokouksia, ilmoitustauluja jne.). Ilman ihmisiä toimintayksikön asiakkaita ja työntekijöitä ei luonnollisesti olisi edes tarvetta tiedon käsittelyjärjestelmille, joten tietojärjestelmätieteellisen käsityksen mukaan myös tietoa tarvitsevat, tuottavat ja käsittelevät ihmiset ovat osa organisaation tietojärjestelmää. Näin ollen myös ihmisten osaaminen ja muut käyttäjien taitoihin ja käyttötapoihin vaikuttavat seikat ovat osa tietojärjestelmää. Tässä luvussa kuvataan ensin menetelmän käyttöön liittyvät ehdot ja riippuvuudet. Sen jälkeen kuvataan menetelmän käyttö vaihe vaiheelta sekä pohditaan joitakin käytännön toteutukseen liittyviä seikkoja. Lopuksi tarkastellaan menetelmästä saatuja kokemuksia ja tulosten hyödyntämistapoja. 3.1 Tavoite Kuvattava menetelmä on tarkoitettu nopean esiselvityksen ohjenuoraksi silloin, kun tavoitteena on lisätä työssä tarvittavan tiedonhallinnan tarkoituksenmukaisuutta, sujuvuutta ja mielekkyyttä. Se on tarkoitettu sovellettavaksi tilanteisiin, joissa halutaan kehittää toimintayksikön tietojärjestelmää, mutta vielä ei tiedetä, missä kohdissa järjestelmää keskeiset ongelmat sijaitsevat tai missä järjestyksessä tai millä tavoin niitä voisi alkaa korjata. Tällainen tilanne voi tulla kyseeseen kun halutaan vähentää päällekkäistä työtä, esimerkiksi samojen tietojen kirjaamista useaan kertaan (toimipisteen tai toimintaverkon sisällä) tai halutaan parantaa useamman yksikön tai organisaation yhteistyötä. Menetelmällä hankitaan siis alkuymmärrystä tilanteessa, jossa tiedetään että jotain pitäisi parantaa, muttei tiedetä vielä tarkkaan, mikä aiheuttaa koetut hankaluudet. Tarkoituksena on esiselvittää tiedonkulun ja toiminnan ongelmakohtia ja niiden yleisyyttä sekä vakavuutta. Selvityksen jälkeen ongelmiin voidaan pureutua syvemmin tulosten osoittamalla tavalla. Kartoituksen avulla saadaan yleiskuva tiedonkulusta ja sen ongelmista sekä toimivista ja hyvistä ratkaisuista. Koska tietojärjestelmä koostuu monenlaisista osista, voidaan sitä kehittääkin usealla tavalla: lisäämällä tietotekniikkaa, hankkimalla laitteistoa, kouluttamalla ihmisiä, muilla keinoilla tai näitä yhdistelemällä. Tällaisessa tilanteessa ei ole aina viisasta sitoutua pitkään ja kalliiseen selvitys- tai tutkimustilanteeseen - voihan olla ettei ongelmien ratkaisemiseen tarvitakaan tekniikkaa vaan pieniä muutoksia toimintatavoissa. Toisaalta, jos voidaan osoittaa, että uuden tieto- tai viestintätekniikan hankkiminen tai muutokset olemassa olevassa tekniikassa parantaisivat kokonaisuutta, voidaan saatuja tuloksia käyttää vaatimusmäärittelyn pohjana. Menetelmällä ei kuitenkaan suoraan tähdätä vaatimus- tai rajapintamäärittelyjen tuottamiseen, vaan vaikkapa integraatiotarpeen osoittamiseen. 3.2 Edellytykset menetelmän käytölle Tilannetta tai kohdetta koskevat edellytykset Menetelmä soveltuu käytettäväksi silloin, kun kiinnostuksen ja mahdollisen kehittämistyön kohteena on useamman henkilön tai tahon muodostama kokonaisuus, jossa on havaittu jotain tiedonkäsittelyyn tai -hallintaan liittyviä hankaluuksia. Ongelmien ei tarvitse olla vakavia; pääasia on, että sinänsä toimivassa järjestelmässä on havaittu jotain kehittämisen tarvetta. Tarkasteltava yksikkö liittyy toimintajärjestelmään, jolla on yhteinen toiminnan kohde ja tavoite, esim. yhteinen asiakas ja 36 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

37 hänelle tuotettava palvelu tai tuote. Kohdealueella käsitellään yhteistä tietoa ja käytössä voi olla joitakin tietoteknisiä välineitä. Jotkin näistä välineistä saattavat olla ainakin osittaisessa yhteiskäytössä. Yhteistä tiedonhallintaa ja -käsittelyä vaativia asioita voivat olla esimerkiksi yhteisten asiakkaiden perustiedot: henkilötiedot ja yhteystiedot, asiakkuuden hoitoon liittyvät tiedot: asiakashistoriaan liittyvät tapahtumat ja niiden väliset suhteet, asiakkuuden kesto, sopimukset, asiakkaalle tuotetut palvelut, palveluiden toimittajat, erityisvaatimukset tai -toiveet, jatkosuunnitelmat jne., yhteisten työntekijöiden ja muiden toimijoiden tiedot, tyypillisesti yhteystiedot ja muut yhteydenottoihin liittyvät tiedot, tiedot työsuhteista, tehtävänkuvaukset jne., tiedot toimintaympäristön olosuhteista: tukitoiminnoista, toimintaa säätelevästä yhteiskunnallisesta tai muusta ohjeistuksesta kuten lainsäädännöstä jne., tarjouspyynnöt, tarjoukset, tilaukset, toimitustiedot ja muut vastaavat dokumentit, tavaranhallinta, varastokirjanpito, markkinointi, mainonta sekä toimintaraportit, koosteet tai tilastot. Useimmat edellä mainituista sisältävät tietoja, joita syntyy ajan kuluessa ja pitkin toiminnan verkostoa ja joita keräävät ja tallentavat monet eri henkilöt. Melko usein niiden kerääminen on päällekkäistä, ts. samoja tietoja on koottu useisiin paikkoihin, eri muodoissa ja erilaisen käyttäjäkunnan hyödynnettäväksi. Toisinaan se johtuu siitä, ettei kyseisen tiedon tiedetä jo olevan olemassa. Toisinaan taas tiedoista tiedetään, missä ne sijaitsevat, mutta toimintajärjestelmän osatekijät, esimerkiksi toimintaa ohjaavat säännöt tai käytössä olevien välineiden puutteellisuus, estävät tietojen järkevän hyödyntämisen. Mielenkiinnon kohteena oleva tietojärjestelmäkokonaisuus koostuu useista rinnakkain käytettävistä ja ilmeisesti ainakin osittain yhteensopimattomista tiedonkäsittelyn välineistä. Toiminnan kenttä tunnetaan kohtalaisen hyvin: siitä on saatettu tehdä aiemmin vaikkapa tietoteknisiin uudistuksiin liittyviä selvityksiä, kuten prosessimallinnusta tai sidosryhmäanalyysi. Aiemman tiedon perusteella esimerkiksi sidosryhmät ja toimintatavat ovat siis pääosin selvillä. Kyseessä ei siis ole niin kutsuttu harmaa alue, selkiytymätön toiminnan kenttä, jonka selvitystyötä on kuvattu luvussa 2. Myös yksittäisten sovellusten kehittämiseen tai yksittäisiin käyttäjiin kohdistuvaan käyttöliittymäja käytettävyystutkimukseen on omat menetelmänsä (esimerkki luvussa 4). Selvitykseen käytettävissä olevat resurssit kuten aika, varat, henkilöt ja heidän osaamisensa ovat usein selvityksen käynnistämisen kynnyskysymys. Tavoitteena tämän menetelmän kehittämisessä on ollut se, ettei mikään edellä mainituista saisi muodostua suureksi haasteeksi. Nopealle ja kevyelle esiselvitysmenetelmälle on tarve monenlaisissa tilanteissa, eikä vähiten silloin kun toimitaan usean organisaation tai intressiryhmän risteyskohdassa, ei kenenkään -maalla. Keskeistä menetelmässä on se, että saatavissa tuloksissa tehdään näkyväksi yleiskuva toimintayksikön toiminnasta ja tiedonkulusta. Tätä yleiskuvaa tarkastelemalla saatetaan löytää ratkaisuja toimintayksikön tiedonkulun ongelmiin. Toisaalta saatetaan myös huomata, ettei jokin ongelma oikeasti olekaan niin vakava kuin alun perin on luultu: asia on saatettu ymmärtää väärin tai on jäänyt huomaamatta hyvin yksinkertainen käytännön ratkaisu. Menetelmä antaa toimintayksikölle itselleen välineitä, joilla tarkastella omaa toimintaa ja tiedonkulkua kokonaisuutena ja ympäröivä verkosto huomioon ottaen. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 37

38 3.2.2 Tilaajaa koskevat edellytykset Selvityksen tilaavalla taholla on mielenkiinto kehittää työtoimintaa tavalla tai toisella. Kehittämisen mittapuuna on kaikilla luonnollisesti omaan toimintaan saatava etu. Esiselvitysmenetelmämme pyrkii palvelemaan tätä tavoitetta unohtamatta toiminnan kokonaisuutta. Menetelmän hyödyntäjiä eli tehtävän selvitystyön tilaajia voivat olla pääasiassa kolmenlaiset tahot, jotka asettavat erilaisia tavoitteita selvitykselle (taulukko 1) : yritykset, jotka tuottavat tieto- ja viestintäteknisiä välineitä ja palveluratkaisuja, toimintakokonaisuuteen kuuluvan yhden tai useamman organisaation johto tai toimintakokonaisuuden työtoimintaan suoraan osallistuva taho. Taulukko 1. Erilaiset tilaajatahot ja selvityksen tavoitteet heidän kannaltaan Tilaajataho Selvityksen tavoite Tilaaja on tietotekniikkaa tuottava tai tietotekniikan alan tuot- mahdolliset integraatiotarpeet muihin ohjelmistoihin. Halutaan selvittää toimintayksikössä jo käytettävän ohjelmiston teita tai konsultointia myyvä yrityhittämiseen. Halutaan saada aineistoa jo käytettävän tuotteen muunlaiseen ke- Halutaan suorittaa uuden ohjelmistotuotteen tarpeellisuuden tai toteutettavuuden esiselvitys (ns. feasibity study). Tilaaja on yksityisiä tai julkisia Halutaan korjata tiedonkulussa havaittuja ongelmia. palveluita tarjoava organisaatio, Asiakkaiden ja muiden yhteistyökumppaneiden tyytyväisyyden esim. yhtiö, kunta tai jokin niiden toimiala Halutaan varustautua tulevaisuudessa nähtäviin muutoksiin toi- lisääminen. mintaympäristössä, esim. asiakaskunnan muutos, henkilöstön saatavuus, muutokset toimintaa ohjaavissa säännöissä jne. Halutaan varmistaa, että jo tehdyt toimenpiteet (hankinnat, muutokset, koulutukset) ovat vieneet kehitystä haluttuun suuntaan. (Halutaan lisätä kannattavuutta tai saavuttaa kustannussäästöjä mm. järkeistämällä hankintoja). Tilaaja on joukko toimintaverkostoon osallistuvia palveluntarjoajia yhdessä: kuntainliitto, saman toimialan yrityksiä tai samalla alueella toimivia yrityksiä, kolmannen sektorin järjestöjen rypäs jne. Tilaaja on työntekijöiden edustaja, esim. paikallisen työyksikön henkilöstö, saman asiakkaan parissa toimivat eri alojen ammattilaiset, ammatillinen järjestö, ammattiliitto jne. Kuten edellä. Lisäksi: yhteistoiminnan kehittäminen paremman tiedonhallinnan keinoin. Yhteisten tietohallintoa koskevien toimenpiteiden aikatauluttaminen. Työn, toimialan ja/tai ammatin kehittäminen. Kehittämistarpeiden ja puutteiden näkyviksi tekeminen. Koulutustarpeiden kartoittaminen. Työssä jaksamisen ja ammatin houkuttelevuuden edistäminen. Asiakastyytyväisyyden ja työn mielekkyyden lisääminen. Tuloksia voidaan käyttää perusteluina toiminnan järjestelyyn toisella tavalla. Uudelleenjärjestely voi tapahtua toimintakokonaisuuden sisällä tai verkoston kesken. Selvityksellä voidaan luoda pohjaa tai perusteita laitteisto- tai ohjelmistohankintojen jatkoselvityksille, ohjelmistointegraatiolle tai uusille ohjelmistohankinnoille osoitettaville vaatimuksille. Lisäksi menetelmää voidaan käyttää osana jo tehtyjen muutosten tai hankintojen toimivuuden arviointia. 38 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

39 3.2.3 Toteuttajaa koskevat edellytykset Toteuttajalla tarkoitetaan tässä sitä henkilöä tai henkilöitä, jotka suorittavat varsinaisen selvitystyön. Jo menetelmää kehitettäessä lähdettiin perusvaatimuksesta, ettei sen käyttö vaadi toteuttajiltaan laajaa osaamista tai pitkää kokemusta. Mikään tietty koulutus tai toiminnan teorian syvällinen tuntemus ei siis ole edellytys selvityksen toteuttamiseen. Toteuttaja voi olla tietotekniikka- tai tietojärjestelmäalan asiantuntija. Toisaalta hän saattaa olla myös kyseessä olevalla kohdealueella tai sen lähettyvillä työskentelevä henkilö eli toimialan (ainakin kohtalainen) tuntija. Ehkä keskeisin vaatimus on ymmärrys siitä, että toimintaa on tarkoitus tarkastella ja tukea yhtä yksittäistä toimenkuvaa tai tehtävää laajempana kokonaisuutena. Aiempi kokemus projektityöskentelystä ja jostakin tietojärjestelmähankkeesta on myös onnistumisen edellytys. Projektikokemukseksi riittää osallistuminen, ei johto- tai koordinaatiotehtävissä toimiminen. Tarvittava tai sopiva kohdealueen tuntemuksen taso on vaikea määrittää täsmällisesti. Nyrkkisääntönä voidaan sanoa, että toimialaa olisi hyvä tuntea sen verran, että tietää, mistä lähteä etsimään aineistoja, sidosryhmiä ja yhdyshenkilöitä. Koska menetelmän on tarkoitus olla nopea, ei alkuselvitysvaiheeseen saisi kulua kohtuuttoman paljon aikaa, kuten helposti käy jos alue on tekijälle aivan vieras. Hiukan ulkopuolinen asema voi olla monessa suhteessa etu: selvityksen tekijän suhtautuminen kohdealueeseen voi olla neutraalimpi kuin sen parissa jatkuvasti arkityötään tekevän. Myös haastateltavien hankinta ja itse haastattelutilanteet saattavat olla helpompia, kun tekijä on osallistujille hiukan vieras. Ryhmäkeskusteluissa on mm. hyödyllistä pystyä esittämään ns. tyhmiä kysymyksiä, ja kynnys niiden tekemiseen voi olla korkea, jos toteuttaja uskoo tuntevansa kohdealueen syvällisesti tai jos hän arastelee ryhmän naurunalaiseksi joutumista. Puolueettomuus ja riippumattomuus voi olla jopa onnistumisen ehto, mikäli kohdealueella on paljon ristiriitoja. Toteutusvaiheessa pitää olla koko ajan mukana luonnollisesti vähintään yksi selvityksestä vastaava henkilö. Toteuttajia voi kuitenkin olla useampiakin, mikäli sellaiseen on resursseista riippuen mahdollisuus. Selvitystyöhön osallistuva ryhmä voi järjestää tapaamisia paljon joustavammin kuin yksi yksittäinen toteuttaja, varsinkin jos selvityksen tekoon ei ole käytettävissä koko päivittäistä työaikaa. Lisäksi ryhmähaastattelut ovat osoittautuneet hedelmällisemmiksi jos keskusteluun osallistujien lukumäärää voidaan säätää optimaaliseksi. Edellisiä vielä tärkeämpi syy tekijäkaartin laajentamiseen on se, että valitsemalla erilaisen koulutus- ja kokemustaustan omaavia ihmisiä saadaan luontevasti mukaan erilaisia näkökulmia työtoimintaan ja tiedonhallintaan. Työssä voi siis olla päätutkijan lisäksi mukana vaikkapa kolmen - viiden hengen löyhä ryhmä. Esimerkkiprojektissa aineiston keruuseen osallistui vaihtelevasti noin kaksi - viisi henkilöä, joilla oli tietojenkäsittelytieteen, ohjelmistotekniikan ja terveydenhuollon kokemustaustaa. Toimialan osaaja ja tietotekniikan tuntija ovat työparina hyvä yhdistelmä varsinkin jos jo alkuvaiheessa tiedetään, että ratkaisu tiedonkulun ongelmiin saattaa olla ohjelmistotuote. 3.3 Menetelmän kuvaus vaiheittain Selvitys on jaettavissa kolmeen vaiheeseen: alustavaan tiedonkeruun ja käytännön asioista sopimisen vaiheeseen, varsinaiseen ryhmähaastatteluin suoritettavaan aineistonkeruuvaiheeseen, sekä tuotosten käsittelemiseen ja jatkohyödyntämisen mahdollistavaan vaiheeseen (kuva 1). Tässä kappaleessa kuvataan menetelmän toteutuksen periaatteet vaiheittain. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 39

40 Vaihe 1 Henkilöiden valinta ja kutsuminen Kirjat, opinnäytteet, sevitykset, raportit, Tutustuminen tutustumiskäynti kohteeseen ActAD-malli Käytännön järjestelyt - tilan varaaminen - opasteet - tarvikkeet Esimateriaalin valmistaminen - kysymyksiä - seinätauluelementit Suunnittelu ja esitietojen kerääminen - Alkuymmärrys kohteen toiminnasta - Haastattelujen esimateriaali: -aikataulut, tilavaraus, ym. -kysymykset -apuvälineet (nauhuri, jatkojohto, kynät, seinätaulu yms.) Vaihe 2 Tarkennettevat asiat Ensimmäinen ryhmätapaaminen Aineiston kerääminen Listat - toimijoista ja sidosryhmistä - tiedonkäsittely ja viestintä Toinen ryhmätapaaminen Vaihe 3 Tilaajan / kohdealueen tavoitteet Perusteet - luokitteluun - ryhmittelyyn - valintaan - priorisointiin Aineiston käsittely Tarkennettu luettelo, jossa - yhteydet ja yhteydenpitovälineet - ongelmat ja toimivuudet yhteyksissä - ratkaisuehdotuksia Tulosten jatkohyödyntämismahdollisuuksien tutkiminen Kuva 1. Menetelmän vaiheet tarkennettuna Vaihe 1: Suunnittelu ja esiselvitys Tässä kappaleessa kerrotaan, mitä tapahtuu ennen kuin varsinainen tiedonkeruu alkaa. Alussa tapahtuva suunnittelu- ja esitietojen keräysvaihe on aivan kuten minkä tahansa projektin aloitusvaihe. Sen aikana tapahtuu mm. tavoitteiden, aikataulun, velvollisuuksien ja vastuiden selkiyttäminen TUTUSTUMINEN KOHTEESEEN Tutkimuskohteeseen voi ja usein kannattaakin tutustua konkreettisesti paikan päällä käymällä. Tutustumiskäynti voi olla tärkeä kohdealueen asiantuntijoille eli tuleville haastateltaville. Tutustumisen aikana voidaan epävirallisissa olosuhteissa tutustua toisiinsa sekä antaa arvokasta tietoa selvityksen tavoitteista. Kun kasvot ovat tulleet tutuiksi jo ennen varsinaiseen työhön ryhtymistä, ovat haastattelutkin tehokkaampia tiedonkeruun välineitä. Lisäksi tutkijat voivat paikan päällä käymällä havaita myöhemmin arvokkaaksi osoittautuvia seikkoja, varsinkin jos kohdealue ei ole ennestään 40 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

41 tuttu. Kenties tärkeintä on kuitenkin saavuttaa osallistujien luottamus ja sitä kautta sitouttaa heidät osallistumaan täysipainoisesti selvitystyöhön. Selvityksen ensivaiheessa kartoitetaan se keskeisten toimijoiden verkosto, johon toimintakokonaisuus sijoittuu. Tahoja ja niiden välisiä suhteita selvitetään ja jäsennetään. Tässä vaiheessa voidaan käyttää hyväksi mm. seuraavia: kohdetta kuvaavaa kirjallisuutta kuten opinnäytteitä, tutkimuksia, kehittämishankkeita, katsauksia, raportteja ja muita aihetta sivuavia tekstejä, toimijoiden kanssa käytyjä epävirallisia keskusteluja (tai vaikkapa haastattelua, mikäli resurssit sen sallivat), toiminnassa tuotettavien tuotteita tai palveluita käyttävien asiakkaiden kanssa keskustelemista tutustumista työtiloihin ja -välineisiin, erityisesti tiedonkäsittelyyn liittyviin, työtoiminnan havainnointia, On huomattava, ettei tarkoitus ole hankkia alueen syvällistä ymmärtämistä vaan kevyesti riittävää alkuymmärrystä. Tähän vaiheeseen ei kannata panna suuria voimavaroja tai menetelmä lakkaa olemasta nopea ja kevyt. Tarkoitus ei siis ole saada täydellistä ja kattavaa kuvaa toiminnasta ja kaikesta siihen liittyvästä. Haastatteluissa on sitten tilaisuus saada tarkennuksia tietoihinsa, mikäli se ylipäätään tuntuu tuossa vaiheessa enää tarpeelliselta. Menetelmässä on olennaista, että työtä tekevät itse tuovat esille työhönsä liittyviä asioita ja kuvaavat ne sellaisina kuin itse kokevat. Jotkut tietojärjestelmä- ja työntutkimuksen asiantuntijat pitävät havainnointia neutraaleimpana ja sopivimpana tiedon hankinnan tapana. Tämä onkin monissa tilanteissa totta. Yhden yksilön tai muunlaisen yksittäisen kohteen havainnoinnilla saadaan kuitenkin tietoa vain kyseessä olevan yksilön työstä ja toiminnasta sekä siitä, miltä nykyiset toimintatavat näyttävät. Näkemättä jäävät syyt siihen, miksi toimitaan niin kuin toimitaan sekä toimintatapojen vaikutukset myöhempiin tapahtumiin ja muihin toimintaan osallistuvien henkilöiden työhön. Työtoimintaa ja tietojärjestelmää laajempana kokonaisuutena tarkasteltaessa yksittäisen kohteen havainnointi ei yksinään käytettynä tuota riittävästi tietoa. Havainnointia voidaan kuitenkin varsin hyvin käyttää tässäkin selvitysmallissa tiedonhankinnan yhtenä tukimenetelmänä, varsinkin alun tutustumisvaiheessa. Yhteenvetona voidaan todeta, että kohteeseen tutustumisen perusteella on syntynyt alkuymmärrys siitä mitä kohdealueella tehdään, mitkä tahot toimintaan osallistuvat eli on tunnistettu alueeseen liittyvät osapuolet ja minkä tyyppisiä tietoja toimintaan liittyy ja miten niitä tällä hetkellä käsitellään AINEISTONHANKINNAN VALMISTELU Toimintakokonaisuuden ja -verkoston laajuudesta riippuen päätetään kuinka monta haastateltavaa tarvitaan ja mitä rooleja heidän pitää edustaa. Osallistujien määrää voi rajoittaa muun muassa eri sidosryhmien, johtoportaan tai työtä tekevien henkilöiden halukkuus/haluttomuus osallistua selvitykseen, työtilanteiden kiireisyys jne. Vaikka haastattelulla on virallinen tavoite, on itse haastattelutilanteesta hyvä yrittää luoda mahdollisimman epävirallinen. Ei kannata kutsua niin paljon ihmisiä, että joudutaan virallisten kokousten tapaan pyytämään tai jakamaan puheenvuoroja jonoiksi asti. Sopiva määrä yhdessä tapaamisessa lienee noin 3-7 osallistujaa. Jos kohderyhmä on kovin pieni, voi olla hyvä lisätä keskusteluun osallistuvien määrää lisäämällä tutkijoita, kuitenkin niin, että haastateltavia on enemmän kuin yksi. Yhtä toimijaa haastattelemalla saadaan vain yhden toimijan näkökulma ja toimintakokonaisuuden näkökulma jää puutteelliseksi. Lisäksi, jos ryhmätapaamisessa on useita tutkijoita ja vain yksi toimija, tilanteeseen tulee helposti kuulustelun maku eikä haastateltava luultavasti tunne oloaan kyllin turvalliseksi. Ryhmää koostaessa on hyödyllistä ottaa huomioon myös tietynlainen tasapuoli- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 41

42 suus: mikäli mukana on toimintaan vain hyvin kaukaisella tavalla liittyviä henkilöitä, he eivät mitä luultavimmin pysty osallistumaan keskusteluun täysipainoisesti ja tuntevat roolinsa turhaksi. Tapaamisten tulee olla kyllin pitkiä, että aihealue ehditään käydä läpi, ja toisaalta kyllin lyhyitä, että niissä keskitytään vain olennaiseen. Lyhyt tapaamisaika on myös usein helpompi järjestää kuin koko päivän kestävä työpaja. Ellei kohdealue ole selvityksen tekijöille ennestään kovin tuttu, kannattaa kysyä alaa tuntevilta mitkä ajat päivästä tai viikosta ovat edullisimpia (tai kerrassaan mahdottomia). Suositeltava tapaamiseen käytettävä aika on kaksi - kolme tuntia kerrallaan. Esimerkkiprojektissamme tapaamiset kestivät noin 2,5 tuntia. Kahden tapaamisen välillä kannattaa pitää ajatusten hauduttamiseksi muutama päivä väliä. Tauon ei kuitenkaan tulisi olla mielellään yli kahta viikkoa. Pidemmän tauon aikana ideoilla on taipumus unohtua ja asioita joudutaan työstämään uudelleen. Kumpaankin tapaamiseen olisi hyvä saada mukaan samat henkilöt, vaikka menetelmä ei välttämättä sitä edellytäkään. Osallistujista voi osa vaihtua jos ryhmän koko sen sallii. Tällöin on huolehdittava, että kesken prosessin mukaan tulleet saavat tarvittavat lähtötiedot. Tämä luonnollisesti aina lisää selvitykseen käytettävää työmäärää, mutta voi olla joskus ainoa mahdollisuus. Henkilöiden tulee edustaa mahdollisimman kattavasti kiinnostuksen kohteena olevaa kokonaisuutta. Mikäli toimintakokonaisuudesta on olemassa useammanlaisia versioita tai ilmentymiä (ja yleensä on), voidaan koota useita ryhmiä. Varianssia voivat luoda esim. toimintayksiköiden koko, henkilöstön määrä ja ominaisuudet, toimintayksiköiden sijainti tai niissä käytettyjen tietoteknisten sovellusten ominaisuudet. Varianssin lisääntyessä ryhmien lukumäärän lisääminen on suositeltavampaa kuin ryhmäkoon kasvattaminen, koska kohtuullisen pienessä ryhmässä asioista on helpompi saada yhteisymmärrys. Lisäksi keskustelun vetäjän on helpompi hallita tilannetta. Mikäli selvitys tehdään ns. oman työn ohessa, voi olla hyvä suunnitella kutsuttavia muutama enemmän kuin todella tarvitaan (jottei tule hätä kun joku jää pois - ja yleensä joku aina jää). Toinen mahdollisuus on pyytää nimeämään osallistujalle varahenkilö KÄYTÄNNÖN JÄRJESTELYT Kun osallistujat ovat selvillä, heille kannattaa lähettää kirjallinen kutsu ja tiedote tapahtuman luonteesta ja siitä, miten heidän tulee valmistautua. Niin kannattaa tehdä vaikka osallistujaan käytäisiin tutustumassakin hänen työpaikallaan. Kirjallisesta tiedotteesta osallistuja voi aina tarkistaa yksityiskohdat ja tapaamisiin osallistuminen on varmempaa. Sähköposti on nykyään paras keino lähettää tietoa monelle henkilölle yhtä aikaa. On kuitenkin muistettava, etteivät kaikki käytä sähköpostia joka päivä tai lainkaan. Tämän vuoksi kannattaa hankkia myös henkilöiden puhelinnumerot ja/tai käyntiosoitteet, ja varmistaa osallistuminen esimerkiksi puhelimitse. Haastatteluihin käytettävä paikka pitäisi olla luonteeltaan mahdollisimman neutraali. Sen tulisi olla mahdollisimman lähellä osallistujia, jottei matkustusaika muodostu pitkäksi. Varsinainen työn tekopaikkakin sopii tapaamispaikaksi, mikäli se on kyllin rauhallinen, keskustelu ei häiritse toimintaa eikä toisaalta työtoiminta keskeytä haastattelua. Ryhmätapaamiset nauhoitetaan ääninauhalle, jotta selvityksen tekijä(t) voi(vat) keskittyä täysin keskustelun seuraamiseen ja ohjaamiseen eikä aikaa kulu muistiinpanojen tekoon. Toinen tästä saatava hyöty on mahdollisuus tarkistaa jälkeenpäin yksityiskohdat ja vaikkapa ilmausten tarkat sanamuodot. Mikäli on oletettavissa, että toimijat osallistuvat aktiivisesti tietojen kokoamiseen eli piirtämiseen, voi tilaisuuden myös videoida. Toisaalta on huomioitava, että videokameralla on ihmisiä jähmettävä vaikutus. Pääasia on, ettei käytettävissä oleva vähä aika kulu muistiinpanojen kirjaamiseen, vaan jokainen voi osallistua täysipainoisesti keskusteluun. Mikä tallennusmuoto on kätevin haastattelutilanteissa ja toisaalta tuotoksia jälkeenpäin purettaessa? Esimerkkiprojektissa koekäytettiin kahta erilaista laitetta: videokameraa (josta hyödynnettiin lähinnä ääniraitaa) sekä digitaalista sanelukonetta. Näistä sanelukone osoittautui paremmaksi. Sillä tallennettu äänitiedosto oli helposti tallennettavissa tietokoneen kovalevylle, josta sitä pys- 42 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

43 tyi kuuntelemaan kaiuttimilla tai kuulokkeilla. Tiedoston käsittelyä ja läpikäyntiä helpotti sanelulaitteen mukana tullut äänenkäsittelyohjelma. Tällä tavoin tallennetuista tiedostoista pystyttiin myös vaivattomasti ottamaan varmuuskopioita tai valitsemaan ääninäytteitä vaikkapa jatkotyöpajan aineistoksi. Tapaamisiin on varattava mukaan: ns. fläppitaulu tai vastaavan kokoinen paperi seinätauluksi tai pöydällä pidettäväksi, selkeät ja yksiselitteiset symbolit tiedonkulkua kuvaamaan (katso kuva 2) taulun kiinnittämiseen tarvittavat teipit, sinitarrat tms. tallennusvälineet: ääninauhuri, videokamera, sanelukone tms. sekä tarvittava määrä sopivia kasetteja, muistikortteja tms. tussikyniä, F A X F A X F A X F A X F A X F A X Kuva 2. Esimerkkejä seinätaulussa käytettävistä symboleista: kokous tai tapaaminen, puhelin, perinteinen kirje, sähköposti, paperilomake, tietokonesovellus ja faksi Tapaamisia sovittaessa tulee varata ennen varsinaisia haastatteluita kylliksi aikaa tilojen ja tarvikkeiden järjestelyyn. Jos mennään täysin vieraisiin tiloihin, aikaa tulee luonnollisesti olla tuttua paikkaa enemmän. Vieraaseen paikkaan mennessä on hyvä varautua myös tukimateriaalilla, kuten jatkojohdolla. Olosuhteisiin tutustuminen ennakkoon on yleensä ottaen hyvä tapa vähentää teknisiä ongelmia - mutta ei tietenkään täysin poista niitä. Tapaamisen alkuun on hyvä järjestää pieni kahvi- tai muu vastaavaa tarjoilu, varsinkin jos osallistujat ovat toisilleen kovin vieraita. Monet suomalaiset ovat melko ujoja tuomaan mielipiteitään julki ventovieraiden seurassa. Kahvinjuonti ja siihen liittyvä kevyt jutustelu auttaa yleensä ihmisiä rentoutumaan ja niin sanotusti rikkoo jäätä Vaihe 2: Aineiston hankkiminen ryhmätapaamisilla ENSIMMÄINEN TAPAAMINEN Ensimmäisessä tapaamisessa käydään läpi tarkastelun kohteena olevan toimintakokonaisuuden keinot välittää tietoa verkostonsa kanssa sekä kartoitetaan niissä ilmenevät erikokoiset ongelmat ja hankaluudet. Ensimmäisenä osallistujille selvitetään, mikä on selvityksen tavoite, mistä selvitys on saanut alkunsa ja millaista hyötyä selvityksestä aiotaan saada aikaan. Heille kerrotaan, mikä heidän tehtä- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 43

44 vänsä on eli millaista osallistumista ja panosta heiltä konkreettisesti odotetaan. Alusta lähtien ja tarvittaessa läpi koko prosessin teroitetaan kaikkien mieliin, ettei ole olemassa ns. oikeita vastauksia. Osallistujat on kutsuttu siksi että he itse ovat oman työnsä parhaita asiantuntijoita ja on olennaista saada selville, miten he itse kokevat jokapäiväiset työolosuhteensa ja millaisia ideoita heillä itsellään on työnsä kehittämisestä. Osallistujia pyydetään kertomaan, mihin henkilöihin ja tahoihin he ovat työssään yhteydessä ja miten yhteydenpito tai muu tiedon välittäminen tapahtuu. Näin käydään läpi kaikki työssä tarvittavat tiedonkäsittelyn välineet, tiedonsiirtomuodot ja tiedonsiirrossa ja viestinnässä sovellettavat käytännöt. Näihin kuuluvat sekä tietotekniikkaan perustuvat että perinteiset, kuten erilaiset lomakkeet, puhelin. Jokaisen välineen ja käytännön kohdalla pyydetään kertomaan, onko se toimiva ratkaisu vai ei ja mikä siitä tekee sellaisen. Mikäli kyseessä oleva tilanne ei ole kaikille osallistujille (mukaan luettuna selvityksen tekijät) tuttu, pyydetään selventämään ja antamaan käytännön esimerkki. Kaiken kaikkiaan pyritään saamaan aikaan vapautunut ja tiedonhaluinen ilmapiiri. Kaikkia osallistujia rohkaistaan ehdottamaan asioita ja kysymään epäselvistä seikoista. Hyviin tuloksiin voidaan päästä vain jos ilmapiiri sallii ns. tyhmien kysymysten tekemisen. On tärkeää, että kaikki eri tahoilta tulevat ihmiset ymmärtävät asian jokseenkin samalla tavalla. Tämä ei suinkaan tarkoita sitä, että tiedonkäsittelyn menetelmistä pitäisi saada aikaan yksimielisyys. Sekä nykytilaa että parannusehdotuksia läpikäytäessä voi ilmetä, että sama tieto tai menettelytapa on lähettäjälle mitä tarkoituksenmukaisin ja vastaanottajalle äärettömän työläs tai turha. Kaikki tämä tulee vain kirjata ylös. Myös hyvät ja toimivat käytännöt pyydetään nimeämään. Tämä on tärkeää sen takia että osataan olla muuttamatta sellaista, mikä jo toimii hyvin. Kuva 3. Haastattelutilanne. Osallistujat on ryhmitelty koostettavan piirustuksen ympärille. Esimerkkiselvityksen tapaamiset pidettiin neuvoloiden toimitiloissa (vastaanotto- tai neuvotteluhuoneissa) ja nauhoitettiin sekä ääni- että kuvanauhalle. Kuva Marko Sormunen Tiedot kirjataan suurelle paperille, joka sijoitetaan fläppitaululle, seinälle tai pöydälle (kuvat 3 ja 4). Sijoituspaikka valitaan ryhmän koosta ja käytössä olevasta tilasta mukaan. Tärkeintä on, että kuva on vaivatta kaikkien nähtävillä. Kuvan keskelle on ajan säästämiseksi valmiiksi hahmoteltu toimintakokonaisuuteen osallistuvia tahoja. Selvityksen keskeisenä kohteena oleva yksikkö tai organisaatio kannattaa sijoittaa kuvan keskelle. Ympärille on jätetty tilaa sidosryhmien nimeämiseen. Jokainen uusi sidosryhmä kuvataan paperille sovitulla tavalla, esim. laatikkona. Tahojen välille piirretään viivat merkitsemään yhteyksiä. Yhteyksille annetaan ominaisuuksia (esiintyvyys, väline, toimivuus) liittämällä niihin yksinkertaisia kuva- ja värisymboleita. Käytettävää tiedonsiirron välinettä ja tiedonsiirtomuotoa kuvaamaan on etukäteen tulostettu symboleita (kuva 2). Symbolien tulee olla mahdollisimman yksinkertaisia. 44 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

45 Symboli kiinnitetään kyseessä olevan tietoyhteyden päälle esim. teipinpalalla. Yleisesti ymmärretty ja siksi kätevä menettely on ilmaista ongelmallista tiedonkulkua punaisella ja ongelmatonta vihreällä. Esimerkkitutkimuksessa käytimme tähän tarkoitukseen itseliimautuvia värillisiä muistilappuja. Kuva 4. Esimerkki ensimmäisessä tapaamisessa syntyvästä yhteyskartasta. Toimintaverkosto on kuvattu toiminnan keskeisen kohteen, tässä tapauksessa asiakkaan, ympärille. Tiedon käsittelykeinot ja - menetelmät on kuvattu kuvasymbolein. Tiedonkulun vahvuuksia ja heikkouksia, kehittämistarpeita ja lisätietoja on kirjattu lapuille asianmukaisiin kohtiin. Kuva Marko Sormunen. Näin syntyvä kuva toimii tilaisuuden aikana keskustelua ohjaavana ja läpikäydyistä asioista muistuttavana karttana. Se auttaa jäsentämään joskus monimutkaistakin kokonaisuutta: minne kaikkialle yhteyksiä otetaan ja missä osa-alueilla näyttää olevan eniten parantamisen tarvetta. Kuvaa tai mieluummin siitä piirrettyä kopiota hyödynnetään myös seuraavassa tapaamisessa palauttamaan asiat osallistujien mieleen. Ryhmän koosta ja muista olosuhteista riippuen kuvan voi koota joko keskustelua johtava henkilö, toinen selvityksen tekijä, tai vaikka koko ryhmä yhdessä. Olennaista on, että kaikki tiedot kirjataan ja niitä käydään tarvittaessa suullisesti läpi esimerkein. Selvennyksiä koottaessa on hyödyllistä jos tutkimustiimin jäsenet, luontevimmin asiaa vähiten tuntevat, pyytävät tarkennuksia tarpeen mukaan. Näin pyritään varmistamaan, ettei mitään oteta itsestäänselvyytenä. Tutkijoiden tarjoama esimerkki helpottaa myös osallistujien rohkeutta tehdä tarkentavia kysymyksiä. Ensimmäisen tapaamisen aikana saadaan aikaan taulukossa 2 luetellut tuotokset. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 45

46 Taulukko 2. Ensimmäisestä tapaamisesta saatavat tuotokset Tuotos Osallistujille on selvää mitä heiltä odotetaan ja he ovat motivoituneet osallistumaan Esiselvitysvaiheessa kerätyt tiedot on varmistettu Lista keskeisistä toimintaan osallistuvista henkilöistä ja sidosryhmistä Lista käytössä olevista tiedonkäsittelyn ja viestinnän menetelmistä Lista ongelmista Lista toimivista käytännöistä Muoto (täysipainoinen osallistuminen) Kysytään suullisesti Kirjattu ja nimetty kuvioon organisaatiolaatikoina ja niiden välisinä yhteyksinä Kirjattu kuvioon symboleilla, tarkennukset kysytty ja tallentuneet nauhalle Sijainti merkitty kyseisen yhteyden kohdalle. Tarvittaessa kysytty esimerkkikuvausta. Esim. en pidä. kuten yllä Nauhoitukset kannattaa purkaa mahdollisimman pian, mieluiten haastattelupäivänä. Nauhat kuunnellaan läpi ja niistä keskustellut asiat kirjataan ylös ja yhdistetään haastattelutilanteessa tehtyihin muistiinpanoihin. Erittäin havainnollisia keskustelunosia voidaan siirtää kirjalliseen muotoon sanasta sanaan ja käyttää raportissa sellaisenaan selventämään ongelmia tai tarpeita. Pääasiassa nauhoilta kuitenkin poimitaan vain asiasisältö. Se lajitellaan ennalta sovitun luokittelun mukaan, esim. tiedonkulun heikkouksiin ja vahvuuksiin tai käytettyjen välineiden mukaan. Tiivistettyjä luetteloita esim. verkostoon kuuluvista sidosryhmistä, tiedonkäsittelyn välineistä ja tiedonkulun ongelmista kannattaa koota muistin tueksi toiseen tapaamiseen. Luetteloita voi myös lähettää osallistujille tapaamisten välissä tarkistettaviksi ja toisen jatkotyöskentelyn materiaaliksi. Esiin tulleita seikkoja voidaan poimia halutun tarkkuustason mukaan. Vähintään pitäisi kuitenkin koota luettelot tahoista, joihin toimintayksiköstä käsin ollaan yhteydessä, tiedonkäsittelyssä käytettävistä välineistä, tiedonsiirtomuodoista, koetuista ongelmakohdista ja hyviksi koetuista käytännöistä. Ongelmia - ja osittain myös onnistuneita ratkaisuja - tulee kuvata pelkkää luetteloa laajemmin. Ainakin pitää kuvata niitä toimintakokonaisuuden osatekijöitä, jotka vaikuttavat ongelmien syntyyn: estävät tai edistävät käytännöt, ohjeet, välineet, muiden toimijoiden odotukset jne. Kuvaukset tulee saada sille tasolle, että aiheeseen perehtymätönkin ymmärtää niistä asian ytimen. Moniammatillinen tutkimustiimi on tässä korvaamaton apu TOINEN TAPAAMINEN Toisessa tapaamisessa ryhmä etsii itse yhteistoiminnallisesti ratkaisuja aiemmin todettuihin tiedonkäsittelyn ja viestinnän hankaluuksiin tai ongelmiin. Täten tuloksena on lista ongelmista kuvauksineen sekä suuntaviivat siitä, minkä tyyppiset ratkaisut soveltuvat työtoiminnan kokonaisuuteen parhaiten. Toisessa tapaamisessa kerrataan aluksi edellisen kerran tuotokset. Muistin virkistämiseksi esitetään verkostokuvio, joka edellisessä tapaamisessa piirrettiin. Kannattaa myös käydä läpi osallistumisen periaatteet eli että osallistujien toivotaan ottavan rohkeasti osaa keskusteluun sekä toiminnasta kertomalla että tarkennuksia kysymällä. Tapaamisen pääasiallinen tavoite on ideoida ratkaisuja havaittuihin ongelmiin. Osallistujia kehotetaan kuvamaan, kuinka he toiveissaan suorittaisivat ongelmallisen tehtävän, mitä välineitä ja keinoja he luontevimmin haluaisivat käyttää. Vastaukset halutaan toimijan kannalta hyvin konkreettisessa muodossa, mutta kuitenkin hyvin yleisellä tasolla. Ei siis pyritä esimerkiksi nimeämään tiettyjä välineitä tai teknologioita, varsinkaan jos osallistujien kokemus tai koulutus ei anna siihen eväitä. Pääasia on saada selville, minkä tyyppinen ratkaisu olisi toimijoiden mielestä parempi kuin nykyinen ja mitä ehtoja siihen liittyy. Voidaan esimerkiksi todeta, että nykyinen tiedon siirtäminen 46 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

47 paperilla tai puhelimessa koetaan epätarkoituksenmukaiseksi ja toivotaan, että tiedon voisi siirtää sähköisesti oman pääasiallisesti käytössä olevan sovelluksen kautta tai että jokin nykyisin paperilla tai sähköisesti välitettävä tieto olisi parempi käsitellä kokoontumalla aika ajoin yhteen. Toisessa tapaamisessa kerättävät tiedot on koottu alla olevassa taulukossa 3. Nauhoitukset puretaan samaan tapaan kuin ensimmäisenkin ryhmätapaamisen jälkeen. Tuotos Edellisellä kerralla kerättyjen tietojen varmistaminen Ideoidut ratkaisut ongelmiin (ratkaisut, joita ei toivota) Taulukko 3. Toisessa tapaamisessa kerättävät tuotokset Muoto Pikainen kuvion läpikäynti (voidaan myös lähettää osallistujille ennen tapaamista) Yhteinen keskustelu ja pohdinta. Esimerkkikuvaus toivottavasta toimintatavasta. Esim. Sairaalassa tehdyn tutkimuksen A tiedot pitäisivät olla helpommin käytössä kun teen lähetettä. Helpointa olisi jos ne olisivat näkyvissä X järjestelmässä, koska käytän sitä muutenkin tässä tilanteessa. Tieto voisi siirtyä suoraan lomakkeelle, ettei sitä tarvitsisi kopioida. (kuten yllä) Esimerkiksi en haluaisi lähettää tätä tietoa sähköpostina koska minun pitää saada keskustella vastaanottajan kanssa silloin kun siirrän tiedon hänelle Vaihe 3: Aineiston käsittely ja analysointi Tuotosten tulevaisuusverstasosio eli tiedonkulkua parantavien käytäntöjen, ohjeiden ja välineiden ideointi pitäisi myös saada kuvattua niin selkeästi, ettei pelkoa väärinymmärryksestä ole. Haastatteluja voidaan käyttää myös toiminnan luonnetta ja toimintatapoja kuvaavien toimintatarinoiden (ks. myös luku 2 sekä liite 2) luomisessa tai rikastuttamisessa. Näitä toimintatarinoita voidaan myöhemmin hyödyntää esimerkiksi vaatimusmäärittelyn pohjana. Kuvion muodostumista haastattelutilanteessa ohjaa aina jonkin verran sattuma, kuten esimerkiksi järjestys, jossa seikat tulevat keskustelussa esiin. Tähän vaikuttavat mm. ryhmän koostumus, osallistujilla tuoreimpina mielessä olevat kokemukset, jne. Tuotokset saattavat siis olla ulkopuolisen silmissä melko vaikeasti hahmotettavia. Piirustukset kannattaa sen vuoksi piirtää puhtaaksi sähköiseen muotoon. Tietokoneella puhtaaksi piirrettäessä esiin tulleiden seikkojen sijoittelut ja ryhmittelyt voidaan tehdä siten, että esimerkiksi eri haastattelupaikoista saatuja tuloksia voi olla helpompi verrata keskenään. Tarkoitukseen sopii mikä tahansa ohjelma, jolla voidaan piirtää yksinkertaisia kuvioita ja jota toteuttajien on luonteva käyttää. Tässä raportissa nähtävistä piirroksista osa on tehty graafiseen mallintamiseen tarkoitetuilla ohjelmilla (SmartDraw, MS Visio) ja osa tavallisilla MS Office -paketin välineillä (Word, PowerPoint). Vaiheen tuloksena pitäisi siis syntyä kuvaus toiminnan yhteistyöverkostosta, sidosryhmistä, lista yhteydenpitoon käytettävistä tavoista ja välineistä, ymmärrettävään muotoon työstetyt kuvaukset jokapäiväisessä tiedonkulussa ilmenevistä ongelmista, lista ongelmien esiintymisolosuhteista ja -tiheydestä, kriittisyydestä ja muista vastaavista seikoista sekä lista työtoiminnan kokonaisuuteen osallistujien mielestä parhaiten soveltuvista ratkaisutyypeistä. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 47

48 TUOTOKSISTA TULOKSIKSI Tapaamisista saadut tuotokset eivät raakamuodossaan vielä kerro kaikkea. Tuotoksia tulee tiivistää, karsia ja järjestää tarpeen mukaan. Havaintoja voidaan luokitella esimerkiksi niputtaa kehittämiskohteet sidosryhmittäin, toimintaprosessin vaiheiden mukaan tai välineittäin. Haluttuja seikkoja voidaan kulloisenkin tarkastelunäkökulman mukaan korostaa tai häivyttää. Voidaan esimerkiksi koota erikseen tietoteknisiin ongelmiin, keskittyä niiden ratkaisemiseen ja häivyttää muut taustalle. Ei ole olemassa yhtä ainoaa oikeaa tulosten esittämistapaa. Nyrkkisääntönä voidaan sanoa, että selvityksen tarkoitus määrää siinä käytettävän esitysmuodon ja -tekniikan. Joitakin konkreettisia esimerkkejä kuvaamistavoista (luettelot, kartat, kaaviot, kuvat, uimaratakaaviot, toimintatarinat) on esitetty tässä raportissa, esimerkiksi kuvat 5, 6 ja 7 sekä liite 2. Lopulliset esitystapojen valinnat riippuvat osallistujien kokemuksesta ja mieltymyksistä. Tärkeintä on esittää tulokset sellaisessa muodossa, että ne ovat havainnollisia ja ymmärrettäviä mahdollisimman monelle kohdeyleisölle: haastatelluille työntekijöille, sidosryhmille, päättäjille, ratkaisujen suunnittelijoille, palvelun asiakkaille jne. Kuva 5: Kuvaus äitiysneuvolan yhteyksistä sidosryhmiin, yhteyksissä käytetyistä viestintävälineistä ja niiden toimivuudesta. Seinätaulusta puhtaaksipiirretty versio, jonka etuja ovat mm. helppolukuisuus ja muokattavuus. Kuvaan voidaan myös koota useammasta lähteestä kerättyä tietoa. 48 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

49 A-klinikka Työterveys Laboratorio Päivystys Röntgen Äitiyspoliklinikka Hammashoito Lasten neuvola Perhesuunnittelu Mielenterveys Terveyskeskus Äitiysneuvola Sairaala Synnytyssali Synnytysosasto Muut osastot, poliklinikat Muut sairaalat Yksityiset vastaanotot Sosiaalitoimi Lastensuojelu Päihdetyö Toimeentulo KELA SPR Ensikoti Kuva 6. Esimerkki äitiysneuvolan tietojärjestelmän integrointitarpeista. Salamat kuvaavat ongelmakohtia nykyisessä tiedonkulussa. Kehittämistarpeiden merkitystä voidaan erotella esimerkiksi salaman koolla tai värillä. Toimija A Toimija B Toimija C Teko Kuva 7. Mikäli tavoitteena on kuvata tiedonkulkua erityisesti ohjelmistotuotannon näkökulmasta, voidaan käyttää ns. uimaratamallia. Siinä kuvataan vuokaavion tavoin toiminnan tyypillistä järjestystä, toimien keskinäisiä riippuvuuksia ja tiedonkäsittelyyn käytettyjä välineitä. Toimintaa ei tarvitse kuvata perinpohjaisesti, vaan juuri sillä tarkkuuden tasolla, mikä kulloinkin on tarkoituksenmukaisin. Sekä keskustelun apuvälineenä käytettävät kaaviot että tulosten erilaiset esitystavat riippuvat paljolti tekijöiden aiemmasta kokemuksesta ja mieltymyksistä. Kaikkein tärkeintä on, että esitystavat ovat ymmärrettäviä kaikille selvityksen tekoon ja hyödyntämiseen osallistuville - siis parhaassa tapauksessa koko toimintaorganisaatiolle tai toimialalle. Toteuttajille jätetään vapaus käyttää kuhunkin tilanteeseen sopivimpia käytäntöjä. Tämä soveltamisen vapaus tekee menetelmän tarkan, oppikirjamaisen kuvaamisen jokseenkin mahdottomaksi. Toivottavasti se kuitenkin myös helpottaa menetelmän soveltamista suunnittelevan lukijan ajattelua. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 49

50 3.4 Yhteenveto ja pohdinta Kuvatulla menetelmällä voidaan kokemustemme mukaan saada kootuksi hyvinkin monella tavalla jatkohyödynnettäviä tietoja toimintayksikön tai -kokonaisuuden tiedonkäsittelytavoista ja kehittämistarpeista. Tuloksia voidaan esimerkiksi käyttää hyväksi kappaleessa 4 kuvatun ohjelmistoprojektin lähtökohtana ja materiaalina. Selvityksessä esille tulevia tietotarpeita voidaan hyödyntää myös ohjelmistotuotteita vertailtaessa, osana tarjouspyyntöä tai projektin tulosvaatimusten kuvausta. Menetelmää voidaan käyttää myös arvioinnin välineenä: laite- tai ohjelmistohankinnan, koulutuksen tai muun toimintajärjestelmässä toteutetun muutoksen jälkeen voidaan uudelleen tutkia, miten tehty muutos on vaikuttanut kokonaisuuteen ja mikä seuraavaksi kaipaa eniten kohentamista. Pilottitutkimuksessamme eräs ryhmä oli sitä mieltä, että heidän työyhteisössään vastaavia keskusteluja pitäisi käydä säännöllisin väliajoin, vaikkapa kerran vuodessa. Osallistujien mielestä ryhmäkeskustelut lisäsivät tehokkaasti sekä yksilöiden että koko yhteisön tietämystä yhteisestä toiminnasta ja tiedon merkityksestä siinä. Olennaista menetelmässä on lisäksi se, että tulosten esitystapoja ohjaa hyvin pitkälle selvityksen hyödyntäjän eli teettäjän tarkoitus. Lopputuotosten määrälle, muodolle tai tarkkuudelle ei siis voida osoittaa yhtä ainoaa oikeaa määrää tai mittaa. Selvitystä suunniteltaessa on muistettava, että tavoitteena ei ole selvittää ja kuvata toimintakokonaisuuden tiedonkulun kaikkia nyansseja. Tarkoitus on suorittaa katsaus, jonka perusteella jatkotoimet voidaan suunnata oikeaan ilmansuuntaan. Katsaus perustuu kohdealueen toimijoiden yhteiseen ymmärrykseen ja se tehdään ripeästi ja kohtuullisin kustannuksin. Esiselvityksen tulisi olla kaikille osallistujille riittävän vaivaton, että myös varsinaiseen tutkimus- ja kehittämistyöhön jää voimia, halua sekä varoja. Oman kokemuksemme mukaan kokeilemillamme toimintatavoilla voidaan tähän tavoitteeseen päästä. 50 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

51 4 TAV O I T T E E N A O H J E L M I S T O VA AT I M U K S E T Tässä luvussa kuvataan PlugIT-hankkeessa luonnosteltu menetelmä ohjelmistovaatimusten toimintalähtöistä määrittelemistä varten. Menetelmän tuloksena saadaan ohjelmiston vaatimusmäärittely, joka koostuu ohjelmiston käyttöliittymäsuunnitelmasta ja tietomallista. Käyttöliittymäsuunnitelmassa ohjelmiston toiminnot konkretisoidaan käyttötapauskuvausten avulla. Tietomalli on kuvaus sovelluksessa käsiteltävistä tai ylläpidettävistä tiedoista. Tietomallissa kohdealueen tieto kuvataan käsitteinä, käsitteisiin liittyvinä tietoina ja käsitteiden välisinä suhteina. Kokemuksia erilaisista komponentti- ja palvelupohjaisen ohjelmistotuotannon menetelmistä ja tekniikoista kerättiin suunnittelemalla uudelleen Kuopion yliopistossa käytössä oleva käyttäjätunnusten hallintaohjelma Pakka. Suunniteltava ohjelma nimettiin Pakkaseksi ja siinä tehtyjä dokumentteja (kaavioita, kuvia jne.) käytetään tässä esimerkkeinä. Kokemuksiemme perusteella uskomme, että toimintalähtöisen vaatimusmäärittelymenetelmän käyttäminen auttaa saamaan parempia ohjelmistoja vähemmällä työllä. Toiminnan syvällinen ymmärtäminen auttaa määrittelemään ohjelmistovaatimukset oikein heti aluksi. Käyttöliittymäsuunnitelmassa nämä vaatimukset konkretisoidaan niin, että eri osapuolten on niitä helppo ymmärtää. Näin mahdolliset virheet löydetään ajoissa ja niiden korjaaminen on helppoa, mikä säästää aikaa ja vähentää kustannuksia. 4.1 Ohjelmistovaatimusten toimintalähtöinen määritteleminen Tämä menetelmä ohjelmistovaatimusten toimintalähtöistä määrittelemistä varten perustuu kolmen erilaisen menetelmän yhdistämisessä saatuihin kokemuksiin. Taulukossa 1. on kuvattu niistä sovelletut keskeisemmät ajatukset, tekniikat ja välineet. Tavoitteena on edetä toiminnan analysoimisesta konkreettisten ohjelmistovaatimusten määrittämiseen ja kuvaamiseen. Taulukko 1. Menetelmäluonnostelun lähtökohtia Työtoiminnan malli, haastatteluteemat, esimerkki työprosessien mallin- Menetelmä Menetelmästä sovellettu idea Välineet, tekniikat ActAD-viitekehys toiminnan analysointiin ja kehittämiseen (Johdantoluku 1.2). Toimintalähtöinen lähestymistapa. tamiseen Cheesman & Daniels (Cheesman & Daniels, 2001) GUIDe-prosessimalli (Laakso, 2003) Idea siitä, kuinka käyttötapaukset ja tietomalli johdetaan toimintaprosesseja tarkastelemalla. Käyttöliittymäsuunnittelun rooli osana koko vaatimusmäärittelyä UML-notaatio vaatimusten kuvaamiseen käyttötapauksina ja tietomallina. Nämä olivat pääasialliset syötteet komponentti- ja arkkitehtuurisuunnitteluun valitulle menetelmälle (Cheesman & Daniels, 2001) Tavoitepohjaiset käyttötapaukset Tämän ohjelmistovaatimusten toimintalähtöisen vaatimusmäärittelymenetelmän keskeisimmät vaiheet on kiteytetty kuvaan 1. Aluksi perehdytään, kuvataan ja analysoidaan sitä toimintaympäristöä, jonka osaksi ohjelmistoa suunnitellaan. Sen jälkeen voidaan tunnistaa ja valita ne tehtävät, jotka kehitettävän ohjelmiston avulla on järkevä hoitaa. (Tässä vaiheessa voidaan myös huomata esimerkiksi, että ohjelmiston sijaan tai lisäksi pitääkin kehittää esimerkiksi uusia työtapoja tms.) Seuraavaksi laaditaan GUIDe-mallin mukaiset tavoitepohjaiset käyttötapaukset ja suunnitellaan niiden perusteel- TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 51

52 la käyttöliittymä. Käyttöliittymä testataan ikään kuin valmis järjestelmä ja näin hyväksytystä käyttöliittymäsuunnitelmasta tunnistetaan ja dokumentoidaan vaatimukset arkkitehtuuri- ja komponenttisuunnittelua, tietokantasuunnittelua ja testauksen suunnittelua varten. Kuva 1. Toimintalähtöinen vaatimusmäärittely ohjelmistotuotantoprosessissa Edellytykset menetelmän käytölle Menetelmä on tarkoitettu käytettäväksi niin, että siihen osallistuvat sekä ohjelmiston toteuttajat että kohdeorganisaation (tai -organisaatioiden) työntekijät. Menetelmän käytön edellytyksenä on se, että työryhmässä on toimintalähtöisten menetelmien ja tavoitepohjaisten käyttötapausten selvittämisen osaamista. 52 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

53 Työryhmässä pitää olla erilaisten kenttätutkimusmenetelmien osaamista (esim. havainnointija haastattelumenetelmät) ja käyttöliittymäratkaisuja pitää osata arvioida ainakin jollakin käyttäjätestausmenetelmällä. Toisaalta tarvitaan teknistä asiantuntemusta suunniteltujen ratkaisujen toteuttamiskelpoisuuden arvioimiseksi. Tämän menetelmän mukaan suunniteltava käyttöliittymä sisältää sekä visuaalisen että vuorovaikutussuunnitelman, joten käyttöliittymäsuunnittelijan on hallittava nämä molemmat käyttöliittymäsuunnittelun osa-alueet. Teknisten vaatimusten (työprosessit, käsitteet ja käyttötapaukset) kuvaamisessa käytetään UML-notaatiota, jonka osaajia siis myös tarvitaan. Käytettyjä kaavioita ovat aktiviteetti- ja luokkakaavio. 4.2 Menetelmä vaiheittain Kohdealueen jäsentäminen ja kuvaaminen Aluksi perehdytään siihen toimintaympäristöön, johon ohjelmistoa ollaan suunnittelemassa ja selvitetään ohjelmiston tulevien käyttäjien työnkulkuja ja tavoitteita erilaisten kenttätutkimusmenetelmien avulla (haastattelut, havainnoinnit jne.). Saatujen tietojen perusteella laaditaan työtoiminnan mallin mukainen nykytilakuvaus, luettelo ohjelmiston toiminnalle asetettavista tavoitteista 1 ja UMLluokkakaavionotaatioon perustuva käsitemalli. Dokumentit käydään mahdollisuuksien mukaan läpi suunniteltavan ohjelmiston loppukäyttäjien kanssa NYKYTILAKUVAUS Toimintalähtöisen vaatimusmäärittelyn teoreettisena lähtökohtana on toiminnan teoria, jonka avulla pyritään muodostamaan käsitys kohdealueen toiminnasta. Toiminnan teoriassa korostetaan, että yksittäisen ihmisen, tekijän tai toimijan, teot ovat tavallisesti osa laajempaa toimintakokonaisuutta, johon osallistuu myös muita toimijoita. Toimintakokonaisuuden kannalta yhteistoiminnan ja kommunikaation keinoin yksittäisistä tekijöistä muodostuu kollektiivinen toimija, jonka yhteisen työn kautta toiminnan tulos syntyy. Toiminnan tulos voi olla jonkin toisen toiminnan, kohdetoiminnan, syötteenä ja vastaavasti tietyn toiminnan osatekijät voivat syntyä joidenkin toisten toimintojen, tukitoimintojen, tuottamina. (Korpela, 1999) Toimintakokonaisuudesta hankitaan tietoja erilaisten haastattelu- ja havainnointimenetelmien avulla. Toimintaprosesseista voidaan saada tietoa myös esimerkiksi kohdeorganisaation laatutyön yhteydessä tehdyistä kuvauksista. 2 Lisäksi toiminnassa nykyisin käytettävät lomakkeet, ohjeet, mahdollinen sovellus ja siihen liittyvä dokumentaatio ovat tärkeitä toiminnan ymmärtämisessä. Eri menetelmin hankitut tiedot toiminnan osatekijöistä ryhmitellään työtoiminnan malliin, jonka avulla saadaan kokonaiskuva kohdealueesta. Sen jälkeen keskitytään tarkastelemaan tulevan ohjelmiston kannalta oleellisia työprosesseja ja työtehtäviä. Kuvassa 2 on havainnollistettu esimerkkitapaus Pakkasessa käytettyjä kuvaustapoja toiminnan mallintamisessa. Mallinnus noudattaa ActAD-mallin ja -notaation mukaista kuvaustapaa, joka on esitelty kappaleessa Pakkasessa toimintakokonaisuuden selvittämisessä myös hyödynnettiin kappaleessa esitettyjä haastatteluteemoja. Esimerkit toimintakuvauksista ovat liitteissä 5: Toimintakokonaisuus, 6: toimijan prosessi ja 7:työtehtävä. 1 Tässä vaiheessa on tehtävä selvä ero tavoitteiden ja toimintojen välillä. Tavoitteet ovat jotain, jotka voidaan ohjelmiston avulla saavuttaa. Toiminnot ovat ohjelmiston ominaisuuksia, jotka selviävät käyttöliittymäsuunnittelun aikana (Laakso 2003). 2 Toisaalta ohjelmistokehityksen yhteydessä mallinnettuja toimintaprosessikuvauksia voidaan käyttää myös organisaation muun toiminnan kehittämisessä. TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 53

54 Kuva 2. Esimerkkitapaus Pakkasessa käytetyt kuvaustavat toiminnan mallintamisessa. Työtoiminnan mallin ja prosessikaavioiden välillä säilyy yhteys. (Riekkinen ym., 2004) TAVOITELUETTELO Ohjelmistovaatimusten selvittämiseksi on ymmärrettävä siihen liittyvää ja sen ympärillä tapahtuvaa toimintaa. Pelkkä nykyisen toiminnan kuvaaminen kuitenkin sitoo suunnittelijat liian tiukasti nykykäytäntöihin, joista on vaikea päästä irti. Siksi sen lisäksi, että selvitetään miten joku asia tehdään, on selvitettävä miksi se ylipäätään tehdään. Tähän yksinkertaiseen kysymykseen vastaamalla voidaan ymmärtää toiminnan merkitystä ja edelleen määritellä sopivan abstraktiotason tavoitteita ohjelmistotuotteen suunnittelun avuksi. Vastausten ja niistä muodostettujen tavoitteiden konkretian taso on sopiva silloin, kun kirjattavat tavoitteet ovat ikään kuin juuri ja juuri suunniteltavan järjestelmän yläpuolella. Esimerkki: Pakkasen nykytilakuvauksessa kerrotaan, kuinka Pakka-järjestelmän käyttäjä saa postissa käyttäjätunnushakemuslomakkeen ja siirtää siitä tietoja järjestelmään. Miksi hän tekee niin? Oikea vastaus voisi olla esimerkiksi se, että asiakas pääsisi käyttämään yliopiston verkkopalveluja, mutta se on tässä tapauksessa liian korkean tason tavoite eikä siitä juuri ole hyötyä ohjelmiston suunnittelussa. Oikea vastaus voisi olla myös se, että tallentajan työtehtäviin kuuluu lomakkeen tietojen tallentaminen järjestelmään, mutta se taas on liian matalan tason tavoite eikä myöskään auta kehittämään järjestelmää. Käyttöliittymäsuunnittelun kannalta sopivan tasoinen vastaus on se, että tallentaja siirtää tietoja lomakkeelta järjestelmään siksi, että hän voisi sen jälkeen luoda asiakkaalle käyttäjätunnuksen. Samaan tapaan tunnistetaan muut järjestelmälle asetettavat tavoitteet: - Asiakkaan käyttäjätunnuksen muuttaminen - Asiakkaan käyttäjätunnuksen poistaminen - jne UML-KÄSITEMALLI Tulevan ohjelmistotuotteen toimintaan liittyvät käsitteet kootaan käsitemalliksi, joka kuvataan UML-luokkakaaviona. Käsitteet esitetään luokkina ja käsitteiden väliset suhteet assosiaatioina ja koosteina. Käsitteiden välisiin suhteisiin voidaan liittää myös lukumääräsuhde (kardinaalisuus, ilmaisee kyseessä olevaan suhteeseen kuuluvien käsitteiden lukumäärän). Käsitteisiin liittyvä tieto kuvataan luokkien attribuutteina, joihin voidaan myös lisätä erikseen lukumäärätietoa. Lisäksi erilaisia käsitteisiin ja tietoihin liittyviä rajoituksia ja sääntöjä voidaan kuvata rajoite-symbolin avulla. Käsitemalli täydentää työtoiminnan mallia siten, että käsitemallissa kuvataan tarkemmin työtoiminnan mallissa ryhmiteltyjen käsitteiden välisiä suhteita. Vaikka käsitemallinnus liittyy tiedon ana- 54 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

55 lysointiin, sitä ei voi erottaa toiminnan analysoinnista. Toiminnan ymmärtäminen perustuu juuri käsitteiden merkityksen ja käsitteiden välisten suhteiden ymmärtämiseen. Kuvassa 3 havainnollistetaan työtoiminnan mallin ja käsitemallin välistä yhteyttä Kuva 3. Työtoiminnan mallin (symbolit ylhäällä vasemalla) ja käsitemallin (UML-luokkakaavio oikealla) välinen yhteys (Riekkinen ym., 2004) Tarkastelun syventäminen TAVOITEPOHJAISET KÄYTTÖTAPAUKSET Tavoitepohjaiset käyttötapaukset (goal-based use case) perustuvat käyttäjien korkean tason konkreettisiin tavoitteisiin eivätkä ne kiinnitä järjestelmän toimintaa millään tavalla. Tavoitepohjaiset käyttötapaukset koostuvat käyttäjän tavoitteesta ja siihen liittyvistä tilatiedoista (Laakso 2003b). Jokaisen käyttötapauksen suorittamiseen liittyy vähintään yksi vaihe, jossa käyttäjä tekee päätöksiä. Jos käyttötapaukseen ei liity päätöksentekovaihetta, sen suorittaminen voidaan yleensä automatisoida (Laakso, 2002b). Lähtökohtana tavoitepohjaisten käyttötapausten laatimisessa käytetään edellisessä vaiheessa laadittua tavoiteluetteloa ja vaatimusmäärittelyn tekijöille kenttätutkimusten aikana syntynyttä ymmärrystä kohdealueen toiminnasta. Tarvittaessa voidaan vielä tehdä uusia haastattelutai havainnointikierroksia. Tavoitepohjaisia käyttötapauksia tarvitaan ohjelmistotuotannon eri vaiheissa muun muassa käyttöliittymäsuunnittelun lähtökohtana, käyttöliittymän arvioinnin testitapauksina, järjestelmän TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 55

56 demojen ja käyttöohjeen esimerkkitapauksina, toteutuksen suunnittelussa ja toteutusratkaisujen katselmoinnin osana sekä järjestelmätestauksen korkeimman tason testitapauksina (Laakso, 2002) UML-TIETOMALLI Tulevien käyttäjien kanssa käydään läpi UML-käsitemallia ja sovitaan niistä käsitteistä, joihin liittyvää tietoa käsitellään tai ylläpidetään suunniteltavassa sovelluksessa. Tässä työvaiheessa käsitemallista siis rajataan tietomalli, jossa ohjelmistoalueen käsitteitä tarkastellaan enemmän ohjelmiston näkökulmasta (Cheesman & Daniels, 2001). Tietomalli luodaan kopioimalla käsitemalli. Tämän jälkeen käsitemallin käsitteet käydään läpi yksitellen ja jokaisen käsitteen osalta mietitään, liittyykö käsitteeseen tai käsitteiden välisiin suhteisiin tietoja, joita joko käytetään tai ylläpidetään tuotettavassa sovelluksessa. Näin toimien käsitemallista poistetaan elementtejä, kunnes tietomalli on määritelty riittävän tarkasti. Tämä tarkoittaa sitä, että käsitemallista on poistettu elementit, jotka eivät ole merkityksellisiä ohjelmiston näkökulmasta (esimerkki liitteessä 8). Näin saatuun tietomalliin liitetään kaikki toiminnassa tarvittavat tiedot ja tunnistetut rajoitteet esittelemällä uusia attribuutteja, lisäämällä attribuutteihin tai käsitteiden välisiin suhteisiin lukumäärätietoa ja/tai kirjoittamalla sääntöjä ja rajoituksia luonnollisella kielellä rajoite-symboleihin (esimerkki liitteessä 9). Sääntöjä ja rajoituksia tunnistetaan olemassa olevasta sovelluksesta, toimintaan liittyvästä dokumentaatiosta sekä kenttätutkimuksen tuloksista. Tietomallin avulla voidaan tarkistaa, että kaikki keskeiset käyttötapaukset on otettu huomioon. Tietomalli käydään läpi seuraavien kysymysten avulla (Cheesman & Daniels, 2001): Voidaanko käsite luoda tai tuhota? Jos voidaan, niin miten se vaikuttaa ohjelmistoon? Liittyykö käsitteeseen attribuutteja, jotka voivat muuttua? Voivatko käsitteiden väliset suhteet muuttua ajan myötä? Jos voivat, niin miten se vaikuttaa ohjelmistoon? Tietomalli rakenteena palvelee arkkitehtuurisuunnittelua, koska siinä kuvataan tuotettavan ohjelmiston tietorakenne ja yhteydet toisiin järjestelmiin. Sen sijaan tietosisällön osalta tietomalli tai -analyysi useimmiten tarkentuu käyttöliittymäsuunnittelun aikana Käyttöliittymäsuunnittelu Käyttöliittymäsuunnittelun tarkoitus on konkretisoida tuotettava ohjelmisto ohjelmistokehitysprojektin eri osapuolille (kuva 4). Suunnittelu aloitetaan suunnittelemalla ratkaisu (tarvittavat toiminnot ja käyttöliittymäratkaisut) yhteen korkeimman tason käyttötapaukseen. Suunnittelija välttää tarkasti lisäämästä mitään sellaista, mikä ei ole tarpeen juuri tämän käyttötapauksen suorittamisessa. Sen jälkeen hän integroi suunnitelmaan ratkaisut muille tehtäville yksi kerrallaan. Suunnittelun edetessä käyttöliittymän toimintaa simuloidaan tehtävä kerrallaan, jotta mukaan otetut uudet tehtävät eivät hankaloita aikaisemmin suunniteltujen tekemistä. Kun koko vuorovaikutussuunnitelman ensimmäinen versio on valmis, suunnittelija laatii käyttöliittymäkuvauksen (user interface specification). Siinä näytetään kuvasarjojen avulla vaihe vaiheelta, kuinka käyttäjä saa tehtävänsä tehdyksi (kuva 5). Tätä kuvausta arvioidaan ikään kuin valmista järjestelmää. Ensin varmistetaan käyttöliittymäratkaisujen toiminta ja tehokkuus; sen jälkeen voidaan ryhtyä korjaamaan mahdollisia opittavuuteen ja intuitiivisuuteen liittyviä ongelmia. Suunnitelmasta tehdään niin yksityiskohtainen, että siitä voidaan tarvittaessa johtaa UMLkäyttötapauskaaviot ohjelmiston teknistä suunnittelua varten. (Laakso 2003.) Käyttöliittymäsuunnitelmaan kuuluu myös ohjelmiston visuaalinen tyyliopas. Sen laajuus ja tarkkuus riippuu tuotteesta ja tilanteesta. Suunnittelun lähtökohtana on hyvä käyttää olemassa olevia standardeja (käyttöjärjestelmästandardit, mahdolliset yrityskohtaiset käyttöliittymä- tai graafiset oh- 56 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 11

57 jeet) ja vakiintuneita käytäntöjä, koska ne ovat käyttäjille todennäköisesti tuttuja. Ohjeistusten soveltuminen kulloiseenkin tilanteeseen on kuitenkin varmistettava. Ensimmäisen käyttötapauksen luonnostelun yhteydessä suunniteltiin myös käyttöliittymän perusvuorovaikutus ja yleisnäkymä. Eri elementit sijoiteltiin paikalleen pääasiassa lukusuunnan mukaisessa järjestyksessä (vasemmalta oikealle ja ylhäältä alas), niin että työtehtävissä ensimmäisenä tarvittava hakutoiminto on vasemmassa yläreunassa ja uloskirjautuminen, johon työprosessi päättyy, on alhaalla oikealla. Tuotteen käyttötarkoituksesta ja tietokantaluonteesta kerrottiin välilehtien avulla ( hakutulos, käyttäjä, palvelimet ; kortistometafora). Käsin piirrettyjen luonnosten perusteella tehtiin mallipohja, jossa ovat näkyvissä kaikki luonnostellun yleisnäkymän elementit. Näihin mallipohjiin lisättiin kussakin työvaiheessa tarvittavat elementit. Tässä näytössä on suunniteltu järjestelmän ehdottavan automaattisesti käyttäjätunnusta iivirtan. Käyttöliittymän visuaalisesta ilmeestä tehtiin kolme vaihtoehtoista luonnosta, joista asiakas valitsi yhden toteutettavaksi. Jos organisaatiolla olisi ollut käyttöliittymäohjeisto, tai jos ohjelma olisi verkkopalvelun sijaan Windows-ohjelma, ulkoasussa olisi tietysti noudateltu olemassa olevia ohjeita. Kuva 4. Käyttöliittymäsuunnittelun eteneminen yleisistä linjoista yksityiskohtiin; käyttöliittymän rakenteesta visuaaliseen hienosäätöön. Käyttäjän sukunimi on muuttunut. Tunnus halutaan saada vastaamaan uutta sukunimeä. Vanha tunnus on iivirtan, koska käyttäjän aikaisempi sukunimi on ollut Virtanen. Kuvassa käyttäjä on jo avannut järjestelmän ja hakenut oikean henkilön. Hän painaa muokkaa -nappia. Järjestelmä generoi uuden tunnuksen uuden sukunimen perusteella. Käyttäjä voisi tässä vaiheessa vielä muokata tunnusta. Hän hyväksyy järjestelmän ehdottaman tunnuksen painamalla varaa tunnus nappia. Järjestelmä vahvistaa tunnuksen onnistuneen vaihtamisen. Käyttäjä voisi perua tunnuksenvaihdon peruuta -napilla tai hyväksyä sen napsauttamalla OK. Kuva 5. Esimerkki käyttöliittymäkuvauksen kuvasarjasta (lyhennelmä). TOIMINTALÄHTÖISYYS TIEDON TARPEIDEN, TIEDONKULUN JA OHJELMISTOVAATIMUSTEN SELVITTÄMISESSÄ. 57