Oikeudelliset ongelmat vanhasta järjestelmästä uuteen siirtymisessä järjestelmäkehityksessä

Uuden IT-järjestelmän luominen yrityksissä on tyypillinen IT-insinöörin tehtäväalue. Kuitenkin, kun puhumme “uuden järjestelmän luomisesta”, usein siihen sisältyy myös prosessi, jossa “aiemmin käytetty järjestelmä poistetaan”. Tässä artikkelissa tarkastelemme uuden järjestelmän kehittämistä projektina erityisesti “vanhan järjestelmän poistamisen” näkökulmasta ja selitämme siihen liittyviä erilaisia oikeudellisia kysymyksiä.

Mitä uuteen järjestelmään siirtyminen tarkoittaa?

IT-järjestelmien elinkaari ei ole ikuinen

Yrityksissä käytettävät IT-järjestelmät eivät ole sellaisia, että ne voitaisiin luoda kerran ja käyttää loputtomasti. Ei myöskään ole välttämättä hyvä idea pitää kiinni vanhasta järjestelmästä ikuisesti. Vaikka yritysten ja järjestelmien käyttötarkoitusten välillä on luonnollisesti eroja, yleisenä ohjeena voidaan pitää, että yhden järjestelmän käyttöikä on noin kymmenen vuotta, jonka jälkeen on usein järkevää päivittää uuteen järjestelmään.

Kymmenessä vuodessa markkinoilla olevien tietokoneiden suorituskyky muuttuu merkittävästi. Tämän seurauksena esimerkiksi kymmenen vuotta sitten, ihmisen näkökulmasta yksinkertaisen ja tehokkaan suunnittelun omaava, mutta tietokoneen prosessointinopeuden rajoitusten vuoksi toteuttamiskelvoton ohjelma, saattaa nykyään olla toteutettavissa. Lisäksi, jos järjestelmää on käytetty kymmenen vuotta, yrityksen työprosessit ja sisäiset säännöt ovat todennäköisesti muuttuneet huomattavasti. Jälkikäteen toteutettu koodi, joka on mukautettu yrityksen sisäisten ja ulkoisten toimintaympäristöjen muutoksiin, saattaa olla niin monimutkainen ja sekava, ettei sitä voida havaita käyttöliittymästä. Tämä voi johtaa tilanteeseen, jossa käyttäjät haluavat lisätoimintoja, mutta kehittäjien näkökulmasta niiden toteuttaminen on jo mahdotonta.

Vanhat järjestelmät saattavat aiheuttaa IT-insinööreille paljon “käsityötä” (esimerkiksi yksittäisten tietojen poimimiseen tarvittavien kyselyjen tekeminen). Ironista kyllä, järjestelmä itse alkaa “henkilökohtaistaa” työtehtäviä vanhetessaan. Kun vanha järjestelmä on tuottanut liikaa henkilökohtaisia tehtäviä ja halutaan toteuttaa lisää “järjestelmällistämistä”, uuden järjestelmän kehittäminen vanhan järjestelmän siirtämiseksi on seuraava askel.

Uuden järjestelmän kehittäminen etenee vanhan järjestelmän poistamisen kanssa

Kuten aiemmin mainittiin, yhden järjestelmän kehitysprojektissa on usein samanaikaisesti mukana siirtymä vanhasta järjestelmästä, vaikka kaikki järjestelmänkehitysprojektit eivät olekaan tällaisia. Järjestelmä itsessään saattaa usein vaihtua epäjatkuvasti tiettynä päivänä.

Kuitenkin päivittäisen liiketoiminnan tulisi jatkua sujuvasti menneisyydestä nykyhetkeen ja nykyhetkestä tulevaisuuteen. Menneisyyden tiedot on säilytettävä tarpeen mukaan, nykyisen liiketoiminnan on jatkuttava esteettä ja lisäksi on esitettävä erinomaisia suunnitelmia tulevaisuuden “järjestelmöinnille”. Uuteen järjestelmään siirtyminen tuo usein mukanaan monia haasteita. Näiden tekijöiden yhdistelmä tekee uuden järjestelmän kehittämisestä ja olemassa olevan järjestelmän käytöstä ja ylläpidosta monimutkaisen prosessin, joka on erottamattomasti yhteydessä toisiinsa.

