Muuttaminen

1. Muuttaminen • Tietojärjestelmän kehittäminen on perinteisesti nähty muutosprosessina • Börje Langefors: System för företagsstyrning 1968 • Tietojärjestelmien merkitys realisoituu liiketoiminnassa • Toiminta muuttuu tehokkaammaksi, nopeammaksi, luotettavammaksi, halvemmaksi • Muistelua: BPR on radikaalin muutosorientoitunut

2. Mikä muuttuu? STRUCTURE TECHNOLOGY TASKS PEOPLE Leavitt’in timantti: kaikki vaikuttaa kaikkeen

3. Toiminnan teoria Työväline Toimija Kohde  Tulos

4. Muutoksen monimutkaisuus • Kaikki vaikuttaa kaikkeen • Siis mitään tekijöistä ei voida muuttaa ilman, että se saa aikaan muutoksia kaikissa muissa tekijöissä • Muutoksen hallittavuus on vaikeaa • Perinteisesti on ollut tapana ottaa lähtökohdaksi tietojärjestelmän muuttaminen • Sitten katsotaan miten paljon muita tekijöitä voi kontrolloida ja varaudutaan odottamattomiin muutoksiin

5. Esimerkkinä ISAC • Lähtökohtana Börje Langeforsin klassikko • ”Theoretical Analysis of Information Systems” 1966 • Stockholms Universitet & KTH • ISAC’in isä oli Mats Lundeberg • ISAC(1) Information Systems and Administrative Control (1970-luku) • ISAC(2) Information Systems and Analysis of Change (1980-luku)

6. ISAC Versio 1 • Informaatioanalyysi (informationsanalys) • Informaatiojoukot ja käsittelyprosessit vuorottelivat • Yleisen systeemiteorian syntaksi • Kaksi perustekniikkaa: • Edeltäjäanalyysi • Systeemin osittaminen osasysteemeiksi

7. Edeltäjäanalyysi • Määritellään ensin (osa)systeemin tuottamat informaatiojoukot • Nämähän ovat liiketoiminnan (lue käyttäjien) informaatiotarpeita • Näistä johdetaan vaiheittain systeemin käsittelyrakenteen perusteella edeltävät informaatiojoukot, kunnes tullaan syöttöinformaatioon (vrt. tarve- tai raaka-ainelaskenta)

8. Osasysteemeihin jakaminen • Muodostetaan rajallinen määrä (esim. 4-8) osasysteemeitä • Määritellään niiden väliset virtaukset edeltäjäanalyysin mukaisesti • Tarkistetaan, että osasysteemien muodostama kokonaisuus on sama kuin oli jaettava systeemi • Menettelyä toistetaan tarvittavan monta kertaa • Vrt. Yleinen systeemiteoria ja rakenteellinen suunnittelu

9. Informaatioanalyysi ja erillisyyspostulaatti • Eräkäsittelyn aikakaudell oli tavallista (ja luonnollista) ajatella tietojärjestelmää omana erillisenä kokonaisuutena • Järjestelmän syötteet • Järjestelmän tulosteet • Koko peräkkäistiedosto käsiteltiin yhdessä eräkäsittelyajossa • Tehdasmetafora: erillisyys kulutuksesta • Dijkstran muuri

10. ISAC versio 2 • Ongelma: yhteys liiketoimintaan liian heikko • Tarpeiden määritys (kattavuus, ristiriidattomuus) • Tarpeiden kohdistus (ketä ja mitä varten?) • Uusi avaus: kuvataan myös toimintaa • Informaatioanalyysin edelle sijoitettiin uusi vaihe: tominnan analyysi (verksamhetsstudier)

11. Toiminnan analyysi • Toiminnan kuvauksen syntaksi sama kuin IA • Lisäyksenä materiaaliset prosessit ja virrat sekä hybridit: samassa joukossa sekä materiaalisia että informaatiojoukkoja • Aloitettiin toiminnan kuvauksesta • Systeemien osittamisen kuluessa materiaaliset osat eriytyivät informaatio-osista • Informaatio-osia edelleen analysoimalla siirryttiin jo informaatioanalyysiin • Vrt. BPR

