Ohjelmisto­kehityksen ulkoistaminen – kumppanin valinta pk-yritykselle

Kun olet päättänyt, että räätälöity ohjelmisto on yrityksellesi oikea ratkaisu, seuraava kysymys on: kuka sen tekee? Valinta on kriittinen – väärä kumppani voi johtaa projektiin, joka myöhästyy, ylittää budjetin ja tuottaa huonolaatuista koodia.

Käymme tässä oppaassa läpi eri toimittajatyypit, niiden edut ja haitat sekä konkreettiset kysymykset, joilla erotat hyvän kumppanin huonosta. Lopussa kerromme erikseen, mitä kannattaa vaatia silloin, kun ulkoistettava kohde on koko yrityksen räätälöity toiminnanohjausjärjestelmä – siinä kumppanivalinta on kaikkein sitovin.

Toimittajatyypit

1. Freelancer / yksinyrittäjä

Yksittäinen kehittäjä, joka tekee projekteja itsenäisesti.

Sopii: Pieniin projekteihin (alle 5 000 €), joissa riski on rajallinen.

2. Pieni ohjelmistoyritys (1–15 henkeä)

Pienet toimijat, jotka tekevät projekteja joustavasti. Datastorm Oy on tämän kategorian pienintä päätä: yritys on pieni, ja teemme työn itse. Tekoälyavusteinen kehitys kattaa nykyään sen työmäärän, johon aiemmin tarvittiin muutaman hengen tiimi.

Sopii: Useimpiin pk-yritysten projekteihin (1 000–50 000 €).

3. Keskikokoinen ohjelmistotalo (15–100 henkeä)

Vakiintuneet yritykset, joilla on laaja osaamispohja ja prosessit.

Sopii: Suurempiin projekteihin (50 000 € +), joissa tarvitaan laajaa osaamista.

4. Suuri konsulttitalo (100+ henkeä)

Tunnetut brändit, jotka palvelevat pääasiassa suuryrityksiä.

Sopii: Hankkeisiin, joissa tarvitaan laajaa organisaatiota ja samanaikaista kapasiteettia.

5. Offshore-tiimi (ulkomaat)

Kehitystiimit halvemman työvoiman maissa (Intia, Itä-Eurooppa, Filippiinit).

Sopii: Yrityksille, joilla on kokemusta offshore-yhteistyöstä ja resursseja valvoa työtä. Ei suositeltava ensimmäiseen projektiin.

Miten toimittajan koko vaikuttaa yhteistyöhön?

Toimittajan koko vaikuttaa yhteistyömalliin. Pienessä toimittajassa yhteys tekijään voi olla suorempi, kun taas suurempi toimittaja voi tarjota enemmän samanaikaista kapasiteettia ja laajemman organisaation.

Valintakriteereitä kannattaa käydä läpi toimittajan koosta riippumatta:

• Referenssit: Onko toimittajalla näyttöä vastaavasta työstä?
• Ymmärrys liiketoiminnasta: Pystyykö kumppani kuvaamaan prosessisi ennen tekniikkaa?
• Omistajuus: Siirtyvätkö lähdekoodi ja data tilaajalle?
• Dokumentointi: Saatko ylläpidettävän dokumentaation?
• Resursointi: Kuka tekee työn ja mikä on varallaolomalli?
• Jatkokehitys: Miten ylläpito ja muutokset hoidetaan julkaisun jälkeen?
• Sopimukset: Onko hinnoittelu, aikataulu ja vastuut kirjattu selkeästi?
• Kommunikaatio: Puhutko tekijälle, ja vastaako toimittaja kysymyksiin konkretialla?

Miten arvioin toimittajaa?

1. Referenssit ja portfolio

Pyydä nähdä aikaisempia projekteja. Hyvä toimittaja:

• Näyttää konkreettisia esimerkkejä
• Kertoo projektin haasteet ja miten ne ratkaistiin
• Antaa yhteystiedot asiakkaille, joilta voit kysyä

2. Tekninen osaaminen

Kysy:

• "Miten käytätte AI:ta kehityksessä?" – Hyvä vastaus kuvaa konkreettiset työkalut ja työnkulun.
• "Miten varmistatte koodin laadun?" – Pitäisi puhua testauksesta, koodikatselmoinnista, CI/CD:stä.
• "Miten dokumentoitte projektin?" – Pitäisi saada koodi ja dokumentaatio itselle.

3. Kommunikaatio ja prosessi

