Mistä tulee huomioida, kun solmitaan alihankintasopimus järjestelmäkehityksessä?

IT-järjestelmien kehittämisprojekteissa solmittavat sopimukset ovat pääasiassa urakkasopimuksia ja osakkuussopimuksia. Sekä käyttäjille että toimittajille on erilaisia etuja ja haittoja kummankin sopimustyypin käyttöönotossa, mutta on tärkeää ymmärtää niiden ominaisuudet ja huomioon otettavat seikat sopimusta solmittaessa. Tässä artikkelissa käsitellään urakkasopimuksia IT-järjestelmien kehitystyössä.

Järjestelmäkehitys ja urakkasopimukset

Mikä on urakkasopimus?

Urakkasopimuksen ymmärtämiseksi on ensisijaisen tärkeää tarkistaa urakkasopimuksen perustamisvaatimukset suoraan lakitekstistä.

Pykälä 632

Urakka syntyy, kun sopijapuolista toinen lupautuu suorittamaan tietyn työn ja toinen lupautuu maksamaan korvauksen työn tuloksesta.

“Työn suorittaminen” on avainkäsite. Urakkasopimuksen tyypillinen esimerkki on rakennuksen rakentaminen, joka vaatii rakennustöitä. Esimerkiksi, jos talo tai rakennus on rakennettu määräaikaan mennessä, sitä pidetään “työn suorittamisena”, ja velvollisuus katsotaan täytetyksi. Jos rakennustyöt eivät edisty ja toimitus viivästyy, velvollisuuden laiminlyöntivastuu voidaan määrätä tietyin edellytyksin. Kuitenkin, jos “työn suorittaminen” on kerran hyväksytty, velvollisuuden laiminlyöntiongelma poistuu, ja sen jälkeen kyse on virhevastuusta. Tässä mielessä, “työn suorittamisen” tuloksen korostaminen on urakkasopimuksen ominaispiirre. Lisätietoja siitä, milloin “työn suorittaminen” hyväksytään, on selitetty seuraavassa artikkelissa.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Urakkasopimuksia käytetään paitsi rakentamisessa, myös suurissa, yksityiskohtaisia suunnitelmia vaativissa järjestelmäkehitysprojekteissa.

Mikä ero on urakkasopimuksella ja osa-aikaisella sopimuksella?

Kun ymmärrämme, että urakkasopimus on sopimustyyppi, joka korostaa “työn suorittamisen” tulosta, ymmärrämme myös osa-aikaisen sopimuksen ominaisuudet. Tämä korostaa prosessia, ei “suorittamisen” tulosta. Esimerkiksi, jos toimistotyö on suoritettu asianmukaisesti riippumatta tuloksesta, palkkion vaatiminen on mahdollista (pykälä 648, kohta 2), ja jos suoritus päättyy kesken syystä, joka ei johdu vastaanottajasta, palkkion vaatiminen on mahdollista suhteessa suoritukseen (pykälä 648, kohta 3).

Lisätietoja toimeksiantosopimuksen ja osa-aikaisen sopimuksen vertailusta on selitetty seuraavassa artikkelissa.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Miksi urakkasopimukset ovat suosittuja järjestelmäkehityksessä?

Järjestelmäkehityssopimuksissa urakointi on erittäin yleistä. Urakointi on yleistä, koska siitä on etua sekä työn tilaajalle että työn suorittajalle.

Ensinnäkin, työn tilaajan kannalta urakointiin perustuvan työn tilaamisen etu on, että velvollisuuden täyttämisen vaatimus “työn suorittaminen” voidaan helposti selkeyttää. Toisin sanoen, (vaikka myöhemmin löytyisi virheitä, kuten bugeja, ja virhevastuukysymyksiä tulisi esiin) periaatteessa palkkiota ei tarvitse maksaa, ellei työ ole “valmis”. Tämä selkeys on erittäin houkutteleva työn tilaajille, jotka eivät halua ottaa riskiä, että heidän on maksettava enemmän, jos työ vie enemmän aikaa kuin odotettiin tai jos aikataulu venyy. “Valmiin” tuotteen vaihtaminen kiinteään palkkioon on erittäin kätevää budjetin hallinnan kannalta.

Toisaalta, myös työn suorittajalle on etua urakointisopimuksen tekemisestä. Urakkasopimus voi tuottaa suuremman voiton kuin osa-aikainen sopimus, jos se sujuu hyvin.

Koska “työn suorittaminen” on velvollisuuden täyttämisen vaatimus, työn suorittajan ei tarvitse miettiä, kuinka paljon tuotteen kustannukset (järjestelmäkehityksessä suurin osa on henkilöstökustannuksia) ovat “valmiin” tuotteen saamiseksi. Tästä syystä, sekä voittoa tavoittelevan työn suorittajan että budjetin hallintaa helpottavan työn tilaajan intressit yhdistyvät, ja järjestelmäkehityksessä urakkasopimukset ovat erittäin suosittuja.

Huomioitavia seikkoja urakkasopimusta tehtäessä