12. ISAC Versio 3 • Ongelma: Toiminta-analyysissa oltiin jo päätetty ryhtyä kehittämään tietojärjestelmää, jonka rajatkin oli ja määrätty • Usein osoittautui kuitenkin, että jokin aivan toisentyyppinen muutos olisi ollut paljon tehokkaampi • Esim. investointi tuotantolaitteisiin tai henkilöstön koulutus • ISACin alkuun lisättiin vielä yksi uusi vaihe: Muutosanalyysi (Change Analysis)

13. Muutosanalyysi • Lähtökohtana olivat koetut ongelmat ja strategiset linjaukset • Tavoitteeksi asetettiin selkeiden muutosvaihtoehtojen tunnistaminen ja esittäminen arviointia varten • Esittämistekniikka lainattiin toiminta-analyysin työkalupakista • Samalla saatiin luonnosteltua kunkin vaihtohdon vaatimat tietojärjestelmän kehittämisvaatimukset

14. Kontekstin löytäminen • Tietojärjestelmätieteen identiteettikriisi • Ydinosaaminen on perinteisesti ollut tietojärjestelmien suunnittelussa • Onnistumisen kriteerit sijaitsevat kuitenkin näiden järjestelmien ulkopuolella • Tietenkin järjestelmä voi olla kehno järjestelmänä (kaatuu usein, tekee virheitä jne.) • Saavatko käyttäjät työnsä tehtyä ja onko järjestelmästä mitään apua heidän työhönsä (lisäarvo)

15. Kontekstin asema • Perinteisesti suunnittelija katsoo järjestelmän suunnasta kontekstia, joka pitää ottaa huomioon, onhan se siinä ympärillä • Muutosanalyysissä astutaan järjestelmän ja kontekstin välisen rajan toiselle puolelle ja tarkastellaan järjestelmää kontekstista käsin tai paremminkin sen osana

16. IS Core • Käynnissä on kiihkeä väittely siitä, mikä muodostaa tietojärjestelmätieteen ytimen • Orlikowski & Iacono: Research Commentary: Desperately Seeking the ”IT” in IT Research – A Call to Theorizing the IT Artifact (2001) • Benbasat & Zmud: The Identity Crisis Within the IS Discipline: Defining and Communicating the Discipline’s Core Properties (2003) • Weber: Still Desperately Seeking the IS Artifact (2002) • Is there a Crisis? • Is there a Core? • If so, what is the Core?

17. Kaksi leiriä • IT artifaktan ympärille leiriytyneet • Vaativat IT-spesifisyyttä erotukseksi muista esim. kaupallisista ja yhteiskuntatieteistä • Ovat vaarassa jäädä teknisen itseymmärryksen kahlitsemiksi: konteksti pysyy periferiassa • IS in Context • Painottaa kontekstia, toimintaa tietotekniikan käytön ja kehittämisen lähtökohtana • Vaarassa jäädä yleiseksi organisaatio-opiksi, jossa tietotekniikka muodostaa epämääräisen mustan laatikon, jonka vaikutusmekanismia ei tunneta ja johon ei voida aktiivisesti vaikuttaa

18. Tekninen versus sosiaalinen • Tietojärjestelmä on tekninen järjestelmä, jolla on sosiaalisia (esim. taloudellisia) seuraamuksia • Tietojärjestelmä on sosiaalinen järjestelmä, joka vain on (osittain) teknisesti toteutettu • Tämä debatti on ollut käynnissä jo ainakin parikymmentä vuotta • Nykyinen kriisi on sen yksi uusi ilmenemismuoto

19. IS in Context • Yksi selkeimmistä edustajista on Steve Alter, San Francisco • Hänellä perustana on käsite ”Work System” • Tietojärjestelmien teknisetkin ominaisuudet pyritään määrittelemään nojautuen tähän työsysteemiin • Tietojärjestelmän kehittäminen nähdään siten osana työsysteemin muuttamista

20. Tämän kurssin mukainen tulkinta • Hyvin lähellä Alterin käsitystä, joskin ehkä vielä radikaalisempi • Erillistä tietojärjestelmää ei ole • Tietojärjestelmä on sulautettu luonnollisiksi osiksi työrooleja • Järjestelmän integroitu rakenne osoittautuu kiistanalaiseksi

21. JSD • Jackson’s System Development (1983) • Olioajattelua ennen olio-ohjelmoinnin läpimurtoa • Järjestelmä äärimmäisen hajautettu • Jokaisella olioesiintymällä on oma prosessorinsa • Hissin ohjausjärjestelmä OK • Pankkitili ?! • Toiminta asettuu järjestelmän edelle