Jo tarjousprosessissa huomaat paljon:

• Vastaako nopeasti? – Jos viesti roikkuu viikon, projektin aikana ei ole paremmin.
• Kysyykö paljon kysymyksiä? – Hyvä kehittäjä haluaa ymmärtää tarpeen.
• Ehdottaako vaihtoehtoja? – Hyvä kehittäjä saattaa ehdottaa yksinkertaisempaa ratkaisua.
• Kertooko rehellisesti riskeistä? – Jokainen lupaa onnistumista – hyvä toimittaja kertoo myös haasteet.

4. Hinnoittelu ja läpinäkyvyys

Hyvä tarjous sisältää:

• Selkeän tuntihinnan tai kiinteän hinnan
• Arvion työmäärästä (tunteja, ei vain "projekti")
• Mitä sisältyy ja mitä ei
• Aikatauluarvion
• Maksuehdot

Varoitusmerkit – vältä näitä toimittajia

🚩 Lupaa kaiken liian halvalla

Jos tarjous on puolet muiden hinnasta, jotain on pielessä. Joko työmääräarvio on alimitoitettu, tai laatu kärsii.

🚩 Ei kysy mitään

Jos toimittaja antaa tarjouksen ilman yhtäkään kysymystä, hän joko ei ymmärrä projektiasi tai aikoo myydä geneeristä ratkaisua.

🚩 Koodi jää toimittajalle

Varmista aina, että saat lähdekoodin ja dokumentaation itsellesi. Muuten olet täysin toimittajan armoilla.

🚩 Ei referenssejä

Jos toimittajalla ei ole yhtään näytettävää projektia tai asiakasta, jolta voit kysyä, riski on suuri.

🚩 "Kaikki on helppoa"

Hyvä kehittäjä tunnistaa projektin haasteet ja kertoo niistä etukäteen. Jos kaikki on "helppoa", joko projekti ei ole ymmärretty tai ongelmat tulevat myöhemmin.

🚩 Ei mainitse ylläpitoa

Ohjelmisto vaatii ylläpitoa. Jos toimittaja ei puhu siitä, joudut ongelmiin julkaisun jälkeen.

Sopimuksen keskeiset kohdat

Varmista, että sopimuksessa on:

1. Omistusoikeus koodiin

"Tilaaja saa täydet oikeudet lähdekoodiin ja dokumentaatioon." Ilman tätä olet riippuvainen toimittajasta.

2. Hinnoittelumalli

Tuntihinta vai kiinteä hinta? Mitä tapahtuu, jos työmäärä ylittyy? Miten muutokset hinnoitellaan?

3. Aikataulu ja välietapit

Milloin mikäkin osa valmistuu? Mitä tapahtuu, jos aikataulu myöhästyy?

4. Hyväksyntätestaus

Miten projekti hyväksytään valmiiksi? Mitä kriteerejä käytetään?

5. Takuu ja tuki

Mitä tapahtuu, jos bugeja löytyy julkaisun jälkeen? Onko takuuaika?

6. Ylläpitosopimus

Kuka vastaa ylläpidosta? Millä hinnalla? Mitä siihen kuuluu?

Käytännön prosessi: Näin etenet

1. Määrittele tarpeesi

Kirjoita 1–2 sivun kuvaus:

• Mikä ongelma ratkaistaan?
• Ketkä käyttävät ratkaisua?
• Mitä ratkaisun pitää tehdä (ominaisuudet)?
• Aikataulu ja budjetti (arvio)?

2. Pyydä 2–4 tarjousta

Lähetä sama kuvaus useammalle toimittajalle. Vertaile:

• Tuntihinta ja arvioitu työmäärä
• Aikataulu
• Kysymykset ja lisäkysymykset
• Referenssit ja portfolio

3. Keskustele suosikkien kanssa

Valitse 1–2 parasta ja käy tarkempi keskustelu. Kysy:

• Miten projekti etenisi käytännössä?
• Kuka tekee työn (kehittäjä, ei myyjä)?
• Mitä riskejä näet?
• Mitä tapahtuu, jos vaatimukset muuttuvat?

4. Tarkista referenssit

Soita ainakin yhdelle aikaisemmalle asiakkaalle. Kysy:

• Pysyikö projekti aikataulussa ja budjetissa?
• Miten kommunikaatio sujui?
• Käyttäisitkö uudestaan?

5. Aloita pienellä

