Kuulin erään asiantuntijaorganisaation HR-järjestelmän käyttöasteesta. Uusi järjestelmä hankittiin pari-kolme vuotta sitten ja sen piti kattaa laajasti työsuhteen elinkaaren hallinta lähtien rekrytoinnista uuden työntekijän tietojen perustamiseen, perehdytykseen, työntekijän osaamisen kehittämiseen ja päättyen lopulta työsuhteen päättämisen toimenpiteisiin.

Olin silloin itsekin tarjoamassa asiakkaalle ratkaisua, mutta se rankattiin heti alkumetreillä pois, koska ratkaisussa ei ollut mukana palkanlaskentaa ja asiakas näki ehdottomana, että palkanlaskentaosio pitää olla samalta toimittajalta.

Tilanne on tällä hetkellä se, että HR-järjestelmä on käytössä kyllä aktiivisesti palkanlaskennassa ja palkanlaskijat ovat siihen oikein tyytyväisiä.

Paha vaan, että palkanlaskijat ovat lähes ainoa käyttäjäryhmä, joka HR-järjestelmää tällä hetkellä käyttää. Organisaatiossa on lähes 1 000 työntekijää ja järjestelmää käyttää työsuhteen elinkaaren hallintaan ainoastaan muutama esimies.

En tietenkään voi ko. organisaation puolesta sanoa, miksi tilanne on tämä, mutta uskaltaisin veikata syyksi yhtä tai useampaa seuraavista:

• Järjestelmän hankinta valmisteltiin kehnosti. Ei käyty läpi eri toimintojen vaatimuksia ja odotuksia uudelle järjestelmälle.
• Ratkaisu on käytettävyydeltään kehno. Tätä vaan ei osattu järjestelmän valinnassa tarkastella riittävästi tai oikealta kantilta.
• Toteutus on tehty palkanlaskenta edellä. Ei palkanlaskennassa mitään huonoa ole (sehän pitää toimia pilkulleen oikein!), mutta valitettavan harva palkanlaskentaohjelma on hyvä muissa HR-toiminnoissa. Aniharva.
• Prosesseja ei ole läpikäyty järjestelmähankinnan yhteydessä. Aina, kun hankitaan uutta järjestelmää, pitäisi toimintatavat perata läpi ja uudistaa niitä. Aina!
• Jalkautus on jäänyt tekemättä. Energia, osaaminen tai jokin muu syy aiheutti sen, että loppukäyttäjät unohdettiin. HR-osasto (palkanlaskijat?) sai homman mielestään valmiiksi, kun heidän tarpeensa tyydytettiin. Jalkautus on muutakin kuin järjestelmäkoulutus!

On jotenkin erikoista, että tänä päivänä kun puhutaan paljon digitalisaatiosta, digiloikasta, tuottavuudesta, ketterästä HR:stä ja muusta organisaation toimintaa lähtökohtaisesti tehostavasta, tehdään samaan aikaan todella huonoja järjestelmähankintoja, jotka tuottavuudeltaan ovat pahimmillaan negatiivisia.

Pahinta lienee se, että vaikka projektin aikana huomattaisiin, että ratkaisu ei ehkä olekaan toimiva, vaan suurin osa tavoitteista jää saavuttamatta, kissaa ei uskalleta nostaa pöydälle ja kyseenalaistaa etenemistä. Luonnollista tietenkin, koska jos itse on perusteltu kyseisen järjestelmän hankinta, olisi kovin uskaliasta kritisoida tätä päätöstä.

Sekin on hyvä huomata, että vaikka tilanne näyttäisi nyt siltä, että on tehty väärä hankinta eikä tästä tule mitään, ei se välttämättä tarkoita, että projekti pitäisi keskeyttää.

Aina voi parantaa suoritusta ja suunnitella esim. jalkautuksen paremmin. Tai tehdä tilanteen uudelleen arvioinnin ja korjata muuten suuntaa.

Tiedätkö organisaation, jossa järjestelmähanke uhkaa mennä puihin jollakin edelläkuvatulla tai muulla tavalla? Ilmianna itsesi tai tuntemasi organisaatio, niin nostetaan kissa pöydälle, ennen kuin on myöhäistä!

