Jokainen kehitysprojekti johtaa jonkinlaiseen muutokseen olipa kysymyksessä sitten pieni toiminnallisuuden muutos tai suuri liiketoiminnallinen muutos. Muutoksen suuruus riippuu yleensä siitä, onko kyse olemassa olevan palvelun tai ratkaisun jatkokehittämisestä vai jonkin uuden rakentamisesta. On inhimillistä ja täysin ymmärrettävää vastustaa muutosta tai odottaa muutokselta liikoja erityisesti kokonaan uuden ratkaisun osalta.
Käyttöönotto ja koulutus on erittäin tärkeä vaihe kaikissa muutoshankkeissa, koska se on keskeinen onnistumistekijä uuden kyvykkyyden, tuotteen tai palvelun suosiossa. On tärkeää, että ihmiset sopeutuvat ja muuttavat toimintaansa käyttöönoton myötä, jolloin muutoksen vastustaminen ei muodostu käyttöönoton pullonkaulaksi.
Liiketoimintavaikutukset
Muutoshankkeiden liiketoimintavaikutukset täytyy tunnistaa ja ymmärtää mahdollisimman varhaisessa vaiheessa. Vaikutusten arvioinnissa on hyvä huomioida seuraavat seikat:
- muutoksen laajuus (maantieteellisesti, liiketoiminnoittain, käyttäjäryhmittäin jne.)
- liiketoiminnan muutokset, mukaan lukien ekosysteemi, ihmiset, prosessit, ratkaisut, käyttöomaisuus ja data
- poistuvat prosessit, palvelut ja käyttöomaisuus
- muodostettavat ja hallittavat integraatiot
- tarvittavat kyvyt ja roolit käyttöönoton ajaksi
- käyttöomaisuus, joka pitää hankkia (data, lisenssit, laitteisto, työkalut jne.)
- noudatettavat määräykset ja lainmukaisuus
- käsiteltävät ja hallittavat riskit
- kustannukset ja taloudellinen vaikutus liiketoimintaan.
Koska liiketoimintavaikutukset ovat yleensä huomattavia ja käyttöönottoon kuluu aikaa, rahaa ja vaivaa, käyttöönottovaihe on hyvä toteuttaa omana projektinaan, johon laaditaan projektisuunnitelma, hyötylaskelma ja porttikohtaiset hyväksymiskäytännöt.
Toiminta käyttöönotto- ja koulutusvaiheessa
Käyttöönotto- ja koulutusvaiheen toimintatavat vaihtelevat valitun kehitysmenetelmän mukaan:
- Jatkuvassa kehityskulussa uusia julkaisuja tehdään toistuvasti, ja siksi käyttöönotto ja koulutus on jatkuvaa. Koulutuksen laajuus pitäisi suhteuttaa muutoksen liiketoimintavaikutukseen. On myös mahdollista, että jatkuva kehityskulku tuottaa isompia julkaisuja, joilla on suuri vaikutus liiketoimintaan. Siinä tapauksessa käyttöönottovaihe kannattaa projektoida.
- Projektoidussa kehittämisessä käyttöönotto ja koulutus alkaa, kun ratkaisu on testattu ja hyväksytty käyttöönotettavaksi hyväksyttämistestauksen (eng. User Accpetance test, UAT) perusteella. Tuotetta, ratkaisua tai palvelua ei pitäisi julkaista ilman asianmukaista UAT-testausta ja hyväksyntää. Itse käyttöönotto voidaan tehdä kerralla (eng. big-bang), vaiheittain tai modulaarisena.
Käyttöönotto- ja koulutusvaihe kostuu seuraavista vaiheista ja toiminnoista:
Kuva 5.4.1 Käyttöönotto- ja koulutusvaihe
- Koulutus: Käyttäjät tarvitsevat koulutusta käyttääkseen uutta tuotetta, ratkaisua tai palvelua ja sen kaikkia toiminnallisuuksia. Tämä mahdollistaa ennakoitujen liiketoimintahyötyjen realisoitumisen. Koulutus- ja ylläpitodokumentit täytyy olla kaikkien käytettävissä ja helposti saavutettavissa. Tukipalvelutiimit saattavat tarvita lisäkoulutusta, jotta ne voivat oppia järjestelmän tai palvelun luomat uudet prosessit.
- Julkaisuhetki (eng. go-live) on hetki, jolloin tuote, ratkaisu tai palvelu julkaistaan ja käyttäjiä pyydetään käyttämään sitä vanhan ratkaisun sijaan. Julkaisuhetki täytyy suunnitella huolellisesti varsinkin silloin, kun uusi ratkaisu korvaa laajasti käytetyn olemassa olevan ratkaisun. Itse julkaisuhetki on siten suuri ponnistus, joka sisältää minuuttikohtaisen toimintasuunnitelman, jossa on toimintaohjeet aiempaan versioon palaamisesta ja virheestä toipumiseen tarvittaessa.
- Tehostettu tukipalvelu: Tehostettu tukipalvelu alkaa juuri ennen julkaisuhetkeä ja kestää muutaman viikon, jotta mahdolliset tukipalvelupyyntöjen synnyttämät ruuhkat voidaan hallita ja hoitaa nopeasti. Tehostetusta tuesta huolehtivat kehitys- ja tuotantotiimit.
- Pilotointi eli kokeileminen: Ratkaisua voidaan kokeilla valituilla käyttäjillä ennen varsinaista käyttöönottoa, jotta voidaan todentaa uuden ratkaisun hyödyt, toiminnallisuus ja tarkoituksenmukaisuus. Käyttöönotto tehdään rajoitetusti ja testaajina toimivat oikeat käyttäjät, jotka yleensä testaavat tuotetta päivittäisissä tehtävissään. Kokeilu vähentää lopullisen käyttöönottovaiheen riskejä, sillä siinä löydetään yleensä testitapauksia, joita ei olla huomioitu hyväksyttämistestausvaiheen (UAT) aikana.
- Palaute ja päivitykset: Loppukäyttäjäpalaute koostetaan ja raportoidaan käyttöönotto-, kehitys- ja palvelutiimeille, jotka arvioivat mahdolliset päivitystarpeet ja vastaavat käyttäjäpalautteeseen.
- Levitys (eng. roll-out): Tuote, ratkaisu tai palvelu tuodaan käyttäjien käyttöön. Valittu levitysmenetelmä riippuu tilanteesta, ja oikean lähestymistavan valinnan tulisi perustua organisaation muutoksenhallintakykyyn ja arvioon muutoksen vaikutuksesta organisaation toimintaan. Vaihtoehtoisia levitysmenetelmiä ovat seuraavat:
- Vaiheistetussa levityksessä (eng. phased roll-out) ratkaisu annetaan käyttäjien käyttöön vaiheittain tietystä käyttäjäkategoriasta alkaen, ja sen jälkeen kategorioita lisätään sovitun aikataulun mukaisesti.
- Levitys moduuleittain (eng. module-based roll-out) tarkoittaa sitä, että ratkaisun tietyn joukon ominaisuuksia sisältävä osa (moduuli) julkaistaan kaikille käyttäjille. Kun tehty muutos on saavuttanut kaikki käyttäjät, julkaistaan seuraava moduuli, ja tätä toistetaan, kunnes kaikki moduulit ovat käytössä.
- Kerralla käyttöön (eng. big-bang) -vaihtoehdossa ratkaisu levitetään kokonaisuudessaan kaikille käyttäjille kertaheitolla.
Kuva 5.4.2 Levitysstrategiat
Projektivastuiden siirtäminen ja projektin päättäminen
Projektoidussa kehittämisessä projekti päätetään onnistuneen julkaisun ja projektin luovuttamisen jälkeen. Vastuiden siirtäminen tarkoittaa projektin toiminnallisten ja kehittämisvastuiden siirtämistä projektiorganisaatiolta bisnesteknologiatoiminnan linjaorganisaatioille. Projektin omistaja ja projektipäällikkö siirtävät vastuut palvelupäällikölle. Tähän vaiheeseen sisältyy myös merkittävä tietojen siirto. Vastuu kehittämisestä siirretään kehitystiimille, jota johtaa ohjelmisto- tai sovelluskehityspäällikkö. Tuotantovastuu siirretään palvelutuotantopäällikölle (eng. OPS lead).
Joissain tapauksissa voi olla parempi, että vastuiden siirtäminen tapahtuu roolien, eikä ihmisten, välillä. Tapauksissa, joissa esimerkiksi linjaorganisaatiossa työskentelevällä henkilöllä on rooli projektiorganisaatiossa, siirto tapahtuu saman henkilön kahden roolin välillä eikä eri ihmisten välillä. Tällainen ”kahden hatun” lähestymistapa ei kuitenkaan yleensä ole optimaalinen tilanne projektin käyttöönottovaiheessa, sillä molemmat roolit tarvitsevat enemmän kuin 50% työajan allokaation henkilön resursseista.
Projektin päättäminen koostuu arvioinnista ja projektin loppuraportista, jota joskus kutsutaan projektin palveluunsiirtoraportiksi. Siinä kuvataan, kuinka hyvin tavoitteet saavutettiin, sovittujen tuotosten hyväksyntä sekä kaikki jatkokehitysideat ja ratkaisemattomat ongelmat. Tuotokset ja projektin jälkihuoltovelvollisuudet sekä takuuajat tallennetaan palveluunsiirtodokumentteihin.
Jatkuvassa kehityskulussa prosessi on jatkuvaa, kunnes tulee tarve käyttää projektoitua menetelmää suuremman tai laajavaikutteisemman muutoksen toteuttamiseksi.
Kehityshankkeen loppuraportin lisäksi on tärkeää tehdä palautekysely kaikille sidosryhmille sekä dokumentoida projektin aikana kertyneet opit ja kokemukset.
Palvelujulkaisun automatisointi
Avain onnistuneeseen käyttöönottoon on organisaation kyky automatisoida uusien tuotteiden, ratkaisujen tai palveluiden julkaisuja. Automatisoidut palvelujulkaisut tehostavat käyttöönottoa ja vähentävät manuaalisiin julkaisuihin liittyviä riskejä. Jos julkaisussa ilmenee ongelmia, automatisointi myös mahdollistaa paluun viimeisimpään toimivaan tilanteeseen.
Julkaisujen automatisointi sopii erityisesti jatkuvan kehityskulun malliin, jossa uusia julkaisuja tehdään päivittäin tai viikoittain. Palvelujulkaisujen automatisoimisella saavutetaan esimerkiksi seuraavat hyödyt:
- julkaisukonfiguraatiot tehdään vain kerran
- julkaisuja voidaan tehdä silloin, kun niitä tarvitaan
- manuaalisten virheiden osuus pienenee
- palaute tuotetaan välittömästi.
Hallinnointi
Käyttöönottovaiheen hallinnointi on sidoksissa liiketoimintavaikutusten suuruuteen: mitä suurempi vaikutus, sitä vahvempi hallinnointi. Kaikki palvelujulkaisut, pois lukien vakiomuutokset, viedään muutoskomitean (eng. Change Advisory Board, CAB) ratkaistavaksi. Lisäksi isommat palvelujulkaisut tarvitsevat palvelu- tai tuoteomistajan tai ohjausryhmän hyväksynnän. Automatisoidussa palvelujulkaisussa ei tarvita muutoskomitean hyväksyntää joka julkaisussa sen jälkeen, kun prosessit on kerran tarkistettu ja hyväksytty.
Hallintomalli sovitetaan myös käytettävään kehitysmenetelmään:
- Projektoitu kehityskulku, jolla on suuri liiketoimintavaikutus, vaatii vahvan ohjauksen käyttöönottopäätöksen osalta projektin lopussa. Riskinäkökulmasta katsottuna monet riskit siirretään projektin loppuvaiheeseen, ja siksi tarvitaan päätöksiä projektin ohjausryhmältä ja salkunhallinnan ohjausryhmältä.
- Jatkuvassa kehityskulussa laaja liiketoimintavaikutus jaetaan pienemmiksi riskeiksi, mikä vaatii jatkuvaa käyttöönottoa ja koulutusputken käyttöä koko kehityksen ajan. Isommat julkaisut, joissa on laaja liiketoimintavaikutus, vaativat kuitenkin arvovirran ohjausryhmän hyväksynnän.
Kuva 5.4.3 Käyttäjän mukaan ottaminen kehittämisen ja käyttöönoton aikana
