Miten käsitellä tilanteita, joissa järjestelmänkehitystyö on keskeytetty käyttäjän olosuhteiden vuoksi

Järjestelmäkehitys on usein pitkäkestoinen projekti. Entä jos käyttäjäpuoli ilmoittaa yksipuolisesti, että “emme enää tarvitse tätä järjestelmää, joten sitä ei tarvitse rakentaa”, kun järjestelmäkehitys on jo aloitettu? Mitä toimittajapuoli, joka on ottanut työn vastaan, voi tehdä tässä tilanteessa?

Tässä artikkelissa käsittelemme järjestelmäkehityssopimuksen erityispiirteitä ja selitämme, miten tällaisessa tilanteessa tulisi toimia.

Käyttäjän aiheuttaman keskeytyksen merkityksen pohtiminen

Järjestelmäkehityssopimuksessa on useita erityispiirteitä, kun sitä tarkastellaan sopimuksena. Yksi niistä on, että työ kestää yleensä pitkään, ja toimittajalla on suuri harkintavalta ja suuret velvollisuudet projektin hallinnoinnissa. Toimittajan projektinhallintavelvollisuuksien kokonaisuutta käsitellään yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/project-management-duties[ja]

Toinen erityispiirre on, että käyttäjällä, vaikka hän onkin asiakas, on laaja velvollisuus tukea toimittajan työtä. Koska kyseessä on yrityksen sisäisesti käytettävä järjestelmä, sitä ei voida vain “heittää” toimittajalle. Myös yrityksen sisältä on velvollisuus tukea toimittajaa tarvittaessa, jotta tämä voi hyödyntää asiantuntemustaan työssään. Tätä käsitellään yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Yhteenvetona voidaan sanoa, että toimittajan ja käyttäjän välillä on sekä “ulkopuolisen kehittäjän” ja “maksavan asiakkaan” välinen vastikkeellinen suhde, että samalla myös yhteisen tavoitteen, projektin saavuttamisen, saavuttamiseksi yhteistyötä tekevien “kumppanien” suhde. Tämä suhteiden monimutkaisuus ei yleensä ole läsnä esimerkiksi räätälöityjen pukujen valmistajilla, ja se on suuri erityispiirre järjestelmäkehityssopimuksissa. Järjestelmäkehitykseen liittyvät riidat johtuvat usein tästä suhteiden monimutkaisuudesta, ja kun ne kerran alkavat, molempien osapuolten suhteen laillinen järjestely voi olla monimutkainen ja hankala.

Kun käyttäjä muuttaa mielensä ja sanoo yhtäkkiä, että “emme lopulta tarvitse tätä järjestelmää, joten projektia ei tarvitse enää jatkaa”, on tärkeää pohtia, miten molempien osapuolten oikeudet ja velvollisuudet tulisi ymmärtää. Tämä on eräänlainen esimerkki siitä, miten laillista ajattelua tulisi soveltaa monimutkaisiin sopimussuhteisiin. Seuraavassa tarkastellaan, mitä asioita tulisi harkita tällaisessa tilanteessa.

Ensimmäiseksi selvitä perusteet, jotka johtivat irtisanomiseen

Myös tapauksissa, joissa toimittaja näkee, että “käyttäjä haluaa yksipuolisesti keskeyttää projektin”, ei välttämättä ole taattu, että tämä näkemys on jaettu käyttäjän kanssa. Esimerkiksi, kuvitellaan tilanne, jossa oli käynnissä projekti kehittää järjestelmä, joka hallinnoi ulkomailla sijoitettujen työntekijöiden henkilöstöasioita, mutta myöhemmin päätettiin perua koko ulkomaan laajentumissuunnitelma, jolloin järjestelmän kehittäminen muuttui tarpeettomaksi. Totta kai, tämän selityksen perusteella, voisi tulkita, että kyseessä on käyttäjän yksipuolinen mielenmuutos.

Mutta entä jos tällaiseen päätökseen johtaneissa tapahtumissa oli myös toimittajan puolella projektinhallinnan velvollisuuksien rikkomuksia, kuten viivästyksiä eri vaiheissa, ja kehityksen eteneminen oli vaikeaa, mikä myös vaikutti yrityksen politiikan muutokseen?