Pilvipalvelu. Kaikkihan siitä puhuvat, mutta ollaanko aina samalla taivaalla ja ymmärretäänkö, mitä ollaan ostamassa? Pilvipalvelut ovat lyöneet läpi laajalla rintamalla myös HR-järjestelmämarkkinassa. Kukaan itseään kunnioittava HR-järjestelmätoimittaja ei jätä mainostamatta omaa pilvipalveluaan. Mutta mikä merkitys sillä on asiakkaalle, millainen toimittajan pilvipalvelu tosiasiassa on? Katsotaanpa.


Pilvipalveluiden lyhyt historia

Pilvipalveluiden alkutaipaleelta on monenlaista tarinaa. Yksi niistä on Amazonin pilvipalveluiden synty, kun varsinaisen liiketoiminnan ylläpitämisestä jäänyttä ylimääräistä palvelinkapasiteettia alettiin myydä ulos. Syntyi Amazon Web Services, eli AWS.

Oma tarinani pilvipalveluiden alkuun on hieman toisenlainen.

Olin jo vuonna 2000 kehittämässä pilvipalveluperiaatteella toimivaa HR-järjestelmää, tarkemmin sanottuna Skillnetin Artist-rekrytointijärjestelmää. Järjestelmää tarjottiin selainkäyttöisenä toimittajan ylläpitämältä palvelimelta. Silloin tosin puhuttiin ASP-palvelusta (Application Service Providing/Provisioning) tai suomeksi sovellusvuokrauksesta. Myöhemmin termi vaihtui SaaS:iksi (Software as a Service), mutta konsepti pysyi samana.

Järjestelmästä haluttiin sellainen, että se olisi sisältöjen osalta (työhakemuslomakkeet ym.) asiakaskohtaisesti sovitettavissa, mutta itse softakoodia ei tarvitsisi räätälöidä. Tässä onnistuttiin lopulta hyvin, vaikka halu saada isoja asiakkaita oli niin suuri, että olihan siinä koodissa ajoittain asiakaskohtaisuuttakin, kun jokin toiminnallisuus luvattiin asiakkaalle ja sitä ei heti ehditty tuotteistamaan loppuun saakka. Käytännössä kaikki asiakkaat olivat samassa versiossa ja pääsääntöisesti versionvaihto tehtiin yhtä aikaa kaikille. Jokaisella asiakkaalla oli oma tietokanta.

Saavutimme Artistin kanssa merkittävän aseman ja se olikin useilla mittareilla mitattuna Suomen johtava rekrytointijärjestelmä vielä muutama vuosi sitten, kunnes Oikotien tarjonnan alla tarinalle kirjoitettiin uusi luku. Artist-palvelua tarjoaa muuten nykyisin Kaaos Unlimited ja he ovat päivittäneet Artistin teknologian ajanmukaiseksi. Tarina siis jatkuu.

Jo edellä kuvatuissa kahdessa tarinassa näemme kaksi hyvin erilaista pilvipalvelua. AWS tarjoaa alustan, jolla voi pyörittää varsinaisia sovelluksia, kuten Artistia.

Public Cloud, Private Cloud, Hybrid Cloud. Usein toistuvia termejä, mutta mitä niiden taakse voisi kätkeytyä, kun puhutaan HR-järjestelmistä?

Otsikossa kuvatut termit ovat usein toistuvia, kun puhutaan yleisesti pilvipalveluista, mutta niiden sijoittamista HR-järjestelmätarjontaan on vaikea tehdä tarkasti. Käytetyt termit kuvaavat tyypillisesti it-infrastruktuurin, kuten palvelinkapasiteetin jakotapaa, mutta termejä käytetään myös eri järjestelmäratkaisuissa. Jaan HR-järjestelmäpilvipalvelut kolmeen kategoriaan ja otan vapauden sijoittaa termit sujuvasti joukkoon:

1. Kaikille asiakkaille täysin sama asennus (instanssi), sama tuoteversio ja yleensä myös sama tietokanta. Kutsutaan tätä nyt vaikka Julkiseksi pilveksi (Public Cloud). Usein puhutaan myös multi-tenant-ratkaisusta. Mielestäni pisimmälle viety pilvipalvelu, jossa pilvipalvelumallin hyödyt näkyvät parhaiten.
   
