Kim Korhonen

Myyntijohtaja

Sovitettu ohjelmistoratkaisu – kattava opas

Yrityksessä voi olla käytössä hyvä toiminnanohjausjärjestelmä, asiakkuudenhallinta ja monta muutakin ohjelmistoa. Silti joku kokoaa raportin käsin joka maanantai. Tuotannon tilannetta kysellään sähköpostilla ja kuormitusta hallitaan Excelillä. Poikkeamien käsittely pyörii Excelissä, ja sama tieto kirjoitetaan useaan paikkaan. Myyjän aikaa kuluu yksityiskohtaisen tuotetiedon ja tuotteen kuvan etsimiseen tarjousta varten.

Järjestelmät ovat olemassa, mutta niiden ympärille jää työtä, jonka ihmiset hoitavat manuaalisesti.

Tässä kohtaa kannattaa pysähtyä. Voisiko prosessi toimia paremmin? Löytyykö markkinoilta sopiva valmisohjelmisto? Voiko nykyisiä järjestelmiä hyödyntää enemmän? Vai tarvitaanko juuri omaan toimintatapaan sovitettu ratkaisu?

Tämä opas auttaa arvioimaan vaihtoehtoja. Käymme läpi, mitä sovitettu ohjelmistoratkaisu tarkoittaa, milloin se on järkevä valinta, miten hankinta etenee ja mistä kustannukset muodostuvat. Lisäksi käsittelemme tekoälyn kahta roolia: tekoälyä osana yrityksen käyttämää ratkaisua ja ohjelmistokehittäjän apuna.

1. Mistä BEL Solutions Oy:n ajatus syntyi?

BEL Solutions Oy perustettiin vuonna 2004. Taustalla oli yksinkertainen ajatus: yritysten pitäisi saada liiketoimintaansa tukevia ohjelmistoratkaisuja ilman, että niiden täytyy itse kantaa huolta teknisestä ylläpidosta.

Teknologian pitää helpottaa tekemistä. Kun yritys haluaa kehittää tuotantoa, nopeuttaa tarjousten tekemistä tai saada paremman näkyvyyden toimitusketjuun, ohjelmiston arvo syntyy siitä, miten se auttaa saavuttamaan nämä tavoitteet.

Tämä ajatus ohjaa BELin toimintaa edelleen. Aloitamme asiakkaan työstä: mitä tapahtuu, missä syntyy ongelmia ja mitä pitäisi saada aikaan. Sen jälkeen etsimme sopivan tavan toteuttaa ratkaisu.

BELin nimi tulee sanoista Beyond Expectation Level. Meille se kuvaa palveluasennetta. Kuunnellaan kunnolla, sovitaan selkeästi ja pidetään huolta siitä, että ratkaisu toimii myös käyttöönoton jälkeen. Yhteistyö jatkuu paljon pidempään kuin ensimmäinen toimitus.

Lue lisää: Rakennettu liiketoimintaa varten – ei IT:tä varten.

2. Mitä sovitettu ohjelmistoratkaisu tarkoittaa?

Sovitettu ohjelmistoratkaisu tehdään asiakkaan tarpeeseen hyödyntämällä olemassa olevaa ratkaisualustaa, valmiita ohjelmistokomponentteja ja ratkaisurunkoja. Kaikkea ei tarvitse rakentaa alusta asti. Viimeinen silaus tehdään sovittamalla ratkaisu juuri asiakkaan tarpeeseen.

BELin mallissa asiakkaalle sovitetaan esimerkiksi käyttöliittymä, työnkulut, laskentasäännöt, raportointi ja yhteydet muihin järjestelmiin. Ratkaisun pitää tukea sekä sitä, mitä työssä tarvitaan, että sitä, miten työ on järkevää tehdä.

Ajatellaan esimerkiksi poikkeamien käsittelyä. Yhdelle yritykselle riittää havainnon kirjaaminen, vastuuhenkilön nimeäminen ja kuittaus. Toisessa yrityksessä vastuuhenkilö on eri roolin henkilö ja asian käsittely etenee aivan eri tavalla.

Perustarve on samantapainen, mutta toimiva ratkaisu voi olla jokaisessa yrityksessä erilainen. Sovittaminen tarkoittaa näiden erojen huomioimista niin, että ratkaisu sopii yrityksen toimintatapaan.

