Räätälöity sovellus tai mobiiliapplikaatio ei ole hyllytuote, jonka voi valita ominaisuuslistalta, vaan sitä varten on hankittava kumppani ja kehitystyötä. Autamme määrittelemään, mitä sovelluksella oikeasti tavoitellaan ja kilpailuttamaan toteutuksen niin, että ratkaisu pysyy teidän hallinnassanne myös vuosien päästä.
Räätälöity sovellus yleensä tukee jotain erityistä prosessia, tarvitsee tietoa muista järjestelmistä ja se kuuluu tiiviisti käyttäjiensä arkeen. Siksi hankinta ratkeaa harvoin tekniikalla: ratkaisevaa on, kenelle sovellus tehdään, mitä sen pitää tehdä, mihin se liitetään ja kuka sitä ylläpitää ensimmäisen version julkaisun jälkeen. Olemme olleet mukana verkkopalvelu- ja mobiilisovellusten kehitys- ja hankintaprojekteissa, joten tunnemme sekä prosessin että alan toimittajat. Emme myy ohjelmistoja emmekä edusta toimittajia, joten katsomme tilannetta puolueettomasti asiakkaan puolelta.
Kun hankitaan valmisohjelmisto, vertaillaan tuotteita ja niiden ominaisuuksia. Räätälöidyssä sovelluksessa vertaillaan tekijöitä: osaamista, työtapaa ja kykyä viedä projekti maaliin. Siksi hyvä hankinta ei nojaa pelkkään tekniseen toteutukseen, vaan selkeisiin vaatimuksiin, realistiseen budjettiin, toimittajan näyttöihin sekä siihen, että lähdekoodi ja oikeudet ovat lopulta teidän hallussanne.
Meidän tehtävämme on auttaa määrittelemään, mitä sovelluksella oikeasti tavoitellaan: kenelle se tehdään, mitä prosessia se tukee, mihin järjestelmiin se liitetään ja miten sen tietoturva, ylläpito, skaalautuvuus ja jatkokehitys varmistetaan. Nämä kysymykset ratkaisevat, onko sovellus vielä kolmen vuoden päästä hallittava kokonaisuus vai riippakivi, johon kukaan ei uskalla koskea.
Ensimmäinen kysymys ei ole, millainen sovellus tehdään, vaan tarvitaanko sitä. Moni tarve ratkeaa valmiilla tuotteella, jota konfiguroidaan: se on tavallisesti nopeampi, halvempi ja riskit ovat pienemmät kuin omaan koodiin perustuvissa ratkaisuissa, joita pitää ylläpitää itse. Räätälöinti kannattaa silloin, kun prosessi on aidosti omanlaisensa, kun sovellus on osa palvelua tai kilpailuetua tai kun valmiit tuotteet eivät taivu tarvittaviin integraatioihin tai käyttökokemukseen.
Käymme tämän rajanvedon läpi rehellisesti, myös silloin kun johtopäätös on, ettei omaa sovellusta kannata teettää. Usein järkevin ratkaisu on välimuoto: valmis alusta, jonka päälle rakennetaan vain se osa, joka on oikeasti räätälöitävä.
Hyvä tarjouspyyntö lähtee siitä, että tiedetään, mitä ollaan hankkimassa. Siksi aloitamme aina vaatimusmäärittelystä. Kuvaamme käyttäjät ja keskeiset käyttötapaukset – mitä sovelluksella tehdään ja missä järjestyksessä – ja kirjaamme, mihin toiminnan prosessiin sovellus liittyy.
Mobiilisovelluksessa on lisäksi joukko valintoja, jotka kannattaa tehdä tietoisesti jo ennen kilpailutusta, koska ne näkyvät suoraan hinnassa ja ylläpidon työmäärässä:
Lähes aina mukaan tulevat myös integraatiot taustajärjestelmiin ja niiden rajapintoihin sekä niiden väliset tietovirrat. Ja koska kyse on räätälöinnistä, määrittelyyn kuuluu alusta asti se, kuka omistaa syntyvän lähdekoodin ja tekijänoikeudet – tähän palaamme sopimuskohdassa.
Räätälöidyssä hankinnassa vaatimusmäärittely on tavallistakin tärkeämpi, koska valmista tuotetta ei ole katsottavana. Kokoamme toiminnalliset ja tekniset vaatimukset, priorisoimme ne ja kuvaamme keskeiset käyttötapaukset niin, että toimittaja pystyy arvioimaan työmäärän ja tarjoukset ovat keskenään vertailukelpoisia. Usein hahmottelemme myös rautalankamallit tai kevyen prototyypin – kuva ruudusta kertoo enemmän kuin sivukaupalla tekstiä ja paljastaa väärinymmärrykset ennen kuin niistä on maksettu.
Samalla sovitaan, mikä on ensimmäisen version (MVP) laajuus ja mikä jää jatkokehityksen ”backlogille”. Räätälöity sovellus ei valmistu kerralla, vaan kasvaa käytön myötä, ja se kannattaa tunnustaa jo vaatimuksissa. Valmis määrittely toimii projektin kirjallisena muistilistana ja liitetään myöhemmin sopimukseen – silloin on myös jälkikäteen selvää, mitä on tilattu.
Räätälöityjen sovellusten toteutus on muuttunut nopeasti tekoälyavusteisen koodauksen myötä. Nykyaikaiset kehittäjätyökalut nopeuttavat prototyyppien, käyttöliittymien, integraatioiden ja testikoodin tekemistä, joten asiakas saa entistä nopeammin näkyviä tuloksia ja vaihtoehtoja päätöksenteon tueksi. Tämä on aito etu: kokeileminen on halvempaa ja suunnan voi tarkistaa aikaisin.
Samalla laadunvarmistuksen merkitys korostuu. Tekoälyn tuottama koodi pitää katselmoida, testata ja sen tietoturva varmistaa yhtä huolellisesti kuin perinteisessäkin ohjelmistokehityksessä. Nopeus ei saa tulla ylläpidettävyyden tai turvallisuuden kustannuksella. Siksi kirjaamme jo vaatimuksiin ja sopimukseen, miten koodi katselmoidaan ja testataan, kuka vastaa sen laadusta ja tietoturvasta ja miten avoimen lähdekoodin komponenttien sekä tekoälyn tuottaman koodin lisenssit ja oikeudet on hoidettu. Tekoäly on kehityksessä työkalu, ei oikotie. Hyvä lopputulos syntyy yhä osaavan ihmisen ohjauksessa.
Työ etenee kahdessa vaiheessa: ensin vaatimusmäärittely, sitten markkinakartoitus ja kilpailutus. Aloitamme haltuunotolla – aloituspalaveri, haastattelut ja olemassa olevan materiaalin läpikäynti – ja teemme varsinaisen määrittelytyön parissa työpajassa. Ennen tarjouspyyntöä avaamme keskusteluyhteyden toimittajiin, tarvittaessa tietopyynnöllä (RFI), jolla kartoitamme sopivat tekijät, hinnoittelumallit ja parhaat ideat tarpeen ratkaisemiseksi.
Kilpailutusvaiheessa laadimme tarjouspyynnön liitteineen – vaatimustaulukon ja hinnoittelulomakkeen – ja lähetämme sen tyypillisesti kolmelle tai neljälle toimittajalle. Koska ostetaan tekijää, tapaamisissa painavat ratkaisuehdotuksen lisäksi referenssit, tiimin kokoonpano ja työtapa. Sovimme myös hinnoittelumallista: kiinteä hinta antaa ennustettavuutta, mutta sopii vain tarkkaan rajattuun kokonaisuuteen, kun taas ketterä, työmääräpohjainen malli joustaa, mutta vaatii tilaajalta tiiviimpää ohjausta. Lopuksi pisteytämme tarjoukset ja kokoamme perustellun päätösesityksen. Käytämme koko ajan valmiita asiakirjapohjia, mikä säästää teidän aikaanne itse sisällön suunnitteluun. Työ tehdään pääosin etänä ja vie tavallisesti muutaman kuukauden.
Räätälöidyssä hankinnassa sopimus ratkaisee, kenen käsissä ratkaisu on tulevaisuudessa. Tärkein kysymys on omistajuus: kenelle syntyvä lähdekoodi ja tekijänoikeudet kuuluvat, saatteko koodin ja dokumentaation käsiinne ja voitteko jatkaa kehitystä toisen tekijän kanssa, jos yhteistyö ei toimi. Ilman tätä syntyy hiljainen sidos, jossa vain yksi toimittaja pystyy muuttamaan sovellusta ja hinnoittelee sen mukaan. Jos oikeuksia ei siirretä, sovitaan vähintään lähdekoodin talletuksesta puolueettomalle taholle (escrow).
Pyydämme valitulta toimittajalta sopimusluonnoksen kaikkine liitteineen, myös GDPR:n edellyttämän tietosuojaliitteen, luemme sen läpi ja kommentoimme kirjallisesti. Sovittavia asioita ovat oikeuksien siirto, lähdekoodin ja dokumentaation luovutus, hyväksymiskriteerit ja testaus, takuu ja virheiden korjaus, ylläpito ja vasteajat sekä toimittajan avustamisvelvollisuus sopimuksen päättyessä. Järjestelmätoimituksissa sovelletaan tyypillisesti IT-alan yleisiä sopimusehtoja, esimerkiksi IT2022-ehtoja, ja julkishallinnossa JIT2025-ehtoja, joissa on omat kohtansa tilaajakohtaisille sovelluksille ja lähdekoodin oikeuksille. Emme anna oikeudellista neuvontaa, mutta varmistamme, että sopimus vastaa vaatimuksia ja asiakkaan etu on turvattu; tarvittaessa työskentelemme hankintajuristinne kanssa.
Sovellus ei ole valmis, kun se julkaistaan. Käyttöjärjestelmät päivittyvät, kirjastot vanhenevat ja tietoturvakorjauksia tulee jatkuvasti – mobiilisovelluksessa Applen ja Googlen alustavaatimukset pakottavat päivityksiin, halusi sitä tai ei. Siksi arvioimme jo hankintavaiheessa elinkaaren kokonaiskustannuksen, emme pelkkää toteutushintaa. Sovimme, kuka ylläpitää, millä vasteajoilla ja mitä jatkokehitys maksaa. Näin vältetään tilanne, jossa toimiva sovellus rapautuu hiljalleen vain siksi, ettei ylläpidosta sovittu ajoissa.
Jos organisaationne kuuluu hankintalain (1397/2016) piiriin, sovelluskehitys kilpailutetaan julkisena hankintana, kun hankinnan ennakoitu arvo ylittää kansallisen 60 000 euron kynnysarvon. Arvoon lasketaan toteutuksen lisäksi sopimuskauden aikainen ylläpito ja jatkokehitys, joten raja ylittyy räätälöintityössä helposti. Silloin hankinta ilmoitetaan Hilmassa ja edetään lakisääteisiä määräaikoja noudattaen, ja sopimusehtoina käytetään usein julkishallinnon JIT 2025 -ehtoja. Kannattaa selvittää myös valmiit puitejärjestelyt, kuten Hanselin sopimukset. Yksityisessä kilpailutuksessa liikkumavaraa on enemmän, mutta hyvät käytännöt – selkeä vaatimusmäärittely, tasapuolinen vertailu ja huolellinen sopimus – pätevät kummassakin. Tunnistamme yhdessä, kumpi reitti teitä koskee.
Voimme vetää koko kilpailutuksen puolestanne tai tukea omaa väkeänne juuri niissä kohdissa, joissa apua tarvitaan. Käytännössä Rubicin konsultti huolehtii projektin vetämisestä, työpajoista, dokumenteista ja aikataulusta, ja teidän projektipäällikkönne hoitaa sisäiset järjestelyt ja tiedottamisen. Työn tueksi avataan yleensä yhteinen Microsoft Teams -työtila, jonne tapaamiset ja päätökset kirjataan. Koska sovelluskehitys etenee usein ketterästi sprinteissä, tuemme tarvittaessa myös tuoteomistajan työtä käyttöönoton aikana. Työnjaosta sovitaan aina tapauskohtaisesti.
Huolellinen vaatimusmäärittely tuottaa vertailukelpoiset tarjoukset ja varmistaa, että tarvitsemasi toiminnot, myös ylläpito ja jatkokehitys, on kuvattu ja hinnoiteltu. Kun omistajuus ja oikeudet on sovittu kuntoon, et jää yhden toimittajan varaan ja voit vaihtaa tekijää, jos siihen on tarvetta. Oma henkilöstösi säästyy kilpailutuksen pyörittämiseltä ja voi keskittyä omaan työhönsä. Ja koska tunnemme toimittajat ja hinnoittelun, saat puolueettoman näkemyksen siitä, mikä tarjous on oikeasti hyvä eikä vain halvin.
Onko edessä tai vasta harkinnassa mobiilisovelluksen tai räätälöidyn järjestelmän hankinta? Ota yhteyttä, niin katsomme yhdessä, mistä kannattaa lähteä liikkeelle.
Usein valmis, konfiguroitava tuote riittää ja on halvempi sekä pienempi riski. Räätälöinti kannattaa, kun prosessi on aidosti omanlaisensa tai sovellus on osa palveluanne. Ratkaisemme tämän yhdessä osana vaatimusmäärittelyä – myös silloin, kun suositus on olla teettämättä omaa.
Se sovitaan sopimuksessa, eikä sitä kannata jättää auki. Suosittelemme, että tilaaja saa lähdekoodin ja tekijänoikeudet tai vähintään oikeuden jatkaa kehitystä toisen toimittajan kanssa. Ellei oikeuksia siirretä, sovitaan lähdekoodin talletuksesta puolueettomalle taholle.
Kiinteä hinta sopii tarkkaan rajattuun kokonaisuuteen ja tuo ennustettavuutta; ketterä, työmääräpohjainen malli joustaa muuttuvissa tarpeissa mutta vaatii tilaajalta tiiviimpää ohjausta. Usein järkevin on yhdistelmä: rajattu MVP kiinteänä ja jatkokehitys sovitulla mallilla.
Voi, kun se katselmoidaan, testataan ja sen tietoturva varmistetaan samalla huolella kuin muukin koodi. Tekoäly nopeuttaa työtä, mutta vastuu laadusta on yhä toimittajalla ja tämä pitää kirjata sopimukseen.
Vaatimusmäärittely ja kilpailutus vievät tyypillisesti muutaman kuukauden. Itse kehitystyö tulee tämän päälle ja vaihtelee laajuuden mukaan.
Kyllä. Tasapuolinen kohtelu on kilpailutuksen lähtökohta, ja nykyinen toimittaja voi tarjota siinä missä muutkin. Selkeä vaatimusmäärittely varmistaa, että tarjouksia voidaan verrata reilusti.
Valmisjärjestelmän hankinnassa vertaillaan tuotteita ja niiden ominaisuuksia. Räätälöidyssä hankinnassa ostetaan työtä, joten vertaillaan tekijöitä: osaamista, työtapaa, referenssejä ja kykyä viedä projekti maaliin. Siksi selkeä vaatimusmäärittely, realistinen budjetti ja lähdekoodin oikeuksista sopiminen korostuvat – valmista tuotetta ei ole katsottavana, vaan tarjousten vertailukelpoisuus syntyy hyvästä tarjouspyynnöstä.
Keskeiset valinnat ovat alustat ja toteutustapa (natiivi iOS- ja Android-kehitys vai yhteinen tekniikka, kuten React Native tai Flutter), jakelutapa (julkiset sovelluskaupat vai hallittu jakelu organisaation käyttöön), tarvittavat laiteominaisuudet (offline-käyttö, push-viestit, paikkatieto, kamera), tietoturva ja henkilötietojen käsittely sekä integraatiot taustajärjestelmiin. Nämä valinnat näkyvät suoraan hinnassa ja ylläpidon työmäärässä, joten ne kannattaa tehdä tietoisesti jo ennen tarjouspyyntöä.
Ylläpidosta sovitaan jo hankintavaiheessa, ei vasta julkaisun jälkeen. Käyttöjärjestelmät päivittyvät, kirjastot vanhenevat ja tietoturvakorjauksia tulee jatkuvasti, mobiilisovelluksissa Applen ja Googlen alustavaatimukset pakottavat päivityksiin. Siksi hankinnassa arvioidaan elinkaaren kokonaiskustannus ja sovitaan, kuka ylläpitää, millä vasteajoilla ja mitä jatkokehitys maksaa. Näin toimiva sovellus ei rapaudu siksi, ettei ylläpidosta sovittu ajoissa.
Kyllä. Rubic ei myy ohjelmistoja eikä edusta toimittajia, joten katsomme tilannetta puolueettomasti asiakkaan puolelta. Tunnemme alan toimittajat ja hinnoittelun aiempien kehitys- ja hankintaprojektien kautta, joten saat riippumattoman näkemyksen siitä, mikä tarjous on oikeasti hyvä eikä vain halvin.
Kun organisaatio kuuluu hankintalain (1397/2016) piiriin ja hankinnan ennakoitu arvo ylittää kansallisen 60 000 euron kynnysarvon. Arvoon lasketaan toteutuksen lisäksi sopimuskauden ylläpito ja jatkokehitys, joten raja ylittyy räätälöintityössä helposti. Tällöin hankinta ilmoitetaan Hilmassa ja noudatetaan lakisääteisiä määräaikoja; sopimusehtoina käytetään usein JIT 2025 -ehtoja.
Hinta riippuu hankinnan laajuudesta ja sovitusta työnjaosta: Rubic voi vetää koko kilpailutuksen tai tukea vain niissä kohdissa, joissa apua tarvitaan. Valmiit asiakirjapohjat pienentävät työmäärää ja pitävät kustannukset kurissa. Ota yhteyttä, niin kartoitamme tarpeen ja annamme kustannusarvion. Konsultoinnin kustannus on tyypillisesti murto-osa siitä riskistä, jonka epäonnistunut sovellushankinta aiheuttaa – räätälöidyssä kehityksessä virheet ovat kalliita korjata jälkikäteen.
Alla muutamia asiakkaitamme, joiden kanssa olemme jo saaneet tehdä ainutkertaisen muutosmatkan.
HAM Helsingin taidemuseosäätiö sr vastaa Helsingin kaupungin taidemuseotoiminnasta, kaupungin laajasta taidekokoelmasta sekä julkisesta taiteesta. HAM järjestää kotimaisia ja kansainvälisiä näyttelyitä Tennispalatsissa ja tuottaa myös kahden...
Picnic Group on suomalainen ravintola- ja kahvilakonserni, johon kuuluvat ravintolaketju Picnic, laadukkaaseen kahviin ja lounaaseen keskittyvä La Torrefazione sekä elintarvikehankinnan ja logistiikan asiantuntija Europicnic. Konsernin...
Rubic vastasi Kemianteollisuuden IT-palvelukumppanin kilpailutuksesta. Päätös Rubicin palveluiden käyttämisestä perustui va. toimitusjohtaja Panu Räsäsen mukaan sekä vahvaan luottamukseen Rubicia kohtaan että yrityksen hyvään maineeseen. –...
Rubic kilpailutti Fingolle julkisen hankintalain mukaisen IT-kumppanin ja toimii nyt Fingon ulkoistettuna IT-päällikkönä Talosta puuttui oma IT-henkilö ja IT-palvelukokonaisuuden kilpailuttaminenkin oli ajankohtaista ”Yhteistyölle Rubicin kanssa...
