Hyvän tarjouspyynnön perusteet

Perttu Tolvanen

Tässä artikkelissa listataan tärkeimmät vinkit hyvän tarjouspyynnön laadintaan verkkosivuston uudistamiseen tähtäävässä projektissa. Artikkeli ei yritäkään olla kaiken kattava ohjeistus, vaan enemmänkin vinkkilista kokeneelle ostajalle tärkeimmistä hyvän tarjouspyynnön elementeistä.

myyntipresentaatio

Työssäni kirjoitan erilaisia tarjouspyyntöjä viikottain ja lisäksi autan asiakkaiden omia tiimejä tarjouspyyntöjen laadinnassa. Artikkelin vinkit pätevätkin todennäköisesti parhaiten hieman isompien verkkopalvelu-uudistuksien ostamiseen (yli 20 000 euron projekteihin), mutta varmasti pienempiäkin projekteja ostavat voivat hyötyä artikkelista.

Vinkkilista myös hieman ohittaa tarjouspyyntöjen vaikeimman ja tärkeimmän asian – eli tarjouspyynnön kohteen kuvaamisen menetelmät ja tyylin. Artikkelin vinkit keskittyvät enemmänkin hyvän tarjouspyynnön tärkeimpiin yksityiskohtiin. Nämä yksityiskohdat usein kuitenkin vaikuttavat eniten siihen saadaanko ylipäätään hyviä tarjouksia vastauksena tarjouspyyntöön sekä siihen miten työläs ja vaikea vertailuprosessista tulee. Paraskaan kohteen kuvaus kun ei välttämättä tee itse hankinnasta vielä onnistunutta.

1) Pyydetyn hinnoittelumallin ja tarjouspyynnön tarkkuuden pitää vastata toisiaan.

Jos pyytää kiinteätä hintaa, niin liitteenä on syytä olla ammattilaisen kirjoittama vaatimusmäärittely. Teknologiaa ei tarvitse olla valittuna, mutta jos teknologiavalinta halutaan tehdä ennen tarjouskilpailua, niin se kyllä parantaa saatujen tarjousten laatua. Edellyttäen tietysti, että vaatimusmäärittely on jo osattu kirjoittaa valittua teknologiaa ajatellen.

Jos taas hakee tavoitehintaista toteutusprojektia, niin kattava hankinnan kohteen kuvaus voi riittää tarjouspyynnön osana, tai liitteenä. Jopa muutaman sivun todella kirkas ja kattava kuvaus hankinnan kohteesta voi tuoda saadut tarjoukset muutamien tuhansien eurojen päähän toisistaan.

Jos valmisteluvaiheessa on tehty konseptisuunnitelma, niin tämä voi olla liitteenä, mutta ostamisen kannalta on järkevämpää yleensä tiivistää tehty suunnittelutyö muutaman sivun pituiseksi vaatimusmäärittely-tyyppiseksi kuvaukseksi. Näin neuvoteltavasta ostamisen kohteesta on yksiselitteinen kuvaus, eikä neuvottelu nojaa sekalaiseen kokoelmaan powerpointteja ja leiskoja.

Ehkä tyypillisin alalla koettu ongelma (kun juttelee toteuttajayrityksien kanssa) on, että asiakkaat haluaisivat kiinteähintaisia projekteja, mutta eivät ole kuitenkaan osanneet tai ehtineet tehdä siihen vaadittavaa valmistelutyötä ennen tarjouspyynnön lähettämistä.

Tavoitehintainen ostaminen on hyvä kompromissi nopeuttaa valmisteluvaihetta ja silti saada ennustettavuutta projektin ensimmäisen vaiheen hintaan. Tavoitehintainenkin ostaminen tosin vaatii melko tarkan kuvauksen siitä mitä kaikkea ensimmäisessä vaiheessa pitää toimittaa, mutta yksityiskohtaisesti tätä kaikkea ei tarvitse tällöin kuvata.

