Kuinka pitkälle lainsäädännöllisesti tulisi toteuttaa toimintoja, joita ei ole määritelty järjestelmän kehityksen määrittelydokumentissa?

Yrityksissä käytettävien IT-järjestelmien kehittämisprojektit luodaan periaatteessa ennalta määriteltyjen vaatimusten mukaisesti. Toisaalta, kun otetaan huomioon, että järjestelmänkehittäjä on saanut täyden vastuun kehitystehtävistä asiantuntijana, käyttäjän odotukset eivät välttämättä ole matalat, jos kehittäjä vain mekaanisesti toteuttaa vaatimusmäärittelyssä kirjoitetut asiat. Tässä artikkelissa käsitellään, kuinka pitkälle kehittäjän tulisi ottaa vastuu “ohjelmista, jotka eivät ole määritelty vaatimusmäärittelyssä, mutta jotka ovat tarpeellisia kehitystavoitteiden kannalta”.

Oikeudelliset ongelmat, jotka liittyvät määrittelyjen ulkopuolisten asioiden toteuttamiseen

Toimittajilta vaaditaan harkintavaltaa

Järjestelmän kehitykseen liittyvien projektien sopimukset ja niihin liittyvät erilaiset oikeudelliset ongelmat korostavat, että työn suorittavalla toimittajalla on suuri harkintavalta.

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

Kuitenkin, tässä yhteydessä “harkintavalta” ei välttämättä päde kaikkiin järjestelmän kehityksen vaiheisiin. Kun eri vaiheet on määritelty ja yksityiskohtaiset tehtävät on jaettu, työ muuttuu usein yksinkertaiseksi. Kuitenkin, yleisesti ottaen, mitä enemmän työ liittyy projektin alkuvaiheisiin, sitä enemmän harkintavaltaa tarvitaan. Tämä on myös syy, miksi alkuvaiheen työt sopivat usein parhaiten osittaiseen valtuutukseen.

Liittyvä artikkeli: Ero järjestelmän kehityksen urakkasopimuksen ja osittaisen valtuutussopimuksen välillä[ja]

Harkintavaltaa tulisi käyttää tiukkojen kehitysvaiheiden aikana

Kuitenkin, vaikka järjestelmän kehittäjällä on suuri harkintavalta, asiakkaan toiveiden sokeaa hyväksymistä tulisi välttää, sillä se voi aiheuttaa suuria ongelmia myöhemmissä vaiheissa. Yksi IT-järjestelmä koostuu monista pienistä osista, ja vaikka muutos saattaa näyttää pieneltä ulkoapäin, se voi vaatia merkittäviä muutoksia kehittäjän näkökulmasta. Alla on artikkeli, jossa selitetään, kuinka hallita muutoksia järjestelmän kehityksessä oikeudellisesta näkökulmasta.

Liittyvä artikkeli: Miten hallita muutoksia järjestelmän kehityksessä oikeudellisesta näkökulmasta[ja]

Mitä asiantuntijan tulisi tehdä, kun ei ole sidottu määrittelyihin?

Jotta järjestelmän kehitysprojekti sujuisi sujuvasti, on tärkeää määritellä kehityksen vaatimukset etukäteen ja edetä suunnitelmallisesti niiden mukaan. Toisaalta, jos vain noudatat etukäteen määriteltyjä vaatimuksia ja teet vain sen, mitä sinulta pyydetään, saatat joutua tilanteeseen, jossa et pysty täyttämään rooliasi järjestelmän kehityksen asiantuntijana. Tässä dilemmassa kysymys “Mitä tulisi toteuttaa, vaikka sitä ei olisi määritelty?” tulee esiin.

Lakisääteiset velvollisuudet määräytyvät “tarkoituksen” mukaan, joka on määritelty eritelmä- ja sopimusasiakirjoissa

Toteutettavan sisällön osalta, vaikka sitä ei olisi mainittu sopimus- tai eritelmäasiakirjoissa, se määräytyy edelleen näiden sopimus- ja eritelmäasiakirjojen “tarkoituksen” eli “millä merkityksellä tai aikomuksella sopimus on tehty” perusteella. Katsotaanpa alla joitakin oikeustapauksia.

Oikeustapaus, jossa toteutusvelvollisuus kiellettiin, koska sitä ei ollut mainittu

Alla lainattu oikeustapaus koskee tilannetta, jossa riita kehittyi, kun järjestelmän kehittänyt toimittaja oli edennyt järjestelmän testikäyttöön asti, mutta käyttäjä vaati sopimuksen purkamista, koska tarvittavat toiminnot puuttuivat. Käyttäjä väitti, että puuttuva toiminto oli “datan automaattinen päivitystoiminto”, joka väitettiin olevan järjestelmän tärkein myyntivaltti. Kuitenkin oikeus ei hyväksynyt tätä toteutusvelvollisuutta.

