Kertomukset ovat merkittävässä roolissa tietojärjestelmähankkeissa. Tietotekniikka ja ihmisten väliset kertomukset mielletään arkiajattelussa eriparisiksi, mutta tekninen ja tarinallinen limittyvät toisiinsa kuitenkin odottamattomilla tavoilla. Yhteydet haastavat niin tietojärjestelmätieteitä kuin kertomustutkimustakin uuteen teoreettiseen ja tulkinnalliseen maastoon kasvattaen ymmärrystä maailmaa yhä enemmän ohjaavien tietojärjestelmien taustavaikuttimista.

Tietojärjestelmien merkitys lienee voimakkaasti digitalisoituvassa nyky-yhteiskunnassa kiistaton. Tietojärjestelmistä on tullut korvaamaton osa monien arkisten rutiinien pyörittämistä elämän eri osa-alueilla terveydenhuollosta kaupankäyntiin ja tiedonvälitykseen. Ajatusleikkinä voit kuvitella syntyvää kaaosta, jos edes viidesosa arjellesi olennaisista tietojärjestelmistä lakkaisi toimimasta. Entäpä jos menettäisimme hallitsemattomasti niistä puolet, saati kaikki maailman tietojärjestelmät?

Tietojärjestelmien merkityksen voi ennustaa yhä kasvavan, sillä uudet tavat hyödyntää teknologiaa ovat pitkälti sidoksissa tietojärjestelmiin. Tämä näkyy suurissa kotimaisissa teknologiahankkeissa, kuten julkisen sektorin tietojärjestelmähankkeessa Apotissa, joka on puhuttanut ja synnyttänyt kamppailevia kertomuksia jo vuosia. Tarinankerrontaa voikin löytää tietojärjestelmäkehityksen eri vaiheista odottamattoman paljon: vaatimuksia tietojärjestelmälle välitetään kertomuksin ja valmiista järjestelmästä niin kehittäjät, käyttäjät kuin mediakin haluavat kertoa oman näkökulmansa. Miksi suuri osa kertomuksista on kuitenkin varsin negatiivissävytteisiä, saa selityksensä kertomusteorian kautta.

Haastavien tietojärjestelmähankkeiden negatiiviset mallitarinat 

Apotti on asiakas- ja potilastietojärjestelmä, joka yhdistää lukuisten Uudenmaan kuntien sosiaali- ja terveydenhuollon ammattilaisten toiminnan ja saa toiminnan piiriinsä lopulta lähes 1,6 miljoonaa kansalaista. Kehittäjiensä mukaan järjestelmän käyttöönotto päivittää ja yhtenäistää asiakasorganisaatioiden teknisen puolen ja toimintamallit lopputuloksenaan laadukkaampaa palvelua kansalaisille: terveydenhuollossa saman potilaan hoitoon saattaa osallistua kymmenittäin keskenään huonosti toimivia tietojärjestelmiä, jotka Apotti-hanke yrittää nyt korvata yhdellä helposti integroitavalla järjestelmällä. Apotti tähtää siis hyvään, mutta se on tuomittu epäonnistumaan huolestuneiden kansalaisten puheissa liian suurena, kalliina ja kunnianhimoisena.

Apotti-hanke on herättänyt poikkeuksellisen kärjekästä julkista keskustelua: tietojärjestelmäkehityksen ammattilaiset ovat kommentoineet vilkkaasti yhdysvaltalaisen Epic-yhtiön toteutettavaksi päätynyttä hanketta; sosiaali- ja terveydenhuoltoalan ammattilaiset ovat julkaisseet Apotin käytöstä niin lehdissä kuin kokemuskertomuksia Apottikokemus.fi -sivustolla; myös media on yrittänyt sanallistaa jo vuonna 2012 käynnistellyn hankkeen vaiherikasta edistymistä. Kasvanut julkinen mielenkiinto tietojärjestelmiä kohtaan osoittaa, kuinka tietojärjestelmien merkitys on sisäistetty. Tulevaisuus on tietojärjestelmissä, joiden toimintaa ei usein arjessa edes tiedosta. Tarinankerronta kuitenkin tekee nuo arjen usein näkymättömät puurtajat näkyviksi – niin hyvässä kuin pahassakin.

Tulevaisuus on tietojärjestelmissä, joiden toimintaa ei usein arjessa edes tiedosta. Tarinankerronta kuitenkin tekee nuo arjen usein näkymättömät puurtajat näkyviksi – niin hyvässä kuin pahassakin.