Jos taas haluaa tehdä projektinsa aidosti ketterien menetelmien avulla, niin tällöin kannattaa harkita hinnoittelumalliksi puhdasta tunti/päivälaskutusta tai melko löysää tavoitehintamallia. Aidosti ketterien toimitusmallien tärkein edellytys kun on asiakkaalta löytyvä projektin johtamiskyky, ja silloin on myös asiakkaan etuna saada mahdollisimman suora vaikutusmahdollisuus projektin sisältöön ja tehtäviin. Ostamisen kannalta tällainen malli on sitten jo lähempänä oman tiimin rekrytointia kuin projektin ostamista, ja siihen kannattaakin suhtautua siten.

2) Valintakriteerit tulee asettaa ennakkoon ja kertoa tarjouspyynnössä selkeästi.

Kaikki asiat, jotka tulevat vaikuttamaan tarjousten arviointiin on syytä kertoa tarjouspyynnössä avoimesti. Erityisesti laadulliset kriteerit on syytä kertoa avoimesti, jos haluaa saada hyviä, laatukriteereihin vastaavia tarjouksia.

Riippumatta pyydetystä hinnoittelumallista, laadulliset kriteerit kannattaa ensisijaisesti kohdistaa tarjottuihin henkilöihin ja erikseen valittuihin ratkaisun avainkohtiin. Keskeiset tavoiteltavan ratkaisun avainosiot kun on joka tapauksessa syytä kirjoittaa auki tarjouspyyntöön tai sen liitteisiin, niin näihin ehdotettuja ratkaisumalleja kannattaa käyttää myös pisteytykseen.

Myös jos esimerkiksi asiakastyytyväisyyttä halutaan käyttää kriteerinä, niin on syytä kirjoittaa tarkasti auki se, miten tätä aiotaan pisteyttää ja mitata. Referenssien käyttäminen laatukriteerinä on syytä myös sitoa tarjottuihin henkilöihin.

Jos taas kustannustehokkuus on tärkeätä, niin tämäkin kannattaa reilusti avata tarjouspyynnössä. Markkinoilta kyllä löytyy riittävästi hyviä kandidaatteja, joita myös tarkan markan asiakkaat kiinnostavat.

Omien valintakriteerien avaaminen tarjouspyynnössä on yksi tärkeimpiä saatavien tarjousten laatua parantavia asioita.

3) Aina kannattaa käyttää hinta-ankkuria.

Tarjoajille on syytä aina viestiä jollain tavalla minkälaisia hintalappuja tarjoajilta odotetaan – edes suurinpiirtein. Jos odotettavissa olevista hintalapuista ei ole ostajalla mitään ennakkoymmärrystä, niin silloin on syytä keskustella vapaamuotoisesti potentiaalisten tarjoajien kanssa vielä ennen kuin lähettää tarjouspyynnön. Hyvä ostaja tietää aina etukäteen minkälaisia hintalappuja pitäisi suurinpiirtein tarjoajilta tulla.

Asiansa osaavat yritykset osaavat myös kyseenalaistaa asiakkaan antaman hinta-ankkurin tarvittaessa. Parhaimmillaan tämä onkin erittäin edullinen ja nopea tapa saada selville ovatko omat vaatimukset ja toivottu hintalappu realistisessa suhteessa.

Ei ole kenenkään etu, että saadut tarjoukset ovat satojen tuhansien eurojen päässä toisistaan. Sellainen kertoo lähes aina siitä, että ostaja ei ole tehnyt riittävästi valmistelutyötä hankintaan.

4) Hinnat kannattaa aina pyytää erillisen liitteen avulla.

Hintavertailu on yksi vaikeimmista asioista isoissa tarjousvertailuissa. Tarjoajille ei kannata antaa vapaita käsiä ilmoittaa hintojaan omissa taulukoissaan ja myyntiesitteissään.

Todellisten hintojen laskeminen kymmenistä liitteistä johtaa todennäköisesti vain virheisiin. Selkeä excel on kaikkien etu, ja hintaexcelistä kannattaa vaikka pyytää tarjoajilta ennakkoon kommentteja, jos ei ole varma sen kattavuudesta.

