Miksi valmisohjelmisto on usein räätälöityä parempi vaihtoehto?

Talousjohtajat joutuvat osallistumaan käytännössä aina yrityksen ohjelmistohankkeisiin ja siten myös valintaan valmisohjelmiston tai räätälöidyn ratkaisun välillä. Ratkaisujen kirjo etenkin taloushallinnon ohjelmistoissa on laaja. Ensimmäinen ja varsin merkittävä haaste tulee usein eteen jo siinä kohtaa, kun pitäisi päättää kriteereistä.

Kun me sovelluskehittäjät ja palveluntarjoajat kuuntelemme asiakkaiden toiveita ja tarpeita uudelle järjestelmälle, kuulemme usein asiakkaan olevan toimialalla uniikki tai ainakin hieman erilainen kuin muut. Joskus yrityksen kilpailuetua perustellaan ohjelmistoilla, ja siksi asiakas kuvittelee olevansa kiinnostunut nimenomaan räätälöidyistä ratkaisuistamme.

Luonnollisesti kaikilla asiakkailla on oikeus kokea olevansa uniikki ja erilainen, mutta palveluntarjoajan vastuulla on suositella asiakkaille ratkaisua, joka parhaiten sopii asiakkaan nykyisiin ja lähitulevaisuuden tarpeisiin. Uuden järjestelmän tulee nykytarpeiden kattamisen lisäksi olla tarpeeksi skaalautuva, jolloin käyttötarpeiden laajentuessakin sen ylläpito ja kehittäminen ei vaadi varsinaista räätälöintiä. Kehittäminen voidaan hoitaa ketterästi ja kustannustehokkaasti, esimerkiksi uusia moduuleja tai toiminnallisuuksia päälle kytkemällä.

Liikkeelle IT-arkkitehtuurista

Millä reunaehdoilla valmisohjelmisto on usein asiakkaalle paras vaihtoehto? Aloitetaan IT-arkkitehtuurista: yleensä kaikkia yrityksen käyttämiä ohjelmistoja ei uusita kerralla, joten ehdotetun uuden ohjelmistoratkaisun tulee sopia yrityksen nykyiseen ohjelmistoarkkitehtuuriin.

Ei riitä, että tarjottu ratkaisu tukee olemassa olevia integraatiota, vaan sen pitäisi tukea myös tulevaisuuden tarpeita, kuten muita järjestelmävaihdoksia. Ne pitäisi osata arvioida valmisratkaisuja vertailtaessa. Nykyään yhä useampi valmisohjelmisto tarjoaa ja hyödyntää valmiita, osin jopa standardeja rajapintoja, joiden avulla muutokset yhdessä ohjelmistossa eivät lamauta koko arkkitehtuuria.

Nykyään yhä useampi valmisohjelmisto tarjoaa ja hyödyntää valmiita, osin jopa standardeja rajapintoja.

Mikäli järjestelmäkokonaisuus muodostuu useammista eri integraatiomahdollisuuksilla varustetuista järjestelmistä, voi niiden välissä käyttää myös integraatioalustaa, joka auttaa aineistokonversioissa ja pystyy hyödyntämään muiden järjestelmien rajapintoja. Alustan käyttö voi myös olla lähes pakollista, mikäli käytössä on sellaisia vanhempia järjestelmiä, joissa ei rajapintamahdollisuuksia ole. Keskitetty integraatioratkaisu helpottaa myös ylläpitoa, kun hallinta on yhdessä paikassa.

Referenssit auttavat päätöksenteossa

Meidän vinkkimme talousjohtajalle onkin tämä: kysy toimittajalta, miten heidän ehdottamansa ratkaisu sopii olemassa olevaan arkkitehtuuriin. Pyydä toimittajaa esittelemään referenssejä muilta asiakkailta, joissa on vastaavia ratkaisuja tuotannossa.