22. Reduktionismi • Mikä on tietojärjestelmäkokonaisuuden ontologinen status? • Voidaanko se jakaa osasysteemeiksi ilman vakavia haittoja? • Onko järjestelmäsegmenttien sijoittaminen osaksi työrooleja mahdollinen tai hyödyllinen? • Voidaanko tämä hajautus suorittaa loogisesti tai ehkä myös fyysisesti? • Tämän kurssin puitteissa vastaus kolmeen edellä olevaan kysymykseen on myönteinen

23. Integroinnin polarisaatio • PC-vallankumous 1980-luvulta lähtien • Verkostoituminen palautti mahdollisuuden integroitua, mutta joustavasti ja monimuotoisesti, oman systeemin sulautumatta • Sulautetut järjestelmät • Ubiquituous Computing • Mutta: organisaationlaajuiset toiminnanohjaus-järjestelmät (ERP) pyrkivät kaiken läpäisevään integraatioon

24. Integroidun järjestelmän piiloagenda • Yhtenäiset käytännöt: rohkaisee / pakottaa • Osa laatujärjestelmää • Osa johtamisjärjestelmää: yhteenvetoraportit • Sisäänrakennettu koordinointijärjestelmä • Yhteiset tietoavaruudet • Työnkulku ja sen seuranta • Ongelmana järjestelmän kasvaminen subjektiksi • Toimija ei näe toisia toimijoita järjestelmän lävitse • Toimija ei voi muuttaa järjestelmäperäisiä toimintatapoja

25. Tietojärjestelmän kehittäminen, karikatyyri • Muuttamista, jossa erottamattomuus ei ole eturivissä • Tarpeet ja määritykset tulevat jollain tavalla toiminnasta • Sitten irtaudutaan käytännöstä järjestelmää tuottamaan • Käyttöönotossa se palautetaan käyttöön otettavaksi

26. Käyttäjien osallistuminen • Pohjoismainen brandi • Perusteluja • Demokraattinen perusoikeus • Järjestelmän laatu paranee kun käyttäjien äänetön tieto välittyy mukana olon, ei vain representaatioiden kautta • Käyttäjien asenteet muuttuvat, jos heillä on tosiasiallinen vaikutusmahdollisuus: panttivanki? • Prototyyppien käyttäminen • Iteratiivisuus

27. Osallistumisen lajit • Konsultoiva • Analyytikko tulee haastattelemaan ja yrittää selvittää tietotarpeita • Ongelmana yhteisen kielen puute ja konkreettisuuden puute • Edustuksellinen • Käyttäjien edustajat mukaan suunnitteluun • Ongelmana vaikutusmahdollisuuksien rajallisuus ja edustuksellisuuden korruptoituminen • Consensus osallistuminen • Kaikki käyttäjät ovat mukana suunnittelussa ja hyväksyvät tuloksen • Ongelmana resurssit ja toiminnan lamaantuminen (demokratia?)

28. Ohjelmistotuotanto • Monet perinteiset menetelmät ovat viitekehykseltään vanhentuneita • Eräkäsittelyn tehdasmetafora paistaa lävitse • Ajatuksena on ollut in-house tuotanto • Järjestelmiä tehdään vain omaan käyttöön • Käyttäjien osallistuminen järjestelmien määrittelyyn ja toteutukseen ei enää ole mahdollista samalla tavoin kuin nostalgiavuosina • Good bye, consensus participation

29. Jako kahteen • Järjestelmien tuottaminen ja käyttäminen tapahtuvat eri organisaatioissa (1 – N) • Tuotanto-organisaatiossa tärkeätä on saada käyttöön sovellusalueen erityisosaamista • Edustuksellista osallistumista; ei-spesifisiä käyttäjiä • Käyttäjäorganisaatiossa muuttaminen on luonteeltaan käyttöönotto • Täällä voi toteutua sekä edustuksellista että consensus osallistumista

30. Ohjelmiston toimitus • Toimituksen yhteydessä sovitaan • Mukaan tulevista toiminnoista / moduleista • Tehtävistä parametrisoinneista • Asiakaskohtaisista räätälöinneistä • Koulutuksesta • Toimittaja myy mielellään samaa järjestelmää muillekin asiakkaille • Järjestelmän kehittämiseen liittyy usein ”käyttäjien kerho”, jossa asiakkaat sopivat mahdollisimman monia tyydyttävistä muutoksista

