Mikä on laki, jos järjestelmän kehityksestä maksettava korvaus jää maksamatta?

Järjestelmänkehittäjänä toimivalle toimittajalle suurin riski saattaa olla tilanne, jossa “käyttäjä ei maksa korvausta, vaikka järjestelmä on toimitettu”. Järjestelmän kehittämiseen liittyvät kustannukset koostuvat usein suurelta osin ohjelmoijista ja muista taitavista työntekijöistä, joten henkilöstökustannukset voivat olla merkittäviä. Myynnin perintäongelmat voivat joskus johtaa jopa elinkelpoisuusongelmiin. Tässä artikkelissa tarkastelemme oikeudellisesta näkökulmasta asioita, joita toimittajan tulisi harkita, jos käyttäjä ei suostu maksamaan korvausta.

Ensin, varmista, että voit laskuttaa

• Vaikka toimittaja on toimittanut tuotoksen käyttäjälle, käyttäjä ei hyväksy toimitusta, minkä vuoksi laskutus on viivästynyt
• Vaikka toimittaja oli ymmärtänyt, että hyväksyntä oli valmis, käyttäjän käsityksessä on jokin ristiriita, eikä hän suostu maksamaan korvausta

Tällaiset tilanteet ovat täysin mahdollisia käytännössä.

Kun käyttäjä tarkistaa valmiin järjestelmän määrittelyt ja hyväksyy toimituksen, sitä kutsutaan järjestelmänkehityksen termeissä “hyväksynnäksi”. Tämän hyväksynnän merkityksestä ja siitä, mitä pitäisi harkita, jos sen eteneminen ei ole suotuisaa, selitetään yksityiskohtaisesti seuraavassa artikkelissa.

Liittyvä artikkeli: Järjestelmänkehityksen hyväksyntä ja oletetun hyväksynnän lausekkeen soveltamistilanteet[ja]

Yleinen selitys hyväksynnästä jätetään edellä mainittuun artikkeliin, mutta on tarpeen tarkastella, onko käyttäjän hyväksyntä laillisesti valmis, ottaen huomioon myös “oletetun hyväksynnän lausekkeen” määräykset.

Tätä ajatellen, ensimmäinen asia, jota pitäisi harkita, kun käyttäjä ei suostu maksamaan korvausta, olisi seuraavat kohdat:

1. Onko työ valmis vai onko se vielä kesken
2. Voiko virhevastuun (Japanin siviililaki 635 §) soveltaa

Syy siihen, miksi nämä kaksi kohtaa pitäisi tarkistaa ensin, on se, että jos työ ei ole valmis ja virhevastuuta (Japanin siviililaki 635 §) ei sovelleta, ei ole odotettavissa, että saat maksun, vaikka nostaisit kanteen.

Joten, mitä toimittajan edustajan pitäisi tarkistaa näiden kahden kohdan tarkastelua varten? Katsotaanpa, mitä asiakirjoja pitäisi tarkistaa.

Mitkä asiakirjat tulee tarkistaa palkkion laskutuksen mahdollisuuden selvittämiseksi

Muun muassa järjestelmän kehittämisen muutosten hallintaa ja muutosjohtamisdokumenttien luomista käsitellään tarkemmin toisessa artikkelissa.

Liittyvä artikkeli: Oikeudellisesta näkökulmasta tarkasteltuna, miten muutosten hallintaa tulisi hoitaa järjestelmän kehittämisessä[ja]

Seuraavaksi, tarkista kuinka paljon voit laskuttaa

Periaatteessa laskutettava summa on määritelty sopimuksessa. Kuitenkin, jos vaatimuksia muutetaan jälkikäteen, voi olla tilanteita, joissa ei ole olemassa asianmukaista sopimusta (tai vastaavaa asiakirjaa). Tässä artikkelissa selitämme yksityiskohtaisesti, miten laskutussumma lasketaan uudelleen, kun vaatimukset muuttuvat tai toimintoja lisätään jälkikäteen.

Liittyvä artikkeli: Onko järjestelmän kehityksen arvioitua summaa mahdollista korottaa jälkikäteen?[ja]