Valmiit osat tuovat toteutukseen tehokkuutta ja laatua. Asiakkaan prosessin ymmärtäminen antaa niille suunnan.

3. Valmisohjelmisto, sovitettu ratkaisu vai alusta asti rakennettu ohjelmisto?

Valmisohjelmisto on usein hyvä valinta. Kun tarve on yleinen ja sopiva tuote löytyy markkinoilta, sen käyttöönotto voi olla suoraviivainen ja kustannuksiltaan järkevä tapa edetä. Joskus myös oman toimintatavan muuttaminen ohjelmiston tukeman käytännön mukaiseksi saattaa onnistua.

Joskus yritys tarvitsee kuitenkin toimintoja, joihin valmis tuote ei taivu kohtuullisella vaivalla. Silloin kannattaa verrata vaihtoehtoja koko toiminnan kannalta.

VaihtoehtoMilloin sitä kannattaa harkita?Mitä on syytä arvioida?
ValmisohjelmistoTarve on yleinen ja tuote tukee sitä riittävän hyvin.Käyttöönotto, prosessimuutokset, integraatiot ja jatkuvat maksut.
Sovitettu ohjelmistoratkaisuOma prosessi tai järjestelmien väliin jäävä tarve vaatii yrityskohtaista toteutusta, jossa voidaan hyödyntää valmiita osia.Sovitettavat toiminnot, integraatiot ja kokonaiskustannus.
Alusta asti rakennettu ohjelmistoTarve vaatii niin erityistä teknologiaa tai toteutustapaa, etteivät saatavilla olevat tuotteet ja alustat sovellu siihen.Kehityksen laajuus, aikataulu, budjetti, ylläpito, aikataulu ja budjettiriskit ja tarvittava osaaminen koko elinkaaren aikana.

Valmisohjelmisto

Milloin sitä kannattaa harkita?

Tarve on yleinen ja tuote tukee sitä riittävän hyvin.

Mitä on syytä arvioida?

Käyttöönotto, prosessimuutokset, integraatiot ja jatkuvat maksut.

Sovitettu ohjelmistoratkaisu

Milloin sitä kannattaa harkita?

Oma prosessi tai järjestelmien väliin jäävä tarve vaatii yrityskohtaista toteutusta, jossa voidaan hyödyntää valmiita osia.

Mitä on syytä arvioida?

Sovitettavat toiminnot, integraatiot ja kokonaiskustannus.

Alusta asti rakennettu ohjelmisto

Milloin sitä kannattaa harkita?

Tarve vaatii niin erityistä teknologiaa tai toteutustapaa, etteivät saatavilla olevat tuotteet ja alustat sovellu siihen.

Mitä on syytä arvioida?

Kehityksen laajuus, aikataulu, budjetti, ylläpito, aikataulu ja budjettiriskit ja tarvittava osaaminen koko elinkaaren aikana.

BELin sovitetussa SaaS-mallissa yhdistyvät asiakkaan tarpeeseen tehtävä ratkaisu ja valmiin teknisen perustan hyödyntäminen. Toimitamme ja ylläpidämme ratkaisun palveluna, jolloin asiakkaan ei tarvitse hankkia erikseen jokaista toteutukseen ja ylläpitoon tarvittavaa osaa.

Valintaa kannattaa lähestyä käytännön kysymyksellä: millä tavalla saamme tämän työn toimimaan parhaiten järkevällä kokonaiskustannuksella?

4. Milloin sovitettu ratkaisu on oikea valinta?

Sovitettua ratkaisua kannattaa harkita, silloin kun kaupallinen valmisohjelmisto on liian raskas ja kallis tai kun toistuva työ jää nykyisten järjestelmien ulkopuolelle tai niiden väliin. Tarve voi olla pieni mutta vaikutuksiltaan suuri. Tässä pari esimerkkiä. Käyttötapauksia on paljon muitakin.

Tietoa kerätään, siirretään ja yhdistellään käsin

Tieto löytyy järjestelmistä, mutta joku joutuu hakemaan sen eri paikoista, yhdistämään taulukot ja tarkistamaan lopputuloksen. Tuotannossa laatutietoja saatetaan kerätä ensin paperille ja syöttää vasta myöhemmin järjestelmään. Jos sama työ toistuu viikosta toiseen, tiedon siirron ja käsittelyn automatisointia kannattaa selvittää.

