Mitä tehdä, jos järjestelmän vika paljastuu vastaanoton jälkeen?

Yleisesti ottaen, järjestelmän kehitys etenee vaatimusten määrittelyvaiheessa päätettyjen sisältöjen mukaisesti, ja ohjelman toteutus etenee. Lopulta sekä käyttäjät että toimittajat tarkistavat, onko lopputulos määritettyjen vaatimusten mukainen, ja projekti päättyy hyväksytyn tarkastuksen jälkeen.

Kuitenkin, todellisuudessa, on täysin mahdollista, että testausvaiheessa tai hyväksynnän yhteydessä havaitsemattomat bugit tai ongelmat paljastuvat myöhemmissä käyttövaiheissa. Mitä voidaan vaatia laillisesti, jos olet jo hyväksynyt toimituksen?

Ei ole yllättävää, että bugeja jää jäljelle hyväksymistestauksen tai testausprosessin jälkeen

Teknisestä näkökulmasta katsottuna, se, että erilaisia bugeja ja ongelmia ilmenee myyjän erilaisten testausprosessien päättymisen tai käyttäjän hyväksymistestauksen jälkeen, ei ole lainkaan harvinaista. Käyttäjän hyväksymistestauksessa tehtävät tarkistukset keskittyvät yleensä syöttöjen ja tulosteiden tarkistamiseen näytöltä. Kuitenkin, IT-järjestelmät ovat usein monimutkaisia ja hienostuneita rakenteita, jotka ulottuvat paljon pidemmälle kuin käyttäjän näkyvissä oleva näyttö, mukaan lukien taustalla oleva tietokanta ja erilaiset laskenta- ja ohjausohjelmat. Tästä syystä, on olemassa rajoituksia sille, mitä voidaan tutkia käyttäjän näkökulmasta näytön syöttöjen ja tulosteiden tarkistuksella. Siksi, on epärealistista yrittää kattavasti tarkistaa kaikki mahdolliset ongelmat, jotka saattavat ilmetä myöhemmässä käyttövaiheessa.

Edellä mainitut seikat pätevät myös, kun tarkastellaan asiaa kehittäjän näkökulmasta. Esimerkiksi, “testausprosessi” on vaihe, jossa tarkistetaan, onko toteutetussa ohjelmassa bugeja tai ongelmia. Kuitenkaan testausprosessissa ei välttämättä pystytä täysin tarkistamaan kaikkia mahdollisia bugeja tai ongelmia. Järjestelmän aktiivisen käytön aloittamisen jälkeen, saattaa ilmetä toimintoja, joita kehittäjä ei ole ennakoitavasti, tai suuria määriä tietoja saatetaan rekisteröidä, tai useat käyttäjät saattavat yrittää käyttää järjestelmää samanaikaisesti. Tällaisissa olosuhteissa, järjestelmän luominen, joka toimii ongelmitta, vaatii erinomaista teknistä osaamista.

Hyväksymistestauksen tai testausvaiheen aikana ei ole realistista löytää kaikkia mahdollisia bugeja tai ongelmia, ja on tärkeää ymmärtää, että IT-järjestelmissä saattaa ilmetä erilaisia ongelmia, kun niitä aletaan käyttää todellisessa käytössä.

Velvollisuuden täyttäminen on yleensä katsottu suoritetuksi

Miten siis tulisi toimia, jos tällaisia ongelmia ilmenee? Käymme läpi asian oikeudellisen järjestyksen mukaisesti.

Ensinnäkin, jos erilaisia bugeja ja ongelmia ilmenee jälkikäteen, käyttäjä haluaisi todennäköisesti syyttää toimittajaa, jolta hän on pyytänyt palvelua. Kuitenkin, yleensä, jos tuote on jo toimitettu ja hyväksytty, on vaikea syyttää toimittajaa velvollisuuden laiminlyönnistä.

Alun perin järjestelmän kehityssopimus, ellei erityistä sopimusta ole tehty, sisältää ohjelman toteutusta koskevat säännöt, jotka perustuvat Japanin siviililakiin (Minpō). Mitä urakkasopimus tarkoittaa, selitetään yksityiskohtaisesti seuraavassa artikkelissa.

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

Urakkasopimuksessa “työn valmistuminen” on velvollisuuden täyttämisen edellytys. Mitä “työn valmistuminen” tarkoittaa konkreettisesti, selitetään yksityiskohtaisesti seuraavassa artikkelissa.

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

Tässä selitetään, että aikaisemmissa oikeuden päätöksissä “työn valmistuminen” urakkasopimuksessa tarkoittaa, järjestelmän kehityksen kontekstissa, koko kehitysprosessin päättymistä. Ja ongelmat, kuten bugit ja viat, jotka ilmenevät koko kehitysprosessin päättymisen jälkeen, ovat urakkasopimuksen mukaisen virhevastuun kysymyksiä.

Yhteenvetona, jos tuote on jo hyväksytty ja toimitettu, velvollisuus on yleensä katsottu suoritetuksi. Tämän jälkeen tulevat laatuongelmat, eli virhevastuun kysymykset, ovat yleensä seuraava haaste.

Vastuun käsittely virheellisen takuuvastuun perusteella

Miten siis toimia, jos haluat vaatia toimittajalta toimenpiteitä virheellisen takuuvastuun perusteella? Mitä ja missä järjestyksessä sinun tulisi harkita? Käydään nämä seikat läpi alla.

Ensimmäiseksi, tarkista vian tai häiriön vakavuus ja merkittävyys

