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

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.

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 erikseen (mm. kehitettävässä ideapankkiprosessissa).
• Muutosten kustannusvaikutukset tulee tunnistaa selkeästi
• Korkeakoulujen muutoksenhallinnan yhteystahot tulee tunnistaa
• Viestintä on tärkeä osa muutoksenhallintaa 

Taustamateriaalia

Palveluintegraattorin prosessisivu: 12 Muutoksenhallinta

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 sovelluskehitykseen ei mene ITSM-välineeseen ja prosessiin vielä. 
    
  • Varsinainen 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ä.
  • Kun ollaan tavoitetilassa normaalissa tuotannossa, IT-palvelunhallinnan prosessit liittyvät myös sovelluskehitykseen joko informaationa muutostarpeista tai sitten uuden version edellyttämien muutosten hallitsemiseksi.
• 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ä muutoksia korkeakoulujen 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?
  
  • Prosessissa 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 digivisiossa 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 konreettisen toteutuksen suunnittelu 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 vain 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)
  • Standardimuutosten listaa tulee täydentää uusilla tarpeilla kun sellaisia havaitaan. Listan ajantasaisuuden katselmointi on osa muutoksenhallinnan prosessin tuotoksia.
• Muutoskalenteria (sisältää toteutettavaksi hyväksytyt ja aikataulutetut muutokset. Muutoksenhallinnan prosessi tuottaa.) ylläpidetään ITSM-työkalussa. Sinne voidaan järjestää pääsy korkeakoulujen edustajille. Julkinen, yhteinen https://www.csc.fi/ideapankki/ tarjoaa mahdollisuuden jakaa ja tunnistaa muiden kanssa eri kehityskulkuja.
• Täsmennättekö vielä mikä taho on muutoksen ehdottaja? Kuten todettiin ideapankki ja muutoksenhallinta on eri asia
  • Lähteitä muutokselle tulee pystyä keräämään 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, jos muutokseen liittyy esimerkiksi arkaluontoinen haavottuvuus tms. 
  • Kuten tehdään digivisiolle keskitettyä muutoksenhallintaa miten varmistetaan, että muutoksen pyytäjällä on organisaationsa valtuudet pyytää muutosta? 
  • Muutosehdotukset korkeakoulujen kautta? Korkeakouluissa nimetty muutosehdotusten toimittaja?
• Kuka on muutoksenhallintaprosessin omistaja?
  • Digivisiossa ICT-palvelupäällikkö (N.N.)
  • Korkeakoulukohtaisesti pitäisi sopia prosessista, kuka pystyy ehdottamaan muutosehdotuksia. Korkeakoulujen tulisi tehdä ensimmäinen arviointi ehdotetun muutoksen viemisestä Digivision muutosprosessiin (businessa tai IT).
  • 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" korkeakouluille 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 tahoille, niille, jotka ovat käyttäjiä lähellä tukirajapinnassa
  • Viestinnän kanssa ollaan laatimassa viestintäohjeita eri prosesseihin

Digivision muutoksenhallinnan piirin leveys ja syvyys

• Mitkä ovat digivision 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ä hallintaa korkeakoulujen kanssa
  • Toiminnallisuuden pieni muutos: ei edellytä merkittäviä muutoksia korkeakouluissa, käsitellään tässä CAB-prosessissa, mutta ei korkeakouluissa
  • Toiminnallisuuden muutos, joka edellyttää korkeakoulujen palveluissa esimerkiksi rajapintamuutoksia: edellyttää mahdollisesti erillisen muutosprojektin toteuttamiseksi, 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

Osallistujat:

Korkeakoulut (25)

• 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
  

Digivision hanketoimisto

• Erika Maliranta
• Jaakko Marin
• Toni Iltanen

Palveluintegraattori CSC:llä

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

CSC

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