Yrityksen oma prosessi tarvitsee erityistä logiikkaa

Tarjouksen laskenta, hyväksyntäketju tai tuotannon työvaiheiden käsittely voi perustua yrityksen omaan toimintamalliin. Sovitettu ratkaisu voi tukea sitä suoraan sen sijaan, että käyttäjät joutuvat täydentämään ohjelmistoa jatkuvilla kiertoteillä.

Raportointi valmistuu liian myöhään

Jos luvut ovat käytettävissä vasta pitkän manuaalisen koostamisen jälkeen, päätöksiä tehdään helposti vanhan tiedon perusteella. Sovitetulla ratkaisulla voidaan yhdistää tietolähteitä ja tuoda tarvittava näkymä lähemmäs päivittäistä työtä. Raportin manuaalinen teko vie aikaa ja inhimillisiä virheitä voi syntyä.

Tarjolla oleva kokonaisuus on tarpeeseen nähden liian laaja

Jos yritys tarvitsee muutaman selkeän toiminnon, laajan valmisohjelmiston tai järjestelmän käyttöönotto voi olla tarpeettoman työläs ja kallis. Rajattu ratkaisu voi olla helpompi ottaa käyttöön, ja sen käyttö on usein helpompi oppia.

Työ on yhden ihmisen muistin tai kokemuksen varassa

Kun prosessi toimii vain siksi, että tietty henkilö tietää, mitä pitää tehdä, yrityksen toiminta on haavoittuvaa. Yhteinen ratkaisu voi tehdä työn etenemisen, vastuut ja tiedot näkyviksi myös muille.

Ennen uuden ohjelmiston hankintaa kannattaa silti tarkistaa, voiko ongelman ratkaista nykyisen järjestelmän toiminnolla. Jos se riittää, siitä kannattaa aloittaa.

Lue lisää: Kun valmisohjelmisto ei tunnu oikealta valinnalta.

5. Nykyisistä järjestelmistä voi saada enemmän irti

Sovitetun ratkaisun hankinta ei yleensä tarkoita yrityksen pääjärjestelmien uusimista. Toiminnanohjaus, asiakkuuden- tai varastonhallinta ja taloushallinto voivat jatkaa omissa tehtävissään. Sovitettu ratkaisu voi venyttää ja rikastaa pääjärjestelmien ominaisuuksia sekä toimia siltana eri järjestelmien välillä.

Nykyisten järjestelmien rinnalle voidaan toteuttaa esimerkiksi selkeä näkymä tuotannon tilanteeseen tai portaali, josta asiakkaat näkevät tilauksensa etenemisen. Myös kenttähuolto voi saada tarvitsemansa tiedot samaan paikkaan, mikä helpottaa huoltoa ja muita myynnin jälkeisiä palveluita. Käyttäjän kannalta tärkeintä on, että tarvittava tieto löytyy ja seuraava työvaihe on helppo tehdä.

Integraatioissa on sovittava, mikä järjestelmä vastaa mistäkin tiedosta. Missä tieto syntyy, missä sitä hallitaan ja missä sitä saa muuttaa? Tämä on perustietojen hallintaa eli master data managementia. Samalla päätetään, kuinka nopeasti tiedon pitää päivittyä muihin järjestelmiin.

Nämä kysymykset vaikuttavat suoraan ratkaisun toimivuuteen. Hyvin suunniteltu kokonaisuus vähentää päällekkäisiä kirjauksia ja auttaa välttämään tilanteen, jossa sama tieto näyttää eri järjestelmissä erilaiselta.

6. Mihin sovitettuja ratkaisuja voidaan käyttää?

Sovitettu ratkaisu voi palvella yksittäistä työvaihetta tai laajempaa prosessia. Esimerkiksi:

Työturvallisuudessa hyöty voi syntyä jo siitä, että havainnon ilmoittaminen on helppoa ja tieto ohjautuu oikealle henkilölle. Helpon käytettävyys madaltaa ilmoituksen teon kynnystä, jolloin kaikki hyötyvät. Sen jälkeen tarvitaan käsittely, vastuut ja seuranta. Pelkkä havaintojen kerääminen ei vielä muuta toimintaa.

