Mikä on järjestelmän kehityksen hyväksyntä ja milloin oletettu hyväksyntäehto on sovellettavissa?

Järjestelmän kehityksen yhteydessä on yleistä, että oikeudellisia ongelmia ilmenee “hyväksymisen” vaiheessa.

“Hyväksyminen” viittaa tarkastus- ja tarkistusvelvollisuuteen, joka syntyy tilaajalle, kun toimittaja toimittaa tuotoksen. Jos tilaaja ei suorita “hyväksymistä” toimituksen jälkeen, toimittaja eli myyjä joutuu epävarmaan oikeudelliseen asemaan.

Monissa sopimuksissa on “oletettu hyväksyminen” -klausuuli tällaisten ongelmien ratkaisemiseksi.

Tässä artikkelissa selitämme, milloin “oletettu hyväksyminen” soveltuu, käyttäen todellisia oikeustapauksia esimerkkeinä.

Mitä tarkoitetaan järjestelmäkehityksessä hyväksynnällä?

Alun perin “hyväksyntä” järjestelmäkehitysprojektissa tarkoittaa, että käyttäjä, joka on tilaaja, tarkistaa ja tarkastaa, onko toimittajan toimittama tuote (tässä tapauksessa IT-järjestelmä) sopiva tilauksen tarkoitukseen.

Kehittäjän näkökulmasta se voisi tarkoittaa “tarkistamista, onko se todella valmis”, ja sitä voidaan pitää testausprosessina.

IT-järjestelmän kehittäminen on työn luonteen vuoksi sellaista, jossa toimittajan harkintavalta on usein suuri, ja on mahdollista, että syntyy eroja todellisen tuotteen ja käyttäjän pyytämän tuotteen välillä.

Yleisesti ottaen hyväksynnän läpäisy tarkoittaa, että käyttäjä on itse vahvistanut, että todellinen tuote, joka vastaa käyttäjän pyytämää (tai järjestelmän kehittämistä koskevaa pyyntöä), on toimitettu.

Todellisissa sopimuskäytännöissä, vaikka on mahdollista, että järjestelmässä ilmenee vikoja myöhemmin, on yleistä, että hyväksynnän läpäisy asetetaan palkkion maksuehdoksi.

Huomioi oletettu hyväksymisehto

Kun ongelmia ilmenee hyväksymisvaiheessa, sekä käyttäjät että toimittajat joutuvat hankalaan tilanteeseen.

Esimerkiksi, mitä tapahtuu, jos toimittaja on valmistanut tuotoksen ja esittänyt sen jo, mutta käyttäjän edustaja ei suostu hyväksymään sitä omista syistään?

Tällaisia tilanteita varten järjestelmänkehityssopimuksiin sisällytetään usein niin sanottu “oletettu hyväksymisehto”.

Mikä on oletettu hyväksymisehto?

(Tämän ohjelmiston hyväksyntä) Pykälä 28
Toimitetuista tuotteista, tämän ohjelmiston osalta, A:n on suoritettava tarkastus määräajassa, joka on määritelty yksittäisessä sopimuksessa (jäljempänä “tarkastusaika”), edellisen pykälän tarkastusspesifikaation mukaisesti, ja tarkistettava, vastaako järjestelmän spesifikaatio tämän ohjelmiston kanssa.

2. Jos tämä ohjelmisto täyttää edellisen kohdan tarkastuksen, A:n on allekirjoitettava ja leimattava tarkastuksen hyväksymistodistus ja luovutettava se B:lle. Lisäksi, jos tämä ohjelmisto ei läpäise edellisen kohdan tarkastusta, A:n on nopeasti toimitettava B:lle kirjallinen selvitys hylkäämisen konkreettisista syistä ja vaadittava korjausta tai täydennystä, ja kun hylkäämisen syyt hyväksytään, B:n on korjattava se maksutta määräajassa neuvottelujen jälkeen ja toimitettava se A:lle, ja A:n on suoritettava edellisen kohdan mukainen tarkastus uudelleen tarvittavassa laajuudessa.

3. Jos tarkastuksen hyväksymistodistusta ei luovuteta, mutta A ei esitä kirjallisesti konkreettisia syitä vastalauseeseen tarkastusaikana, tämä ohjelmisto katsotaan läpäisseen tämän pykälän mukaisen tarkastuksen.

4. Tämän pykälän mukaisen tarkastuksen hyväksyminen merkitsee tämän ohjelmiston hyväksymisen valmistumista.

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

Lakiteknisesti ottaen, kolmannen kohdan “oletetaan” ilmaisu on yksi huomionarvoinen kohta. Lakitermeinä tarkasteltuna, “olettaa” ja “olettaa” tarkoittavat itse asiassa täysin eri asioita.

Olettaa…
→Vaikka todellisuudessa ei olisi XX, sitä kohdellaan lain mukaan samalla tavalla kuin jos se olisi XX

(Esimerkki) Jos käytät älypuhelinta testin aikana, se “oletetaan” huijaamiseksi
→Riippumatta siitä, oliko älypuhelimen käyttö todellisuudessa huijausta vai ei, se saa saman kohtelun kuin huijaus.

Olettaa…
→Ellei ole erityisiä todisteita, jotka kiistävät XX:n tosiasian, sitä kohdellaan tosiasiana.

(Esimerkki) Jos katsot älypuhelinta testin aikana, se “oletetaan” huijaamiseksi
→Periaatteessa oletetaan, että huijausta on tapahtunut, mutta jos voit todistaa, että se oli muuta kuin huijausta, se päätös voidaan kumota jälkikäteen. (Tosin, tällaista ilmoitusta ei yleensä kuulla testipaikalla.)