2. Jokaiselle asiakkaalle oma asennus, usein eri tuoteversio ja käytännössä aina oma tietokanta. Kutsutaan tätä Yksityiseksi pilveksi (Private Cloud). Usein palveluja, jotka on väkisin työnnetty pilveen, kun muutkin niin tekevät ja asiakas haluaa ostaa pilvipalvelua. Usein kuitenkin kelvollinen ratkaisu, mutta kutsuisin mieluummin ”vain” SaaS-palveluksi.
   
3. Eri asiakkaille oma asennus, usein eri tuoteversio tai oma tietokanta. Jotakin omaa, jotakin yhteistä. Kutsutaan tätä Hybridiksi (Hybrid Cloud).
   

Käytettävästä termistä riippumatta on hyvä ymmärtää HR-pilvipalvelua ostettaessa, mikä on ostettavan palvelun toimintaperiaate ja kuinka hyvin se soveltuu omiin tarpeisiin. On siis tärkeää ymmärtää kunkin ratkaisun ominaisuudet sekä rajoitteet ja mahdollisuudet.

Julkinen pilvipalvelu

Kun HR-järjestelmä toimii Public Cloud -periaatteella, saatte järjestelmän käyttöönne usein hyvin nopeasti, joissakin tapauksissa jopa saman tien ainakin koekäyttöön tilaamalla yrityksen nettisivuilta tunnukset. Tämän jälkeen pääsette pääkäyttäjäoikeuksilla rakentamaan järjestelmän sisältöjä niissä rajoissa, joissa ko. tuote sen mahdollistaa, tekemään siis käyttöönottoa eli implementointia.

Käytännössä aina järjestelmätoimittaja tarjoaa myös käyttöönottopalveluja ja näitä kannattaakin hyödyntää, jotta ratkaisusta saadaan kerralla toimiva. Myös rajapintojen käyttöönotoissa toimittajan rooli on tärkeä. Tämän mallin tyypillisiä ominaisuuksia:

• Kaikkien asiakkaiden tieto on yleensä tallennettu samaan tietokantaan (mutta eri asiakkaiden välillä tietojen näkyminen on koodi-/tietokantaratkaisuilla rajattu hyvin tarkkaan).
  
• Järjestelmä on erittäin pitkälle tuotteistettu ja kaikille asiakkaille saman näköinen.
• Kun toimittaja tekee versiopäivityksen, siitä tyypillisesti tiedotetaan etukäteen, mutta ette pääse itse käytännössä vaikuttamaan, milloin päivitys tehdään.
• Kun tuote kehittyy, saatte joko kaikki uudet piirteet automaattisesti käyttöönne tai toimittajan hinnoittelustrategian niin määrittäessä, voitte ostaa lisäosia (toki osa uusista ominaisuuksista sisältyy aina jo ostettuun palveluun ja tulevat automaattisesti käyttöön).
• Pisimmälle viedyissä tuotteissa lähes kaikki sisältöjen rakentaminen ja asetusten muuttaminen on asiakkaan pääkäyttäjän toimesta mahdollista (jos osaa).
• Palvelu skaalautuu myös hinnoittelun osalta tarpeen mukaisesti.
• Räätälöintiä järjestelmän toiminnallisuuksiin ei tehdä. Piste.
  

Mitä saatte?

• Järjestelmän perusversion yleensä heti käyttöön.
• Aina tuorein versio käytössä järjestelmästä.
• Todennäköisesti nopeammin kehittyvän järjestelmän.
• Aidosti volyymin mukaisen hinnoittelun. Voitte aloittaa esim. koekäytön pienellä käyttövolyymilla ja laajentaa käyttöä tarpeen mukaan.
• Kohtuullisen standardin palvelutason, jota ei välttämättä rahallakaan pysty parantamaan.
  

Mitä menetätte?

• Ette voi vaikuttaa järjestelmän päivitysaikatauluihin.
  
• Mikäli haluaisitte teettää jotakin räätälöintiä järjestelmään, tuskin saatte toimittajalta edes tarjousta. (Toisaalta, kuka haluaa vielä tänä päivänä räätälöidä tällaista perussoftaa, kuin HR-järjestelmä?)
• Joudutte hyväksymään, että henkilötiedot ovat ”fyysisesti” samassa tietokannassa muiden asiakkaiden kanssa ja luottamaan siihen, että ohjelmakoodi ”kestää”.
• Joudutte tyytymään järjestelmään niillä ominaisuuksilla, mitä siinä on. Pääsette vaikuttamaan tuotteen kehittymiseen antamalla enemmän tai vähemmän painokkaasti palautetta toimittajalle.