Jos toimittajan ehdottaman ratkaisu on jo tuotannossa muilla asiakkailla osana vastaavaa arkkitehtuuria, voit luottaa siihen, että rajapinta- ja integraatiohaasteet sekä niiden mahdollisuudet on jo kertaalleen muualla ratkottu. Markkinoilta löytyy riittävästi asiantuntijoita, jotka osaavat tukea ylläpidossa ja kehityksessä myös tulevaisuudessa. Arkkitehtuurireferenssit voivat olla melkein miltä toimialalta tahansa, eli asiakkaan ei tarvinne vaatia saada nähdä samaan ohjelmistoon päätyneen kilpailijan IT-arkkitehtuuriratkaisua.

Pyydä toimittajaa esittelemään referenssejä muilta asiakkailta, joissa on vastaavia ratkaisuja tuotannossa.

Mikäli palveluntarjoaja tai ohjelmistokumppani ehdottaa ensimmäisenä integraatioratkaisuksi robotiikkaa tai tekoälyä hyödyntävää automaatiota, pitäisi hälytyskellojen alkaa soida. Vaikka RPA ja AI ovatkin tällä hetkellä ehkä trendikkäin aihe talousjohdon seminaareissa, suosittelemme ensin viilamaan prosessia, hyödyntämään järjestelmän sisäänrakennetut automatisointimahdollisuudet ja integroimaan järjestelmät.

Ulkoiset automaatioratkaisut, kuten RPA-ohjelmistot, ovat vasta viimeinen oljenkorsi IT-arkkitehtuuria mietittäessä. Ulkoiset automaatioratkaisut vaativat integraatioihin verrattuna huomattavan paljon valvontaa ja ylläpitoa. Siksi mitään, minkä voi joko eliminoida tai hoitaa integraatioilla, ei pitäisi väkisin automatisoida erillisillä lisäohjelmistoilla.

Eräs insinööritaustainen metsäteollisuuden talousjohtaja totesi jo vuosia sitten automaatiokonsultille, joka innoissaan demosi kuukausiraportoinnin automatisointia RPA:lla:
– Minun tavoitteeni on eliminoida kuukausraportointi. Me edellytämme liiketoimintajohtoa olemaan tilanteen tasalla joka päivä, ja tarjoamme siihen heille BI-ratkaisun.

Liiketoiminnan tarpeet puntariin

Kun IT-arkkitehtuuriportti on läpäisty, kannattaa seuraavaksi keskittyä niihin liiketoiminnan tarpeisiin, joita ohjelmiston pitäisi tukea. On itsestään selvää, ettei ole olemassa ohjelmistoa, joka sellaisenaan riittäisi täyttämään liiketoiminnan tarpeet kaikilla toimialoille ja yrityksen kaikissa lokaatioissa. Sen suhteen suosittelisimmekin pyytämään palveluntarjoajaa esittelemään, miten valmisohjelmisto soveltuu teidän toimialallenne.

Tässäkään vaiheessa emme vielä suosittelisi käyttämään aikaa oman liiketoiminnan erilaisuuden perustelemiseen ja vaatimaan palveluntarjoajaa kertomaan, miten juuri teidän uniikit liiketoimintaprosessinne pystytään tarjottuun ratkaisuun konfiguroimaan. Päinvastoin, suosittelemme käyttämään ohjelmisto­hanketta tekosyynä olemassa olevien prosessien ja käytäntöjen kriittiseen tarkasteluun.

Me palveluntarjoajat näemme valitettavan usein asiakkaan pyytävän meitä toteuttamaan jotain sellaista, mikä koetaan välttämättömäksi, jopa liiketoimintakriittiseksi, kun se ei sitä kuitenkaan ole. Usein havaitsemme myös asiakkaan henkilöstön, erityisesti keskijohdon, tottuneen yrityksen sisällä liian hyvään palveluun, joka ei kuitenkaan käytännössä ole yritykselle kustannustehokkain tapa toimia.

Tässä kohtaa mitataankin ratkaisumyyjän integriteetti – luvataanko kaikki mahdollinen, vai uskalletaanko haastaa asia­kasta ajattelemaan uudella tavalla?

Näemme valitettavan usein asiakkaan pyytävän meitä toteuttamaan jotain sellaista, mikä koetaan välttämättömäksi, jopa liiketoimintakriittiseksi, kun se ei sitä kuitenkaan ole.