Mitä uuteen järjestelmään siirtymisen vaiheet ovat

Erityisen tärkeää on siirtää tiedot oikein, kun siirrytään vanhasta järjestelmästä uuteen. Tietojen siirtämisen vaiheet etenevät yleensä seuraavasti:

1. Selvitetään, mitkä vanhan järjestelmän tallentamista tiedoista tulisi siirtää uuteen järjestelmään. Tämä tarkoittaa myös sitä, että on määriteltävä, mitkä tiedot tulisi olla helposti haettavissa uuden järjestelmän näytöltä ja mitkä tiedot, vaikka niitä ei tarvitse hakea näytöltä, tulisi olla saatavilla tarvittaessa (esimerkiksi tarkastuksia varten).
2. Tuodaan uuteen järjestelmään siirrettävät tiedot CSV-tiedostona tai vastaavassa muodossa.
3. Siirretään vaiheessa 2 tuodut tiedot uuteen järjestelmään.
4. Varmistetaan, että vaiheessa 3 tuodut tiedot heijastuvat uudessa järjestelmässä ja että tiedot on siirretty oikein. Tämän varmistamiseksi tulisi jättää todisteita, kuten näyttökuvia tai tulosteita (ns. testausvaihe).

Uuden järjestelmän käyttöönotossa käyttäjän ja toimittajan roolien määrittely on haastavaa

Kuten aiemmin mainitussa tietojen siirtämisen vaiheessa, usein ongelmaksi muodostuu se, kuinka pitkälle käyttäjän tulisi pitää se omana sisäisenä asianaan ja hallinnassaan. Lisäksi, tämä ei koske pelkästään tietojen siirtämistä, vaan myös yleisesti järjestelmän kehitysprojekteja. Yleiskatsauksen “käyttäjän yhteistyövelvollisuudesta” järjestelmän kehitysprojekteissa voit lukea alla olevasta artikkelista.

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

Yleisesti ottaen järjestelmän kehitysprojekteissa toimittajalla on usein etulyöntiasema käyttäjään nähden järjestelmän kehityksen asiantuntemuksen suhteen (tai pikemminkin, tämä on usein syy, miksi heille on annettu tehtävä). Toisaalta, vain käyttäjäpuoli voi usein määritellä, millainen yrityksen järjestelmän tulisi olla.

Tämä huomioon ottaen, voisi olla järkevää, että käyttäjä hoitaisi aiemmin mainitut vaiheet 1 ja 4. Toisin sanoen, tietojen siirtämisen yhteydessä, siirrettävien tietojen “vaatimusten määrittely” ja tietojen siirtämisen “hyväksyminen” voitaisiin järjestää käyttäjän vastuulle. Tai toinen tapa järjestää asiat olisi, että jos käyttäjäpuolella on henkilö, jolla on laaja tietämys vanhasta järjestelmästä, hän voisi hoitaa myös vaiheen 2.

Jos vanhan järjestelmän asiat voidaan hoitaa yrityksen sisällä ilman ulkoistamista, uuden järjestelmän kehitys voidaan ulkoistaa toimittajalle. Tällä tavalla, tietojen siirtämisen yhteydessä, käyttäjän ja toimittajan roolien määrittely voi joskus muuttua epäselväksi. Lisäksi, kun käyttäjä ulkoistaa järjestelmän kehitystehtävät toimittajalle, yleiskatsauksen siitä, mitä rooleja toimittajalta yleensä odotetaan ja mitkä ovat heidän lailliset velvollisuutensa, voit lukea alla olevasta artikkelista.

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

Vanhoja oikeustapauksia, jotka liittyvät siirtymiseen uuteen järjestelmään