Sama periaate pätee muihinkin prosesseihin: tiedon pitää virrata ja johtaa seuraavaan hyödylliseen työvaiheeseen.

7. Sovitetun ohjelmistoratkaisun hankinnan viisi vaihetta

Ohjelmistohankinta helpottuu, kun tavoite, työnjako ja päätöksenteko ovat selkeitä. BELin toimintamalli etenee nykytilan ymmärtämisestä suunnitteluun, toteutukseen, käyttöönottoon ja jatkuvaan palveluun.

Vaihe 1: Ymmärretään nykyinen työ ja sen ongelma

Hyvä aloitus on yhden todellisen tapauksen läpikäynti alusta loppuun. Näin nähdään, mistä tieto tulee, kuka sitä käsittelee ja missä työ jää odottamaan tai takertuu.

Samalla arvioidaan tapahtumien määrää, käytettyä työaikaa ja virheiden vaikutuksia. Näistä syntyy lähtötaso, johon ratkaisun hyötyjä voidaan verrata.

Vaihe 2: Sovitaan tavoite ja tehdään ratkaisu näkyväksi

Määrittelyssä kuvataan tarvittavat toiminnot, käyttäjämäärät ja -roolit, tietolähteet sekä integraatiot. Päätetään myös, mitä ensimmäiseen versioon kuuluu ja mitä on ehkä fiksua jättää myöhemmäksi.

BELin tekemä prototyyppi auttaa arvioimaan tulevaa ratkaisua käytännössä. Kun käyttäjä näkee näkymät ja työnkulun, hänen on helpompi kertoa, mikä toimii ja mikä tarvitsee muutosta. Prototyyppiä hiotaan, kunnes se vastaa sovittuja tarpeita ja on sujuva käyttää.

Vaihe 3: Toteutetaan ja tarkennetaan yhdessä

Ratkaisu toteutetaan sovitun kokonaisuuden mukaisesti hyödyntäen BELin alustaa ja ohjelmistokomponentteja. Asiakkaan palaute auttaa varmistamaan, että toiminnallisuudet tukevat todellista työtä.

Vaihe 4: Otetaan käyttöön osana arkea

Käyttöönottoon kuuluvat sovitun tarpeen mukaan tietojen siirto, käyttäjien opastus ja toiminnan varmistaminen. Myös uuden toimintatavan vastuut on tehtävä selviksi: kuka käyttää ratkaisua, kuka käsittelee tapahtumat ja kuka seuraa prosessin toimivuutta?

Onnistumisen huomaa viimeistään silloin, kun joku kysyy: ”Miksi emme tehneet tätä jo paljon aikaisemmin?”

Vaihe 5: Ylläpidetään ja kehitetään

BEL vastaa palvelun teknisestä toimivuudesta ja ylläpidosta sovitun palvelusisällön mukaisesti. Asiakkaan tarpeiden muuttuessa arvioidaan myös jatkokehitystä.

Kun ensimmäinen vaihe toimii, seuraavat kehityskohteet on helpompi tunnistaa käytön ja kertyneen tiedon perusteella.

8. SaaS-palvelu tuo jatkuvuutta ja selkeän vastuun

SaaS tarkoittaa ohjelmiston käyttämistä palveluna. BELin mallissa sama kumppani suunnittelee ja toteuttaa ratkaisun sekä huolehtii sen ylläpidosta.

Asiakkaalle tämä tuo huolettomuutta ja auttaa pitämään kustannukset hallinnassa. Ratkaisun taustan tunteva kumppani on mukana myös silloin, kun käytössä herää kysymyksiä tai liiketoiminnan tarpeet muuttuvat.

Palvelusta sovittaessa käydään läpi esimerkiksi ylläpito, päivitykset, tuki, varmuuskopiointi ja valvonta. Myös palvelun kustannusten ja mahdollisen jatkokehityksen hinnoittelun pitää olla selkeitä.

Pitkäaikaisessa palvelussa sovitaan aina myös siitä, miten asiakkaan tiedot saadaan ulos palvelusta tarvittaessa. Selkeät käytännöt rakentavat luottamusta koko yhteistyön ajaksi.

9. Tekoäly osana yrityksen käyttämää ohjelmistoratkaisua