Käytännössä muutosvastarinnan pelko on usein niin kova, että ylin johto päätyy valitsemaan turvallisemman mutta kalliimman vaihtoehdon, eli alusta alkaen räätälöidyn ohjelmiston. Se on luonnollisesti johtajan oman pallin kannalta turvallisempaa, harva kun uskaltaa laittaa päätään pölkylle yhden IT-projektin takia.

Olemme valitettavan usein nähneet käytännössä, että väärä, tai ainakin yritykselle liian kallis tapa toimia muuttuu vasta, kun sen mahdollistaneet, usein pitkän työuran tehneet asiantuntijat yrityksen talous- tai palkkahallinnossa jäävät eläkkeelle. Tai ehkä heidän tehtävänsä osittain automatisoidaan uudessa järjestelmässä ja loput ulkoistetaan. Keskijohto nauttii usein heidän suunnaltaan hyvää palvelua, joka mahdollistaa esimerkiksi esimiesrooliin kuuluvien vastuiden täyttämisen – tai jossain tapauksissa täyttämättä jättämisenkin – ja tehtävien hoitamisen useissa eri kanavissa ja muodoissa.

Ulkoistettu kumppani, joka hyödyntää prosessin lähes kokonaan automatisoivaa IT-ratkaisua, edellyttäisi kaikkien noudattavan sovittuja prosesseja ja kanavia. Esimerkiksi sähköposti- ja Teams-viestien sijaan palveluntarjoaja edellyttää käyttämään valmiita järjestelmän sähköisiä lomakkeita ja pitämään kiinni sovitusta aikataulusta.

Kärjistetty esimerkki palkanlaskentaprosessista: yrityksen omat palkanlaskijat ovat aiemmin hoitaneet kaiken tiedon­keruun uuden henkilön aloittaessa työsuhteessa. He ovat sen jälkeen syöttäneet tiedot manuaalisesti palkanlaskentajärjestelmään sitä mukaa kun tiedonmurusia on saatu kerättyä. Mikäli käytössä on ollut järjestelmä, johon tietoja on syötetty, on syötettyyn tietoon tehty osittain jopa turhia tarkastuksia, jotka hidastavat prosessia merkittävästi.

Prosessin toimiessa tehokkaimmin on keskijohdon tehtävänä hoitaa kootusti henkilö- ja työsuhdetietojen kerääminen tai ohjeistaa uusi työntekijä syöttämään omat tietonsa HR-järjestelmään. HR-järjestelmästä tiedot siirtyvät automaattisesti palkanlaskentaan ilman turhaa manuaalityötä. Prosessia määritellessä on syytä miettiä samalla muidenkin integraatioiden tarve: onko esimerkiksi matka- ja kululasku-, työajanseuranta- tai ostolaskujärjestelmiin tarpeen viedä henkilötietoja automaattisesti?

Viranomais- ja muut lainsäädännölliset vaatimukset tulee huomioida

Tarjotun ohjelmiston tulee luonnollisesti täyttää viranomais- ja muut lainsäädännölliset vaatimukset. Kun asakas vaatii ohjelmistokumppania kirjaamaan sopimukseen, että muuttuvaan lainsäädäntöön ja viranomaistarpeisiin liittyvä ohjelmistokehityksen kustannukset eivät kuulu asiakkaalle, alkavat liiaksi räätälöityjen ratkaisujen tarjoajat vetäytyä kisasta tai korottavat tarjoustaan merkittävästi.

Toimialaspesifit tai yleiset auditoinnit ovat vaikeampi kysymys. Pitääkö tarjotun ratkaisun mahdollistaa toimialan mahdollisesti pakolliset tai vapaaehtoiset auditoinnit, ja miten muuttuvien auditointikäytäntöjen aiheuttamat kustannukset jaettaisiin? Tähän ei varmasti ole vielä yhtä ainoaa tai oikeaa ja reilua tapaa, joten asiasta kannattaa keskustella potentiaalisen palveluntarjoajan ja ohjelmistokumppanin kanssa. Luonnollisesti valmisohjelmistoratkaisut ovat tässäkin yleensä vahvempia vaihtoehtoja, koska ohjelmistokehityksen ja ylläpidon kustannukset auditointien osalta voidaan jakaa useammalle ohjelmistoasiakkaalle.