Kuten yllä todettiin, sopimusasiakirjoissa, perussuunnitteludokumentissa ja yksityiskohtaisessa suunnitteludokumentissa ei ole mainintaa siitä, että toiminto ③ olisi järjestelmän kehityskohteena.

Kantaja väittää, että toiminto ③ oli vastaajan tärkein myyntivaltti kantajalle ja korostaa tämän toiminnon tarpeellisuutta, mutta jos tämä väite pitäisi paikkansa, sen pitäisi olla selvästi mainittu sopimusasiakirjoissa ja on vaikea uskoa, että tämän toiminnon kehittämisestä olisi sovittu, vaikka sitä ei ole mainittu.

Tokion alioikeuden päätös 18. helmikuuta 2009 (Heisei 21)

Tämä päätös voidaan tosiaan yksinkertaistaa sanomalla, että “jos sitä ei ole mainittu suunnitteludokumentissa, ei tarvitse tehdä sitä, mitä ei ole”. Mutta tarkemmin sanottuna, päätös ei perustu muodolliseen tosiasiaan, kuten onko se mainittu suunnitteludokumentissa, vaan suunnitteludokumentin ja sopimusasiakirjan “tarkoituksen” huomioon ottavaan arviointiin. Toisin sanoen, “jos ajatellaan syitä, miksi sitä ei ole mainittu suunnitteludokumentissa tai sopimusasiakirjassa, on järkevää olettaa, että myöskään vastaavaa sopimusta ei ole tehty”.

Oikeustapaukset, joissa toteutusvelvollisuus on hyväksytty, vaikka sitä ei ole mainittu

Toisaalta, on olemassa oikeustapauksia, joissa on katsottu, että toteutusvelvollisuus on olemassa, vaikka sitä ei olisi mainittu sopimuksessa tai määrittelydokumentissa. Seuraavassa lainauksessa esitetty oikeustapaus koskee lääkkeiden käyttöhistorian hallintajärjestelmän kehittämistä, jossa ei voitu siirtää tietoja olemassa olevasta järjestelmästä uuteen järjestelmään, eikä uutta järjestelmää voitu hyödyntää, minkä seurauksena käyttäjä päätti purkaa sopimuksen. Kuitenkin, palveluntarjoaja väitti, että tietojen siirto ei kuulu heidän toimialaansa, mikä johti kiistaan.

Uuden järjestelmän kehittäminen usein sisältää olemassa olevan järjestelmän poistamisen ja tietojen siirtämisen. Näiden tehtävien merkityksestä ja niihin liittyvistä oikeudellisista kysymyksistä on yksityiskohtainen selostus seuraavassa artikkelissa.

Liittyvä artikkeli: Oikeudelliset kysymykset, jotka liittyvät vanhasta järjestelmästä uuteen siirtymiseen järjestelmäkehityksessä[ja]

Olemassa olevassa järjestelmässä oli jo tallennettuna yli 50 000 potilaan tiedot, ja kantaja oli pyrkinyt tehostamaan toimintojaan näiden tietojen avulla. Jos potilastietoja ei voitu siirtää olemassa olevasta järjestelmästä tähän järjestelmään, on selvää, että se aiheuttaisi ongelmia apteekin lääkkeiden toimituksessa, ja kantajan edustajan olisi luonnollisesti pitänyt olla tietoinen tästä. Lisäksi, ennen tämän sopimuksen solmimista, kantajan edustaja oli kysynyt vastaajan edustajalta tietojen siirron mahdollisuudesta, mikä on asia, jonka vastaajan edustaja myöntää (keskeneräinen), ja kantajan edustajan olisi täytynyt ymmärtää, että on suuri todennäköisyys, että hän joutuisi syöttämään käsin yli 50 000 potilaan tiedot, ja on vaikea kuvitella, että hän olisi päättänyt ottaa käyttöön tämän järjestelmän huolimatta tästä. Lisäksi, kuten edellä mainittiin (1)I, koska vastaaja ei voinut siirtää olemassa olevan järjestelmän lääkehistoriatietoja tähän järjestelmään, hän tulosti tiedot paperille ja otti ne mukaan PDF-tiedostoon, vaikka tietojen siirtoa ei ollut oletettu tässä sopimuksessa, on vaikea kuvitella, että vastaaja olisi tehnyt tällaisen työlään työn palveluna.

Tokion alioikeuden päätös 18. marraskuuta 2010 (Heisei 22)

