Tämä esitys jakaantuu kahteen osaan: Ensiksikin pohdintaan laadusta ja sen useammasta eri määritelmästä sekä toiseksi analyysiin yhteistyöstä. Tarve yhteistyöhön johtuu siitä, että tietosysteemi (IS) on yleensä laaja, ja IS-systeemin rakentaminen ja käyttö vaativat monen eri henkilön työpanosta. Kun osalla IS-systeemin rakentajia, käyttäjiä ja ohjaajia on eri käsitykset laadusta, yhteistyön vaatimus on vieläkin perustellumpi.
Ainakin neljä eri laadun määritelmää
Reeves ja Bednar {Defining quality: Alternatives and implications. Academy of Management Review (19:3), 419-445} selvittivät 1994, että on ainakin 4 eri laadun määritelmää: Laatu on erinomaisuus (excellence), laatu on arvo (value), laatu on yhteensopivuus spesifikaatioiden kanssa (conformance to specifications) ja laatu on asiakkaiden odotusten täyttäminen (meeting and/or exceeding customers’ expectations). Kirjoittajat päätyvät näihin neljään laadun eri määritelmään käymällä läpi kirjallisuutta.
Laatu on erinomainen, kun se on kaikista paras. Jos tavara tai palvelu on arvioitu kalliiksi, niin tavaraa tai palvelua pidetään arvokkaana. Kun tavaran tai palvelun hinta on halpa, niin sitä ei kovin paljon arvosteta. Organisaation ylin johto pitää siitä, että tuotteen tai palvelun laatu voidaan kuvata hyvin yksinkertaisella tavalla eriomaisuutena tai arvokkaana. Organisaation alemman tason ihmiset mielellään painottavat, että tuote tai palvelu vastaavat täsmälleen sitä, mitä on luvattu, siis spesifikaatioita. Kun mennään organisaation ulkopuolelle, silloin asiakas on erittäin tyytyväinen, kun tuote tai palvelu ainakin vastaa, ellei jopa ylitä hänen odotuksiaan, Neljäs laadun määritelmä nojaa siihen, että organisaation ulkopuolinen määrittää, milloin tuotteen tai palvelun laatu on hyvä.
Reeves ja Bednar (R&B) ovat etsineet neljän eri laatu -käsitteen (eriomaisuus, arvo, yhteensopivuus spesifikaatioiden kanssa ja asiakkaan odotusten täyttäminen) vahvuuksia ja heikkouksia. Esimerkiksi muiden laatu -määritelmien kuin yhteensopivuuden spesifikaatioiden kanssa mittaaminen on vaikeaa, Asiakkaiden odotusten täyttäminen laatumittarina lienee parhaiten yleistettävissä. R&B ovat lisäksi pohtineet, mitä jotkut tekijät vaikuttavat laatuun. Yllä totesimme, että tuote tai palvelu on arvokas, jos siitä saadaan hyvä hinta. Laatu näyttää lisäävän markkinaosuutta. Vähällä panostuksella (alhaisilla kustannuksilla) ei juuri saada laatua. Lyhyellä aikavälillä asiakkaan odotusten täyttäminen voi hyvin tuoda tuloja, kunnes kilpailijat tuovat vielä parempia tuotteita tai palveluita markkinoille.
Onko vielä muita laatu -käsitteen määritelmiä? R&B vastaavat itse, että on mm. ”yhteensopivuus käytössä” ja ”menetysten välttäminen”. Edellinen koskee erityisesti informaatiosysteemien (IS) alaa, sillä tekninen kehitys muuttaa alaa jatkuvasti. Sen seurauksena uuden sukupolven myötä IS-alalla tehdään ensin pieniä sovelluksia ja sitten toivotaan, että niihin on myöhemmin helppo ympätä uusia. Tällöin on laadukasta, jos yhteensopivuus toimii käytössä.
Yleisesti siitä, että samalla termillä, tässä laadulla, on useampia eri määritelmiä, seuraa, etteivät osapuolet aina ymmärrä toisiaan. Vähintä, mitä voidaan silloin tehdä, on, että osapuolet kertovat toisilleen, mitä he termillä laatu tarkoittavat.
Yhteistyöstä
IS-alalla on ainakin kolmenlaisia yhteistyön mahdollisuuksia: a) henki-ö–henkilö, b) henkilö – IT-komponentti ja c) IT-komponentti – IT-komponentti. Yritän esittää joitakin ajatuksia kustakin parista.
Yhteistyö henkilöiden välillä
Tässä oletetaan, että kumpikin on ollut omassa kuplassaan, ja että kummallakin on käytössä oma paikallinen kieli. Minulla, joka mielestäni olen ollut IT:n hyödyntämisen parissa pitkään, on silti ollut vaikeuksia ymmärtää oman organisaation IT-toiminnon väen kieltä. Olemme eläneet eri kuplissa. Ehdotan tällä kohtaa, että kumpikin osapuoli ainakin hiukan opastaa toistaan. Tällöin nuodatetaan artikkelin Boland ja Tenkasi {Perspective making and perspective taking in communities of knowing. Organization Science (6:4), 350-372} sanomaa. He esittivät 1995, että kumpikin osapuoli kertoo omasta alastaan (kuplastaan) ja yrittää ymmärtää toisen alaa ja näkökohtia. Vaikka ohje näyttää yksinkertaiselta ja luonnolliselta, niin esimerkiksi omasta alasta puhuminen on yllättävän vaikeaa. Siitä olen saanut useita todisteita käytännössä. Tässä yhteydessä painotan erityisesti laatu -käsitteen määritelmää, joka voi aikaisemmasta koulutuksesta, toimialasta ja työkokemuksesta johtuen poiketa eri osapuolilla toisistaan kovinkin paljon. Aikaisemmin IT-asiantuntijat muuttivat manuaalisia IS-systeemejä IT-tekniikkaa hyväksikäyttäviksi, nykyään useat tehtävät ovat aikaisemman IS-systeemin vikojen korjauksia ja uusien piirteiden täydennyksiä niihin.
Yhteistyö henkilön ja IT-komponentin kesken
Oletan, että tässä henkilö on IT-asiantuntija, joka on hankkimassa yleensä toisesta organisaatiosta, esimerkiksi IT-palvelutalosta, IT-komponenttia omaan organisaatioonsa. On hyvä, jos palvelutalolla on IT-komponentista hyvä kuvaus. Mutta kenelle kuvaus on kirjoitettu? Onko kuvaus tarkoitettu hyväksikäyttäjälle vai IT-asiantuntijalle liitettäväksi osaksi käyttöorganisaation aikaisempaa IS-sovellusten joukkoa?
Jo 1980-luvulla ns. Seeheim-mallissa lisättiin yhteistyömahdollisuuksia käyttäjän ja IT-komponentin (ohjelman) välillä jakamalla jälkimmäinen kolmeen osaan
käyttäjä ↔ esityskomponentti ↔ keskustelukomponentti ↔ IT-sovellus
IT-komponentti, siis ohjelma, järjestetään niin, että esityskomponenttiin kootaan eri tavat, joilla keskustelu on mahdollista esittää, keskustelukomponenttiin sisällytetään ne eri tavat, joilla käyttäjä voi käydä keskustelua muun osan ohjelmaa (IT-sovelluksen) kanssa. Kaikki eri esitystavat ja kaikki eri keskustelutavat ohjelmoidaan etukäteen. Käyttäjä sitten kunkin käyttökertansa alussa valitsee itselleen sopivan esitys- ja keskustelutavan. – Suunnilleen samalla tavalla toimitaan, kun halutaan delegoida lisää päätösvaltaa esim. tekoälyn muodossa ohjelmalle: ohjelmoidaan ns. äly ohjelmaan etukäteen omana aliohjelmanaan ja käyttäjä sitten päättää, käyttääkö hän “älyä” vai ei.
IT-komponentti voi joskus olla iso ja sisältää miljoonia ohjelmarivejä. Sellaisen hallitseminen on vaikeaa, kuten Olsen ja Sætre {IT for niche companies: Is and ERP system the solution? Information Systems Journal (17:1), 317-342} 2007 osoittivat. He huomasivat, että ohjelmoija oli sisällyttänyt ERP-systeemiin varastojärjestelmän, joka ohjasi jatkuvasti tilaamaan lisää tavaraa. Varasto täyttyi ja olisi ylittynyt, ellei ERP:n käyttöä siltä osin olisi lopetettu. Esimerkki osoittaa, että käyttäjän tulee ainakin jollakin tavalla hallita koko ohjelma. Sama koskee ohjelman rakentajaa, myyjää, ostajaa ja henkilöä, jonka ohjauksessa rakentaminen, myynti, osto ja käyttö tapahtuvat.
Yhteistyö IT-komponenttien kesken
Tällainen yhteistyö ja työnjako perustuu ohjelmoijien (ei systeeminsuunnittelijoiden) toteuttamiin ratkaisuihin. Ohjelman jako komponentteihin ja komponenttien välisen yhteistyön hoito on suunniteltava, ohjelmoitava ja testattava etukäteen sekä valvottava käytössä. Ohjelman päivittäminen virheiden poistamiseksi, uusien tehtävien lisäämiseksi ja huoltotoimenpiteiden helpottamiseksi jatkossa on vaativa tehtävä. – Samanlaiset ongelmat kuin henkilöiden kesken sekä henkilön ja IT-komponentin kesken toistuvat.
Yhteenveto
Laatu on vaativa käsite. Kun sillä on monta perusteltua merkitystä, ne täytyy ottaa huomioon keskustelussa ihmisten kesken sekä ihmisten ja IT-komponentin kesken, jotta onnistumme yhteistyössä.
Pertti Järvinen on aloittanut Imatran rautatehtaalla ATK-matemaatikkona vuonna 1963. Hän on sittemmin siirtynyt Tampereen yliopistoon ja on eläkkeellä ohjannut yli 20 tohtoria, jotka ovat toimineet yrityksissä ja AMK:ssa.
Pertti valittiin Tietojenkäsittelytieteiden seura ry:n toimesta vuoden tietojärjestelmätieteilijäksi 11.6.2024.