Yksinkertainen ohjelmistoratkaisu ei usein tarvitse tekoälyä. Se lisää kustannuksia ja tekee kokonaisuudesta monimutkaisemman, joten mukaan ottamiseen pitää olla hyvä syy. Tekoäly voi auttaa esimerkiksi tiedon löytämisessä, dokumenttien käsittelyssä, tekstin luokittelussa ja yhteenvetojen tekemisessä. Hyöty on usein suurin silloin, kun tekoäly tuodaan osaksi tuttua työnkulkua.

BEL voi liittää ratkaisuun ulkoisen kielimallipalvelun rajapinnan kautta. Käytettävä malli voi olla esimerkiksi OpenAI:n, Anthropicin tai muun toimittajan kielimalli. Sopiva kielimalli, käyttötapa, käsiteltävä aineisto ja tietojen käsittelyn ehdot valitaan ratkaisun vaatimusten mukaan.

Tekoälyn antamaa vastausta pitää arvioida sen mukaan, mihin sitä käytetään. Luonnoksen tekeminen ja tuotannon päätöksen ohjaaminen ovat eri asioita. Ratkaisussa määritellään, mitä tekoäly saa tehdä ja missä tarvitaan ihmisen hyväksyntä.

Myös käyttäjien oikeudet on huomioitava. Tekoälyn kautta saa tulla näkyviin vain sellainen tieto, johon käyttäjällä muutenkin on oikeus. Samalla on huomioitava, mitä tietoa voidaan lähettää ulkoiseen tekoälypalveluun ja mikä aineisto pidetään omassa ympäristössä.

10. Paikallinen tekoäly, kun aineisto halutaan pitää omassa ympäristössä

Kaikkea yrityksen tietoa ei ole fiksua siirtää ulkoiseen tekoälypalveluun. Kyse voi olla esimerkiksi tuotekehitysaineistosta, sopimuksista, henkilötiedoista tai muusta luottamuksellisesta tiedosta.

BEL pystyy toimittamaan myös paikallisesti ajettavan tekoälyratkaisun. Tässä paikallinen tarkoittaa, että malli toimii ratkaisulle sovitussa, omassa ja hallitussa palvelinympäristössä.

Kokonaisuus toteutetaan niin, että käsiteltävä aineisto, käyttäjän kysymykset ja tekoälyn vastaukset pysyvät tässä omassa suljetussa ympäristössä eikä niitä lähetetä julkisiin tekoälypalveluihin ties minne. BEL käyttää paikallista tekoälyratkaisua myös omassa toiminnassaan.

Paikallinen toteutus antaa mahdollisuuden hallita tiedon käsittelyä tarkemmin. Sen tietoturva edellyttää silti yhtä huolellista toteutusta kuin muissakin ratkaisuissa. Käyttöoikeudet, suojaukset, päivitykset ja tietovirtojen hallinta on suunniteltava kunnolla.

Ulkoisen palvelun ja paikallisen mallin välillä valitaan käyttötarpeen perusteella. Arvioinnissa huomioidaan tiedon luottamuksellisuus, mallin soveltuvuus tehtävään, tarvittava kapasiteetti ja kokonaiskustannukset.

11. Tekoäly ohjelmistokehittäjän apuna

Tekoälyn toinen rooli näkyy siinä, miten ohjelmistoratkaisuja tehdään. BEL on käyttänyt tekoälyä ohjelmistokoodin tuottamisen apuna vuodesta 2024 lähtien.

Tekoäly voi avustaa koodin kirjoittamisessa ja muokkaamisessa, testitapausten laatimisessa, virheiden etsimisessä, tietoturvatestauksessa sekä dokumentoinnissa. Se voi nopeuttaa työvaiheita, joissa kehittäjä muuten tekisi paljon toistuvaa työtä.

Asiakkaalle hyöty voi näkyä nopeampana toteutuksena ja siinä, että vaihtoehtoja päästään arvioimaan aiemmin. Kehittäjälle jää enemmän aikaa vaativien kohtien ratkaisemiseen.

