Ohjelmistohankintoihin erikoistuneena hankintakonsulttina luemme ja arvioimme North Patrolissa useita satoja tarjouksia vuosittain. Näiden taso vaihtelee aivan surkeista aivan ylenpalttisen laajoihin ja tarkkoihin. Tässä artikkelissa kiteytän viisi (5) asiaa, jotka jokaisen ohjelmistotoimittajan kannattaisi muistaa, kun ryhtyy kirjoittamaan vastausta asiakkaan tarjouspyyntöön – oli sitten kyse julkisesta hankinnasta tai yksityisestä kilpailutuksesta.
Tämän listan voisi ehkä myös kirjoittaa muotoon: ”Älä mokaa ainakaan näitä” – mutta tässä on nyt tietoisesti otettu hieman positiivisempi kulma.
Kuulostaa yksinkertaiselta, mutta hämmentävän usein isoimmat erot tarjoajien välille syntyvät juuri siitä, miten tarkkaan tarjoajat ovat lukeneet tarjouspyynnön. Yleensä asiakkaalla on kuitenkin hyvät syyt vaatia niitä asioita, joita tarjouspyynnössä vaaditaan, ja tällöin asiakkaan puolella kiinnitetään erityistä huomiota siihen, onko tarjoajan vastauksessa kaikki keskeiset kohdat huomioitu.
Tarjouspyynnön lukeminen ajatuksella tulisikin aina olla ensimmäinen asia, eikä haittaa, jos myös se tarjouksen laadintaan osallistuva ohjelmistoarkkitehti lukisi sen tarjouspyynnön kunnolla. Ei ole huono idea vaikka lukea se yhdessä, ja varmistaa että kaikki kohdat ymmärretään samalla tavalla.
Jos siis asiakas pyytää ylläpidon valmiusaikaa välille 8–18 tai haluaa hakukoneen indeksoivan myös pdf-tiedostot, niin nämä todennäköisesti eivät ole vahinkoja. Ei kannata olettaa, että asiakkaalle kelpaa vähempikin, tai että ”kyllähän tästä sitten varmasti voi neuvotella myöhemmin”. Jos toimittaja ei kysy mitään prosessin aikana, ja sitten tarjoaa eri asiaa kuin mitä on pyydetty, lentää helposti jonon perälle niin yksityisellä kuin julkisella puolella.
Tarjoajana kannattaa pyrkiä aina vastaamaan asiakkaan vaatimuksiin täsmällisesti, tai sitten kannattaa kysyä asiakkaalta, onko vaatimus ehdoton, ja jos vaatimuksen täyttämisestä syntyy huomattavia lisäkustannuksia, onko tämä ok.
Ensimmäinen asia, jota asiakkaat arvioivat tarjouskisassa on aina se, onko toimittaja lukenut hyvin tarjouspyynnön. Jos jostain huomaa selvästi, että jokin kohta on luettu ylimalkaisesti tai jotain ei ole huomattu ollenkaan, syntyy helposti epäluottamus koko tarjousta ja toimittajaa kohtaan.
Ohjelmistokehitys on tarkkuuslaji, ja tätä tarkkuutta vaaditaan myös tarjousvaiheessa. Jos toimittajan tarjous sisältää joukon kriittisiä bugeja, miksi asiakas odottaisi varsinaisen koodin tason olevan yhtään sen parempaa?
Tavalla tai toisella, ota selvää, miten tarjouksia tullaan arvioimaan. Mikä on tärkeintä asiakkaalle? Mitkä aiheet ovat aivan kriittisiä, mitkä vähemmän kriittisiä? Millaiset ovat asiakkaan kokemukset edellisestä kumppanista? Mitkä olivat edellisen kumppanin heikkoudet?
Julkisissa tarjouskisoissa, etenkin astetta isommissa kisoissa, tämä on yleensä aika helppoa, jos vain osaa lukea tarjouspyyntöasiakirjoja oikein. Joskus avaimet onnistumiseen voivat olla esimerkiksi hintaliitteen ymmärtämisessä. Miten kokonaishinta lasketaan? Mitkä hinnat kerrotaan ja kuinka monella vuodella? Joskus kisoja on hävitty ihan vain siksi, että ei ole ymmärretty, että jatkokehitykselle annettava päivähinta kertautuu kokonaishinnan kaavassa 800:lla henkilötyöpäivällä. Tällöin projektihintaa ratkaisevampi asia voi olla se, mitä laittaa jatkokehitystyön hinnaksi.
Erityisesti jos julkisen hankinnan kilpailutuksessa käytetään jonkinlaista laadullista arviointia, kannattaa pyrkiä ymmärtämään, miten laadullinen arviointi tapahtuu. Mistä saa pisteitä, mistä menettää pisteitä? Millainen vastaus on laadukas vastaus? Jos laadullisen arvioinnin rooli on iso, ei kisaa välttämättä voi voittaa edes agressiivisella hinnoittelutaktiikalla. Tällöin täytyy panostaa laadullisiin asioihin, ja joskus laadullisiin asioihin ylipanostaminen voi jopa mahdollistaa hieman korkeampien hintojen tarjoamisen.
Yksityisellä puolella on usein ratkaisevaa ymmärtää, mistä asiakas on tulossa. Jos edellisen kumppanin kanssa on ollut haasteita, kannattaa nämä selvittää, ja yleensä vahva strategia on todistaa olevansa erityisen vahva juuri niillä osa-alueilla jotka olivat edellisen kumppanin heikkouksia. Harva asiakas haluaa vaihtaa kumppania toiseen samanlaiseen. Tarve saada mukavaa vaihtelua voi joskus saada ylenkatsomaan heikkouksia muilla osa-alueilla.
Mikäli tarjouspyynnössä pyydetään tarjoajilta vastauksia, ratkaisuehdotuksia, selvityksiä tai kuvauksia hankittavaan projektiin ja yritykseesi liittyen, panosta näihin. Vastaa kysymyksiin selkeästi, ammattitaitoanne esiin tuoden, täsmällisesti ja uskottavasti. Novellien muodossa vastaaminen ei kuitenkaan suoraan anna bonus-pisteitä, vaan tiivistäminen on hyve.
Etenkin jos tarjouspyyntö esittää täsmällisen kysymyksen täsmäaiheesta, ei siihen kannata vastata satasivuisella geneerisellä liitedokumentilla, jonka joiltain sivuilta vastaus on tulkinnan kautta kursittavissa kasaan. Mitä täsmällisemmin osaat sitoa vastauksesi asiakkaan tilanteeseen, sitä paremman arvion saat.
Ohjelmistokehityksen onnistuminen on usein kiinni vuorovaikutuksen laadusta. Siksi on erittäin perusteltua arvioida juuri kysymys-vastaus-keskustelua, koska jos toimittaja ei osaa vastata selkokielisesti ja täsmällisesti tarjousvaiheessa, miksi asiakas odottaisi parempaa tasoa projektivaiheelta?
Lähetä tarjous ajoissa, tai ainakin ennen deadlineä. Jos et osaa pitää kiinni aikatauluista edes tarjousvaiheessa, miksi asiakas odottaisi parempaa tasoa projektivaiheelta?
Ylipäätään läpi koko myyntiprosessin kannattaa olla johdonmukainen ja tarkka omissa vastauksissa, niin palaverien aikataulutuksessa kuin lisätietopyyntöihin vastaamisessa. Ei haittaa myöskään, jos uskaltaa epäselvissä kohdissa tarttua puhelimeen ja pyytää selvennystä suullisesti. Tarjousprosessi on aina myös eräänlainen maistiainen siitä, millaista toimittajan kanssa tehtävä yhteistyö olisi.
Liian usein ohjelmistotoimittajat ajattelevat, että heillä on vahvuuksia tai erityisetuja, jotka ovat etuja kaikille asiakkaille, ja tämän seurauksena asiantuntijat toistelevat samoja asioita asiakkuudesta toiseen. Tarjousvaiheessa asiakkaat ovat kuitenkin lähes poikkeuksetta keskittyneitä vain siihen haasteeseen ja projektiin joka heillä on juuri nyt käsillä. Jos siis vahvuutesi on palvelumuotoilu, mutta asiakas hakee kumppania integraatioihin, kannattaa korostaa niitä vahvuuksia, jotka liittyvät integraatioihin ja siihen kumppanuuteen, jota asiakas juuri nyt hakee.
On toki tapauksia, joissa asiakkaan lopullisen valinnan ratkaiseekin jokin kyseiseen hankkeeseen etäisesti liittyvä asia, kuten ”kilpailijanne vahvuudet palvelumuotoilussa ratkaisivat tämän kisan” tai ”kilpailijan kokemus meidän toimialalta oli ratkaiseva asia”, mutta näissä on hyvin usein kyse siitä, että on ollut useita hyviä tarjoajia. Tällöin asiakkaat usein sanovat ratkaisevaksi asiaksi sellaisen vahvuuden, joka on selvästi erotteleva tekijä parhaaksi arvioitujen toimittajien välillä.
On täysin mahdollista, että häviää kisan, jossa teki lähes täydellisen tarjouksen. Siksi ei aina kannata yrittää etsiä vikoja omasta toiminnasta, joskus kaveri on vain parempi.
Huijauskoodeja on tässä lajissa myös aika vähän. Ehkä ainut huijauskoodi, johon aina välillä itsekin törmää, on erittäin osuva referenssi. Jos yhdellä toimittajista on erittäin osuva referenssi, jolle asiakas vielä voi soittaa ja kysyä kokemuksia, voi tämä joskus auttaa nelossijalle tulleen kandidaatin lopulliseen voittoon.
Pelkästään hyvällä referenssillä ei toki pääse pitkälle, kokonaissuorituksen pitää olla laadukas aina.
Näitä hommia lähes 20 vuotta tehneenä konsulttina on lopuksi myös sanottava, että varsin usein toimittajat pettyvät häviöistään aivan liiallisesti.
Usein jos on päässyt tarjouskisassa viimeisten joukkoon, ja asiakkaalle on jäänyt toimittajasta hyvä vaikutelma, voi uutta kauppaa olla tiedossa jo vuoden tai kahden sisällä. Siksi on mielestäni tärkeätä, että toimittajat suhtautuvat jokaiseen myyntiprosessiin samalla vakavuudella ja samalla asenteella.
Ja vaikka edellisissä kohdissa painotankin sitä, että omat vahvuudet pitäisi sovittaa asiakkaan tilanteeseen, on yhtä lailla tärkeätä, että ei väitä olevansa jotain mitä ei ole. Mitä johdonmukaisempi pystyy olemaan, mitä enemmän saa viestittyä sitä, mikä on oman yrityksen se todellinen vahvuusalue, sitä todennäköisemmin tätä omaa vahvuusaluetta pääsee toteuttamaan kyseiselle asiakkaalle – joko parin vuoden päästä tai jollekin toiselle yritykselle sen jälkeen kun asiakkaan avainhenkilöt ovat vaihtaneet työpaikkaa.
Suomi ei ehkä ole aivan klubi, mutta kyllä tämä sen verran pieni markkina on, että yhtään tarjousprosessia ei kannata hoitaa vasemmalla kädellä, jos aikoo menestyä pitkällä tähtäimellä.
Tarjouskilpailuissa pärjää usein tarkkuudella, mutta voittaminen on usein myös kestävyyslaji.
Pertulla on yli viidentoista vuoden kokemus erilaisista web-, extranet- ja intranet-projekteista mm. projektipäällikön, suunnittelijan ja konsultin rooleissa. Perttu on toiminut muun muassa tilaajana ja projektipäällikkönä suuressa mediayhtiössä, sisällönhallintajärjestelmien konsulttina isossa IT-alan yrityksessä sekä itsenäisenä, riippumattomana konsulttina omassa yrityksessään. Lisäksi Perttu on tunnettu kouluttaja ja bloggaaja sekä päätoimittaja web-aiheisessa Vierityspalkki.fi -blogissa.