Yksityinen pilvipalvelu

Private Cloud -periaatteella toimiva HR-järjestelmä vaatii tyypillisesti joko enemmän tai vähemmän projektoidun käyttöönottoprojektin ennen, kuin saatte mitään käyttöönne. Eli ensin tehdään hieman määrittelyjä, jonka jälkeen toimittaja tekee asennuksen, luo tietokannan ja antaa pääkäyttäjätunnukset asiakkaalle. Tyypillisesti toimittaja myös tekee kaikki tai lähes kaikki muutokset järjestelmän sisältöihin. Usein toimittaja on päätynyt tähän malliin, koska (vanhentunut) teknologia ei mahdollista parempaa toteutustapaa. Tämän mallin tyypillisiä ominaisuuksia:

• Jokaisella asiakkaalla on oma asennus ja oma tietokanta.
• Tyypillisesti lähes kaikki muutostyöt sisältöihin tehdään toimittajan toimesta (asiakas määrittelee ja toimittaja tekee lisätyönä).
• Koodia on usein räätälöity eri asiakkaiden tarpeiden mukaan.
• (josta johtuen):
• Päivitykset eri asiakkaille tehdään usein eri aikaan eri asiakkaille ja usein käy niin, että joidenkin asiakkaiden päivitykset roikkuvat. (Tuntuuko, että teillä on vuosia vanha versio käytössä ja oikein mitään uutta ei ole tullut järjestelmään? Syynä voi olla toimittajan tekemä priorisaatio tai se, että käytössänne olevaa versiota on räätälöity niin paljon, että päivitykset tämän vuoksi laahaavat jäljessä.)
  

Mitä saatte?

• Varmuuden, että järjestelmän sisällä tiedot eivät ”sotkeennu” toisen asiakkaan tietojen kanssa (tämä ei tosin varmista sitä, että tietoturva muutoin olisi kunnossa).
  
• Pääsette vaikuttamaan palvelutasoon siten, että se sopii teille mahdollisimman hyvin. Usein tätä tehdään tarpeettomastikin.
• Voitte todennäköisesti sopia toimittajan kanssa, milloin versiopäivitys tehdään.
• Tunteen siitä, että toimittaja toimii ketterästi ja toteuttaa lähes kaikki pyyntönne, mitä keksitte pyytää (rahalla tai ilman). Aluksi.

Mitä menetätte?

• Todennäköisesti käytössänne ei ole koskaan aivan tuorein versio järjestelmästä (riippuen siitä, kuinka vahvassa asemassa olette toimittajan asiakas-luokittelussa).
  
• Pitkässä juoksussa / isossa kuvassa järjestelmä ei kehitykään aivan niin ketterästi, kuin aluksi tuntui. Toimittajan energia menee eri asiakkaiden pienten muutospyyntöjen toteuttamiseen, jolloin tuotekehityksen road map jää jalkoihin. Kuulostaako tutulta?
• Usein toimittaja haluaa kohtuullisen pysyväisluonteisen hinnoittelun (ylöspäin hinnoittelu joustaa toki aina).

Hybridi

Hybrid Cloud -periaatteella toimiva HR-järjestelmä on sitten jotakin edellä kuvattujen välimaastosta. Riippuen ratkaisusta, siinä on tiettyjä etuja mutta myös tiettyjä haittapuolia. Usein tästä kategoriasta voi kuitenkin löytyä se paras ratkaisu. Saatte ehkä standardiratkaisuja järkevällä hinnoittelulla, mutta pystytte myös jonkin verran vaikuttamaan, kuinka järjestelmä taipuu tarpeisiinne.

No mikä sitten pitäisi valita?