Tuottavuushyöty kuitenkin vaihtelee tehtävän mukaan. Asiakkaan prosessin ymmärtäminen, ratkaisun ja sen teknisen rakenteen suunnittelu sekä tietovirtojen ja integraatioiden toteuttaminen vaativat edelleen asiantuntijan työtä. Myös ratkaisun soveltuvuus on varmistettava. Koodin tuottaminen on yksi osa kokonaisuutta.

Tekoälyn tuottama koodi tarvitsee tarkistuksen

Olemme nähneet tekoälyn tuottamaa koodia, jossa on ollut hyvin merkittäviä tietoturvapuutteita. Toimivalta näyttävä ohjelma voi esimerkiksi käsitellä käyttöoikeuksia puutteellisesti tai luottaa liikaa käyttäjän antamaan tietoon. Tai pahimmillaan se hakee jostain julkisesta lähteestä osia, jotka ovat saastuneita. Hakkerit laittavat valmista koodia tarjolle mutta koodi sisältääkin osia, joita hakkeri voi hyödyntää.

Tekoäly on optimisti eikä välttämättä osaa huomioida ratkaisun tietoturvaa ja toimintaympäristöä riittävästi. Siksi sen tuottama koodi pitää tarkistaa ja testata, kuten muukin ohjelmistokoodi.

Ohjelmistokumppanin tehtävä on vastata toimitettavasta kokonaisuudesta. Tekoäly voi auttaa työssä, mutta vastuu ratkaisun laadusta, turvallisuudesta ja ylläpidettävyydestä säilyy toimittajalla.

12. Mistä sovitetun ohjelmistoratkaisun kustannukset muodostuvat?

Ohjelmiston kustannuksia kannattaa arvioida koko käyttöajalta ja suhteessa saavutettavaan hyötyyn. Pelkkä toteutushinta tai kuukausimaksu kertoo vain osan kustannuksista.

Toteutuksen hintaan vaikuttavat esimerkiksi prosessin laajuus, tarvittavat toiminnot, integraatiot, käyttäjien ja datan määrät sekä tietoturvan ja käytettävyyden vaatimukset. Jatkuviin kustannuksiin vaikuttavat sovitun palvelun sisältö, käyttömäärät ja mahdolliset ulkoiset palvelut.

Myös tekoälyvalinnoilla on merkitystä. Ulkoisen mallipalvelun käytöstä voi syntyä käyttöön perustuvia maksuja. Paikallisesti ajettava malli puolestaan tarvitsee palvelinkapasiteettia ja ylläpitoa. Valinta arvioidaan osana kokonaisuutta.

BELin mallissa sovittu toimitusprojekti hinnoitellaan kiinteästi ja jatkuvan palvelun kustannukset sovitaan erikseen. Näin asiakas pystyy arvioimaan hankintaa ennen päätöstä ja ymmärtää tulevat kustannuksia. Riski on minimaalinen.

Tekoälyn tuottavuushyödyn kuuluu hyödyttää asiakasta

Kun tekoäly tehostaa ohjelmistokehitystä, on luonnollista, että asiakkaat odottavat hyödyn näkyvän myös hinnoissa. Meistä odotus on perusteltu.

BELin kustannuskilpailukyky on rakentunut jo ennen tekoälyä oman ratkaisualustan, valmiiden komponenttien ja tehokkaan toimintamallin varaan.

Kokonaiskuluihin vaikuttaa myös toimittajan oma kustannusrakenne. Pienenä ja joustavana kumppanina pidämme organisaatiomme ja toimintamme kulut hallinnassa. Se auttaa tarjoamaan asiakkaalle kilpailukykyisen kokonaisuuden.

Olemme aina olleet ratkaisuissamme erittäin hintakilpailukykyisiä, ja uskomme olevamme sitä jatkossakin. Palkän hinnan rinnalla kannattaa kuitenkin katsoa, mitä ratkaisulla saadaan aikaan ja kuinka nopeasti investointi maksaa itsensä takaisin.

Tekoälyllä saatava hyöty voi näkyä alempana toteutuskustannuksena, nopeampana toimituksena tai siinä, että samalla budjetilla saadaan enemmän hyödyllisiä toimintoja. Tämä tekee myös pienten ratkaisujen toteuttamisesta entistä järkevämpää. Me BELillä toteutamme mielellämme myös pieniä ja edullisia ratkaisuja. Koko yrityksen mittakaavassa pieni parannus voi helpottaa yksittäistä työvaihetta paljon: vähentää käsityötä ja inhimillisiä virheitä tai parantaa asiakaskokemusta.

