Verkkosivusto tai sähköinen asiointipalvelu kannattaa hankkia harkiten. Autamme määrittelemään tarpeesi selkeästi ja kilpailuttamaan sopivimman toimittajan, riippumattomasti ja ilman kytköksiä.
Verkkosivuston uusiminen lähtee harvoin liikkeelle tekniikasta. Taustalla on jokin muu: ilme on jäänyt jälkeen, sisällön päivittäminen takkuaa, lomakkeiden tiedot naputellaan käsin asiakas- tai jäsenrekisteriin, tai kävijä ei yksinkertaisesti löydä etsimäänsä. Jos näitä asioita ei kirjata auki ennen tarjouspyyntöä, ne siirtyvät uuteen sivustoon sellaisenaan, mutta uudella ulkoasulla.
Siksi aloitamme siitä, mitä sivuston pitää tehdä ja kenelle. Julkaisujärjestelmästä, tekniikasta ja hinnasta puhutaan vasta sen jälkeen. Tämä on myös nopein tapa saada tarjouksista vertailukelpoisia.
Verkkokehityksen arki on mennyt muutamassa vuodessa uusiksi. Tekoälyavusteiset kehitystyökalut tuottavat koodiehdotuksia, selittävät olemassa olevaa koodia ja auttavat testien kirjoittamisessa. Sivustoista on tullut sovellusmaisempia: progressiivinen verkkosovellus (PWA) voidaan asentaa laitteelle ja se toimii myös ilman verkkoyhteyttä ja voi lähettää käyttäjälle ilmoituksia. Dynaamisia toiminnallisuuksia saa nykyään pystytettyä ilman omaa palvelinympäristöä, ja julkaiseminen on automatisoitunut osaksi kehitysputkea.
Käytännössä painopiste on siirtynyt käsityömäisestä koodaamisesta suunnittelu-, integraatio- ja laadunhallintatyöhön. Tilaajan näkökulmasta muutos on kaksisuuntainen. Toteutus voi olla nopeampaa ja edullisempaa kuin viisi vuotta sitten. Samalla vaatimusten määrittelyn, tuotetun jäljen arvioinnin ja laadunvarmistuksen merkitys vain kasvaa.
Olemme havainneet, että tarjousten hintahaarukka on tästä syystä leventynyt. Kun tarjoukset eroavat toisistaan kymmeniä prosentteja, ero ei useimmiten ole tehokkuudessa vaan siinä, mitä tarjoukseen on luettu mukaan. Sen selvittäminen onkin nyt tilaajan tehtävä.
Autamme kilpailuttamaan mm.:
Usein hankinnan kohde on näiden yhdistelmä. Silloin kannattaa pysähtyä miettimään, ostetaanko kokonaisuus yhdeltä toimittajalta vai jaetaanko se osiin. Molemmissa on puolensa, ja valinta vaikuttaa sekä hintaan että siihen, kuinka helposti toimittajaa voi myöhemmin vaihtaa.
Määrittelyssä käymme läpi ainakin nämä:
Määrittelyssä käytämme valmiita asiakirjapohjia ja vaatimusmäärittelyaihioita, joita täydennetään yhdessä asiakkaan kanssa työpajoissa. Tavoite ei ole tuottaa mahdollisimman paksua dokumenttia vaan sellainen, jonka perusteella toimittajat osaavat hinnoitella saman sisällön.
Kaksi asiaa jää usein tarjouspyynnöissä epämääräiselle tasolle. Molemmat saa kirjattua numeroina.
Saavutettavuus. Digipalvelulaki koskee julkista sektoria ja osaa yksityisen ja kolmannen sektorin organisaatioista. Vaatimustasona ovat WCAG-ohjeistuksen A- ja AA-tason kriteerit, jotka määritellään eurooppalaisessa EN 301 549 -standardissa. Palvelusta pitää löytyä saavutettavuusseloste, ja käyttäjän saavutettavuuspalautteeseen on vastattava 14 vuorokauden kuluessa. Kirjaamme tarjouspyyntöön myös sen, kuka saavutettavuuden todentaa ja missä vaiheessa – jälkikäteen korjaaminen on aina kalliimpaa.
Suorituskyky. Käyttäjäkokemusta mitataan yleisesti Googlen Core Web Vitals -mittareilla: LCP eli suurimman sisältöelementin latautuminen 2,5 sekunnissa, INP eli vuorovaikutuksen vasteaika 200 millisekunnissa ja CLS eli sivun visuaalinen vakaus 0,1 tai alle. Tavoitetaso mitataan 75. persentiilissä erikseen mobiilissa ja työpöydällä. Nämä luvut kannattaa kirjata tarjouspyyntöön hyväksymiskriteereinä.
Vaihe 1: Nykytila ja tavoite. Käymme läpi nykyisen sivuston, sen analytiikan, sisällöt ja liittymät muihin järjestelmiin. Haastattelemme avainhenkilöt ja tarvittaessa myös sivuston käyttäjiä.
Vaihe 2: Vaatimusmäärittely. Työpajoissa syntyy määrittely, joka on samalla tarjouspyynnön liite. Tarvittaessa teemme markkinakartoituksen tai tietopyynnön, jotta tiedetään mitä on saatavilla ja millä hinnalla.
Vaihe 3: Kilpailutus. Laadimme tarjouspyynnön, vertailukriteerit ja arviointilomakkeet. Vastaamme tarjoajien kysymyksiin ja pisteytämme tarjoukset yhdessä asiakkaan kanssa. Demot ja työnäytteet kannattaa ottaa osaksi vertailua – niistä näkee enemmän kuin tarjousliitteistä.
Vaihe 4: Sopimusneuvottelut. Tuemme neuvotteluissa ja käymme läpi sopimusehdot, immateriaalioikeudet, ylläpidon vasteajat ja hinnaston jatkokehitykselle.
Vaihe 5: Toteutusprojektin tuki. Rubicin asiantuntija voi jatkaa projektipäällikkönä tai tuoteomistajan tukena käyttöönottoon asti, valvoa sovitun toteutumista ja hoitaa takuuajan reklamaatiot.
Roolimme mitoitetaan sen mukaan, mitä asiakkaalla on itsellään käytettävissä. Voimme vetää koko hankinnan alusta loppuun, tuottaa vain vaatimusmäärittelyn ja tarjouspyyntömateriaalin, tai toimia asiakkaan oman projektipäällikön tukena ja sparraajana yksittäisissä kohdissa. Osassa projekteista Rubicin asiantuntija istuu ohjausryhmässä varmistajana ja tuo mukanaan markkinatiedon sekä vertailukohdat muista projekteista.
Emme myy toteutusta emmekä saa provisioita toimittajilta. Sama riippumattomuus koskee julkaisujärjestelmän valintaa.
Ota yhteyttä, niin katsotaan yhdessä mistä kannattaa lähteä liikkeelle.
Yleisimmät hetket ovat ylläpitosopimuksen päättyminen, julkaisujärjestelmän versiotuen loppuminen ja tilanne, jossa sivusto ei enää tue organisaation toimintaa. Myös tyytymättömyys nykyiseen kumppaniin on pätevä syy: silloin kannattaa ensin selvittää, onko kyse toimittajasta vai siitä, mitä aikanaan tilattiin.
Verkkosivuprojekti on tyypillisesti pienempi kuin järjestelmähankinta, mutta samat sudenkuopat toistuvat: puutteellinen määrittely, toimittajan valinta väärin perustein ja sopimus, jossa tilaajan etu ei ole turvattu. Apu kannattaa mitoittaa sen mukaan, usein riittää tuki määrittelyyn ja kilpailutukseen.
Se näkyy hinnoissa ja aikatauluissa. Suosittelemme kysymään tarjouspyynnössä suoraan, miten toimittaja käyttää tekoälyavusteisia työkaluja, kuka vastaa tuotetun koodin laadusta ja tietoturvasta, ja kenelle oikeudet lopputulokseen kuuluvat. Vastaukset kertovat toimittajan työtavoista enemmän kuin moni muu kysymys.
Vähintään lähdekoodin ja sisältöjen omistus, ylläpidon sisältö ja vasteajat, jatkokehityksen hinnasto, tietoturvan ja saavutettavuuden vastuut sekä se, miten palvelu siirretään toiselle toimittajalle. Näistä viimeinen unohtuu useimmin ja maksaa eniten.
Ero on harvoin tehokkuudessa. Useimmiten se syntyy siitä, mitä tarjoukseen on luettu mukaan: sisällön siirto, integraatiot, testaus, saavutettavuuden todentaminen ja käyttöönoton tuki voivat olla yhdellä tarjoajalla hinnassa ja toisella erikseen laskutettavaa lisätyötä. Kun tarjouspyynnössä on määritelty sama sisältö kaikille, tarjoukset muuttuvat vertailukelpoisiksi ja hintaero alkaa kertoa jotain todellista. Sen selvittäminen on tilaajan tehtävä.
Molemmissa vaihtoehdoissa on puolensa. Yksi toimittaja tarkoittaa yhtä vastuutahoa ja yleensä kevyempää projektinhallintaa tilaajalle. Osiin jaettu hankinta taas pitää hinnoittelun läpinäkyvämpänä ja tekee toimittajan vaihtamisesta myöhemmin helpompaa. Ratkaisu kannattaa tehdä tietoisesti ennen tarjouspyynnön laatimista, koska se vaikuttaa sekä hintaan että siihen, mihin sitoudutaan pitkäksi aikaa.
Sen ratkaisemista, mikä nykyisistä sisällöistä siirtyy sellaisenaan, mikä kirjoitetaan uusiksi ja mikä poistetaan ja kuka työn tekee. Sisältömigraatio on tyypillisesti kohta, jossa tarjoukset eroavat eniten toisistaan, koska sivumäärä ja työn laajuus jäävät tarjouspyynnössä helposti auki. Siirrettävien sivujen määrä, kieliversiot, kuvien ja liitteiden käsittely sekä tilaajan ja toimittajan työnjako kannattaa kirjata mahdollisimman tarkasti.
Digipalvelulaki koskee julkista sektoria ja osaa yksityisen ja kolmannen sektorin organisaatioista, joten soveltuvuus kannattaa tarkistaa tapauskohtaisesti. Kun laki koskee, vaatimustasona ovat WCAG-ohjeistuksen A- ja AA-tason kriteerit, jotka määritellään eurooppalaisessa EN 301 549 -standardissa. Palvelusta pitää löytyä saavutettavuusseloste, ja käyttäjän antamaan saavutettavuuspalautteeseen on vastattava 14 vuorokauden kuluessa. Vaatimus kannattaa kirjata tarjouspyyntöön velvoitteena ja sopia samalla, kuka saavutettavuuden todentaa ja missä vaiheessa projektia.
Irtautuminen on hyvä sopia jo hankintavaiheessa. Käytännön kohtia ovat lähdekoodin ja sisältöjen omistus, pääsy palvelinympäristöön ja tietokantaan, missä muodossa sisällöt saadaan ulos sekä millä hinnalla ja aikataululla toimittaja avustaa siirrossa. Myös julkaisujärjestelmän valinta vaikuttaa: laajasti käytetty järjestelmä tarkoittaa, että osaajia löytyy muualtakin kuin nykyiseltä kumppanilta.
Kyllä. Roolimme mitoitetaan sen mukaan, mitä teillä on itsellänne käytettävissä. Voimme katsoa keskeneräisen määrittelyn läpi ennen tarjouspyynnön julkaisua, tukea tarjousten pisteytyksessä ja sopimusneuvotteluissa tai toimia oman projektipäällikkönne sparraajana toteutuksen aikana. Emme myy toteutusta emmekä saa provisioita toimittajilta, joten näkemyksemme ei ole sidottu mihinkään yksittäiseen ratkaisuun tai tekijään.
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...