Tässäkin tapauksessa tärkeää on sopimuksen tarkoitus ja sopimusdokumentin “tarkoitus”. Jos molemmat osapuolet olisivat ymmärtäneet tietojen siirron kuuluvan toimialan ulkopuolelle ja solmineet sopimuksen tämän ymmärryksen pohjalta, tuomioistuin huomautti, että sekä käyttäjä että palveluntarjoaja olisivat solmineet sopimuksen epäluonnollisella tavalla. Toisin sanoen, käyttäjä olisi ottanut vastaan valtavan määrän käsityötä, ja palveluntarjoaja olisi tietoisesti lähtenyt projektiin, joka aiheuttaisi ongelmia käyttäjän toiminnalle tulevaisuudessa, mikä olisi erittäin epäloogista.

Mitä voimme oppia näistä kahdesta päätöksestä

Vaikka sopimus- tai määrittelydokumentissa ei olisi mainintaa datan siirrosta, sen toteuttamisvelvollisuuden hyväksymisen taustalla on yksi asia, joka liittyy “dataan”, joka ei näy järjestelmän näytöllä tai ulkoasussa. Edellä mainittu “välttämättömien toimintojen puuttuminen” on jotain, joka ilmenee suoraan järjestelmän näytöllä tai ulkoasussa. Siksi, vaikka olisitkin järjestelmän kehityksen aloittelija, määrittelydokumentin puutteiden havaitseminen ei ole kovin vaikeaa. Toisaalta datan siirtoon liittyvät ongelmat ovat sellaisia, että järjestelmän kehityksen aloittelijalle on vaikea ymmärtää prosessin merkitystä, työn vaikeusastetta tai työmäärää. Tästä syystä on mahdollista, että myös se, että toimittajan puolella oletettiin, että heidän asiantuntemuksensa avulla heidän tulisi sujuvasti hoitaa nämä asiat, vaikutti asiaan.

Tällä tavoin ajateltuna, määrittelydokumentin tai sopimuksen puutteet liittyvät läheisesti käyttäjän “yhteistyövelvollisuuteen”. Toisin sanoen, on kysymys siitä, onko käyttäjä todella täyttänyt “yhteistyövelvollisuutensa” sopimuksen solmimiseksi ja määrittelydokumentin laatimiseksi. Yleinen selitys käyttäjän laillisista velvollisuuksista järjestelmän kehitysprojektissa on käsitelty yksityiskohtaisesti seuraavassa artikkelissa.

Liittyvä artikkeli: Mitä yhteistyövelvollisuus tarkoittaa järjestelmän kehityksen tilaajalle eli käyttäjälle[ja]

Jos tarkastelet myös yllä olevaa artikkelia, saatat ymmärtää, että käyttäjän yhteistyöpyynnöt, kuten näytön ja välttämättömien toimintojen määrittely, ovat suuria alueita, ja datan siirron laiminlyönnissä keskustelu on hyvin erilainen.

Miten tulisi suhtautua korvauksiin, jotka liittyvät määrittelydokumentissa mainitsemattomaan kehitystyöhön?

Tämän artikkelin aiheeseen liittyen saattaa herättää kysymyksen, onko mahdollista vaatia lisäkorvausta, jos on tehty jotain, jota ei ole mainittu määrittelydokumentissa. Onko tällainen lisäkorvaus lain mukaan sallittua? Lisäkorvauksen mahdollisuus ja sen laskentamenetelmät on selitetty yksityiskohtaisesti seuraavassa artikkelissa.

Liittyvä artikkeli: Onko järjestelmän kehityksen arvioinnin jälkeinen lisäys mahdollista?[ja]

Yllä olevassa artikkelissa selitetään, että on tärkeää selvittää, onko ollut työtä, joka ylittää korvauksen ja vastikkeen suhteen määritellyn työn laajuuden. Toisin sanoen, jos toimittaja on suostunut tekemään kehitystyötä, joka ei sisälly alkuperäiseen määrittelyyn (tässä artikkelissa, kielteinen esimerkki), on mahdollista vaatia lisäkorvausta.

Yhteenveto

Järjestelmäkehityksessä toimittajan rooli määräytyy tietyllä tavalla sopimusasiakirjojen ja teknisten määrittelyjen sisällön mukaan. Kuitenkin, ottaen huomioon, että heidät on palkattu asiantuntijoina ja heihin luotetaan suuresti, on selvää, että heidän todellinen roolinsa ei määräydy pelkästään muodollisuuksien perusteella. Kuitenkin, ymmärtääksemme tämän sisäisen todellisuuden, meidän tulisi ymmärtää, että laki näyttelee suurta roolia tässä.