Tähän kysymykseen en osaa tältä istumalta vastata. Koska tarpeenne ratkaisevat. Suosittelen tutustumaan ratkaisuihin huolella, jotta tiedätte, mitä saatte. Oma suositukseni on valita mahdollisimman tuotteistettu ratkaisu unohtaen samalla ns. ”toiveiden tynnyri” -ajattelumalli. Se kannattaa pitkässä juoksussa. Ja yleensä myös lyhyessä. Ja tietenkin on myös niitä ratkaisuja, jotka jo ominaisuuksiltaan taipuvat lähes kaikkeen. Mutta hintalappukin on sitten sen mukainen.

Valintaa vaikeuttaa myös se, että toimittajat eivät tyypillisesti kategorisoi palveluaan (osin sen vuoksi, että selkeää kategorisointia on vaikea tehdä), vaan myyvät vain pilvipalvelun helppoutta ja ihanuutta. Asiakkaan vastuulle jää selvittää, mitä mikäkin ratkaisu pitää käytännössä sisällään. Itse järjestelmän ominaisuuksien lisäksi pitää selvittää vielä ylläpitopalveluiden sisältö, tietoturvan taso ym. palveluun olennaisesti liittyvät seikat.

Olen tehnyt 15 vuotta töitä HR-pilvipalveluiden parissa ja tunnen markkinat kattavasti. Mikäli asiaan paneutuminen tuntuu haastavalta omin voimin, autan mielelläni näkemyksen muodostamisessa, mikä ratkaisu sopisi tarpeisiinne parhaiten. Ota siis yhteyttä, niin sovitaan veloitukseton konsultaatio!

PS. Loppuun vielä muistutus, että ratkaisusta riippumatta, paras hyöty uudesta järjestelmästä saadaan ulosmitattua, kun samassa yhteydessä uudistetaan HR-käytännöt ja -prosessit. Älkää siis keskittykö pelkkään teknologiavalintaan, vaan viekää samalla HR- ja esimiestyö kohti ketterämpää maailmaa.

HR-järjestelmä- tai muu järjestelmähankinta työlistalla? Poimi nopeat vinkit, kuinka parannat todennäköisyyttä onnistua järjestelmähankinnassa!

Järjestelmähankinnan onnistuminen ei ole itsestään selvää. Onnistumiseen vaikuttavat monet seikat, kuten kuinka hyvin hankinnan tavoitteet on osattu asettaa (mitäs tässä oltiinkaan hankkimassa), kuinka hyvin esimerkiksi toiminnalliset vaatimukset on määritelty (viestitään tarjoajille hankinnan tavoitteet vaatimusten muodossa) ja kuinka hyvin tunnetaan toimittajien ratkaisut juuri tähän tarpeeseen (tutustutaan huolella markkinoihin). Hyvin tehdyllä valmistelu- ja taustatyöllä voidaan välttää monet sudenkuopat ja ongelmat itse käyttöönottoprojektissa sekä jatkuvan palvelun aikana. Näin varmistetaan järjestelmähankinnasta saatava kokonaishyöty ja saadaan uudesta järjestelmästä mahdollisimman paljon irti.

Lähes jokaisessa järjestelmähankkeessa on itse järjestelmän käyttöönoton lisäksi käytännössä kyse myös muutosprojektista, kun asioita tehdäänkin uuden järjestelmän myötä hieman eri tavalla. Tämän vuoksi järjestelmähankintaa ja -käyttöönottoa ei pitäisi koskaan ajatella pelkästään järjestelmän käyttöönottona. Käyttäjien sitouttaminen jo järjestelmän hankintavaiheessa auttaa merkittävästi käyttöönottoa ja jalkauttamista. Hyvä ja nykyaikainen järjestelmä ei itsessään vaadi merkittävää panostusta käyttäjäkoulutuksiin, mutta uusien käytäntöjen ja muuttuneiden prosessien kouluttamista ei pidä unohtaa. Uudesta hienosta järjestelmästä saadaan paras hyöty vain, jos sitä käytetään tarkoituksenmukaisesti ja mahdollisimman laajasti!

HR-järjestelmähankinta on viestintää

