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
Aika | Asia | |
---|---|---|
5 min | Työpajan avaus / Antti Mäki |
|
5 min | Mistä muutoksenhallinnassa on kyse? / Jaakko Marin |
|
10 min | Muutoksenhallinnan prosessi ja vastuunjako / Jaakko Marin |
|
5 min | Palveluintegraattorin toimintakäsikirja / Jussi Vestman |
|
60 min | Keskustelua / puheenjohtaja Jussi Vestman |
|
5 min | Yhteenveto ja lopetus / Antti Mäki |
|
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.
- 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ä.
- 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ä.
- 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/
- Muutoksenhallinnan yläpuolella oleva ideoiden hallintaprosessi - tätä työstetään ja kuvataan digivisiossa par aikaa (portfolion hallinnan prosessi)
- 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