Toisin sanoen, “olettaa” ja “olettaa” eroavat toisistaan siinä, kuinka suuri kynnys niiden kumoamiselle on. Tässä on mukana merkitys “riippumatta siitä, onko hyväksyntä saatu vai ei, sitä kohdellaan samalla tavalla kuin jos se olisi hyväksytty”.

Oletuslausekkeiden määräysten liittyvät oikeustapaukset

Oletushyväksyntälausekkeiden määräyksillä on ollut ratkaiseva merkitys oikeudenkäynneissä myös menneisyydessä. Esimerkiksi alla lainattu tuomioistuimen päätös koskee tapausta, jossa käyttäjä nosti kanteen, koska hän ei ollut hyväksynyt toimitusta määräajassa ja väitti, että tarvittavia toimintoja ei ollut toteutettu jälkikäteen. Kuitenkin tuomioistuin päätti, että toimitus oli jo suoritettu oletuslausekkeiden määräysten perusteella.

Tässä sopimuksessa, Y-yrityksen tuli suorittaa tarkastus viipymättä järjestelmän toimituksen jälkeen ja ilmoittaa hyväksynnästä kirjallisesti 10 päivän kuluessa. Jos ilmoitusta ei ole tehty määräaikaan mennessä, se katsotaan hyväksytyksi. Koska tässä tapauksessa ei voida hyväksyä, että ilmoitus ei vastannut tarkastusta, toimituksen ja hyväksynnän tosiasiat voidaan vahvistaa.

Tokion alioikeuden päätös 29. helmikuuta 2012 (Heisei 24)

Toisaalta, vaikka tämä oletushyväksyntälauseke olisi ollut voimassa, on olemassa oikeustapauksia, jotka ovat kieltäneet sen soveltamisen ja tunnustaneet toimittajan velvollisuuden rikkomisen.

Alla lainattu tuomioistuimen päätös koskee tapausta, jossa toimittajan yhteistyö oli välttämätöntä hyväksynnän suorittamiseksi, mutta toimittaja oli laiminlyönyt yhteistyön, mikä eroaa edellä mainitusta oikeustapausta.

Kantaja (toimittaja) väittää, että vastaaja (käyttäjä) ei ilmoittanut tarkastustuloksista 10 päivän kuluessa tuotteen toimituksesta, joten ohjelmistokehityssopimuksen 9 artiklan 4 kohdan mukaan tuote katsotaan hyväksytyksi. Kuitenkin, jotta tällainen tulos saavutettaisiin, kantajan yhteistyö on välttämätöntä, ja kantaja ei ole tehnyt tällaista yhteistyötä vastaajan kanssa, joten tässä tapauksessa, vaikka vastaaja ei ilmoittanut tarkastustuloksista 10 päivän kuluessa tuotteen toimituksesta, ohjelmistokehityssopimuksen 9 artiklan 4 kohdan mukaan vastaajaa ei voida katsoa hyväksyneen ohjelmistoa.

Tokion alioikeuden päätös 23. kesäkuuta 2004 (Heisei 16)

Oletushyväksyntälausekkeen perusajatuksena voidaan pitää sitä, että se vapauttaa toimittajan nopeasti epävarmasta tilanteesta, jossa “työ on viivästynyt, koska käyttäjä ei ole edennyt hyväksyntään huolimatta halusta tehdä niin”, ja pitää molempien osapuolten suhteen reiluna.

Näin ollen ei voida hyväksyä, että poiketaan merkittävästi tästä tarkoituksesta ja “käytetään oletushyväksyntälauseketta kilpenä, yritetään viivyttää hyväksyntää ja työntää viallinen tuote eteenpäin”.

Jos hyväksyntä “katsotaan” suoritetuksi, käyttäjän on maksettava korvaus järjestelmän kehittämisestä. Ottaen huomioon tämän merkittävyyden, tuomioistuin pyrkii tekemään reilun päätöksen ottamalla huomioon myös toimittajan yhteistyön.

Tämän päätöksen tukena on usein sopimuksen lisäksi myös järjestelmän kehityksen edistymistä koskevat pöytäkirjat, jotka voivat olla tärkeitä todisteita. Tämä on selitetty yksityiskohtaisesti alla olevassa artikkelissa.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Mitä velvollisuuksia toimittajalla on asiantuntijana järjestelmän kehityksessä ja miten se suhtautuu kattavasti projektiin, katso alla oleva artikkeli.

Vaikka hyväksyntätehtävät ovat periaatteessa käyttäjän suoritettavissa, toimittajan tulisi myös tehdä erilaisia yhteistyötoimia järjestelmän kehityksen asiantuntijana. Tämä on hyvin ymmärrettävää, kun otetaan huomioon alla olevan artikkelin sisältö.

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

Virheitä löytyy tarkastuksessa

Toki, tarkastusvaiheessa voi paljastua järjestelmän puutteita (lakitermi näille on usein ‘virheet’). Tässä tapauksessa oikeudelliset kysymykset ovat seuraavat, katso lisätietoja alla olevasta artikkelista.

https://monolith.law/corporate/defect-warranty-liability[ja]

Yhteenveto

“Hyväksyntä” järjestelmäkehityksessä osoittaa periaatteessa toimittajan velvollisuuden täyttämisen, joten se on erittäin tärkeä sekä käyttäjän että toimittajan kannalta. Sekä tilaajan että toimittajan tulisi ymmärtää hyvin “oletettu hyväksyntäehto”, jotta vakavia ongelmia ei synny.

Ja jos hyväksyntä ei suju sujuvasti, molempien osapuolten tulisi ottaa huomioon mahdollisuus ja tehdä huolellista yhteisymmärrystä jo sopimusvaiheessa, erityisesti hyväksyntää koskevien määräysten osalta.