Jos mahdollista, aloita pienemmällä projektilla (1 000–3 000 €) ennen suurempaa sitoutumista. Näet, miten yhteistyö sujuu.

ERP-kumppanin valinta – mitä toiminnanohjausjärjestelmältä pitää vaatia

Yksittäisen työkalun voi ulkoistaa melko kevyin perustein: jos yhteistyö ei toimi, teetät sen uudestaan jollain muulla. Toiminnanohjausjärjestelmä on eri asia. Se on se järjestelmä, jossa tilaukset, varasto, laskutus ja raportointi elävät päivittäin, ja siihen sitoudut vuosiksi. Siksi ERP-kumppanilta kannattaa vaatia enemmän kuin tavalliselta ohjelmistotoimittajalta.

• Prosessi ennen tekniikkaa: Kumppanin pitää pystyä kuvaamaan sinun tilaus-toimitusketjusi omin sanoin ennen kuin hän puhuu tietokannoista. Jos ensimmäinen keskustelu menee teknologioihin, hän myy työkalua, ei ratkaisua.
• Näyttö vastaavasta työstä: Pyydä esimerkki järjestelmästä, joka on oikeasti tuotantokäytössä ja jossa on integraatioita varastoon, laskutukseen tai verkkokauppaan. ERP-integraatiot varastoon, laskutukseen ja verkkokauppaan käy läpi, mitä nämä liittymät käytännössä vaativat.
• Vaiheittainen käyttöönotto: Kunnollinen kumppani ehdottaa ensimmäistä tuotantoversiota yhdestä ydinprosessista, ei kertarysäystä. Kuvaan mallin oppaassa ERP:n käyttöönotto vaiheittain.
• Koodi ja data sinulle: Lähdekoodi, dokumentaatio ja tietokanta ovat tilaajan omaisuutta. ERP:n kohdalla tämä on tärkein yksittäinen sopimuskohta – ilman sitä koko liiketoimintasi on yhden toimittajan hallussa.
• Jatkokehityksestä sovitaan etukäteen: ERP ei ole koskaan valmis. Sovi tuntihinta ja reagointiaika jo ennen käyttöönottoa.

Yhden kehittäjän riski on tässä syytä sanoa ääneen: yksi tekijä on yksi pullonkaula. Pienennän sen sillä, että koodi ja dokumentaatio ovat aina asiakkaan, järjestelmät rakennetaan valtavirtateknologioilla, joita osaa moni muukin, eikä mikään olennainen jää vain yhden ihmisen muistiin. Vastapainoksi saat sen, mikä ERP-projektissa ratkaisee eniten: puhut suoraan sille, joka kirjoittaa koodin, etkä myyjälle tai projektipäällikölle. Kun kerrot puhelimessa, että keräilylista pitäisi järjestää eri tavalla, muutos on usein tuotannossa saman viikon aikana.

Jos mietit, kannattaako oma järjestelmä ylipäätään teettää vai riittäisikö valmispaketti, lue milloin oma ERP kannattaa ja räätälöity ERP vs. valmis ERP. Hintahaarukat ja aikataulut löytyvät oppaasta ERP-projektin hinta ja aikataulu.

Miksi Datastorm?

Datastorm Oy on pieni ja ketterä: otamme projektin vastaan ja rakennamme sen itse. Päätuotteemme ovat räätälöidyt toiminnanohjausjärjestelmät pk-yrityksille, ja niiden ympärille integraatiot ja automaatiot.

• Tekoälyavusteinen kehitys: Käytämme Claudea, GPT:tä ja Cursoria jokaisessa projektissa. Se on syy siihen, että kokonainen ERP on pk-yrityksen budjetissa.
• Selkeä tuntihinta: Kaikki työ 70 €/h + ALV, kilometrikorvaus 1 €/km + ALV Mäntsälästä. Ei erillisiä konsultointi- tai projektinjohtolisiä.
• Suora kommunikaatio: Puhut kehittäjälle, et myyjälle.
• Rehellinen neuvonta: Sanomme suoraan, jos työtä ei kannata teettää meillä – esimerkiksi silloin, kun tarve on täysin vakio ja valmisohjelmisto hoitaa sen halvemmalla.
• Koodi on sinun: Saat aina lähdekoodin ja dokumentaation.
• Kasvavan yrityksen ymmärrys: Tiedämme, miten muutamien miljoonien ja muutamien kymmenien miljoonien eurojen liikevaihtoa tekevä yritys toimii ja mihin sen aika oikeasti kuluu.