Tietojärjestelmähankkeet on toistuvasti todettu haastaviksi. Näkemystä puoltaa Suomessa julkinen keskustelu, jossa otsikoissa ovat olleet menneisyyden epäonnistumisiksi tuomitut tapaukset, kuten VR-Yhtymän uudistetun lippujärjestelmän käyttöönotto. Käyttöönotto epäonnistui aiheuttaen harmaita hiuksia kansalaisille ja runsaat taloudelliset tappiot organisaatiolle. Toisaalta tietojärjestelmätieteen arvostetut tieteelliset tutkimusartikkelit myös tarjoavat perustaa näkemykselle näiden hankkeiden hankaluudesta (Baghizadeh et al., 2020; Dwivedi et al., 2015; Nelson, 2007). Kyse ei ole kuitenkaan enää vain tiettyihin tapauksiin kytkeytyvistä käsityksistä tai tutkimuksen esittämistä todisteista: tarinankerrontaa niin tietojärjestelmistä kuin suurista hankkeistakin ohjaa auttamattoman negatiivinen mallitarina.

Mallitarina (masterplot) on eräänlainen alati toistettu ilmiötä kuvaava luurankomainen kertomus, josta yksittäiset tarinat ammentavat. Mallitarinat kytkeytyvät “elimellisesti syvimpiin arvoihimme, toiveisiimme ja pelkoihimme” ja niitä voidaankin pitää myös yhteiskuntia yhdistävinä kertomuksellisina rakenteina. (Abbott 2002/2008, 42–45.) Mallitarinat saavat pontta ja vahvistuvat valtaapitävien tahojen ja esimerkiksi median toistaessa niitä, mutta toisaalta myös sosiaalinen media tukee ennemmin olemassa olevien mallitarinoiden toistamista kuin niistä poikkeamista: on turvallisempaa toistaa kaikille tuttua tarinaa vain uudessa ulkoasussa (Mäkelä 2019). Erityisesti Suomen kontekstissa tietojärjestelmistä kerrotaan negatiivisesti, sillä sellainen on kansakuntaa ohjaava mallitarina. Tekniikka & Talous -lehden Startup-blogissa Elina Uutela kuvaa osuvasti suomalaista asennetta tietojärjestelmähankkeisiin kuvaten samalla negatiivista mallitarinaa:

”Julkisen keskustelun kautta kosketuksemme suomalaiseen teknologiaosaamiseen – painottuen ohjelmistopuoleen – on melkoisen negatiivissävytteinen. Suomalaiset eivät ole osanneet rakentaa VR:n lipunmyyntijärjestelmää. Sähköisen reseptijärjestelmän kyllä osasivat, mutta se vei järjettömän määrän vuosia ja rahaa. Apotti-potilasjärjestelmähanke maksaa lopulta satoja miljoonia, eikä monikaan elättele toiveita sen korkeasta laadusta. Tässä maassa kaikki ympärillämme huutaa, että teknologia on vaikeaa ja kallista.” (Uutela 2013.)

Negatiivinen mallitarina muovaa mallinsa kautta yksilöiden kertomuksia ja jopa heidän kokemuksiansa tietojärjestelmistä.

Kertomuksin käsinkosketeltavaksi

Tietojärjestelmähankkeita toteutetaan monin eri metodein, mutta lähestymistavasta riippumatta toiminta pohjautuu nimenomaan ihmisten väliseen kommunikaatioon – siis tiedon välittämiseen ihmisten välillä prosessin eri vaiheissa. Tietojärjestelmän voi ajatella sosiotekniseksi järjestelmäksi, jossa teknologia jää joskus jopa sivuosaan sosiaalisen viestinnän rinnalla: Tietojärjestelmän vaatimusmäärittelijä kuuntelee järjestelmiä käyttävän ammattilaisen tarinoita nykyisen järjestelmän haasteista. Järjestelmäkehittäjä yrittää tulkita tuon tarinan, jotta se lopulta voitaisiin koodin kautta muuttaa todeksi. Kehittäjäfirman edustaja yrittää esimerkein kertoa sidosryhmille, mitä järjestelmä oikeastaan tekee. Tuohtunut järjestelmän loppukäyttäjä kertoo, missä kehittäjät ovat menneet pieleen. Media kertoo lukijoilleen kiinnostavista seikoista prosessin eri vaiheissa ja nostaa usein heidän tarinoitaan esiin.

