2023-02-03 Muutoksenhallinnan työpaja

Aika: Perjantai 3.2.2023 klo 9:00-10:30

Paikka: https://cscfi.zoom.us/j/67546523866

Tavoite

Laajempana tavoitteena on toteuttaa Digivision arvoverkossa toimiva muutoshallinnan toimintatapa. Työpajassa pohditaan yhdessä, miten Digivision palvelujen muutoksenhallintaa voidaan edistää IT-palvelunhallinnan näkökulmasta ja miten palveluintegraattori tukisi kytkeytyä korkeakoulujen sisäisiin muutoksenhallinnan toimintoihin mahdollisimman tarkoituksenmukaisella tavalla.

Taustamateriaalia

Palveluintegraattorin prosessisivu: 12 Muutoksenhallinta Digivisio2030

Työpajan alustus:

Läpivienti

Muistiinpanot keskustelusta

• Onko tarkoitus perustaa CAB (Change Advisory Board)?
  
  • On Digivision IT-palvelunhallinnan osalta, mutta täytyy sovittaa yhteen myös muiden CAB:ien kanssa, tarvitaanko esimerkiksi Digivision palvelutarpeisiin Korkeakoulujen IT-palvelutuotannon ja IT-palveluhallinnan PAHA-johtoryhmän (https://wiki.eduuni.fi/x/8BbzEw) lisäksi erillinen. 
  • Korkeakoulujen kanssa integroitavan it-palvelunhallinnan kokonaisuudessa on ulottuvuuksina ainakin a) digivision CAB, b) korkeakoulun oman it-palvelunhallinnan CAB sekä c) kolmannen korkeakouluekosysteemille palveluita tuottavan kokonaisuuden CAB, kuten Funidatalla Sisu-kokonaisuuden hallitsemiseksi.
  • PAHA-johtoryhmä työstää IT-palveluhallinnan tukipalvelun mallia, joka auttaa jäsentämään myös muutostenhallinnan prosessia
• Selvennätkö suhdetta sovelluskehitykseen? Miten versiomuutokset kannattaa hoitaa
  •  Tuotekehityksen kanssa jatkuva keskustelu käynnissä, Toni Iltasen kanssa ollaan jo määritelty rajapintoja. Tällä hetkellä mirtä muutospyyntöjä nousee sovelluskehitykseen ei laiteta ITSM-välineeseen. Menevät tällä hetkellä Jiraan
  •  Varsinen ohjelmistokehitystyö menee hanketoimiston ohjaamana. Johdetaan hanketoimisen tuoteomistajien johdolla. Integraatioista, tällä hetkellä isoimmat ovat VIRTA-integraatioita opintosuoritteiden hakuun. Keskustelut myös Sisun ja Pepin kanssa käynnissä.
• Osa muutoksista ovat sellaisia jotka voivat vaikuttaa korkeakouluihin asti, kuten integraatiorajapinnan muutokset ja lisäykset. Näitä käsitellään toivottavasti asianmukaisissa forumeissa.
  • Iltanen: Tässä vaiheessa rajapinnat vielä monitahoinen kysymys. Erikseen käyttöönottovaihe missä korkeakoulut ottavat palvelua käyttöön ja silloin keskustellaan koirkeakoulujen kanssa mitä mutuoksien korkekaolujen tulee tehdä.
    
• Muutos voi aiheuttaa kustannusvaikutuksia, kuten aiemmin todettu. Prosessissa niitä ei kommunikoida muutoksen esittäjälle, vaikka niillä voi olla iso merkitys siihen halutaanko muutos lopulta toteuttaa (panos-hyöty suhde). Tapahtuuko tuo jo ennen kuvattua prosessia, vai miten asia on ajateltu huomioida?
  
  • Prosesissa arvioi ja evaluoi -aktiviteetin kohdalla. Monesti voi olla niin, että ennen prosessia emme tiedä mitä kustannusvaikutuksia muutoksesta tulee.
  • Mielenkiintoinen kysymys konsortiotilanteessa, sillä kustannuksia voi aiheutua kumppanillekin.
  • Tämän voisi piirtää niin, että kommunikaatio mernee myös muutoksenhallinnan syövereistä ulospäin
  • Voi olla, että reagoiminen muutoksiin voidaan hoitaa suhteellisen kevyesti, mutta on riski että syntyy "kaikki vaikuttaa kaikkeen" -tilanne.
  • Yksittäisten käyttäjien palautteita tai muutostoiveita ei viedä tähän muutosprosessiin, sen voisi tarkentaa muutoksenhallinnan kuvauksessa.
• Tällä hetkellä esim. Uudet ominaisuudet menee ns. Ideapankin kautta, jossa punnitaan eri ideoiden/toivomusten tuleva kustannus (sekä digivision ja korkeakoulun päässä) ja hyötyvaikutus - palveleeko kaikkia vai onko toivomus enemmänkin yhtä korkeakoulua palveleva muutos. Näiden arviointien jälkeen vasta ominaisuus päätyy suunnitteluun tai tuotekehitykseen
  • Muutoksenhallinnan yläpuolella oleva ideoiden hallintaprosessi - tätä työstetään ja kuvataan digisiviossa par aikaa
  • Ideapankin arviossa arvioidaan esimerkiksi: Onko tämä asia sellainen että se mahtuu RRF-rahoituksen scopeen. Arivoidaan korkean tason toteuttamiskelpoisuus. Eroaa muutoksenhallinasta siten, että muutoksen
  • Kyseessä on Ideapankki-prosessi osana Digivision palvelukehitystä ja palveluhallintaa, mikä on siis eri asia kuin julkinen, yhteinen https://www.csc.fi/ideapankki/ 