13. Mitä maksaa, jos mitään ei tehdä?

Ohjelmistohankinnassa lasketaan usein uuden ratkaisun kustannukset tarkasti. Nykyisen toimintatavan kustannukset jäävät helpommin piiloon.

Paljonko aikaa kuluu tiedon hakemiseen ja siirtämiseen? Kuinka usein virheitä korjataan jälkikäteen, ja mitä korjaaminen maksaa työaikana ja euroina? Mitä seuraa siitä, että tilannetta ei nähdä ajoissa? Entä mitä henkilöstö voisi tehdä, jos toistuva käsityö vähenisi?

Havainnollistava esimerkki: jos viisi työntekijää käyttää kukin puoli tuntia työpäivässä tietojen kokoamiseen, työtä kertyy 20 työpäivän kuukaudessa yhteensä 50 tuntia. Kun laskennallinen tuntikustannus on 40 euroa, työajan kustannus on 2 000 euroa kuukaudessa. Vuodessa vastaava määrä on 24 000 euroa, jos työ toistuu samalla tavalla 12 kuukautta.

50 hkuukaudessa
2 000 €kuukaudessa
24 000 €vuodessa

Luvut ovat esimerkki, eivät lupaus säästöstä. Kaikki työ ei välttämättä poistu, eikä vapautunut aika muutu automaattisesti kassasäästöksi. Se antaa kuitenkin tilaa tuottavammalle työlle. Laskelma tekee näkyväksi sen, mistä nykyisessä toimintatavassa maksetaan.

Hyödyn seurantaa kannattaa miettiä jo ennen toteutusta. Mittarina voi olla käsittelyaika, virheiden määrä, raportin valmistumiseen kuluva aika tai asiakkaalle vastaamisen nopeus. Valitaan sellainen mittari, joka kertoo todellisesta muutoksesta.

14. Miten valita sopiva ohjelmistokumppani?

Hyvä kumppani osaa keskustella tavoitteesta ennen ratkaisun tarjoamista. Hän haluaa ymmärtää käyttäjiä, tiedonkulkua, prosesseja ja sitä, mistä nykyisen työn ongelma syntyy.

Keskustelussa kannattaa selvittää ainakin nämä asiat:

Olennaista on myös yhteistyön tapa. Saatko kysymyksiin ymmärrettävät vastaukset? Tiedätkö, kuka hoitaa asiaasi? Uskaltaako kumppani sanoa, jos jokin ehdotus on tarpeeton tai asia kannattaa ratkaista toisella tavalla?

Pitkä yhteistyö tarvitsee avointa keskustelua ja selkeitä vastuita. Yhtä tärkeää on halu tehdä yhteistyötä ja auttaa asiakasta. Se näkyy erityisesti silloin, kun tarve muuttuu tai eteen tulee ongelma.

15. Aloita yhdestä työstä, jonka pitäisi toimia paremmin

Sovitetun ohjelmistoratkaisun selvittäminen ei edellytä valmista vaatimuslistaa. Usein riittää, että osaat kuvata yhden tilanteen, joka vie liikaa aikaa, aiheuttaa virheitä tai vaikeuttaa johtamista.

Käydään läpi, miten työ tehdään nyt, miten sen pitäisi toimia ja mitä muutoksella tavoitellaan. Sen perusteella voidaan arvioida, löytyykö sopiva valmis ratkaisu, voidaanko nykyisiä järjestelmiä hyödyntää paremmin vai onko sovitettu ohjelmistopalvelu oikea vaihtoehto.

BEL yhdistää tähän työhön yli 22 vuoden kokemuksen, oman ratkaisualustan ja vastuun jatkuvasta palvelusta. Tekoäly tuo lisää mahdollisuuksia sekä ratkaisujen toimintoihin että niiden toteuttamiseen. Pitkä kokemus auttaa meitä ymmärtämään myös omat rajamme. Sanomme rehellisesti ei, jos emme ole asiakkaalle paras vaihtoehto.

Mikä teidän arjessanne pitäisi saada toimimaan paremmin?

Ota yhteyttä BELiin, niin katsotaan yhdessä, mistä kannattaa aloittaa.