Varsinkin suuret tietojärjestelmähankkeet ovat useiden sidosryhmien yhteistoimintaa. Tarvettaan palvelevan tietojärjestelmän kehitys pohjautuu sidosryhmien välisissä keskusteluissa rakennettuun yhteisymmärrykseen. Keskeisiksi haasteiksi kattavan yhteisymmärryksen rakentamisessa ovat kuitenkin nousseet esimerkiksi käyttäjien kognitiiviset rajoitteet omien tarpeiden kommunikoinnissa (esim. Appan & Browne, 2012).  Käyttäjän on vaikea hahmottaa, mitä kaikkea hän tarvitsee tietojärjestelmältä, ja vielä vaikeampaa on kertoa siitä toiselle ymmärrettävässä muodossa. Toisaalta kehittäjät tuppaavat yksinkertaistamaan kontekstia ja sosiaalista puolta sivuuttava tekninen vinouma vaikuttaa usein heidän näkemyksiinsä. Tavoitteeksi nousee tällöin mekaanisesti kerätä käyttäjien tarpeet, jotta saadaan tarvittavat ohjeet varsinaisille järjestelmän koodaajille, mutta samalla toiminnan sosiaalinen konteksti unohtuu (Holmström & Sawyer, 2011).

Yhteisymmärryksen rakentaminen usein monimutkaisesta, huonosti käsinkosketeltavasta kokonaisuudesta on siis haastavaa. Tässä saattaa olla yksi tietojärjestelmähankkeiden haasteiden juurisyistä. Kertomukset kuitenkin tekevät maailmasta helpommin ymmärrettävän, konkreettisemman ja ennen kaikkea ihmisen kokoisen. Kertomus välittää kokemuksia maailmasta, jonka kertoja havaitsee. Kertomuksella voimme järkeistää kovin satunnaiselta vaikuttavaa elämää ja sen tapahtumia, tai kertoa vaikka tietojärjestelmän teknisestä ongelmasta, jota meidän olisi muutoin vaikea sanallistaa tai edes käsittää.

Siten tietojärjestelmät eivät ole ainoastaan tekniikkaa, vaan kompleksinen vyyhti teknologiaa, organisatorista ympäristöä ja ihmistoimintaa, jota sanallistetaan kertomuksin. Asiaa havainnollistavat Rosio Alvarez & Jacquiline Urla (2002) yliopiston järjestelmähanketta kuvaavassa artikkelissaan ”Tell me a Good Story”, jossa työntekijöitä pyydetään kertomaan työstään, jotta tietojärjestelmän tarpeet saadaan kerättyä ja tuotettua kehityssuunnitelmat. Artikkeli nostaa esiin esimerkin, jossa yliopiston työntekijät maalailevat kertomuksillaan kuvan vastuuttomista opiskelijoista. Kertomus opiskelijoista, jotka eivät esimerkiksi vastaa yliopiston hallinnon työntekijöiden lukuisiin viesteihin on helposti ymmärrettävä ja uskottava kertomus, johon monen on helppo samaistua. Tekninen ongelma tulee kertomuksen kautta ihmisen kokoiseksi ja kokemukselliseksi.

Ihmiskokemus teknologian välissä

Tyypillinen tarina tietojärjestelmästä kuvailee, kuinka uusi tietojärjestelmä tuo käyttäjän harmoniseen työelämään kaaosta, jonka rinnalla järjestelmän luvatut hyödyt eivät tunnu riittäviltä: työntekijän rutiinit särkyvät ärsyttävällä tavalla muutoksen edessä. Toisaalta kertomus voi herättää toivoa muutoksen tuomista eduista, joihin koettua kärsimys johtaa: kunhan tästä selvitään, niin millaiset kissanpäivät sitten koittavatkaan! Karrikoidut esimerkit osoittavat, miten kertomus tarjoaa ihmisen kokoisten näkökulman tietojärjestelmiin ja niiden ympäristöön. Samalla ne antavat tärkeää ja ymmärrettävissä olevaa tietoa tietojärjestelmien kehittäjille. Toistuva kertomus uusien käyttöliittymien kanssa kipuilevasta käyttäjästä neuvoo heitä panostamaan yksinkertaisuuteen järjestelmän käyttöönoton alkuvaiheissa.

Onko taidokkaan tarinankertojan mahdollista saada kertomuksillaan tietojärjestelmään muutoksia, jotka eivät vastaa muiden käyttäjien totuuksia?

Kertomukset eivät kuitenkaan välitä objektiivista totuutta. Ne välittävät kokemuksia, jotka kyllä ovat todellisuutta kertojalle, mutta ovat kuitenkin aina subjektiivisia tulkintoja. Kuitenkin yksilön kokemuskertomukset ovat voimakkaita ja monin tavoin vastaansanomattomia: ei toiselle voi sanoa, että ethän sinä noin ole kokenut! Yksilöiden kokemuskertomukset voivatkin saada turhan paljon valtaa mukaansa tempaavina, jolloin ne saattavat hämärtää ilmiöiden todellista laitaa. (Ks. Mäkelä et al 2020.) Tutkimuksen haaste onkin selvittää, onko taidokkaan tarinankertojan mahdollista saada kertomuksillaan tietojärjestelmään muutoksia, jotka eivät vastaa muiden käyttäjien totuuksia.