Kun vika tai häiriö ilmenee jälkikäteen ja sitä pidetään laillisena “virheenä”, josta vaaditaan jonkinlaista takuuta, vian tai häiriön vakavuus tulee ongelmaksi. Laillisen virheen kysymys on alun perin

1. vaikka se olisi vika tai häiriö, se on vain vähäinen, eikä sitä voida pitää laillisena “virheenä”
2. se täyttää laillisen “virheen” kriteerit, mutta sopimuksen tavoitteen saavuttaminen on mahdollista
3. se täyttää laillisen “virheen” kriteerit, eikä sopimuksen tavoitteen saavuttaminen ole mahdollista

Nämä kolme skenaariota jakautuvat. Mikä erottaa mahdollisuuden seurata vastuuta virheellisen takuuvastuun perusteella, on raja 1:n ja 2:n välillä, ja mikä erottaa mahdollisuuden purkaa sopimus virheellisen takuuvastuun perusteella, on raja 2:n ja 3:n välillä.

Artikkeli 634

1. Kun työn kohteessa on virhe, tilaaja voi vaatia urakoitsijaa korjaamaan virheen määräajassa. Tämä ei kuitenkaan päde, jos virhe ei ole merkittävä ja sen korjaaminen vaatii kohtuuttomia kustannuksia.

2. Tilaaja voi vaatia vahingonkorvausta virheen korjaamisen sijaan tai sen lisäksi. Tässä tapauksessa sovelletaan artikkelin 533 säännöksiä

Artikkeli 635

Kun työn kohteessa on virhe ja sen vuoksi sopimuksen tavoitetta ei voida saavuttaa, tilaaja voi purkaa sopimuksen. Tämä ei kuitenkaan päde rakennuksiin tai muihin maanrakennustöihin.

Lisätietoja tästä “virheen” vaiheittaisesta erottelusta on selitetty yksityiskohtaisesti seuraavassa artikkelissa.

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

Seuraavaksi, määritä selkeästi, mitä toimittajalta tulisi vaatia

Seuraavaksi sinun on selvitettävä tarkasti, mitä sinun pitäisi vaatia toiselta osapuolelta. Jos haluat purkaa sopimuksen, sinun on todistettava, että se on virhe, mutta se ei riitä. Sinun on osoitettava, että se on niin merkittävä, että se “estää sopimuksen tavoitteen saavuttamisen”. Tässä “tavoitteen” arvioinnissa kokouksen pöytäkirjat, jotka pidettiin järjestelmänkehitysprojektin alussa, ja eritelmien tiedot ovat tärkeitä vihjeitä. Koska on mahdollista, että vikoja tai häiriöitä ilmenee jälkikäteen hyväksynnän jälkeen, on tärkeää säilyttää kaikki asiakirjat huolellisesti projektin päättymisen jälkeen.

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

Muuten, sopimuksen purkamisen lisäksi voit vaatia vahingonkorvausta tai virheen korjaamista virheellisen takuuvastuun perusteella.

Muita huomioitavia seikkoja

Sopimuksen purkaminen ja muut oikeustoimet vaativat huolellisuutta

Jos aiot purkaa sopimuksen virhevastuun perusteella, sinun tulisi myös ymmärtää, miten oikeudelliset toimenpiteet toteutetaan. Sopimuksen purkamisen vaikutukset, tehokkaat ilmaisutavat ja ongelmien välttämiseksi tarvittavat ilmoitustavat on selitetty yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Riitojen sijaan neuvotteluratkaisut ovat suositeltavia

Lisäksi tämä oikeudellinen keskustelu ei ole merkityksellinen vain oikeudenkäynnin sattuessa. Oikeudenkäynnin kautta tapahtuva riidanratkaisu on molemmille osapuolille erittäin rasittavaa. Sen sijaan, näitä oikeudellisia näkökohtia tulisi hyödyntää jo ennen oikeudenkäyntiä neuvotteluvaiheessa. Kuinka merkityksellisiä nämä oikeudelliset näkökohdat ovat oikeudenkäynnin ulkopuolisissa neuvotteluissa, on selitetty yksityiskohtaisesti seuraavassa artikkelissa.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Virheet ja toimintahäiriöt tulee erottaa toiminnallisuuden puutteista

Keskustelu eroaa, jos toteutetuissa toiminnoissa tai määrittelyissä on virheitä tai toimintahäiriöitä, tai jos tarvittavat ominaisuudet puuttuvat kokonaan. Jos tarvittavat toiminnot eivät ole täysin käytettävissä, “työn valmistuminen” ei ehkä hyväksytä urakkasopimuksessa, eikä velvoitteen täyttämistä voida tunnustaa.

Vaikka tarvittavia toimintoja tai määrittelyjä ei olisi, jos käyttäjä ei ole antanut asianmukaista tietoa vaatimusten määrittelyvaiheessa, sopimuksen osana olevan asian arvioiminen saattaa olla sopimatonta.

Yhteenveto

Projektin vaiheissa ilmenevät ongelmat voivat tulla ilmi projektin aikana tai jälkikäteen, kuten käyttövaiheessa. Järjestelmäkehitysprojektin ominaisuus, joka ei välttämättä takaa turvallisuutta, vaikka kaikki vaiheet olisivatkin päättyneet onnistuneesti, näyttäisi olevan symboloitu ‘virhevastuun’ järjestelmässä. On tärkeää ymmärtää tämä prosessi ja varmistaa, että dokumentaatiohallinta ottaa huomioon asiat järjestelmäkehitysprojektin päättymisen jälkeen.