Õigusprobleemid, mis kaasnevad vanast süsteemist üleminekuga süsteemiarenduses

Uute IT-süsteemide loomine ettevõtetes on IT-inseneride tüüpiline töövaldkond, kuid “uue süsteemi loomine” tähendab sageli ka “vana süsteemi kaotamist”. Selles artiklis vaatleme uue süsteemi arendamise projekti julgelt “vana süsteemi kaotamise” aspektist ning sellega kaasnevaid erinevaid õiguslikke küsimusi.

Mida tähendab üleminek uuele süsteemile

IT-süsteemide eluiga ei ole igavene

Ettevõttes kasutatavad IT-süsteemid ei ole sellised, mida saaks luua üks kord ja seejärel kasutada lõputult. Samuti ei ole alati hea, kui vanu asju kasutatakse pidevalt ja hoolikalt. Kuigi ettevõtete ja süsteemide kasutusotstarbe vahel on loomulikult erinevusi, on üldine suundumus see, et ühe süsteemi kasutamine kestab tavaliselt umbes 10 aastat, mille järel on parem teha uus süsteem.

Kümne aastaga muutub turul levivate arvutite jõudlus märkimisväärselt. Seega võib olla, et programmid, mida ei olnud 10 aastat tagasi võimalik rakendada arvuti töötluskiiruse piirangute tõttu (kuigi need tundusid inimestele lihtsad ja hästi kavandatud), on nüüd rakendatavad. Lisaks, kui olete süsteemi kasutanud 10 aastat, võivad ettevõtte töövoog ja sisekorra reeglid olla märkimisväärselt muutunud. Kood, mis on rakendatud ettevõtte sisemise ja välimise juhtimiskeskkonna muutustele reageerimiseks, võib olla nii keeruline ja keerukas, et seda ei saa ekraanilt tuvastada. Sellisel juhul võib juhtuda, et kasutajatel on soovitud funktsioone, mida arendajad ei saa enam lisada.

Vananenud süsteemid võivad IT-inseneridele järk-järgult tekitada palju “käsitsi” tööd (näiteks andmete eraldi väljavõtmiseks päringute tegemine jne). Süsteem ise muutub iroonilisel kombel vananedes “isikupõhiseks”. Kui süsteem on liiga vana ja isikupõhiseid ülesandeid on palju, siis kui proovitakse rakendada veelgi suuremat “süsteemistamist”, tekib projekt “uue süsteemi arendamine vanast süsteemist üleminekuks”.

Uue süsteemi arendamine toimub koos vana süsteemi kaotamisega

Nagu eespool mainitud, on paljudel süsteemiarendusprojektidel (kuigi mitte kõigil) sageli kaasas ka üleminek vanalt süsteemilt. Süsteem ise võib sageli muutuda diskontinuutselt ühel päeval.

Kuid igapäevane töö peaks jätkuma järjepidevalt minevikust olevikku ja olevikust tulevikku. Hoides alles vajalikud mineviku andmed, jätkates praegust tööd takistusteta ja pakkudes välja suurepäraseid “süsteemistamise” kontseptsioone tulevikuks, kaasnevad uuele süsteemile üleminekuga sageli mitmesugused väljakutsed. Nende asjaolude kombinatsioon muudab uue süsteemi arendamise ja olemasoleva süsteemi haldamise ja hooldamise keerukaks ja lahutamatuks seoseks.

Mis on uuele süsteemile ülemineku sammud?

Vana süsteemist uuele süsteemile üleminekul on eriti oluline andmed korrektselt üle kanda. Andmete ülekandmise sammud järgivad tavaliselt järgmist protseduuri:

1. Selgitage välja, millised andmed vanast süsteemist tuleks uude süsteemi üle kanda → tuleb kindlaks teha, millised andmed peaksid olema uue süsteemi ekraanilt hõlpsasti otsitavad, samuti millised andmed ei pruugi olla ekraanilt otsitavad (näiteks auditeerimiseks), kuid tuleks vajadusel välja võtta.
2. Väljastage CSV-faili või muus vormingus andmed, mis tuleks uude süsteemi importida, andmetest, mis on kindlaks tehtud esimeses etapis.
3. Importige teises etapis ekstraheeritud andmed uude süsteemi.
4. Kontrollige, kas kolmandas etapis imporditud andmed on uues süsteemis kajastatud, ja kontrollige, kas üleminek on õigesti tehtud. → Tavaliselt jäetakse ülemineku õigsuse kontrollimise tulemused ekraanil kuvatavate ekraanide või trükitud aruannete abil maha tõendusmaterjalina (nn testimisprotsess).

Uuele süsteemile üleminek on kasutaja ja tarnija rollide määratlemisel keeruline

Eelnevalt mainitud andmeülekande etappides on sageli probleemiks, kui palju peaks kasutaja oma ettevõtte sisemise probleemina seda haldama. Lisaks, üldise ülevaate saamiseks “kasutaja koostöökohustusest” süsteemiarendusprojektides laiemalt, mitte ainult andmeülekande kontekstis, vaadake järgmist artiklit.

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

Üldiselt on süsteemiarendusprojektides tõepoolest sageli nii, et tarnija on kasutajast üle erialaste teadmiste poolest (või pigem on see sageli põhjus, miks neile tööd usaldatakse). Kuid teisest küljest on sageli nii, et ainult kasutaja saab arutada, milline peaks olema ettevõtte süsteem.

