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 on jatkuva keskustelu käynnissä, rajapintoja on määritelty. Tällä hetkellä nousevat muutospyynnöt seovelluskehitykseen ei mene laiteta ITSM-välineeseen, vaan
    
  •  Varsinaien ohjelmistokehitystyö menee hanketoimiston tuoteomistajien ohjaamana. Tällä hetkellä isoimmat integraatiot ovat VIRTA-integraatioita liittyen 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 asianmukaisissa forumeissa.
  • Tässä vaiheessa rajapinnat vielä monitahoinen kysymys. Käyttöönottovaiheessa keskustellaan korkeakoulujen 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 menee 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 (muutos tuotantoon) tai tuotekehitykseen (muutos kehitteillä olevaan ohjelmistoon)
  
  • Muutoksenhallinnan yläpuolella oleva ideoiden hallintaprosessi - tätä työstetään ja kuvataan digisiviossa par aikaa (portfolion hallinnan prosessi)
    
  • Ideapankin arviossa arvioidaan esimerkiksi: Onko tämä asia sellainen että se mahtuu RRF-rahoituksen scopeen. Arvioidaan korkean tason toteuttamiskelpoisuus. Eroaa muutoksenhallinasta siten, että muutoksen onreettisen toteutuksen suunniteelu aloitetaan vasta tämän portfolio/business tason harkinnan jälkeen.
    
  • Kyseessä on Ideapankki-prosessi osana Digivision palvelukehitystä ja palveluhallintaa, mikä on 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, vaikka ne eivät ole standardimuutoksia.
  
  • Toisaalta pikkumuutos täällä voi olla iso asia naapurille (vrt. kokemukset, kun OPH muuttaa rajanpintaansa pikkuisen)
  • (Standimuutosten listaa tulee täydentää uusilla tarpeilla kun sellaisia havaitaan. Listan ajantasaisuuden katselmoitin osa muutosenhallinnan prosessin tuotoksia.)
• Muutoskalenteria (sisältää toteutettavaksi hyväksytyt ja aikataulutetut muutoset. Muutosenhallinnan prosessi tuottaa.) 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
  • Muutosehdotukset korkeaoulujen kautta? Korkeakouluissa nimetty muutosehdotusten toimittaja?
• Kuka on muutoksenhallintaprosessin omistaja?
  • Digivisiossa ICT-palvelupäällikkö (N.N.)
  • Korkeakoulukohtaisesti pitäisi sopia prosessista, kuka pystyy ehdottamaan muutosehdotuskia. Korkeakoulujen tulisi tehdä ensimmäinen arviointi ehdotetun muutoksen viemisestä Digivision muutosprosessiin (businessa tai IT).
• Kuten tehdään digivisiolle keskitettyä muutoksenhallintaa miten varmistetaan, että muutoksen pyytäjällä on 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 (ehdotusten arvioinnin "joukkoistaminen" korkeakkouluille esim. jonkin äänestyssysteemin kautta rajatulla yhteisellä kanavalla/alustalla?)
• 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 lähteistä
• 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 (Häiriönhallinnan prosessista, laajavaikutteisen häiriön selvitys. ongelmanhallinnasta??)
• 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, HAMK
• Eija Heiskanen, HY
• Jaakko Riihimaa, AAPA-verkosto
• Jani Leino, TY
• Jari Virtanen, Jamk
• Jarmo Kauppinen, Centria
• Joonas Kröger, Haaga-Helia
• Jouni Penttinen, JYU
• Juha Alioravainen, JYU
• 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, Laurea
• Samuli Malinen, OAMK/OY
• Sanna Taimen, VAMK
• Stefan Levander, ÅA
• Tuomas Orama, Metropolia
• Juhani Aurava, HY
  
• Sari Nieminen, TUNI
  
• Sanna Partanen
• Tuuli X, X
  

Digivisio:

• Erika Maliranta
• Jaakko Marin
• Toni Iltanen

Palveluintegraattori:

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

CSC:

• Antti Mäki (Anttoni Lehdon sijaisena)
• Kirsti Hänninen
• Anja Kärkkäinen