Tämä artikkeli kuvaa, miten laskutussumma lasketaan uudelleen, mutta erityisesti, jos tarkastelemme mahdollisuutta korottaa laskutussummaa, keskitymme seuraaviin seikkoihin:

1. Lisäkehityksen tai toiminnon korjauksen arviointi ja sen sisältö
2. Käyttäjän reaktio arviointiin
3. Sopimuksen olemassaolo tilanteesta, joka aiheutti lisäkehityksen tai toiminnon korjauksen, ja sen summa, joka on kirjattu tehtävienhallintataulukkoon

Ydinajatuksena on selvittää, onko käyttäjän kanssa saavutettu yhteisymmärrys siitä, että “tilaamme työn tällä summalla” (toisin sanoen, onko sopimus tehty).

Lopuksi, tarkastellaan oikeudenkäynnin toteuttamisen kohdalla huomioon otettavia asioita

Kiinnitä huomiota mahdollisuuteen vastakanteen esittämisestä

Järjestelmäkehityksessä, kun joko käyttäjä tai toimittaja nostaa kanteen toista osapuolta vastaan, ei ole harvinaista, että toinen osapuoli esittää vastakanteen. Toisin sanoen, tilanteessa, jossa palkkion maksamista ei suoriteta, käyttäjälläkin on todennäköisesti jotain sanottavaa.

Alun perin järjestelmäkehityksessä käyttäjän on myös kannettava erilaisia yhteistyövelvollisuuksia, mutta ensisijaisesti ei pidä unohtaa, että toimittaja kantaa laajaa harkintavaltaa ja suurta vastuuta järjestelmäkehityksen asiantuntijana. Toimittajan järjestelmäkehitykseen liittyvistä projektinhallintavelvollisuuksista on yksityiskohtainen selostus seuraavassa artikkelissa.

Liittyvä artikkeli: Mitä ovat projektinhallintavelvollisuudet järjestelmäkehityksessä[ja]

Toisin sanoen, onko mahdollista syyttää yksipuolisesti palkkion maksamatta jättävää käyttäjää, on asia, joka on syytä harkita etukäteen. Katsottaessa aikaisempia oikeustapauksia, on useita tapauksia, joissa alun perin toimittaja nosti kanteen palkkion vaatimiseksi, mutta käyttäjä esitti vastakanteen, vaatien alkuperäisen tilan palauttamista tai vahingonkorvausta.

Onko liiketoiminnallisesti todella hyötyä, on myös harkittava

Vaikka toimittajan argumentti hyväksyttäisiin ja palkkion vaatiminen todettaisiin mahdolliseksi oikeudenkäynnissä, jos tilanne eskaloituu oikeudenkäyntiin asti, jatkuvan liiketoiminnan jatkaminen on todennäköisesti käytännössä vaikeaa. Lisäksi, vaikka oikeudenkäynnissä omat argumentit hyväksyttäisiin, on syytä varautua siihen, että palkkion saaminen vie paljon aikaa. Jos otetaan huomioon myös oikeudenkäynnin vaatima vaiva ja kustannukset, on usein parempi pyrkiä löytämään kompromissi.

Yhteenveto

Jos käyttäjä ei suostu maksamaan palkkiota, ongelman laillinen tarkastelu vaatii useiden erilaisten dokumenttien tarkastelua. Lisäksi ei riitä, että dokumenttien hallinta on perusteellista, vaan on myös harkittava, millaisia riskejä ja haittoja organisaatio kantaa, jos lopulta päätetään ryhtyä oikeustoimiin.

On totta, että dokumenttien hallinnan tehostaminen on yleensä osa päivittäistä työtä. Kuitenkin, jos päätetään ryhtyä oikeustoimiin säilytettyjen dokumenttien ja materiaalien perusteella, se voi olla merkittävä liiketoimintapäätös. Tällaisissa epäsäännöllisissä tilanteissa on tärkeää ymmärtää kenttäpuolen ja johdon yhteenkuuluvuuden ja organisaation voiman merkitys sekä hallita koko prosessi.