Kertomuksilla on helppo yleistää, jolloin osa totuudesta jää aina piiloon. Tietojärjestelmäkehittäjän on helppo myös kuitata käyttäjän kritiikki muutosvastarintana uskoen toistuvaan kertomukseen kiittämättömistä käyttäjistä, jotka tykästyvät lopputuotteeseen opittuaan käyttämään sitä. Toisaalta käyttäjän on helppo unohtaa kokonaiskuva tulevaisuuden hyödyistä ja pakottavasta tarpeesta uudelle järjestelmälle, jos se aiheuttaa hänen henkilökohtaisessa kokemusmaailmassaan vain harmia ja huolta.

Kuinka kertoa tietojärjestelmistä?

Lopulta tietojärjestelmien kertomisen haasteet tuntuvat kiertyvän kysymykseen, miten kertoa jostain, mitä emme edes huomaa ennen kuin se ei toimi? Tietojärjestelmiin suhtaudutaan niiden monimutkaisuutta typistävästi kuin työkaluihin, ja kuulostaisikin absurdilta kertoa, miten vasara toimi taas kerran moitteetta. Sen sijaan ongelma vasaran toiminnassa synnyttää yksilökokemustarinoita: se meni ja hajosi kesken kovan kiireen! Niinpä esimerkiksi asiakas- ja potilastietojärjestelmä Apotista voisi tarjota loputtomasti lukuja järjestelmän onnistumisesta, mutta luvut eivät koskaan kumoaisi ammattilaisen kertomaa negatiivista kokemuskertomusta sen käytöstä, Apottikokemus.fi -sivustolla.

Ensiaskel olisikin oppia tunnistamaan kertomukset, joita tietojärjestelmähankkeissa esiintyy ja luoda malleja niiden kriittiseen tulkitsemiseen pelkkää pinnallista samaistumista syvemmin.

Toisaalta on ymmärrettävä, että negatiiviset mallitarinat ovat muovanneet ainakin Suomen kontekstissa koko keskustelukulttuurin: ajattelussamme sekä tietojärjestelmät että julkiset hankkeet ovat tuomittu jo etukäteen epäonnistuviksi, kalliiksi ja viivästyviksi olkiluotokolmosiksi, länsimetroiksi ja VR:n lipunmyyntijärjestelmiksi. Tietojärjestelmäkehityksen tarinankerronnan tutkijoiden haaste on korjata rikkinäinen puhelin, jossa kehittäjät ja käyttäjät kuulevat, mitä haluavat, eikä todellista yhteisymmärrystä synny. Ensiaskel olisikin oppia tunnistamaan kertomukset, joita tietojärjestelmähankkeissa esiintyy ja luoda malleja niiden kriittiseen tulkitsemiseen pelkkää pinnallista samaistumista syvemmin. Tietojärjestelmä- ja kirjallisuustieteen on siis syytä yhdistää ajatteluaan, jotta kehittäjät voivat tulevaisuudessa ymmärtää paremmin tietojärjestelmähankkeiden sosiaalista ja tarinallista vuorovaikutusta.

Lähteet

Abbott, P. H. (2002/2008). The Cambridge Introduction to Narrative. Cambridge: Cambridge University Press.

Alvarez, R., & Urla, J. (2002). Tell me a good story: Using narrative analysis to examine information requirements interviews during an ERP implementation. ACM SIGMIS Database: The DATABASE for Advances in Information Systems, 33(1), 38–52.

Appan, R., & Browne, G. J. (2012). The impact of analyst-induced misinformation on the requirements elicitation process. MIS Quarterly, 85–106.

Baghizadeh, Z., Cecez-Kecmanovic, D., & Schlagwein, D. (2020). Review and critique of the information systems development project failure literature: An argument for exploring information systems development project distress. Journal of Information Technology, 35(2), 123–142.

Dwivedi, Y. K., Wastell, D., Laumer, S., Henriksen, H. Z., Myers, M. D., Bunker, D., Elbanna, A., Ravishankar, M. N., & Srivastava, S. C. (2015). Research on information systems failures and successes: Status update and future directions. Information Systems Frontiers, 17(1), 143–157.

Holmström, J., & Sawyer, S. (2011). Requirements engineering blinders: Exploring information systems developers’ black-boxing of the emergent character of requirements. European Journal of Information Systems, 20(1), 34–47.

Nelson, R. R. (2007). IT project management: Infamous failures, classic mistakes, and best practices. MIS Quarterly Executive, 6(2).

Uutela, E. (2013). Insinööri ymmärtää ihmistä – tai ainakin yrittää. Tekniikka & Talous, Startup-blogi 1.10.2013.

Tarinat tietotekniikan toteutuksessa -projektin kotisivut.