Aiemmin tietojärjestelmiä kehitettiin koko organisaation voimin niin, että yhdessä protoiltiin, mallinnettiin ja simuloitiin organisaation toimintoja, tehtäviä ja työnkulkuja. Nykyisin palvelumuotoilussa protoilemalla, mallintamalla ja simuloimalla kuvataan palvelupolku ja puretaan palvelutilanne atomeiksi. Mikä palvelumuotoilussa on uutta ja mikä tuttua meille pitkän linjan tietojärjestelmäalan ammattilaisille?

Neljännesvuosisata sitten – jolloin asiakkaat eivät vielä itse käyttäneet tietojärjestelmiä –erään ison organisaation osaston tietojärjestelmien uudistusprosessi sysättiin liikkeelle osaston henkilökunnan ideapäivässä, kun osastolla työskentelevät kertoivat, miten joustamattomasti työt silloisten tietojärjestelmien kanssa sujuivat. Tietojärjestelmät eivät kattaneet kaikkia toimintoja, joten osa niistä jouduttiin hoitamaan manuaalisesti. Asiakaspalvelun työvälineet olivat puutteelliset niin, ettei asiakkaan käsittelyvaihetta saanut helposti näkyviin. Tietojärjestelmät olivat osin päällekkäisiä ja niiden yhteydet muihin tietojärjestelmiin olivat huonot niin, että tiedot jouduttiin siirtämään järjestelmistä toisiin manuaalisesti ja samat työt ja tarkistukset tekemään moneen kertaan.

Ideapäivän jälkeen käynnistettiin projekti tutkimaan osaston tietojärjestelmätarpeita. Silloisten tietojärjestelmien suurin ongelma oli muutostarpeiden hidas toteutus. Päätöksentekoon tarvittavia tilastoja ei voitu tuottaa joustavasti vaan uudenlainen tietojen poimiminen olemassa olevista tietokannoista vaati aina erillisen suunnitteluprosessin.

Projektissa käytettiin Systeemien rakennusmenetelmää (SRM), joka pohjautui E. F. Coddin relaatioteoriaan ja oli omaksunut piirteitä James Martinin tietokeskeisestä Information Engineering -menetelmästä. Haaastattelemalla hahmotettiin ensin koko organisaation ja osaston päämäärät, ongelmat ja keskeiset menestystekijät sekä luotiin kuvaus koko organisaation tiedoista ja toiminnoista.

Anthonyn kolmio

Organisaation toiminnot kirjoitettiin liimalapuille ja järjestettiin hierarkkisesti. Ne aseteltiin fläppipapereista koottuun Robert Anthonyn kolmioon, jossa villalangoilla erotettiin toisaalta strateginen, taktinen ja operatiivinen taso, toisaalta organisaation keskeiseen tuotteeseen tai palveluun liittyvät toiminnot, tukitoiminnot ja kehittämistoiminnot.

Kun esittelimme toimintomallia johtoryhmän kokouksessa, johtajat katsoivat sitä ensin epäillen. Sitten joku heistä osoitti yhtä toimintolappua ja ehdotti sille kuvaavampaa nimeä. Annoin hänelle tussin ja liimalapun ja kehotin korjaamaan seinällä olevaa mallia. Ensin hän epäröi, mutta nousi sitten, vei kirjoittamansa lapun seinälle ja perusteli tekemäänsä muutosta. Vähitellen johtoryhmän jäsenet vuorotellen tarttuivat tusseihin ja liimalappuihin ja veivät niitä seinälle toimintomalliin ja keskustelivat innokkaasti organisaationsa toiminnoista.

Vaatimusmäärittelyssä ja analyysissa haastateltiin osaston asiakaspalvelijoita, jotka kertoivat arjen työtehtävistään ja niissä tarvitsemistaan tiedoista. Kokonaisuuden hahmottamista varten koottiin osaston toimihenkilöt puolen päivän seminaariin, jossa simuloitiin asiakaspalvelun työtehtäviä ja tietojen siirtymistä eri henkilöiden ja tietojärjestelmien välillä.

Päivän päätyttyä projektipäällikkö, joka oli kyseisen osaston osastopäällikkö, totesi, että projekti on jo maksanut itsensä takaisin vaikka mitään uutta tietojärjestelmää ei koskaan kehitettäisikään. Hänelle oli päivän aikana selvinnyt iso joukko osastonsa asiakaspalvelun tiedonkulun ongelmia, jotka voidaan korjata muuttamalla työnkulkuja ja viestintää. Siihen ei tarvita uutta tietojärjestelmää.