31. Tietotyöpeli muuttamisen välineenä • Ongelmana perinteisissä suunnittelumenetelmissä on, että niitä vain harvoin suunnitellaan osaksi ihmisten työntekoa. • Esimerkiksi rakenne, jossa jokin moduli voitaisiin siirtää yhden roolin vastuualueelta toiselle • Tai ”what if” ominaisuus, jossa voisi kokeilla toimenpiteen vaikutuksia ja halutessaan peruuttaa ne • Tai prosessimalli, jossa määriteltäisiin prosessikohtainen tietojärjestelmän osasysteemi • Tietotyöpelissä työnteko on päällimmäisenä ja tietojärjestelmä siihen sulautettuna

32. Tietotyöpelin siirrot • Tietotyöpelin siirto on esitysmuoto muutokselle, jossa integroidusti nähdään kaikkien tekijöiden muutokset: • Tehtävät • Roolit ja niiden osaamisvaatimukset • Järjestelmät (ja muut välineet) • Toimijat ja heidän osaamisensa • Kaikki vaikuttaa kaikkeen yhdessä pakkauksessa

33. Siirtoluokat • Kahden roolin yhdistäminen • Yhden roolin jakaminen kahdeksi • Kahden roolin välisen rajan siirtäminen • Voidaan toteuttaa kahden ensimmäisen säännön yhdistelmänä: ensin yhdistä ja sitten jaa uudesta kohdasta • Työroolikäsitteen skaalautuvuuden vuoksi menettelyä voidaan soveltaa myös isoihin muutoksiin

34. Muutoksen tekijöitä • Muutoksen ”ontologia” • Mikä muuttuu? • Muutoksen representaatio • Kuvaus tilanteesta ennen muutosta • Kuvaus tilanteesta muutoksen jälkeen: tavoite • Muutoksen toteutustapa • Miten aiotaan siirtyä pisteestä A pisteeseen B? • Miten muutosta seurataan ja varmistutaan sen onnistumisesta? • Muutoksen tavoitteinen läpivienti ei ole mahdollinen ilman representaatioita • Kollektiivisen muutoksen representaatio pitää olla eksplisiittinen

35. Muutosprosessin toinen osa • Järjestelmän käyttöönotto • Teknisen järjestelmän lisäksi on suunniteltava ja toteutettava organisaation omat muutokset • Tehtävät ja prosessit • Työroolit • Toimijoiden osaaminen • Tarpeellinen harjaantuminen • Tätä kokonaisuutta kutsutaan organisatoriseksi käyttöönotoksi

36. Käyttöönotoissa usein pulmia • tietojärjestelmien onnistunut käyttöönotto on yllättävän vaikeaa • monien tutkimusten/arvioiden mukaan noin kolme neljäsosaa käyttöönotoista on enemmän tai vähemmän epäonnistuneita • onnistuneiden käyttöönottojen suhteellinen osuus ei ole viimeisten vuosikymmenten aikana kasvanut

37. Mitä(än) ei ole opittu? • sekä tietojärjestelmien käyttöönotossa että toimintaprosessien uudelleensuunnittelussa tekniikan toimivuus saa usein pääosan • pulmat vain harvoin perimmiltään teknisiä • tekniset pulmat usein ”helppoja” ratkaista (koska ”oikean” ratkaisun löytyminen voidaan havaita ja todentaa)

38. Tekniikka vs. toiminta • teknisten ongelmien ratkaisemisen jälkeen järjestelmä ja työtehtävät tulisi vielä saada sovitettua toisiinsa • järjestelmän tulisi palvella toimintaa eikä päinvastoin • toisin sanoen, toiminnan pitää saada etusija ja tekniikan tulla vasta hyvänä kakkosena • 3T3K = paikallisen toiminnan ja sitä tukevan tietojärjestelmän yhteensovittaminen

39. ”Hälläpyörä”käyttöönottomalli ja -menettely Miksi?

40. Mitä yhteensovittaminen vaatii? • paikallisen toiminnan, käytäntöjen, infrastruktuurin ja toimijoiden tuntemusta • käyttöönotettavan tekniikan (riittävää) tuntemusta • mielikuvitusta