Arvestades neid aspekte, võib ühe võimalusena kaaluda rollide määratlemist nii, et kasutaja teostab eelnevalt mainitud sammud 1 ja 4. Teisisõnu, võib öelda, et andmeülekande protsessis on “nõuete määratlemine” ja “aktsepteerimine”, kas andmed on nõuetele vastavalt üle kantud, kasutaja koostöökohustused. Või kui ettevõttes on keegi, kes on vanema süsteemi suhtes väga teadlik, võib kaaluda ka sammu 2 määramist kasutaja vastutusalaks.

Kui vanema süsteemi küsimusi saab lahendada ettevõttesiseselt, ilma et oleks vaja seda välja anda, võib kaaluda uue süsteemi küsimuste väljastamist tarnijale. Sellisel viisil võib andmeülekande töös kasutaja ja tarnija rollide määratlemine muutuda mõnikord ebaselgeks. Lisaks, kui kasutaja annab süsteemiarendusega seotud tööd tarnijale, vaadake üldist ülevaadet selle kohta, milliseid rolle tarnijalt tavaliselt oodatakse ja millised õiguslikud kohustused neile langevad, järgmisest artiklist.

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

Varasemad kohtuotsused seoses üleminekuga uuele süsteemile

On olemas tegelikke juhtumeid, kus süsteemiarendusprojektid, mis on suunatud uuele süsteemile üleminekule, on põhjustanud probleeme ja viinud kohtuasjadeni. Allpool tsiteeritud kohtuotsuse juhtumis ebaõnnestus andmete ülekandmine andmete ülekandmise ajal, tekitades uues süsteemis mitmeid andmete ebakõlasid ja vigu ning põhjustades viivitusi tähtajates. Selliste erinevate probleemide korral oli vaidlusküsimuseks, milliseid kohustusi olid tarnija ja kasutaja pool projekti suhtes võtnud. Lõppjäreldusena määrati tarnija poolt täidetavate hoolsuskohustuste sisu järgmiselt ja tunnistati tarnija hoolsuskohustuse rikkumine.

Kaebaja oli võtnud endale kohustuse mitte ainult lihtsalt üle kanda andmeid vanast süsteemist uude süsteemi lepingu alusel, vaid ka käivitada uus süsteem üle kantud andmetega, täpsemalt, enne andmete ülekandmise tööde alustamist uurida ja analüüsida andmeid, mis on ülekandmise objektiks vanas süsteemis, mõista andmete olemust ja seisundit, kaaluda, kas need andmed võivad pärast ülekandmist uude süsteemi takistada selle tööd, ja kui need võivad takistada, otsustada, millal ja kuidas neid andmeid parandada, enne kui asuda andmete ülekandmise töödele (ülekandmise kavandamine, ülekandevahendi arendamine, andmete ülekanne) ja lõpuks võtta endale kohustus käivitada uus süsteem üle kantud andmetega vanast süsteemist.

See on õiglane otsus, ja selles juhtumis oleks pidanud kaebaja võtma endale kohustuse parandada andmete ebakõlasid andmete ülekandmise ajal.

Tokyo District Court, November 30, Heisei 28 (2016)

Selles juhtumis oli algselt tehtud rollijaotus nii, et kasutaja pool võttis endale sammud 1 ja 4 ning tarnija pool sammud 2 ja 3. See tähendab, et tarnija pool oli üks kord võtnud endale andmete väljavõtmise vanast süsteemist (samm 2). Seega otsustas kohus, et kui tarnija oli võtnud endale andmete väljavõtmise, sealhulgas kas andmete väljavõtmine saab toimuda sujuvalt, oleks pidanud seda eelnevalt kaaluma.

Kuid mis oleks juhtunud, kui kasutaja pool oleks eelnevalt rollijaotuse teinud ja võtnud endale sammu 2 (st andmete väljavõtmise) ja seejärel ebaõnnestunud väljavõtmises? Sellisel juhul oleks võimalik, et kui kasutaja ei ole teinud eelnevat uurimist, kas andmete väljavõtmine saab toimuda sujuvalt, ja see on põhjustanud viivitusi tähtajates, siis nüüd võib kasutaja poolt olla rikutud koostöökohustust.

Lisaks tehakse selliseid otsuseid mitte ainult lepingute põhjal, vaid ka süsteemiarenduse edenemisele vastavate koosolekute protokollide põhjal tõenditena. Koosolekute protokollide olulisust selgitatakse üksikasjalikult allpool toodud artiklis.

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

Kokkuvõte

Süsteemiarenduse projektid nõuavad nii kasutajatelt kui ka tarnijatelt vastastikuseid kohustusi, mida tuleb hoolikalt suheldes täita. Seetõttu võib eelmainitud kohtupraktikas vaid väikeste eelduste muutumine põhjustada vastutuse lihtsa ümberpööramise kasutaja ja tarnija vahel.

Arvestades, et süsteem võib hõlmata tohutult andmeid ja keerukaid mehhanisme, mida ei saa ekraani välimuse põhjal ette kujutada, ning et väikeste eelduste erinevused võivad oluliselt mõjutada lõplikku kohtuotsust, võib öelda, et uue süsteemi arendusprojekti riskijuhtimine on oluline, võttes arvesse ka vana süsteemi kaotamist.