Tuosta lähtien olen ymmärtänyt tietojärjestelmäprojektin parhaimmillaan mahdollisuudeksi kehittää organisaation toimintaa. Kun tietojärjestelmäprojektissa toiminta mallinnetaan eri näkökulmista juurta jaksaen ja keskustellen, niin toimintaa voidaan myös muuttaa ja kehittää. Tietojärjestelmäprojekti on aina organisaation pieni tai suuri muutosprosessi – kaikkine ongelmineen ja mahdollisuuksineen – ja, kuten monessa Sytyke-seminaarissa on todettu, tietojärjestelmien kehittäminen on ennen kaikkea ihmisten välistä vuorovaikutusta. Tätä olen myös pyrkinyt opettamaan IT-tradenomeille parinkymmenen vuoden ajan.

Palvelumuotoilun työpaja

Pari vuotta sitten osallistuin palvelumuotoilun työpajaan. Meille kerrottiin, että palvelumuotoilussa käytetään protoilua, mallintamista ja simulointia, joilla kuvataan palvelupolku ja puretaan palvelutilanne atomeiksi. Palveluun liittyy paljon oletuksia, mutta kun prosessia analysoidaan, niin huomataan, ettei kaikki toimikaan oletusten mukaisesti. Palvelumuotoilu on oppimisprosessi, protoilua, ideointia ja osallistamista. Simuloimalla voidaan seurata jonkin asiakirjan kulkua tietojärjestelmässä ja vähentää turhaa odottelua.

Muotoilija laatii työpajan käsikirjoituksen, jossa kerrotaan tavoite ja kuvataan, mitä tapahtuu ennen työpajaa, työpajan aikana ja sen jälkeen. Meille kerrottiin myös, että palvelumuotoilussa on paljon samaa kuin ihmiskeskeisten tietojärjestelmien kehittämisessä, esimerkiksi ISO-standardit ja vuorovaikutuksen suunnittelu. Palvelumuotoilija tuo asiakkaalle ratkaisuja, jotka sisältävät aina muutoksen ja organisaation muutosprosessien suunnittelun.

Palvelumuotoilun työpajassa esitetyssä menetelmässä oli paljon tuttua isojen projektien toiminto- ja tietomallinnuksesta neljännesvuosisadan takaa, jolloin haastattelimme käyttäjiä ja simuloimme toimintoja yhdessä heidän kanssaan. Toimintojen tarvitsemat ja tuottamat tiedot ryhmittelimme käsite-, tieto- tai oliomalliin kohteiksi, tieto- tai olioluokiksi (object class), joita yhdistimme toisiinsa ja kirjoitimme yhteysviivaan, miten ne liittyvät toisiinsa.

Suurin ero palvelumuotoilutyöpajassa esitetyn menetelmän ja perinteisten tietojärjestelmien mallinnusmenetelmien välillä tuntui olevan se, mitä tehtiin samaa tarkoittaville mutta erinimisille käsitteille. Perinteisissä menetelmissä ne yhdistettiin, jolloin syntyi selkeästi erillisiä kohderyhmiä tai toimintoja. Palvelumuotoilutyöpajan menetelmässä taas sama käsite hiukan erinimisenä (vuorovaikutus, viestintä, kommunikaatio, yhteistyö) saattoi olla mukana eri kokonaisuuksissa, mikä hankaloitti kokonaisuuksien nimeämistä ja yhdistämistä toisiinsa.

Palvelumuotoilutyöpajassa alkoi tuntua siltä, että meidän, pitkän linjan tietojärjestelmäalan ammattilaisten, jotka olemme vuosikymmeniä kehittäneet tietojärjestelmiä asiakkaille ja käyttäjille yhdessä asiakaspalvelijoiden, markkinapäällikköjen, juristien, aktuaarien, käyttöliittymäsuunnittelijoiden, tietokanta-asiantuntijoiden, ohjelmoijien ja testaajien kanssa, pitäisi tutustua palvelumuotoiluun. Miten paljon palvelumuotoilussa on meille ennestään tuttua ja mikä siinä on uutta?

Kohtaaminen ja dialogi voisivat olla hedelmällisiä!


Eija Kalliala, VTM, on kehittänyt tietojärjestelmiä vakuutusyhtiöissä kymmenen vuotta ja opettanut niiden kehittämistä ammattikorkeakoulussa parikymmentä vuotta.