Digitalisointiprojekteihin pätee yleisesti ottaen samat lainalaisuudet kuin mihin tahansa projektiin. Projekti on selkeä ja uniikki kokonaisuus, jossa on alku ja loppu. Projekti on erotettava jatkuvasta kehittämisestä, jota tehdään osana jatkuvaa toimintaa ja palveluita. Tämän artikkelin idea ei ole avata koko projektinhallinnan kenttää, vaan tarkoitus on ensisijaisesti tuoda esiin niitä erityispiirteitä, joita digitalisointiprojekteihin liittyy. Selvyyden vuoksi todettakoon, että suurista projekteista voidaan käyttää myös sanaa hanke tai ohjelma. Tässä yhteydessä hanke, ohjelma ja projekti voidaan nähdä toistensa synonyymeina.
Digitalisointiprojektilla viittaan projektiin, jossa informaatioteknologiaa (it) hyödyntämällä tehdään jotakin uutta tai uudella tavalla. Eli kääritään hihat ja ryhdytään toimeksi!
Digitalisointiprojektin läpiviemisessä oleellista on kohderyhmään kohdistuva muutos ja muutoksen johtaminen. Aina. Lisäksi on hyvä ymmärtää, että muutosta tuskin koskaan voidaan rajata pelkän it-työkalun tai palvelun toiminnallisuuksien määrittelyksi ja opetteluksi. Kun puhutaan digitalisointiprojektissa tapahtuvasta muutoksesta, puhutaan kokonaisuudesta, jossa uutta, lisäarvoa tuottavaa toimintaa syntyy tai jossa se saa tehokkaamman muodon. Käytännön tasolla se tarkoittaa prosessien ja käsitteiden uudistamista. Uusia henkilöiden työnkuvia ja rooleja. Uusia organisaatiomalleja ja kokonaisia ekosysteemejä. Uudenlaisia yhteistyömalleja ja tapoja jakaa tietoa. Digitalisointiprojektia ei saisi koskaan erehtyä rajaamaan yhden toimittajan toimittaman palvelun hankinnaksi ja käyttöönotoksi.
Toteutustapoja ja ratkaisumalleja
Projekteissa määritellään aikataulu, budjetti ja henkilöresurssit. Digitalisointiprojektissa on tyypillistä tehdä töitä ulkopuolisten resurssien kanssa. Siksi edellä mainitut tavoitteet ovat erityisen suuren huomion alla heti projektin alkumetreiltä lähtien. On tehtävä sopimuksia; sovittava siitä mitä tehdään ja miten, millä hinnalla ja aikataululla. Seuraavassa käsittelen projekteja niille tyypillisen elinkaaren kautta.
Digitalisoinnin projektointi
Jokaisessa yrityksessä on omat tapansa kehittää liiketoimintaa ja projektityö on usein hyväksi havaittu keino toteuttaa tätä kehitystyötä. Projekti on edeltävän kuvauksen mukaisesti: selkeä ja uniikki kokonaisuus, jossa on alku ja loppu. Projektin läpivieminen puolestaan tarkoittaa, että aikaansaadaan haluttu muutos. Muutos täytyy pystyä kuvaamaan riittävällä tarkkuudella, jotta sen projektointi on ylipäätään tarkoituksenmukaista. Kun tämä on tehty, on muutoksen aikaansaamista mahdollista johtaa projektinhallinnan keinoin esimerkiksi vesiputousmallilla tai ketterillä menetelmillä. Yleistä on käyttää myös näiden kahden menetelmän yhdistelmiä.
Miten sitten kuvata haluttu muutos? Lähdetään siitä, että muutokseen tarvitaan idea. Ideoita voi periaatteessa saada mistä tahansa, milloin tahansa. Koska digitalisoinnin alueella uusia innovaatioita syntyy jatkuvasti, on monesti hyvä sparrata omia ajatuksiaan ulkopuolisten, toisen alan asiantuntijoiden kanssa. Jos ajatustenvaihdosta syntynyt idea tuntuu kantavan, voi olla järkevää projektoida siihen liittyvä selvitystyö tai ostaa asiantuntijan konsultointia tuntityötä. Onko tässä ideassa järkeä? Minkälaisesta muutoksesta on kyse? Mitä se edellyttää? Olisiko muutos linjassa strategian kanssa? Vaiheesta voidaan käyttää monia erilaisia nimityksiä, esim. ’konseptointi’ ja sen tulisi aina edeltää varsinaista digitalisointiprojektia. En käsittele vaihetta tässä yhteydessä enempää, mutta korostan, että vaiheen yli ei kannata hypätä. Jos ideasta hyppää varsinaiseen digitalisointiprojektiin liian äkkiä, voi aikataulu- yms. tavoitteiden kautta projektityön suorittamisesta tulla hyötyjen realisointia tärkeämpää.
Projektin käynnistäminen ja kumppaneiden kilpailuttaminen
Oletetaan, että muutostavoite on riittävän selkeä, jotta projekti voidaan käynnistää ja jotta sitä voidaan mitata. Usein tässä vaiheessa kuullaan toimittajia ja ratkaisuehdotuksia ja laaditaan suunnitelmia ja budjettiesityksiä. Tässä vaiheessa oletan, että oma pohjatyö, ns. konseptointi on tehty. Ilman pohjatyötä tulet ostaneeksi jotakin, jota et tarvitse ja pahimmassa tapauksessa maksat siitä itsesi kipeäksi. On hyvä muistaa, että digitalisoinnissa on aina kyse omasta liiketoiminnastasi. Mieti, mikä itsellesi on tärkeää ja vaadi sitä!
Kilpailuttamista voi ja kannattaa vaiheistaa. On usein eduksi kuulla monia tahoja ja mielipiteitä kilpailutusvaiheen alussa. Yksi asiantuntija voi olla täysin eri mieltä kuin toinen. Ja kaikilla toki on taustalla omat kaupalliset intressinsä. Referenssejä kannattaa tutkia ja suosittelijoita kuunnella. Yleistä on tehdä myös referenssikäyntejä muihin yrityksiin, mikäli harkitsee vastaavaa palvelua kuin heillä. On myös mahdollista pyytää palvelua demokäyttöön itselleen tai suorittaa ns. POC (Proof of Concept), jossa testattavana on paitsi ratkaisun toimivuus myös myyjän ja ostajan välisen yhteistyön sujuvuus. Pelkät myyntitapaamisissa esitellyt demot eivät riitä. Henkilöresursseja hankittaessa on helppo tilata muutama tunti työtä ja katsoa miten yhteistyö sujuu. Kehitystyötä voi tilata myös erissä, niin että aluksi sitoudutaan vain tiettyyn kehityspakettiin tai ennalta määrättyyn määrään sprinttejä (sprint tarkoittaa yhtä kehitysjaksoa ketterän kehityksen menetelmässä. Yhdessä sprintissä toteutetaan ennalta sovittu toiminnallisuus järjestelmään). Uuteen kumppaniin sitoutuminen on usein iso päätös eikä vaihtaminen tilanteen niin vaatiessa käykään ihan käden käänteessä.
Kilpailuttamisessa on omat haasteensa, koska tyypillisesti ostaja-myyjä roolituksessa on epäsuhta. Usein ostajalle tilanne on uniikki, myyjälle puolestaan yksi monista. Usein myös myyjä on se osapuoli, joka laatii sopimuspaperit. Tällä tavoin myyjälle voi helposti kertyä etua sopimusneuvotteluvaiheeseen. Digitalisointiprojektin hankintavaiheeseen on olemassa konsultteja, jotka osaavat auttaa neuvotteluissa ja arvioida sopimuspapereiden sisältöä ja hintatasoa. Varsinkin isompien sopimusten kohdalla tällaista palvelua kannattaa harkita.
Digitalisointiprojektiin liittyvää sopimusta laadittaessa kannattaa olla hyvin tarkka ainakin seuraavien asioiden suhteen (näitä asioita toimittajat eivät välttämättä itse korosta):
- Projektikustannusten lisäksi mitkä ovat jatkuvan palvelun kustannukset esim. vuositasolla? Miten kustannukset määrätytyvät (esim. käyttäjien määrän vai palvelun sisällön määrän mukaan)?. Onko kustannuksiin odotettavissa muutoksia?
- Projektissa tulee aina vastaan asioita, joiden toteutusta ei ole alunperin ajateltu. Toisaalta joku toteutus voi jäädä tekemättä. Laske siis budjettiin ja aikatauluun riskilisä. Jos joku asia tuntuu epäselvältä, tilaa se optiona. Pyydä toimittajaa kertomaan millaisia lisätöitä tyypillisesti vastaavanlaisissa projekteissa joudutaan tilaamaan. Näin vältytään monilta väärinkäsityksiltä myöhemmässä vaiheessa. Ole selvillä myös lisätöiden hinnasta.
- Jos kumppanilla on merkittävä osuus projektissa, sovitaanhan kattohinnasta?
- Toimittajan ehdottama aikataulu on tyypillisesti eri asia kuin projektin kokonaisaikataulu. Jätä tarpeeksi aikaa omien määrittelytöiden tekemiseen ja muutoksen jalkauttamiseen.
- Ketkä ovat projektiin dedikoidut resurssit? Haastattele heitä tarvittaessa. Ovatko omat resurssisi kunnossa? Tiedätkö kuka tekee palveluun liittyvät linjaukset, joita toimittaja teiltä kysyy? Kuka vastaa muutosjohtamisesta?
- Tunnista kaikki kokonaisuuteen vaikuttavat osapuolet ja vastuut: esim. mistä palvelun suorituskyky muodostuu? Voiko tietoliikenneongelmia syntyä? Tai yhteensopivuusongelmia muun infran kanssa (esim. selaimen).
- Mitä kuuluu toimittajan laadunvarmistukseen?
- Kuka kehittää palvelua/järjestelmää, jonka olet aikeissa hankkia? Palvelun toimittajalla ei välttämättä ole valtuuksia kehittää tai korjata palvelua.
- Kuka omistaa tuotokset ja palvelun sisällöt? Jos maksat palvelun kehitystyöstä, tulee sinun saada myös omistus.
- Mikä on takuuaika?
- Mikä on exit-plan? Mitä tapahtuu, jos toimittaja menee konkurssiin?
- Sopikaa maksupostit projektin valmiusasteen mukaan. Viimeinen erä vasta projektin päätyttyä.
- Kaksi yksittäistä asiaa, joihin käytetty aika ja kustannukset usein aliarvioidaan: integraatiot ja datojen migraatio. Jos projektiinne liittyy jompaa kumpaa, uhratkaa sille pari ajatusta jo tässä vaiheessa.
Ja yleisesti: Tehkää sopimukset ajan kanssa. Usein sopimukset runnotaan kasaan liiassa kiireessä.
Projektin toteutus
Digitalisointiprojektissa kohtaavat usein infromaatioteknologian ja tietyn liiketoiminnan tai prosessin ammattilaiset. Mitä syvemmälle osaamisessa mennään, sen todennäköisemmin nämä kaksi ryhmää puhuvat eri kieltä. Siitä ei kannata yllättyä. Digitalisointiprojektin toteutusvaiheessa uidaan todella syvissä vesissä. Ollaan lopulta sellaisten kysymysten äärellä, kuten: ”Mikä laitetaan kentän nimeksi?”, ”Mitä fonttia käytetään?”, ”Monelta tiedonsiirto ajastetaan?”.
Laadukkaat ja ketterät kommunikointikeinot ja läpinäkyvyys tuovat projektiin kuin projektiin tehokkuutta. Myöskään dokumentaatiota ei saa unohtaa, niin turhalta kuin sen tekeminen kaikessa kiireessä tuntuukin. Toimittajalta vaaditaan tietyt dokumentit, mutta myös omalta organisaatiolta vaaditaan dokumentointikykyä. Valmiit dokumentaatiopohjat auttavat usein paljon.
Koska syväosaaminen ostajalla ja myyjällä kohdistuu usein eri asioihin, aiheuttaa se väkisinkin myös väärinkäsityksiä. Ihmisellä on taipumus mennä asioiden edelle ja hyppiä johtopäätöksiin liian nopeasti. Tämän vuoksi liiketoimintaihmisen ja teknisen ihmisen tekemät oletukset toistensa osaamisalueista voivat osoittautua projektin edetessä vääriksi. Usein näin tapahtuu ainakin pienemmässä mittakaavassa. Tämä puolestaan edellyttää muutoksia alkuperäisiin suunnitelmiin. Toimivassa projektissa muutokset tehdään ostajan ja myyjän välillä hyvässä yhteisymmärryksessä ja esimerkiksi ongelman ilmettyä tiivistetään kommunikaatiota automaattisesti sen ratkaisemiseksi. On kuitenkin hyvä muistaa, että toimittajalla on usein resurssit varattuna muihinkin projekteihin, joten asiantuntijan hyödyntäminen suunniteltua enemmän ei välttämättä onnistukaan saman tien.
Väärinkäsitysten vuoksi on liiankin tyypillistä, että asiakas joutuu tilanteeseen, jossa hänen on palvelun tai teknologian toimintalogiikan takia valittava sellaisista ratkaisuvaihtoehdoista, joista yksikään ei ole täysin sitä mitä on ajateltu. Tässä esimerkki elävästä elämästä, jossa konfiguroitavana on valmisohjelmisto:
Asiakas: Haluaisimme, että kentässä ”Toimipiste” käytetään pudotusvalikkoa
Toimittaja: Sopii, mutta pyydän huomioimaan, että mikäli käytätte pudotusvalikkoa, teille ei jää historiatietoja aiemmista valinnoista. Jos käytätte tavallista, vapaasti kirjoitettavaa kenttää, historiatieto tallentuu.
Esimerkin valmisohjelmistossa ei ole muuta vaihtoehtoa kuin valita joko pudotusvalikko vai historiatieto.
Pudotusvalikko olisi tärkeä, jotta Toimipisteet saataisiin valittua standardisti listasta. Historiatieto puolestaan voi olla raportoinnin kannalta tärkeä. Lopulta asiakas valitsee pudotusvalikon.
Asia voi tuntua pikkujutulta, mutta sillä voi olla isoja vaikutuksia palvelun käyttöön asiakkaalla. Tämän tyyppinen outous toimintalogiikassa ei tule ilmi, jos vaatimusmäärittelyyn on listattu ”historiatiedon tallentuminen” ja ”pudotusvalikoiden käyttö”, sillä molempiin vaatimuksiin toimittaja olisi voinut vastata ”Kyllä, onnistuu”. Vaikkakaan ei samanaikaisesti, mutta kukapa sellaista olisi osannut kysyä.
Tämäntapaisten hankaluuksien ymmärtämiseksi valmiiden palveluiden aito demokäyttö ennen ostopäätöstä on tärkeää. Jos tarkoitus on räätälöidä tai toteuttaa palvelu alusta saakka itse, on valittujen teknologioiden ymmärtäminen puolestaan tärkeää. Miksi olemme valinneet juuri nämä teknologiat? Kysymykseen on hyvä osata vastata.
Jotta isommilta väärinkäsityksiltä vältyttäisiin, on digitalisointiprojekteissa yhä enenevässä määrin otettu käyttöön vesiputousmallin sijaan tai sen lisänä ns. ketterät menetelmät. Ketterien menetelmien käyttö on aikanaan lähtenyt ohjelmistokehitysprojekteista, mutta soveltaen ne toimivat hyvin myös useimmissa digitalisointiprojekteissa. Ketterissä menetelmissä ideana on, että ratkaisua kehitetään lyhyissä sykleissä, ns.sprinteissä. Ratkaisun ensimmäiset tuotokset ovat käytössä nopeasti, jolloin myös uuden palvelun omaksuminen käynnistyy heti. Tämä edesauttaa yhteisen ymmärryksen saavuttamista eri osapuolten välillä ja muutoksia voidaan tehdä nopeasti ja tehokkaasti kun saadaan heti tuntuma siitä mistä on kyse. Mikäli ketteriä menetelmiä sovelletaan valmiin palvelun konfigurointiin, ovat räätälöintimahdollisuudet kuitenkin rajalliset. Samoin tietyn teknologian valinta voi muodostaa rajoitteita, jotka saattavat nousta esiin vasta tässä vaiheessa. Jotta totaalisilta showstoppereilta vältyttäisiin, olisi kaikkien osapuolten edun mukaista, että tämäntyyppiset ongelmat nousisivat esiin jo ennen toteutusta.
Laadunvarmistus digitalisointiprojektissa
Laadunvarmistus projektissa, niin itse projektityöskentelyn kuin tuotosten suhteen on selkeä tulevaisuuden kehityskohde. Laadunvarmistus ei välttämättä ole toimittajalle ykkösasia, vaan toimittaja saattaa reagoida vasta kun asiakas ilmiottaa ongelmista. Toimittajasta on joskus nähtävissä, että kaikki on hyvin, kunhan asiakas on riittävän tyytyväinen, ts. joka laatupoikkeamista huolimatta on valmis maksamaan palvelusta. Tämä voi näkyä esimerkiksi siten, että toimittaja vähättelee ongelman merkitystä tai ei aktiivisesti edesauta sen selvittämistä.
Laadunvarmistuksessa haasteita aiheuttaa usein myös it-maailmassa tyypillinen monitoimittajaympäristö, jossa yhden palvelun ongelma voi heijastua moniin muihin palveluihin tehden juurisyyn selvityksestä vaikeaa. Laadunvarmistuksen kehittyminen systemaattisempaan, proaktiivisempaan ja läpinäkyvämpään suuntaan myös toimittajien osalta olisi varmasti kaikkien osapuolten etu. He tuntevat omat palvelunsa, järjestelmänsä ja teknologiansa ja tietävät parhaiten minkätyyppisiä ongelmia on mahdollista tulla vastaan. Edellisessä kappaleessa kuvattu kuvitteellinen keskustelu asiakkaan ja toimittajan välillä on hyvä esimerkki. Asiakas kokee laatupoikkeaman, josta toimittaja on varmasti ollut tietoisempi kuin asiakas. Tätä ei ole kuitenkaan tuotu esille. Laadunvarmistuksen suhteen palveluntarjoajissa ja jopa yksittäisissä henkilöissä voi olla huomattavia eroja.
Laadunvarmistuksessa olennainen asia on testaus ja testauksen asianmukainen dokumentointi. Lisäksi on hyvä ymmärtää, että teknisiä ratkaisuja kehitettäessä on usein mahdollista, että päivänä 1 toimivaksi todettu toiminto ei päivänä 2 enää toimi. Tämä johtuu siitä, että ratkaisun eri osat ovat usein riippuvaisia toisistaan, ts. kun liikutat yhtä palikkaa, kaikki palikat liikkuvat. Yksi muutos tai korjaus voi siis rikkoa aiemmin toimineen toiminnon. Siksi muutosten jälkeen kannattaa aina testata kriittiset toiminnot.
Yksi keino varmistaa laatu projektissa on pilotointi eli ratkaisun tuotantokäyttö pienemmällä kohderyhmällä. Jokainen pilotoinnin johdosta löydetty kehityskohde edesauttaa varsinaisen käyttöönoton onnistumista, sillä siihen ehditään vielä reagoida. Kehityskohteita voidaan löytää paitsi teknisistä seikoista myös esim. prosesseista, tietomalleista, koulutuksesta ja viestinnästä.
Digitalisoinnin käyttöönotto ja jalkautus
Viestintä on digitalisoinnin käyttöönoton ja jalkautuksen kulmakivi. Selkeää ja käyttäjiä puhuttelevaa viestintää ei ole koskaan liikaa. Tärkeää on selittää miksi tämä koskee juuri minua? Miksi minun pitäisi vaivautua? Siitähän on lopulta kyse. Sama pätee sekä organisaation sisällä tehtävään digitalisointiin että uuden palvelun lanseeraamiseen. Digitalisoinnissa on kyse muutoksesta eikä muutos tule itsestään, vaan sitä pitää johtaa. Keinoja on monia, tässä muutama:
- Aloita ajoissa
- Osallista mahdollisimman moni, sitouta avainhenkilöt
- Mieti miten viestit puhuttelevasti eri kohderyhmille (aihe ei välttämättä aina puhuttele), ole luova!
- Viesti eri kanavissa ja riittävän usein
- Rakenna muutosagenttien verkosto
- Kouluta
- Kuka aktivoi käyttäjiä ja kuulee heitä haasteissa?
SWOT-analyysi
Seuraavassa on esitelty Digitalisointiprojekteihin liittyviä vahvuuksia, heikkouksia, mahdollisuuksia ja uhkia.
Vahvuudet: Liiketoiminnan kehittäminen, muutosten aikaansaaminen hallitusti.
Heikkoudet: Onnistumisen arviointi, vanhanaikaiset mittarit
Mahdollisuudet: Laadunvarmistuksen paraneminen, mittareiden kehittyminen. Yhteiset sopimukset usean toimittajan kanssa. Riskien jakamisen kehittyminen. Läpinäkyvyyden ja tiedonjaon paraneminen.
Uhat: Byrokratian ja protektionismin lisääntyminen. Kuilun kasvaminen liiketoimintaosaajien ja informaatioteknologia-asiantuntijoiden välillä.
Kirjoittaja: Eeva Melama, ite wiki oy