On olemassa tapauksia, joissa uuteen järjestelmään siirtymistä tavoittelevissa järjestelmänkehitysprojekteissa on syntynyt ongelmia, jotka ovat johtaneet oikeudenkäyntiin. Alla lainattu tuomioistuimen päätös liittyy tapaukseen, jossa siirtotyö epäonnistui datan siirron aikana, mikä johti useisiin datan epäjohdonmukaisuuksiin ja bugeihin uudessa järjestelmässä ja aiheutti myös viivästyksiä toimitusajassa. Tällaisissa ongelmissa kiistakysymykseksi nousi, millaisia velvollisuuksia toimittajalla ja käyttäjällä oli projektissa. Lopputuloksena tuomioistuin totesi, että toimittajan olisi pitänyt noudattaa seuraavia huolellisuusvelvollisuuksia ja tunnusti toimittajan huolellisuusvelvollisuuden rikkomisen.

Toimittajan olisi pitänyt, ei ainoastaan siirtää dataa vanhasta järjestelmästä uuteen, vaan myös ottaa vastuulleen velvollisuus saada uusi järjestelmä toimimaan siirretyn datan avulla. Tarkemmin sanottuna, ennen datan siirtotyön aloittamista, toimittajan olisi pitänyt tutkia ja analysoida siirrettävän datan tilaa vanhassa järjestelmässä, ymmärtää datan luonne ja tila, harkita, aiheuttaako data ongelmia uuden järjestelmän toiminnassa siirron jälkeen, ja jos ongelmia ilmenee, päättää milloin ja miten kyseinen data korjataan. Tämän jälkeen toimittajan olisi pitänyt suorittaa datan siirtotyö (siirtosuunnittelu, siirtotyökalun kehittäminen, datan siirto) ja lopulta ottaa vastuulleen velvollisuus saada uusi järjestelmä toimimaan siirretyn datan avulla.

Tämä on oikeudenmukainen päätelmä, ja tässä tapauksessa toimittajan olisi pitänyt ottaa vastuulleen velvollisuus korjata ja poistaa datan epäjohdonmukaisuudet siirron aikana.

Tokion alioikeuden päätös 30. marraskuuta 2016 (Heisei 28)

Tässä tapauksessa käyttäjä oli alun perin ottanut vastuulleen vaiheet 1 ja 4, ja toimittaja vaiheet 2 ja 3. Toisin sanoen, toimittaja oli alun perin ottanut vastuulleen datan poiminnan vanhasta järjestelmästä (vaihe 2). Siksi tuomioistuin katsoi, että jos toimittaja (järjestelmänkehityksen asiantuntijana) oli ottanut vastuulleen datan poiminnan, sen olisi pitänyt harkita etukäteen, voitiinko datan poiminta suorittaa sujuvasti.

Mutta entä jos käyttäjä oli alun perin ottanut vastuulleen vaiheen 2 (eli datan poiminnan) ja epäonnistunut siinä? Tässä tapauksessa on mahdollista, että jos käyttäjä ei olisi tehnyt etukäteistutkimusta siitä, voitiinko datan poiminta suorittaa sujuvasti, ja tämä olisi johtanut toimitusajan viivästymiseen, käyttäjä olisi voinut joutua syytteeseen yhteistyövelvollisuuden rikkomisesta.

Lisäksi tällaiset päätökset perustuvat paitsi sopimustekstiin, myös järjestelmänkehityksen edistymiseen liittyviin pöytäkirjoihin, jotka toimivat todisteina. Pöytäkirjojen merkitystä käsitellään yksityiskohtaisesti alla olevassa artikkelissa.

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

Yhteenveto

Järjestelmäkehitysprojekti on sellainen, jossa sekä käyttäjän että toimittajan on kannettava monia velvollisuuksia ja edettävä tiiviissä kommunikaatiossa. Siksi mainitussa oikeustapauksessa, jo pienet muutokset lähtökohtaisissa olosuhteissa voivat helposti kääntää vastuun joko käyttäjän tai toimittajan puolelle.

Uuden järjestelmän kehitysprojektin riskienhallinta on tärkeää ottaen huomioon, että järjestelmä voi sisältää valtavan määrän dataa ja monimutkaisia mekanismeja, jotka eivät ole ilmeisiä ulkoasusta, ja että pienetkin eroavaisuudet lähtökohdissa voivat suuresti muuttaa lopullista oikeudellista päätöstä. Tämä on tärkeää ymmärtää, kun vanha järjestelmä poistetaan ja uusi otetaan käyttöön.