5) Projektin pitää kuulostaa sinulle tärkeältä.

On ensiarvoisen tärkeätä, että kuvaat tarjouspyynnössä projektisi liiketoiminnallisen tärkeyden, tarjouspyyntöä edeltäneet vaiheet, jatkokehityssuunnitelmat ja oman organisaatiosi avainresurssit projektiin liittyen.

Mitä sitoutuneemmalta vaikutat hankkeeseesi, sitä parempia tarjouksia saat.

Bonuksena näiden viiden kohdan lisäksi voisi vielä todeta, että mitä selkeämmät sävelet sinulla ylipäätään on projektia kohtaan, niin sitä tärkeämpää on, että myös tarjouspyyntösi viestii tätä määrätietoisuutta kaikilta osin. Lopputuloksen ei tarvitse olla valmiiksi suunniteltu, mutta asiakkaan omien rivien pitää olla suorassa ja projektiorganisaatio valmiina. Tällöin myös tarjoajat suhtautuvat projektiisi hyvällä asenteella, saat hyvän tiimin ja realistisen hinta-arvion.

PS. Jos olet töissä julkishallinnossa, niin hankinnan valmistelussa on vielä pari lisämuuttujaa. Siksi kannattaa tutustua esimerkiksi tähän Verkkopalvelun hankinta julkishallinnossa -oppaaseen.

PSS. Haluatko Vierityspalkin artikkelit sähköpostiisi? >> Tilaa kuukausikirje

  1. Anu Halme says:

    Erittäin hyvä ja tärkeä teksti, kiitos Perttu. Itse olen viime aikoina viihtynyt hyvin ”räätälöinti” -termin kanssa. Tarjouspyynnöissä usein saa hyvät pisteet, jos räätälöintiä ei tarvita, vaan kaikki toiminnallisuudet löytyvät valmiina. Usein tilaaja on kuitenkin selvästi hankkimassa asiakaskohtaista verkkopalvelua, mutta räätälöidä ei saa. Tällöin pisteytyskriteerit johtavat joskus absurdeihin tilanteisiin ja sanamuotoihin kun tarjouspyyntö on tehty valmisohjelmistoa varten, mutta hankkeen kohde on kuitenkin selvästi asiakaskohtainen tai ainakin asiakkaan näköinen sovellus.

  2. Perttu Tolvanen says:

    Kiitos kommentista, Anu.

    Tuo räätälöinnin välttely liittyy minun kokemuksen mukaan ensisijaisesti SharePoint-projekteihin. Tällaisissa tilanteissa on meillä ainakin tapana kertoa valittu teknologia, ja tällöin yleensä tuosta asiasta ei synny ongelmaa.

    Ainakaan meidän tarjouspyynnöissä verkkopalveluprojekteissa ei yleensä anneta mitään ”erityispisteitä” siitä, että syntyykö lopputulos koodaamalla vai paketista. Tärkeintä on pystyä vakuuttamaan asiakas siitä, että lopputulos on toivottu. Joskus paras lopputulos syntyy valmisohjelmiston palikalla, joskus koodaamalla asiakaskohtainen toteutus. Ei räätälöitykään lopputulos mitenkään itseisarvoisesti ole parempi, etenkin jos vastassa on vaikkapa joku aktiivisessa kehityksessä oleva lisäosa-moduuli.

    Ykköskohtana vinkeissä on hyvin tarkoituksellisesti tuo tarjouspyynnön ja vaatimuksien tarkkuuden suhde. Jos aikaisessa vaiheessa pystytään valitsemaan teknologia, niin se kannattaa niin tehdä. Jos ei pystytä, niin silloin ei kannata kirjoittaa vaatimusmäärittelyä mitään yksittäistä valmisohjelmistoa vastaan.

    Pahintahan on juuri sellainen, että oikeasti haluttaisiin joku teknologia, ja sitten on kirjoitettu vaatimusmäärittely sen mukaisesti, mutta ei ole uskallettu/pystytty lukitsemaan tarjouspyynnössä sitä teknologiaa kuitenkaan.