Kuten aiemmin mainittiin, järjestelmän kehittäminen on prosessi, jossa sekä toimittaja että käyttäjä ottavat vastuun ja tekevät tiivistä yhteistyötä. Siksi, vaikka käyttäjä olisi se, joka haluaa keskeyttää ja toimittaja ajattelisi, että kyseessä on käyttäjän itse aiheuttama irtisanominen, on tärkeää ymmärtää, että käyttäjä saattaa päinvastoin osoittaa toimittajan vastuullisuuden ja väittää, että kyseessä on sopimuksen purkaminen velvollisuuksien laiminlyönnin perusteella tai yhteisymmärryksessä tehty irtisanominen.

Onko kyseessä itse aiheutettu irtisanominen, sopimuksen purkaminen velvollisuuksien laiminlyönnin perusteella vai yhteisymmärryksessä tehty irtisanominen, riippuu projektin etenemisestä ja aiemmista neuvotteluista, ja nämä asiat arvioidaan yleensä tapauskohtaisesti. Siksi, jos toimittaja aikoo jatkaa jälkitoimenpiteitä olettaen, että kyseessä on käyttäjän itse aiheuttama irtisanominen, on tärkeää jättää selkeä merkintä tästä esimerkiksi kokouksen pöytäkirjaan, jotta tätä asiaa ei myöhemmin kyseenalaisteta.

Seuraavaksi tarkistetaan korvausvaatimuksen ja vahingonkorvauksen perustelut

Edellä mainittujen seikkojen huomioon ottaen, jos keskustelu etenee käyttäjän omasta tahdosta johtuvan irtisanomisen suuntaan, seuraavaksi tarkastellaan, onko toimittajalla mahdollisuus vaatia käyttäjältä palkkion maksamista valmiusasteen mukaan tai vahingonkorvausta.

Tällaisissa tapauksissa viitattavat pykälät vaihtelevat sopimustyypin mukaan. Järjestelmän kehitykseen liittyvät sopimukset voidaan karkeasti jakaa urakkasopimuksiin ja osittaisiin toimeksiantosopimuksiin.

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

Ja osittaisen toimeksiantosopimuksen ja urakkasopimuksen tapauksessa, siviililaki määrittelee seuraavasti:

a.) Osittaisen toimeksiantosopimuksen tapauksessa
Palkkion vaatiminen: Siviililaki 648 § 3 momentti
Kun toimeksianto päättyy kesken suorituksen syystä, joka ei johdu toimeksiantajan vastuusta, toimeksiantaja voi vaatia palkkiota suoritetun työn osuuden mukaan.
Vahingonkorvausvaatimus: Siviililaki 651 §
1. Toimeksianto voidaan purkaa milloin tahansa kummankin osapuolen toimesta.
2. Jos toinen osapuoli purkaa toimeksiannon haitallisena ajankohtana toiselle osapuolelle, tämän osapuolen on korvattava toiselle osapuolelle aiheutunut vahinko. Tämä ei kuitenkaan päde, jos on olemassa pakottava syy.

b.) Urakkasopimuksen tapauksessa
Vahingonkorvausvaatimus: Siviililaki 641 §
Urakoitsija ei ole suorittanut työtä loppuun, tilaaja voi milloin tahansa purkaa sopimuksen korvaamalla vahingon.

Huomautettakoon, että siviililain 641 §:n mukaisen vahingonkorvauksen piiriin kuuluu paitsi jo kuluneet kulut, myös “voitto, joka olisi saatu, jos sopimusta ei olisi purettu”. Tämä johtuu siitä, että on järjetöntä, että laki vaatii työn loppuunsaattamista, vaikka tilaaja ei enää tarvitse sitä. Siksi on järkevämpää taata urakoitsijan voitto maksamalla vastaava korvaus.

Kuitenkin siviililain 641 §:n mukaisen vahingonkorvauksen osalta on huomattava, että toimittajan ja käyttäjän välisessä erillisessä sopimuksessa vahingonkorvaus saatetaan usein jättää korvaamatta. Tällaisissa tapauksissa osapuolten välillä erikseen sovittu sopimus (eli sopimus) on etusijalla, joten siviililain säännökset eivät välttämättä päde, joten varovaisuus on tarpeen.

Edistetään lisää suoritettujen töiden ja vahinkojen todistamista