Yhteenveto

Ohjelmistokehityksen ulkoistaminen onnistuu, kun:

• Valitset toimittajan kriteereillä: referenssit, ymmärrys liiketoiminnasta, omistajuus, dokumentointi, resursointi, jatkokehitys, sopimukset ja kommunikaatio
• Arvioit toimittajan huolella: Referenssit, kommunikaatio, tekninen osaaminen
• Vältät varoitusmerkkejä: Liian halpa, ei kysymyksiä, koodi jää toimittajalle
• Teet hyvän sopimuksen: Omistusoikeus, aikataulu, ylläpito
• Aloitat pienellä: Testaa yhteistyö ennen suurempaa projektia

Oikea kumppani on investointi, ei kustannus. Väärä kumppani voi tuhota koko projektin. Käytä aikaa valintaan.

Usein kysytyt kysymykset

Kannattaako ohjelmistokehitys ulkoistaa freelancerille, pienelle toimijalle vai ohjelmistotalolle?

Toimittajan koko vaikuttaa yhteistyömalliin. Pienessä toimittajassa yhteys tekijään voi olla suorempi, kun taas suurempi toimittaja voi tarjota enemmän samanaikaista kapasiteettia ja laajemman organisaation. Valinnassa kannattaa katsoa referenssejä, ymmärrystä liiketoiminnasta, omistajuutta, dokumentointia, resursointia, jatkokehitystä, sopimuksia ja kommunikaatiota.

Mitä ERP-kumppanilta pitää vaatia?

Vaadi neljää asiaa: että kumppani osaa kuvata sinun prosessisi omin sanoin ennen kuin puhuu tekniikasta, että hän on tehnyt vastaavan järjestelmän aiemmin, että lähdekoodi ja dokumentaatio siirtyvät sinulle, ja että jatkokehityksestä on sovittu ennen käyttöönottoa. ERP ei ole projekti, joka päättyy julkaisuun.

Mikä on riski, jos ERP:n rakentaa yksi kehittäjä?

Riski on aito, jos järjestelmän jatkuvuus jää yhden henkilön varaan. Se pienennetään kolmella asialla. Lähdekoodi ja dokumentaatio ovat tilaajan, järjestelmä rakennetaan valtavirtateknologioilla, joita osaa moni muukin, eikä mitään jää vain yhden ihmisen muistiin. Laajaa, liiketoimintakriittistä ERP-kokonaisuutta ei pidä olettaa yhden henkilön kertatyöksi. Kevyt toteutusmalli tarkoittaa sitä, ettei rajatun ensimmäisen tuotantovaiheen tarvitse vaatia raskasta projektiorganisaatiota.

Kuka omistaa lähdekoodin ulkoistetussa projektissa?

Sovi kirjallisesti, että tilaaja saa täydet oikeudet lähdekoodiin ja dokumentaatioon. Ilman tätä olet pysyvästi riippuvainen yhdestä toimittajasta. Datastorm Oy:n projekteissa koodi ja dokumentaatio ovat aina asiakkaan.

Mitä ulkoistussopimuksessa pitää olla?

Sopimuksessa pitää olla kuusi asiaa: omistusoikeus lähdekoodiin ja dokumentaatioon, hinnoittelumalli ja se miten muutokset hinnoitellaan, aikataulu ja välietapit, hyväksyntätestauksen kriteerit, takuu ja tuki julkaisun jälkeen sekä ylläpitosopimus.

Maksaako tarjous ja onko se sitova?

Tarjous on ilmainen eikä sido mihinkään. Tarjouksen voi pyytää myös silloin, kun hankkeesta ei ole vielä tehty päätöstä. Saat samalla konkreettisen arvion siitä, mitä järjestelmän toteuttaminen teidän tapauksessanne maksaisi. Arvio annetaan tunteina ja euroina, eikä mitään laskuteta ennen kuin se on hyväksytty.

Lue myös

• Räätälöity toiminnanohjausjärjestelmä pk-yritykselle
• Milloin oma ERP kannattaa – ja milloin ei
• ERP-projektin hinta ja aikataulu
• Ohjelmistoprojektin budjetointi pk-yritykselle
• AI ohjelmistokehityksessä – miten tekoälyavusteinen kehitys muuttaa työmäärää ja kustannuksia
• Räätälöity ohjelmisto vs valmisratkaisu
• Ohjelmistokehitys palveluna →