Miten laaditaan hyvä tarjouspyyntö verkkopalveluprojektista? – Janne Jääskeläisen muistilista asiakkaalle
Otathan huomioon, että tämä artikkeli on yli 14 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Nettiauto.com uudistui ja erillinen mobiiliversio jäi vihdoin historiaan.
Artikkeli on kappale kirjasta “Verkkopalvelun ostajan opas” (Janne Jääskeläinen 2010). Teksti julkaistaan kirjan kirjoittajan Janne Jääskeläisen luvalla.
Tarjouspyynnössä tulisi olla selkeästi mainittuna ainakin nämä asiat, jotta turhilta lisätöiltä ja väärinymmärryksiltä vältyttäisiin:
- Yhteystiedot: Yrityksen nimi, verkkopalvelun osoite, käyntiosoite, puhelinnumero, tarjouspyynnöistä vastaavan henkilön nimi, titteli, puhelinnumero ja sähköpostiosoite.
- Päivämäärät: Päivä ja kellonaika, joihin mennessä tarjous tulee toimittaa (ja riittääkö sähköpostitse toimittaminen) ja mikä on verkkopalvelun toivottu julkaisupäivämäärä.
- Tavoite: Mikä on sivuston tarkoitus? Onko kyseessä yrityksen oman sivuston uusiminen, markkinointisaitti, kampanjasaitti vai bannerikampanja? Onko sivustouudistuksella jonkinlaisia tavoitteita hakukonenäkyvyyden kannalta? Onko sivustouudistuksen tarkoituksena saada lisää kauppaa, rekisteröityneitä asiakkaita vai vain uudistaa sivusto yritysilmeen mukaiseksi? Jos olet epävarma termeistä, kuvaa vapaamuotoisesti, mitä verkkopalvelu-uudistukselta toivot.
- Hyvää/huonoa nykyisessä: Mikä nykyisessä sivustossa on hyvää, mikä huonoa? Onko joitain ominaisuuksia, mitä erityisesti haluatte säilyttää tai hankkiutua eroon?
- Saatu palaute: Millaista palautetta sivusto on elinkaarensa aikana saanut? Mitä on kehuttu, mitä haukuttu?
- Kohderyhmä: Mitkä ovat sivuston pääkohderyhmät? Miten hyvin nykyinen sivusto mielestänne palvelee näitä kohderyhmiä?
- Päivitystarve: Kuinka usein sivustoa tarvitsee päivittää? Jos tarpeet ovat satunnaisia, ei välttämättä kannata erikseen tilata julkaisujärjestelmää, vaan kannattaa pitää sivustot staattisina.
- Konsepti ja määrittely: Tarvitsetteko apua tarpeiden määrittelyssä, sivuston sisältöjen määrittelyssä, sivukartan teossa tai verkkopalvelun konseptin hiomisessa?
- Referenssit: Jos sinulla on jo tiedossa ne sivustot, joihin lopputulosta tullaan vertailemaan, tai jos olette löytäneet verkosta sellaisia sivustoja, joissa on joitain ominaisuuksia, joista pidätte tai ette pidä, ne kannattaa liittää jo tässä vaiheessa mukaan.
- Lisätyöt: Jos samassa tarjouspyynnössä haluat tarjouksen muistakin verkkopalveluprojektiin liittyvistä töistä (esimerkiksi markkinointikampanja, johon liittyy Flash-animointia ja erillinen bannerikampanja), ne kannattaa eritellä.
- Tekniikka: Onko palvelin, jolle sivusto tulee, määrätty? Jos ei, haluatteko tarjouksen ylläpidosta samassa yhteydessä? Jos on, millaisesta palvelimesta on kysymys ja millä ohjelmointikielellä sivusto tulee toteuttaa? Jos käytössä on jo olemassa oleva julkaisujärjestelmä, mikä sen nimi ja versio on?
- Verkkotunnus: Onko sivuston verkkotunnus jo olemassa? Hallitsetteko sivuston verkkotunnusta itse, vai ovatko oikeudet jollain kolmannella osapuolella?
- Kieliversiot: Tuleeko verkkopalvelusta kieliversioita? Onko kieliversioiden tarkoitus olla identtisiä (eli jokaisesta sivusta on olemassa oma versionsa kaikilla valituilla kielillä), vai poikkeavatko kieliversiot toisistaan? Tuleeko julkaisujärjestelmän hallinnointiliittymän olla käytettävissä useilla kielillä?
- Hallinnoinnin käyttäjäryhmät: Onko sivustolla useampia eri käyttäjiä, joiden tulee voida hallinnoida sivustoa? Täytyykö teidän pystyä itse päivittämään käyttäjäryhmiä ja näiden oikeuksia?
- Koulutus: Tarvitsetteko sivustouudistuksen yhteydessä koulutusta? Jos verkkopalvelun yhteydessä sivustoon liitetään julkaisujärjestelmä, tämän käyttökoulutuksesta kannattaa pyytää myös tarjous (yleensä julkaisujärjestelmien toimittajat antavat tästä tarjouksen pyytämättäkin).
- Sisällöntuotanto: Jos sivustouudistuksen yhteydessä sivustoon liitetään julkaisujärjestelmä, kopioiko asiakas itse tiedot edellisestä järjestelmästä tai staattisilta sivuilta, vai toivotaanko, että yhteistyökumppani tekee sen?
- Rajoitukset: Mitä muita rajoituksia verkkopalvelun suunnitteluprojektiin mahdollisesti liittyy?
- Muut asiat: Kaikki muu sellainen projektin kannalta olennainen, mitä haluatte tässä vaiheessa tuoda julki.
Jos haluat olla oikein kiltti ja tehdä samalla positiivisen vaikutuksen palveluntarjoajaan, liitä tarjouspyyntöön vielä lisäksi tieto siitä, mikä on budjetin koko ja kuinka monelle kilpailijalle tarjouspyyntö on lähetetty. Tämä vähentää todella paljon ylimääräisen työn tekemistä, ja parhaimmassa tapauksessa tarjouspyynnön vastaanottaja voi ohjata tarjouspyynnön yhteistyökumppanilleen, jos esimerkiksi budjetti on liian pieni tai suuri (kyllä, budjetti voi olla myös liian suuri).
Janne Jääskeläinen
Lue lisää: Tässä blogissa on myös julkaistu toinen artikkeli samasta aiheesta: Hyvä tarjouspyyntö verkkosivuston uudistukseen
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
2 kommenttia on “Miten laaditaan hyvä tarjouspyyntö verkkopalveluprojektista? – Janne Jääskeläisen muistilista asiakkaalle”
Kommentointi on suljettu.
Petri Mertanen
Hyvä muistilista ja toimii mukavasti alustavan määrittelyn runkona. Tavoitteet ovat tosi tärkeitä ja niistä voi helposti johtaa säännöllisesti seurattavat verkkopalvelun avainmittarit. Ehkä tuohon voisi lisätä vielä toivomukset käyttötuelle.
En ole lukenyt kyseistä teosta, mutta tähän liittyen näen erittäin tärkeänä, että myös tarjouspyyntöön kirjattaisiin valintakriteerit sekä näiden painotukset toimittajan, hankittavan palvelun tai järjestelmän osalta.
Perttu Tolvanen
Hyvää muistilistaa voisi täydentää muutamalla disclaimerilla ja ideoilla jatkoartikkeleiksi:
1) Jos päivitystarve on merkittävä, ja päivittäjiä tulee olemaan useita, niin julkaisujärjestelmän valintaan kannattaa panostaa melkein yhtä paljon kuin sivuston kehitystarpeiden pohdintaan. Yleisin syy isompiin uudistusprojekteihin nykyisin on nimittäin se, että ollaan hyvin tyytymättömiä omaan julkaisujärjestelmään – ja tämä on etenkin silloin ikävää jos itse sivusto on muuten ihan moderni ja toimiva.
2) Tärkeä valinnan paikka on myös siinä, että kuinka pitkälle tekee itse määrittely- ja suunnittelutyötä. Joskus kannattaa tehdä itsenäisesti aika pitkälle (ehkä ostaa sparrausapua tueksi), ja sitten hakea hyvä toimittaja hoitamaan homma loppuun. Joskus taas fiksumpaa on ostaa erikseen yksi porukka tekemään vaatimusmäärittelyä ja konseptointia, ja sitten kilpailuttaa suunnitellulle kokonaisuudelle hyvä toimittajakumppani. Jälkimmäinen on tyypillinen malli vähänkin isommissa hankkeissa, mutta ei ainut mahdollinen koska siinäkin on haasteensa. Julkishallinnon puolella tosin erillinen vaatimusmäärittelyvaihe on käytännössä pakollinen useimmissa tapauksissa.
3) Millainen kumppani halutaan sivuston pitkäjänteiseen kehitykseen? Usein asiakkaat haluavat löytää kumppanin jolla olisi bisnesymmärrystä, käyttöliittymäosaamista, visuaalista näkemystä, vahva tekninen osaaminen ja vielä hyvät tukipalvelut. Valitettavasti aina kaikkea ei voi saada, ja karu fakta on, että uskottavasti koko paletin tekeviä tahoja on todella vähän Suomessa. Joskus toki riittää yksi tosi pätevä tyyppi, mutta silloin ollaan sitten sen yhden kaverin varassa. Etenkin bisnesosaaminen ja näkemys verkkokehityksen trendeistä hyvin harvoin yhdistyy tekniseen osaamiseen. Asiakkaiden kannattaisi useammin lähteä ajatuksesta, että hyvä saitti syntyy muutaman valikoidun yhteistyökumppanin kanssa. Toteutusprojektista toki kannattaa vastuuttaa yksi taho selkeästi, mutta nyrkkisääntönä voi pitää että liikaa asioita ei kannata tunkea siihen toteutusprojektin tarjouspyyntöön. Harvalla teknisellä toimittajalla on oikeasti uskottavaa flash-osaamista tai konseptiosaamista.