Ohjelmistoyrittäjät ry tutki vuonna 2013 yhdessä Celkee Oy:n ja Tietotekniikan liitto ry:n kanssa tietojärjestelmien hankintaa. Tutkimuksen mukaan tilaajien mielestä hankinnan kunnollinen resursointi ja valmistelu ovat tärkein tekijä järjestelmähankkeen onnistumiselle. Tämä on helppo allekirjoittaa.

Usein käy niin, että kun hankkeelle ei ole osoitettu riittäviä resursseja, koko hanke ei lähde käyntiin. Toimitaan huonoilla järjestelmillä tai ilman järjestelmiä ja halua olisi uudistaa, mutta hanke ei pyörähdä käyntiin, kun kukaan ei ehdi. Vanha totuus kuvaa tätä hyvin, eli juostaan moottoritien laitaa samalla kun autot sujahtavat ohitse, mutta ei ehditä pysähtyä, jotta voitaisiin nousta kyytiin.

Kun vihdoin sitten kypsytään riittävästi tilanteeseen, lykätään vastuu jollekin ja sanotaan, että nyt täytyy saada tämä asia kuntoon. Ongelmaksi muodostuu silti usein se, että edelleenkään hankkeelle ei ole saatu riittävästi resursseja. Esimerkiksi HR-päällikköraukka joutuu YT-kierrosten puristuksessa vielä hankkimaan uuden HR-järjestelmän (jos nyt saa siihen ylipäänsä rahaa).

Tässä kohtaa onkin syytä miettiä, onko talossa sellaista osaamista, jonka avulla koko hanke voidaan viedä läpi? Jos tällaista osaamista löydetään, täytyy näille henkilöille varata riittävästi aikaa hankkeen ajaksi. Ei voida olettaa, että kukaan pystyy muiden töidensä ohella viemään vaativan järjestelmähankkeen läpi. Toisaalta, ei pidä lastata koko projektia myöskään yksille harteille. Hyvä olisi olla backupia esimerkiksi sairastumisten tai muiden tilanteiden varalle, jotta projekti ei jää seisomaan.

Mitä osaamista sitten tarvitaan?

Kaikista tärkeintä on ymmärtää, mihin tarpeisiin ja mitä ollaan hankkimassa. Nykyisessä pilvipalveluiden maailmassa esim. teknisen osaamisen merkitys ei ole niin suuri. Monia järjestelmähankkeita voidaan viedä läpi jopa täysin ilman tietohallinnon osallistumista. Mikäli tarvitaan rajapintoja tilaajan muihin järjestelmiin (esim. AD tai IDM) ja näiden ylläpito on tietohallinnon vastuulla, tarvitaan toki IT-osastokin mukaan.

Tärkeimpänä siis substanssiosaaminen siltä alueelta, mille järjestelmää ollaan hankkimassa, esim. HR:stä, myynnistä, tuotannonohjauksesta, jotta järjestelmälle osataan asettaa oikein mitoitetut vaatimukset ja projektin aikana myös uudistaa ja kuvata prosesseja. 

Hankintaosaamisesta on toki hyötyä, eikä muutoksenhallinnanosaaminenkaan olisi haitaksi. Sitä tarvitaan koko hankkeen läpiviennissä, mutta erityisesti jalkautuksessa. Hienointa olisi, jos talossa olisi henkilöitä, joilla on sekä osaamista että kokemusta kaikilta em. osa-alueilta.

Osaamisen ja resurssien lisäksi kaikille järjestelmille pitäisi pystyä osoittamaan ns. omistaja. Henkilö, joka viime kädessä vastaa siitä, että hankkeen tavoitteet toteutuvat, liiketoiminnan tarpeet saadaan täytettyä ja järjestelmä saadaan jalkautettua organisaatioon. Henkilö on usein myös tilaajan projektipäällikkö. Hankkeessa hän on joka tapauksessa avainroolissa. Hänellä pitäisi olla valtaa tehdä tarvittavia pienpäätöksiä projektin aikana, jotta projekti ei turhaan seiso pienen muutospyynnön hyväksynnän vuoksi.

Hulluinta on se, jos jokaisesta pienestä muutospyynnöstä joudutaan kysymään lupa ylemmältä taholta. Olen usein katsonut, kun puolen tunnin lisätyöstä on lähtenyt tilaajan päässä hyväksyntäkierros käyntiin. Pelkästään tähän liittyvästä viestinnästä on tullut suurempi kulu ja toimittajan(kin) kannalta olisi ollut järkevintä alun perin tehdä ko. muutostyö veloituksetta.

Oikeilla resursseilla saat todellakin tolkullisen suunnan koko hankkeelle. Ja muista, että vähemmän on enemmän. Ei ole mitään järkeä haalia jokaiseen määrittelytyöpajaan 10 henkeä eri puolilta organisaatiota. Palaverin ajasta menee puolet siihen, kun kinastellaan täysin merkityksettömistä asioista.

Ja ennen palaveria odotetaan kaikki paikalle, sähköpostin luku- ja muista tauoista puhumattakaan. Ei siis tuhlata kaikkien aikaa, vaan otetaan mukaan sellaiset henkilöt, joilla oikeasti on merkitystä (ja osaamista ko. asiaan).

Mikäli huomaat, että sisäiset resurssit ovat liian ohuet hankkeelle, selvitä ulkoisten resurssien käyttömahdollisuudet ja hyödynnä niitä.

PS. kirjoituksen alussa viitattuun tutkimukseen pääset tutustumaan täällä.

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.