Kun käyttäjä päättää irtisanoa sopimuksen omasta tahdostaan, yleisimpiä sopimusehtoja ovat suoritettujen töiden (eli valmiiden osien) palkkioiden vaatiminen ja vahingonkorvausvaatimukset. Tästä syystä toimittajan on yleensä todistettava suoritettujen töiden määrä ja vahingot vahingonkorvausvaatimuksen tekemiseksi.

Kuitenkin, tällaisen suoritettujen töiden eli valmiusasteen todistaminen voi olla erittäin työlästä, jos se tehdään käytännössä. Tämä johtuu siitä, että on vaikea määrittää, kuinka paljon työtä on tehty, erityisesti jos on useita alihankkijoita. Haastattelut edistymisen tarkistamiseksi voivat olla huomattavia, ja lisäksi on tehtävä paljon työtä, kuten haastattelutulosten vahvistamiseksi tarvittavien asiakirjojen laatiminen ja haastattelujen sisällön kirjoittaminen. Jos todisteet ovat edelleen riittämättömiä kaiken tämän jälkeen, kaikki nämä ponnistelut voivat olla turhia, ja tämä on yksi monista haasteista.

Tällaiset seikat huomioon ottaen, yksi mahdollinen ratkaisu on tehdä sopimus alusta alkaen niin, että jos sopimus irtisanotaan kesken kaiken, se lasketaan päivittäin irtisanomispäivään asti. Tämä tekee laskennasta yksinkertaisempaa. Lisäksi, koska suoritettujen töiden todistaminen on työlästä, voit harkita luopumista suoritettujen töiden vaatimisesta ja sen sijaan vaatia korvausta “jo suoritettujen osien kehittämiseen käytetyistä kustannuksista”. Jos kyseessä ovat yrityksen sisäiset kehityskustannukset, ne voidaan usein laskea yksinkertaisesti “työtuntien määrä x yksikköhinta”. Erityisesti vähän voittoa tuottavissa projekteissa, suoritettujen töiden sijaan kustannuspohjainen vaatimus voi olla realistisempi ratkaisu, koska se helpottaa saatavien perintää ja mahdollistaa tappioiden korvaamisen.

Mitä käyttäjän pitäisi harkita?

Muuten, myös käyttäjän, joka haluaa irtisanoa sopimuksen omasta tahdostaan, tulisi harkita joitakin asioita etukäteen. Tämä tarkoittaa, että sinun tulisi tarkistaa karkea summa, jonka sinun pitäisi maksaa vahingonkorvauksena toimittajalle. Tässä yhteydessä “karkea” tarkoittaa, että sinun tulisi asettaa jonkinlainen suuntaa-antava luku, joka auttaa sinua ohjaamaan tulevia neuvotteluja (on parempi, että irtisanomisilmoitus ei viivästy, joten tarkka summa ei ole välttämätön).

Jos tarkistettu karkea summa vaikuttaa kohtuuttoman suurelta, sinun tulisi pyytää selitystä. Kuitenkin, jos yrität neuvotella liian kovasti pitääksesi maksut alhaisina, saatat joutua turhaan oikeudenkäyntiin, mikä voi vain pahentaa tilannetta. Jos neuvottelut kahden osapuolen välillä näyttävät olevan vaikeita, voit harkita asianajajan konsultointia.

Muuten, tässä artikkelissa olemme olettaneet, että järjestelmän kehityssopimus on voimassa. Kuitenkin todellisessa järjestelmän kehitystilanteessa on usein kiistaa siitä, onko sopimus todella voimassa. Tätä käsitellään yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/system-development-contract[ja]

Yhteenveto

Tässä artikkelissa olemme käsitelleet, kuinka käyttäjän taholta tulevan projektin keskeyttämisen tapauksessa tulisi toimia. Kuitenkin, tämän artikkelin tärkein pointti on, että on tarpeen tarkastella, voiko keskeyttämistä todella pitää käyttäjän omasta tahdosta johtuvana, ja onko toimittajalla todella ollut mitään laiminlyöntejä.

Järjestelmän kehittämisen kaltaisessa projektissa sekä toimittajalla että käyttäjällä on suuria velvollisuuksia. Tästä syystä on tärkeää harkita etukäteen, onko vastapuolen yksipuolinen syyttäminen todella mahdollista. Jos tätä ei tehdä, saattaa seurauksena olla tilanne, joka vain pahentaa ongelmia, joten tämä seikka tulisi pitää mielessä.