HR-järjestelmä- tai mikä tahansa järjestelmähankinta on loppupelissä viestintää. Ensin asetetaan hankinnalle ja uudelle järjestelmälle tavoitteita sekä mietitään vaatimuksia ja kirjataan niitä ylös. Välissä tutustutaan toimittajien ratkaisuihin, jotta osataan suhteuttaa omat vaatimukset markkinoilta löytyviin ratkaisuihin. Lopuksi viestitään nämä vaatimukset mahdollisimman selkeästi tarjoajille, eli järjestelmätoimittaijlle. Tässä apuna toimii huolellisesti kirjalliseen muotoon tehty tarjouspyyntö. Hyvin laadittu tarjouspyyntö antaa tarjoajille selkeän kuvan, mitä asiakas tarvitsee ja minkälaisia reunaehtoja asiakas on hankinnalle asettanut.

Toiminnallisia- ja muita järjestelmän vaatimuksia kuvattaessa on pysyttävä kohtuudessa ja mitoitettava vaatimukset hankinnan kohdetta vastaavaksi. Täytyy muistaa, että järjestelmätoimittajillakin on omia reunaehtojaan, mistä hankkeista kiinnostuvat. Mikäli tarjouspyyntö on ehdoiltaan kohtuuton, voi järjestelmätoimittajan mielenkiinto lopahtaa ja tarjous jää tekemättä.

Erityisesti julkisissa hankinnoissa tämä on tärkeää, koska hankintayksiköllä on velvollisuus hylätä tarjoukset, jotka ovat tarjouspyynnön vastaisia. Muutoin joudutaan suurella todennäköisyydellä markkinaoikeuteen, jolloin hanke vähintäänkin viivästyy. Tarjouspyyntöön ei siis saisi päätyä sellaisia rajoittavia tekijöitä, joilla ei tosiasiassa ole merkitystä hankinnan kannalta.

Tarjouksen hinta ei ole koko totuus kustannuksista

HR-järjestelmän hankinta on pitkäaikainen investointi, jonka vuoksi järjestelmän valintavaihe on tehtävä huolella. Tänä päivänä erityisesti HR-järjestelmä ostetaan lähes aina pilvipalveluna, joka osaltaan pienentää kertainvestointia ja helpottaa tarvittaessa järjestelmän vaihtoa, kun ei tarvitse miettiä, kuinka paljon rahaa on ”heitetty hukkaan”. Käyttöönotossa rahallinen panostus on tyypillisesti kuitenkin se pienempi osuus hankinnasta. Sisäisen työn määrä järjestelmän käyttöönotossa ja jalkauttamisessa on usein suurempi panostus, joka helposti unohdetaan.

Jos ajatellaan HR-järjestelmän käyttöönottoa vähänkään suurempaan organisaatioon, puhutaan joka tapauksessa isosta jalkautustyöstä, ennen kuin järjestelmä on koko henkilöstön ulottuvilla ja arkikäytössä. Tämän vuoksi järjestelmän hankintaan ja käyttöönoton valmisteluun kannattaa panostaa hieman enemmän, jotta voidaan välttyä suurelta ylimääräiseltä työltä mahdollisen virhehankinnan vuoksi. Sitä paitsi, se työ, mikä tehdään hankinnan valmistelussa, tulee käyttöönottovaiheessa takaisin monin verroin.
Hyvällä sopimuksella varmistat tavoitteiden täyttymisen

Onnistuneen tarjouskilpailun lopputuloksena on yleensä voittaneen tarjoajan kanssa solmittu toimitus-/palvelusopimus, jonka jälkeen käynnistetään käyttöönottoprojekti. Sopimuksen tarkoitus on varmistaa, että asiakas saa sitä, mitä oli tarkoitus hankkia (eli tavoitteiden mukaista palvelua). Huolellisesti ja hyvässä yhteistyössä toimittajan kanssa laaditulla sopimuksella saavutetaan yleensä erinomainen lähtökohta onnistuneelle käyttöönottoprojektille ja jatkuville palveluille. Hyvä sopimus on yhtä kuin molemmin puolin ymmärretty ja hyväksytty tahtotila, mitä toimitukseen sisältyy, millä tavalla projekti halutaan viedä läpi ja kuinka jatkuvien palveluiden pitäisi sujua.