Vaikka urakkasopimuksella on etuja sekä käyttäjän että toimittajan näkökulmasta, erityisesti toimittajalle harkitsematon urakkasopimuksen tekeminen sisältää myös riskejä. Ennen kaikkea se, että “työn valmistuminen” on velvoitteen täyttämisen edellytys, tarkoittaa, että periaatteessa ei voida vapautua velvollisuuden täyttämättä jättämisen vastuusta ilman, että lopputulos on valmis. Tämä on myös syy siihen, miksi palotilanteita, joissa toimittajan on jatkettava työtä tappiollisesti esimerkiksi aliarvioinnin vuoksi, tapahtuu toistuvasti.

Mitä sitten tulee ottaa huomioon urakkasopimusta tehtäessä sopimusasiakirjan kirjauksissa? Katsotaanpa alla yksityiskohtaisesti.

Järjestelmän vaatimusten ja hyväksymiskriteerien selkeyttäminen etukäteen

Urakkasopimuksessa tärkeää on, sanomattakin selvää, “työn valmistumisen” ehtojen selkeyttäminen. Yleensä tässä mainittavat “työn valmistumisen” vaatimukset viittaavat vaatimusten määrittelyvaiheen sopimuksen sisältöön. Käytännössä kuitenkin, kun kehitysprosessi etenee, saatetaan jälkikäteen vaatia muutoksia, jolloin “työn valmistumisen” vaatimukset voivat myös muuttua. Tämä sisältäen, on tärkeää pyrkiä dokumentoimaan muutoshistoria. Seuraavassa artikkelissa selitetään, miten järjestelmäkehitysprojektin muutosten hallintaa tulisi hoitaa oikeudellisesta näkökulmasta.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Lisäksi, tähän aiheeseen liittyen, on tehokasta ehkäistä tulevia ongelmia sopimalla etukäteen myös “hyväksynnän” kriteerit, jotka käyttäjäpuoli suorittaa. On luonnollista olettaa tilanteita, joissa tuotteen toimittaminen on vaikeaa, koska käyttäjäpuolen vastuuhenkilöä ei saada kiinni tai vastausta ei saada pitkään aikaan. Jotta hyväksynnän hyväksyminen tai hylkääminen ei jää epäselväksi pitkäksi aikaa, on hyödyllistä asettaa tietty määräaika myös hyväksynnälle. Tätä kutsutaan “oletetuksi hyväksymisehdoksi”, ja siitä kerrotaan lisää seuraavassa artikkelissa.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Ennakollinen sopiminen tekijänoikeuden siirron olemassaolosta

Toinen yleinen ongelma liittyy tekijänoikeuden siirtoon. Tekijänoikeus kuuluu periaatteessa “luojalle”, eli järjestelmän kehittäjälle, mutta sen siirtäminen tai luovuttaminen on myös mahdollista oikeuden luonteen vuoksi. Siksi on hyvä sopia etukäteen, siirretäänkö tekijänoikeus käyttäjälle vai ei, jotta voidaan välttää ongelmat jälkikäteen. Tekijänoikeuden omistajuudesta ja siirrosta on yksityiskohtainen selostus seuraavassa artikkelissa.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Muita huomioitavia seikkoja

Jos haluat tietoisesti välttää alihankintasopimuksen kaltaisia elementtejä ja solmia sopimuksen urakkasopimuksena, kannattaa ottaa huomioon seuraavat seikat:

• Palkkion tulee olla riippumaton työtunneista
• Sopimuksen otsikossa tulee lukea selvästi “urakkasopimus”
• Virhevastuun ehdot tulee määritellä selvästi
• Palkkion maksaminen perustuu tuloksiin tai saavutettuihin tuloksiin

Nämä seikat on hyvä pitää mielessä.

Huomaa, että sopimuksen otsikossa lukevan “urakkasopimus” ei tarkoita, että kaikki sopimukset olisivat urakkasopimuksia. Käytännössä on mahdollista, että toisen yrityksen sopimuspohjaa käytetään huolettomasti, riippumatta siitä, onko sopimuksen sisältö urakkasopimus vai alihankintasopimus. Jos asia päätyy oikeuteen, sopimuksen otsikon tai muiden pinnallisten elementtien sijaan tärkeämpää on sopimuksen kokonaisuus, aiemmat kaupalliset tavat ja muut olennaiset seikat. Tämä on myös tärkeää pitää mielessä.

Yhteenveto

Kun otetaan huomioon edellä mainitut seikat, sopimusasioiden käsittely urakkasopimuksen perusteella helpottuu. Huomautettakoon, että termiä “valtuutus” käytetään sekä urakkasopimuksissa että quasi-valtuutussopimuksissa. Lisäksi termiä “toimeksianto” käytetään yleensä silloin, kun osapuolten välillä on ymmärrys siitä, että kyseessä on quasi-valtuutussopimus. On hyvä kiinnittää huomiota myös näihin hienovaraisiin terminologisiin eroihin.