41. Kuka on suorittaja? • Tämä tapahtuu järjestelmää hyväksikäyttävässä organisaatiossa • Sitä ei voida ulkoistaa • Jokaisen käyttäjän pitää itse tuottaa itselleen tulkinta järjestelmästä ja sen käytöstä hänen työssään • yhteensovittaminen vaatii pääasiallisesti paikallista osaamista, josta syystä suorittajien on oltava paikallisia työntekijöitä • ryhmässä oltava edustajat koko toimintaketjusta

42. Miksi yksi kierros ei riitä? • oppimisen, unohtamisen, ulkoisten muutosten jne. vaikutuksesta toimintatavat saattavat epäyhtenäistyä • ensimmäisellä kerralla ei ehkä olekaan keksitty parhaita toimintatapoja • (tarpeellisten) käytäntöjen yhtenäistäminen – ja sitä kautta laadun ylläpitäminen – on jatkuva prosessi

43. Kuka tarjoaa seuraavan kierroksen? • käytön aikaiset ongelmat eivät ole kenenkään kiinnostuksen kohde (ongelmien selvittämisestä tulee osa työrutiineja) • käytön aikaiseen kehittämiseen ei yleensä ole käytettävissä erityisresursointia • vaihtoehtoiskustannukset tai toiminnan laadun rapistuminen eivät tule näkyviin mikäli niihin ei kiinnitetä huomiota

44. Liiketoiminnan muuttaminen • Liiketoiminta on vaihdantaa • Tarvikkeiden valmistaminen vain omaan käyttöön ei ole liiketoimintaa • Liiketoiminnassa on (perusmuodossaan) kaksi osapuolta, ostaja ja myyjä • Vaihdannan kohde voi olla tavara tai palvelu, jolla on hinta • Elintarviketehtaan liiketoiminnan tärkein transaktio tapahtuu asiakkaiden tekemien tilausten muodossa • Tilausten käsittely ja kokoaminen toimituksiksi tapahtuu lähettämö-varastossa

45. Tilausten käsittely • Tilausten vastaanotto • Tuotteet ja niiden määrät • Toimitusehdot ja hinnat • Tilausten aikatauluttaminen toimituksiksi • Kuljetusten suunnittelu • Tilausten / toimitusten keräily • Rahtikirjan kirjoittaminen • Toimituksen siirtäminen laskutukseen

46. Tilausten käsittelyn työroolit • Myyjä / tilausten vastaanottaja • Myyjät kiertävät asiakkaiden luona • Asiakkaat voivat myös soittaa tilauspalveluun • Toimitusten aikatauluttaja • Keräilijä (käsitelty jo edellä) • Tarkastaja (muodollinen luovutus, edellä)

47. Myyjän rooli • Tehtävänä myydä mahdollisimman paljon hyvään hintaan • Toiset tuotteet toivotumpia kuin toiset • esim. parempi kate tai tuleva strategia • Sovittava jokaisen toimituksen yksityiskohdat • Varmistettava tavaran saatavuus ja toimitusaikataulu • Hyvien asiakassuhteiden ylläpito • Joskus johtaa hintaetuihin

48. Tietojärjestelmän osuus • Myyjä tarkistaa toimitettavuuden järjestelmästä • Myyjä kirjaa tilauksen mahdollisimman täydellisenä järjestelmään • Myyjä ylläpitää asiakaskohtaista tieto-profiilia, johon tulee mukaan (laskutuksesta) myös maksukäyttäytyminen

49. Sisäinen asiakkuus • Prosessiajattelun tavoitteena oli tunnistaa ja parantaa asiakkaalle koituvaa lisäarvoa toimintaprosessien kaikissa vaiheissa • Asiakkaat voivat olla ulkoisia tai sisäisiä • Liiketoiminnan periaatteet voidaan siten ulottaa myös sisäisen asiakkuuden piiriin • Sisäisessä asiakkuudessa ei ole aitoa kilpailua. Sisäinen asiakas ei yleensä voi hankkia tarvitsemaansa tavaraa tai palvelua ulkopuolelta.

50. Varastonpidon asiakkaat • Varastonpito on palvelu • Lisäarvo seuraa parantuneesta toimituskyvystä • Tässä edunsaajana on myynti • Varsinainen asiakas on kuitenkin tavaran omistaja • Omistusoikeus ei siirry varastolle • Maksaako asiakas palvelusta? • Kustannustietoisuus voisi parantaa varaston käytön tehokkuutta