• CABissä (tai ainakin muutoksenhallintaprosessissa jossain vaiheessa) pitää olla mukana asiantuntijatason ihmisiä korkeakouluista, IT:stä ja opintohallinnosta. Ei ole johtajien työtä
• Muutoksenhallintaan tuskin viedään kaikkia pikku muutoksia, vaiukka ne eivät ole standardimuutoksia.
  • Toisaalta pikkumuutos täällä voi olla iso asia naapurille (vrt. kokemukset, kun OPH muuttaa rajanpintaansa pikkuisen)
• Muutoskalenteria ylläpidetään ITSM-työkalussa. Sinne voidaan järjestää pääsy korkeakoulujen edustajille
• Täsmennättekö vielä mikä taho on muutoksen ehdottaja? Kuten todettiin ideapankki ja muutoksenhallinta on eri asia
  • Lähteitä muutokselle tulee pystyä kerätä koko ekosysteemistä
  • Liittyy myös tietoturvanäkökohta, asialla voi olla merkitystä sekä ehdottajan ja organisaation näkökulmista ja toisaalta kuka pystyy näkemään yksittäisen muutoksen
• Kuka on muutoksenhallintaprosessin omistaja?
  • DIgivisiossa ICT-palvelupäällikkö (N.N.)
  • Korkeakoulukohtaisesti pitäisi sopia prosessista, kuka pystyy ehdottamaan, k
• Kuten tehdään digivisiolle keskitettyä muutoksenhallintaa miten varmistetaan, että muutoksen pyytäjällä oin organisaationsa valtuudet pyytää muutosta? Tietoturvanäkökulma
  • Muutokset kannattaa tulla korkeakouluista joidenkin nimettyjen henkilöiden kautta.
  • Kuitenkin tärkeää, että muutoksen ehdottajalle on hyvät kanavat joiden kautta ehdotuksia voi laittaa
• Prosessissa olevien muutosten on hyvä olla näkyvissä laajemmalle joukolle (poislukien tietoturva tms. sensitiiviset, joita ei haluta koko maailmalle näyttää).
• Viestintä kannattaa tässä pitää myös mielessä. Edellyttääkö muutos viestintää. Jos on toiminnallisia muutoksia, kuka niistä viestii eri käyttäjätahoille?
  • Joskus muutos voi olla teknisesti pieneltää tuntuva, standardi tms. Mutta jos ne näkyy käyttäjille on huolehdittava että muutos viestitään kaikille tahoile
  • Viestinnän kanssa ollaan laatimassa viestintäohjeita eri prosesseihin

Digivision muutoksenhallinnan piirin leveys ja syvyys

• Mitkä ovat digisivion kytkökset muiden palveluiden muutoksen hallintaan?
• Korkeakoulu rakentaa oman muutoshallintansa jossa se arvioi omaan korkeakouluun vaikuttavia muutoksia, digivisiosta tulevista ja muista
• Esimerkkejä erilaisista muutoksista MUUTOKSEN TEKNINEN MERKITYS
  • Kapasiteetin muutos: ei edellytä korkeakoulujen kanssa asioitua
  • Toiminnallisuuden pieni muutos: ei edellytä merkittäviä muutoksia korkeakouluissa, käsitellään tässä CAB-prosessissa, mutta ei korkeakouluisa
  • Toiminnallisuuden muutos, joka edellyttää korkeakoulujen palveluissa esimerkiksi rajapintamuutoksia: edellyttää mahdollisesti erillisen muutosprojektin toteutamiseksi, jotta voidaan määrittää, keitä / mitä sidosryhmiä muutos koskee ja miten muutos on hallittava
  • Hätämuutokset
• Nelijaottelu DV:n muutosenhallinnanskopessa, muutosohjelma (kuten pilotit) ei ole DV:n muutosenhallinnan scopessa MUUTOKSEN SISÄLTÖ
  • IT-conf muutos scopessa
  • business tason muutokset projekteina  ulkopuolella

Tiivistelmä ja päätelmät

• Muutoksenhallinta (change management) ja muustosjohtaminen (transformation) ovat eri asioita.
• Muutoksenhallinta käsittelee (pääsääntöisesti) konfiguraation rakenneosien muutoksia. Palvelun liiketoimintalogiikkaan kohdistuvat muutokset käsitellään ideapankkiprosessissa.
• Muutosten kustannusvaikutukset tulee tunnistaa selkeästi
• Korkeakoulujen muutoksenhallinnan yhteystahot tulee tunnistaa.
• Viestintä on tärkeä osa muutoksehallintaa 

Osallistujat:

Anne-Maarit Selinummi
Eija Heiskanen, HY
Tuuli?
Jaakko Riihimaa, AAPA-verkosto
Jani Leino, TY
Jari Virtanen, Jamk
Jarmo Kauppinen, Centria
Joonas Kröger, Haaga-Helia
Jouni Penttinen
Juha Alioravainen
Juhani Aurava
Jussi-Pekka Pispa, TAU
Kari Kataja, HAMIK
Kari Keinänen, OY
Katja Lempinen, SAMK
Kimmo Nikkanen, Metropolia
Mari Nyrhinen, TaiY
Osmo Santamäki, SAMK
Sami Ahlgren
Samuli Malinen, OAMK/OY
Sanna Partanen
Sanna Taimen
Sari Nieminen
Stefan Levander
Tuomas Orama, Metropolia

Palveluintegraattori:

• Jussi Vestman
• Anna Luoma
• Maarit Saaresto
• Marko Memonen
• Tarja Aromaa

Digivisio:

• Erika Maliranta
• Jaakko Marin
• Toni Iltanen

CSC:

• Antti Mäki
• Kirsti Hänninen
• Anja Kärkkäinen