Pilvipalvelun ostaminen on monipolvinen prosessi. Ennen kuin tarttuu ensimmäiseen tarjoukseen, kannattaa asiaan syventyä kunnolla. Controller Mika Vesa Auditar Oy:stä avaa kirjoituksessaan, mitä eri vaiheita hankinnassa on syytä huomioida.
Lehdessä ja netissä uusi ohjelmistotalo kertoo ilosanoman. Nyt on tullut hyvä uusi pilvipalveluna toteutettu ohjelmistokokonaisuus, järjestelmä, jolla voidaan hoitaa kaikki asiat ajasta ja paikasta riippumatta ja lähes vain nappia painamalla!
Ajatus alkaa hahmottua. ”Meillähän on nykyinen ohjelmisto ollut jo aika kauan ja olisi varmaan syytä uudistua ja siirtyä tälle vuosituhannelle tai ainakin vuosikymmenelle. Nykyiseen ohjelmaan ei ole tullut mitään uudistuksiakaan pitkään aikaan. Nykyinen järjestelmä on asennettu paikallisesti ja pilvipalvelu on nykyaikaa.”
Mielenkiinto heräsi ja myyjä voi tulla esittelemään ohjelmistoa. Myyjä näyttää demoaineistolla kaiken hienouden mitä ohjelma pitää sisällään Demossa kaikki sujuu leikiten ja aikaa säästäen. Ohjelmalla voi tehdä sitä ja ohjelmalla voi tehdä tätä ja vielä tuotakin. Tilanne, jossa ohjelmatoimittaja johtaa puhetta ja kertoo kaikki hienot ominaisuudet ja muut paikallaolijat nyökkäilevät tyytyväisenä. Myyjä kertoo mitä me tarvitsemme. Tilanne etenee esittelijän käsikirjoituksen mukaan. Demossa ovat paikalla yrityksen ylin johto koska he päättävät yrityksen rahan käytöstä ja heillä on kokonaiskuva hallussa ja selkeä visio tulevasta.
Yrityksessä tehdään päätös hankinnasta ja kerrotaan henkilöstölle uudesta järjestelmästä, joka otetaan käyttöön heti tai kuukauden kuluttua.
Yllä oleva esimerkki on ehkä hieman kärjistetty, mutta kuvaa tilannetta joka on yleinen.
Pitäisikö kuitenkin edetä hieman eri järjestyksessä?
Nykyinen järjestelmä on mahdollisesti ollut käytössä jo vuosia. Jos se toimii, ohjelmatoimittaja on edelleen olemassa ja tukea on saatavilla sekä tarvittavat muutokset ohjelmaan on saatavissa esimerkiksi lain tai muun tarpeen ilmaantuessa, ei tarvetta uudelle välttämättä ole Nykyisen ohjelman alkukankeudet ovat takanapäin, ohjelman käyttö osataan ja ohjelmassa olevat puutteet on tiedossa ja on käytössä kiertotie asioiden tekemisessä. Mikäli organisaation käyttöjärjestelmät uusitaan, on selvitettävä ohjelmien järjestelmävaatimukset ja onko kaikkien oltava samalla alustalla. Jos nähdään, että ohjelman vaihto on väistämätön, on syytä aloittaa tarvekartoitus ja mallinnus:
- mitä tarvitaan?
- miksi tarvitaan?
- milloin tarvitaan?
- millaisilla resursseilla lähdetään asiassa etenemään
Usein odotetaan sopivaa hetkeä. Esimerkiksi hetkeä kun on vähän hiljaisempaa ja on aikaa perehtyä asiaan. Tällaista aikaa ei tule ja parempi on aloittaa nyt. Mutta kuka tekee, kun kaikilla on kiire ja aikataulut ovat tiukat jo pelkästään omien töidenkin suhteen. Omien töiden ohessa vaatii paljon keskittymiskykyä ottaa projektin vetovastuu tai olla sitoutuneena ja innostuneena mukana uudessa projektissa.
On suunniteltava ketkä kuuluvat projektiryhmään ja millä panoksella, kuka tekee tarvekartoituksen, aikatauluttaa, käy läpi järjestelmätoimittajat ja eri järjestelmien rajapintoja. Dokumentointi ja projektin hallinnointi sekä raportointi ovat tärkeitä tehtäviä, jotka on otettava käyttöön ensivaiheessa.
Tärkeää on miettiä asia organisaation kannalta eikä vertaillen nykyiseen järjestelmään. Tilanteessahan ollaan usein siitä syystä, että nykyinen järjestelmä vaihdetaan uuteen. Järjestelmän pitää sopeutua meidän tarpeeseen eikä niin, että me sopeudumme siihen kuinka järjestelmä toimii. Kompromisseja toki joudutaan tekemään.
Selkeänä tarkastuksen kohteena on ainakin seuraavia asioita:
- Uuden järjestelmän toiminta tilanteissa, joissa vanhassa oli puutteita (Näiden puutteiden takia ollaan uusimassa)
- Uuden järjestelmän oleelliset puutteet meille tärkeissä tilanteissa
- Uuden järjestelmän muutokset lain tai omien tarpeiden vuoksi
- Aikataulut ja kustannukset
Siirtyminen vaatii resursseja ja aiheuttaa kustannuksia, ja on tärkeää arvioida nykyisen järjestelmän uudistamis- ja jatkomahdollisuuksia. Vaikka nykyisessä järjestelmässä olisi puutteita ja vikoja, ovat ne mahdollisesti sellaisia, että niiden kanssa voi elää. On myös selvitettävä onko vika järjestelmässä vai käyttäjässä.
Järjestelmän käyttäjä ei saa dominoida valintaa/vaihtamista vääristä syistä. Järjestelmän käyttäjien koulutus on tärkeää, jotta järjestelmää käytetään tehokkaasti ja oikein, eikä tapahdu väärään suuntaa menevää itse oppimista. Mikäli koulutusta ei esimerkiksi ohjelmapäivitysten jälkeen uusiin ominaisuuksiin saada, voi työntekijä tuskastua ja nähdä järjestelmässä enemmän ongelmia kuin tosiasiassa on.
Ei pidä aliarvioida muutosvastarintaa. Uusi järjestelmä tuo paljon uudistuksia henkilöstön työskentelyyn ja ajankäyttöön varsinkin alkuvaiheessa. Resurssien kohdentaminen projektiin on suunniteltava huolella. Aiheeton istuminen palavereissa vaikuttaa negatiivisesti ja aiheuttaa passiivisuutta.
Muutoksen johtamiseen pitää varata resursseja projektin aikana, mutta myös projektin jälkeen. On huolehdittava sitoutumisesta uuteen tilanteeseen ja tilanteen vakauttamiseen. Kun uutta järjestelmää valitaan, informoidaan siitä organisaatiossa ja järjestelmän käyttäjien tulee olla edustettuna projektissa heti alkuvaiheessa. Heillä on käytännön tietotaito tämän hetken tilanteesta sekä korjaus-, parannus-, muutosehdotuksia. Heitä pitää kuunnella.
Henkilöstö sitoutetaan projektiin ja jokaiselle määritellään oma vastuualueensa. Kulloinkin tarvittava määrä resursseja vie projektia eteenpäin.
Nykyistä järjestelmää käytetään kunnes uusi on valittu, testattu, koekäytetty ja asennettu, tiedot siirretty ja henkilöstö koulutettu. Tämänkin jälkeen käytetään usein kahta järjestelmää päällekkäin tietyn ajan, jotta voidaan varmistua, että uusi järjestelmä toimii käytännössä.
Testiaineistolla ei päästä varmuuteen
Vaikka järjestelmää on testattu, tulee eteen odottamattomia tilanteita, jotka aiheuttavat ongelmia. Ongelmien raportointi, niiden selvittäminen sekä tämän aikataulu on oltava tiedossa ennen ongelmien ilmaantumista.
Jokainen päivitys tai järjestelmävaihto tuo tehokkuutta ja usein myös kustannussäästöjä. Järjestelmän asetuksilla päästään eroon manuaalityöstä ja asioita tapahtuu määritysten mukaisesti.
Kirjanpito ja siitä johdettu tilinpäätös tehdään niiden samojen sääntöjen mukaan kuin ennen automatisointia. Arvonlisäverot lasketaan, kirjataan, ilmoitetaan ja maksetaan kuten aiemminkin. Ostolaskut tiliöidään kulutileille, kohdistetaan projekteille, kustannuspaikoille. Jonkun on valvottava, että kaikki menee oikein. Valvonta, tarkastukset, hyväksymiset ja kontrollitoimenpiteet korostuvat. Kirjanpitäjän rooli ja osaamisvaatimukset muuttuvat. Kirjanpitäjästä tulee yritysjohdon kumppani.
Järjestelmävalinnan pitäisi tapahtua vasta viime vaiheessa ja siihen on matkaa. Nykyisin eri järjestelmät ovat toiminnallisuuksiltaan lähellä toisiaan. Mikä näistä soveltuu parhaiten jollekin yritykselle, ei kerro sitä, soveltuuko se meille.
Mitä apua Tilintarkastustoimisto Auditar Oy voi tarjota?
On monta porrasta kiivettävänä ja alla on lueteltu muutamia. Ne eivät ole kronologisessa järjestyksessä, mutta ne lisäävät ymmärrystä siitä, mikä liittyy järjestelmän kehittämiseen tai vaihtamiseen hallitusti.
- liiketoimintaprosessien kuvaaminen
- mitä tarvitaan ja miksi
- onko itsellä resursseja ja aikaa
- onko ilmapiiri otollinen
- mitä tietoa tarvitaan liiketoiminnan johtamisessa ja ohjaamisessa
- mitkä ovat tarpeet lähivuosina
- taipuuko vanha järjestelmä uuteen
- missä vaiheessa siirtyminen tulee tehdä
- arvio järjestelmän käytöstä ja hyödyntämisestä suunnitellulla tavalla
- valvonta ja kehittäminen, miten järjestelmän toimintaa pitää muuttaa