Page History

...

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.

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 Digivisio2030

...

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 Tuotekehityksen kanssa on jatkuva keskustelu käynnissä, rajapintoja on määritelty. Tällä hetkellä nousevat muutospyynnöt seovelluskehitykseen sovelluskehitykseen ei mene laiteta ITSM-välineeseen , vaan
    ja prosessiin vielä. 
    
  • Varsinainen  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ä.
  • 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ä mutuoksien korkekaolujen 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?
  
  • Prosesissa 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 digisiviossa 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 onreettisen konreettisen toteutuksen suunniteelu 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)
  • (Standimuutosten Standardimuutosten listaa tulee täydentää uusilla tarpeilla kun sellaisia havaitaan. Listan ajantasaisuuden katselmoitin katselmointi on osa muutosenhallinnan muutoksenhallinnan prosessin tuotoksia.)
• Muutoskalenteria (sisältää toteutettavaksi hyväksytyt ja aikataulutetut muutosetmuutokset. Muutosenhallinnan 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 onmuutoksen ehdottaja? Kuten todettiin ideapankki ja muutoksenhallinta on eri asia
  • Lähteitä muutokselle tulee pystyä kerätä 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 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 muutosehdotuskiamuutosehdotuksia. 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 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ää pieneltä tuntuva, standardi tms. Mutta jos ne näkyy käyttäjille on huolehdittava että muutos viestitään kaikille tahoiletahoille, 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 digisivion 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 asioitua
  • Toiminnallisuuden pieni muutos: ei edellytä merkittäviä muutoksia korkeakouluissa, käsitellään tässä CAB-prosessissa, mutta ei korkeakouluisakorkeakouluissa
  • Toiminnallisuuden muutos, joka edellyttää korkeakoulujen palveluissa esimerkiksi rajapintamuutoksia: edellyttää mahdollisesti erillisen muutosprojektin toteutamiseksitoteuttamiseksi, 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:

Korkeakoulut

• 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

...