Mikäli toimitus-/palvelusopimukseen ei aseteta minkäänlaisia sanktioita esimerkiksi toimituksen myöhästymisestä tai selkeistä palvelutason alituksista, voi näistä olla vaikea vääntää kättä silloin, kun olisi aihetta. Palvelupoikkeamiin on paras varautua sopimuksessa ja kun sopimus on hyvä, ei siihen todennäköisesti tarvitse palata, vaan se jo itsessään motivoi toimittajan tuottamaan laadukasta palvelua. Usein puhutaan sopimusvalvonnasta, mutta itse kiinnittäisin huomiota mieluummin palvelun valvontaan, eli täyttääkö saatu palvelu ne tavoitteet, joita hankkeen alussa asetettiin. Mikäli kaikki on kokonaisuutena mennyt hyvin, voi olla, että jokainen sopimuksen yksityiskohta ei ole täyttynyt prikulleen, mutta näihin on tuskin tarvetta puuttua. Voihan olla, että vastaavasti joissakin asioissa toimittaja on ylittänyt reippaasti asiakkaan alkuperäiset tavoitteet ja sen ansiosta ollaan erittäin tyytyväisiä. Tässä kohtaa voidaan tietysti kysyä, että mikäli tavoitteita ei ole asetettu, niin mitä vasten palvelun toteutumista sitten peilataan? Niinpä.

Tiukat sopimusehdot ja sanktioinnit ovat niitä tilanteita varten, joissa tuntuu, että oikein mikään ei tunnu menevän hyvin tai palvelussa on jatkuvasti isompia tai pienempiä puutteita. Tällöin on helpompi ottaa toimittaja tiukkaan puhutteluun ja penätä sopimuksen velvoitteiden perään sekä vaatia tarvittaessa hyvityksiä. Mikäli sopimus on väljästi laadittu, jää ainoastaan reklamaation mahdollisuus ja toive, että toimittaja tekisi jotakin.

Hyvä projektinhallinta ja oikeat resurssit varmistavat onnistuneen käyttöönoton

Lyhyesti voisi kiteyttää, että hyvin valmistellulla ja suunnitellulla projektilla sekä oikein mitoitetuilla resursseilla mahdollistetaan käyttöönoton onnistuminen. Liian usein odotetaan, että toimittaja hoitaa projektin ja asiakas vain osallistuu muutamaan projektipalaveriin.

Tosiasiassa esimerkiksi HR-järjestelmän käyttöönotossa asiakkaan rooli projektin onnistumisen kannalta on avainasemassa. Projektin eri vaiheissa tarvitaan myös asiakkaan päässä hyvää projektiosaamista. Lisäksi erilaisten toimenpiteiden, kuten vaikkapa datamigraatioiden toteuttaminen ilman asiakkaan panostusta jää kokonaan tekemättä.

Varaudu siis jo etukäteen riittävällä resursoinnilla ja ammattitaidolla. Yksi hyvä keino on ottaa myös sisäiseen projektinhallintaan ulkopuolinen asiantuntija, joka tuntee ko. järjestelmäkentän ja on vienyt läpi vastaavia projekteja. Tällainen henkilö voi toimia projektipäällikön roolissa myös toimittajaan päin yhteyshenkilönä ja ymmärtää paremmin myös toimittajan ”kieltä”. Näin omat resurssit voidaan käyttää tehokkaammin ja aikaa jää kunkin projektitiimiläisen varsinaiseen työhön.

Muistilista järjestelmähankintaan

• Aseta hankkeelle tavoitteet (toiminnalliset & taloudelliset) sekä varaa resurssit jo hankintavaiheeseen (sisäiset & ulkoiset)
• Kuvaa prosessit tavoitetilassa (näitä tarkennetaan sitten valitun ratkaisun mukaan)
• Tutustu markkinoihin ja toimittajien ratkaisuihin
• Kuvaa vaatimukset riittävällä tasolla tarjouspyyntöön (pidä vaatimukset realistisina ja tarkoituksenmukaisina)
• Anna toimittajille aikaa ja edellytykset tehdä paras mahdollinen tarjous
• Varmista, että tarjoukset sisältävät halutun laajuuden
• Varmista tavoitteiden täyttyminen ja varaudu poikkeamiin hyvällä sopimuksella
• Varaa käyttöönottovaiheeseen riittävästi resursseja talon sisältä ja hanki tarvittaessa ulkopuolista tukea

Vielä lopuksi, hankinnan voi tehdä itselleen helpoksi ottamalla avuksi asiantuntijan, joka tuntee markkinat ja on ennenkin vienyt läpi vastaavia hankkeita.