Pitääkö tarjotun ratkaisun mahdollistaa toimialan mahdollisesti pakolliset tai vapaaehtoiset auditoinnit, ja miten muuttuvien auditointikäytäntöjen aiheuttamat kustannukset jaettaisiin?

Auditointien ohella myös yrityksen yhtiörakenne saattaa vaikuttaa hankintapäätökseen. Vaikka Suomessa riittäisi kevyempikin ratkaisu, saattaa Suomen yhtiö olla osa kansainvälistä konsernia, ja pääkonttorilla Lontoossa edellytetään kaikkien tytäryhtiöiden ja mahdollisesti jopa tärkeimpien kumppanien noudattavan esimerkiksi SOX:ia. Tämä tulee ainakin talous- ja henkilöstöhallinnon ohjelmistoja hankittaessa ottaa huomioon.

Yrityksen liiketoimintakriittiset prosessit

Vasta kun edellä mainitut asiat on saatu ratkottua, kannattaa syventyä yrityksen liiketoimintakriittisiin prosesseihin, joita valmisohjelmistonkin pitää pystyä tukemaan.

Käytännön esimerkki lääketeollisuudesta: jopa talous­hallinnon ohjelmistossa toteutetun varastonkäsittelyn pitää pystyä tukemaan esimerkiksi tuotteiden jäljitettävyyttä ja mahdollisia takaisinvetoja komponentti- ja erätasolla. Parhaassa tapauksessa valmisohjelmistosta löytyy tähänkin tarpeeseen tuotteistettu moduli, jonka kehitys- ja ylläpitokulut voidaan jakaa useammalle ohjelmistoasiakkaalle. Palveluntarjoajan pitää pystyä kuvaamaan vähintäänkin se, miten kyseinen toiminnallisuus voitaisiin valmisratkaisuun konfiguroida.

Mikäli valmisohjelmistosta ei kuitenkaan löydy sopivaa moduulia tai kynnys ydinjärjestelmän vaihtamiseen on muista syistä liian suuri, palataan jälleen siihen, kuinka helposti järjestelmät ovat integroitavissa toisiinsa.

Palveluntarjoajan pitää pystyä kuvaamaan vähintäänkin se, miten kyseinen toiminnallisuus voitaisiin valmisratkaisuun konfiguroida.

Prosesseissa kannattaa huomioida myös niiden tehokkuuden vaikuttavuus. Esimerkiksi jos valmisohjelmiston osto­laskujen käsittely on sujuvaa yrityksen 50 hyväksyjälle, mutta matka- ja kululaskuissa järjestelmä ei toimi täydellisesti yrityksen kolmelle matkustavalle henkilölle, on matka- ja kululasku­prosessin sujuvuus varmasti toissijainen asia. Sen vuoksi ei kannata lähteä räätälöityä järjestelmää hakemaan, siltä osin voisi hyväksyä jopa nykyiseen ohjelmistoon verrattuna heikomman ratkaisun.

Edellä mainituista tilanteista ja esimerkeistä huolimatta on mahdollista löytää tilanne, jossa valmisratkaisut eivät riitä. Silloin kyseessä voi olla yritykselle kilpailuedun mahdollistava ohjelmisto. Tai yrityksen taustalla tai omistajana saattaa olla esimerkiksi yleishyödyllinen organisaatio, joka ei tavoittele liike­toiminnalla voittoa, vaan ainutlaatuista asiakas- ja henkilöstökokemusta. Näissäkin tapauksissa kannattaa selvittää palveluntarjoajalta, onko heillä räätälöityjen ratkaisujen päälle tuotteistettuja paketteja. Tällöin jokaista erillistä toiminnallisuutta ei ole tarpeen rakentaa tyhjästä.