MONOLITH LAW OFFICE+81-3-6262-3248Hétköznapokon 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Jogi problémák a régi rendszerről történő átállással kapcsolatban a rendszerfejlesztés során

IT

Jogi problémák a régi rendszerről történő átállással kapcsolatban a rendszerfejlesztés során

Az új IT rendszerek létrehozása a vállalatokban az IT mérnökök jellemző feladatköre, de amikor “új rendszert hozunk létre”, gyakran magában foglalja a “korábban használt rendszer megszüntetésének” folyamatát is. Ebben a cikkben újraértelmezzük a “régi rendszer megszüntetése” szempontjából az új rendszer fejlesztésének projektjét, és magyarázatot adunk a hozzá kapcsolódó jogi kérdésekre.

Mit jelent az új rendszerre való áttérés?

Az IT rendszerek élettartama nem örökké tart

A vállalatok által használt IT rendszerek nem olyanok, hogy ha egyszer elkészültek, akkor örökké használhatók lennének. Sőt, nem is feltétlenül jó, ha valamit túl sokáig használunk. Természetesen vállalatonként és a rendszer felhasználási módjának megfelelően változik, de általános irányelvként elmondható, hogy egy rendszert általában legfeljebb 10 évig érdemes használni, utána pedig célszerű új rendszerre váltani.

Tíz év alatt a piacra kerülő számítógépek teljesítménye is jelentősen megváltozik. Ez azt jelenti, hogy például egy olyan program, amely 10 évvel ezelőtt (emberi szempontból egyszerű és kiváló tervezésű, de a számítógép feldolgozási sebességének korlátai miatt) nem volt gyakorlatilag megvalósítható, ma már megvalósítható lehet. Ráadásul, ha egy rendszert 10 évig használtunk, akkor valószínűleg a cég munkafolyamatai és belső szabályai is jelentősen megváltoztak ebben az időszakban. A kódok, amelyeket a cég belső és külső üzleti környezetének változásaihoz igazodva implementáltak, olyan bonyolult és összetett struktúrává válhatnak, amelyet a felhasználók már nem is érzékelnek. Ebben az esetben előfordulhat, hogy a felhasználók számára szükséges új funkciók hozzáadása már nem lehetséges a fejlesztők számára.

Az elavult rendszerek gyakran sok “kézi munkát” igényelnek az IT mérnököktől (például egyedi adatok kivonására szolgáló lekérdezések kiadása). Az a rendszer is, ha elavult, paradox módon “személyre szabottá” teszi a munkát. Ha egy rendszer túl régi és a személyre szabott munka túlságosan megnő, akkor egy új “rendszeresítési” intézkedést kell hozni. Ekkor jön létre az “új rendszer fejlesztése a régi rendszerről történő áttérés érdekében” projekt.

Az új rendszer fejlesztése a régi rendszer megszüntetésével egyidejűleg halad

Ahogy azt korábban említettük, egy rendszerfejlesztési projekt (bár nem minden projekt esetében) gyakran magában foglalja a régi rendszerről történő átállást is. A rendszer maga gyakran egy adott napon hirtelen vált át.

Az üzletmenet azonban a múltból a jelenbe, a jelenből a jövőbe folyamatosan halad. A múltbeli adatokat megőrizve, a jelenlegi üzletmenetet zavartalanul folytatva, továbbá kiváló “rendszeresítési” elképzeléseket kidolgozva a jövő felé, az új rendszerre történő átállás gyakran számos kihívással jár. Ezek a körülmények összetett módon összefonódnak, és az új rendszer fejlesztése, valamint a meglévő rendszer működtetése és karbantartása összetett módon kapcsolódik egymáshoz, és elválaszthatatlan kapcsolatot alakít ki.

Mi a lépések az új rendszerre való áttérésnél?

Melyek a legfontosabb lépések a régi rendszerről az új rendszerre való áttérésnél?

A régi rendszerből az új rendszerbe való áttérés során különösen fontos a megfelelő adatátvitel. Az adatátvitel lépései általában a következő sorrendben történnek:

  1. Tisztázni kell, hogy a régi rendszerben tárolt adatok közül melyeket kell átvinni az új rendszerbe → mely adatokat kell könnyen kereshetővé tenni az új rendszer képernyőjéről, és mely adatokat kell úgy tárolni, hogy szükség esetén (például ellenőrzéskor) elő lehet hozni őket, még ha a képernyőről való keresés nem is szükséges.
  2. Az 1. pontban azonosított adatok közül azokat, amelyeket be kell vinni az új rendszerbe, CSV-fájl formátumban kell kimenteni.
  3. A 2. pontban kiválasztott adatokat be kell vinni az új rendszerbe.
  4. Az ellenőrzés során meg kell győződni arról, hogy a 3. pontban bevitett adatok megjelennek-e az új rendszerben, és hogy az adatátvitel helyesen történt-e. → Az adatátvitel helyességének ellenőrzését általában a képernyőn megjelenő képek vagy a nyomtatott dokumentumok bizonyítják (ez az úgynevezett tesztelési folyamat).

Az új rendszerre való áttérés nehéz feladatot jelent a felhasználók és a szolgáltatók szerepkörének tisztázása szempontjából

Az adatmigráció előzőleg említett lépéseiben gyakran felmerülő probléma, hogy a felhasználóknak mennyire kell saját belső problémájukként kezelniük és irányításuk alatt tartaniuk azt. Ezen túlmenően, az adatmigrációra vonatkozóan nem korlátozódó, a rendszerfejlesztési projektek általános “felhasználói együttműködési kötelezettségéről” szóló áttekintést az alábbi cikkben találhatja.

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

Általánosságban elmondható, hogy a rendszerfejlesztési projektekben a szolgáltatók gyakran felülmúlják a felhasználókat a rendszerfejlesztés szakmai tudásában (vagy inkább ezért bízzák rájuk a feladatot). Ugyanakkor gyakran előfordul, hogy a saját rendszerük “ideális állapotáról” csak a felhasználók tudnak vitatkozni.

Ezt figyelembe véve, a korábban említett 1. és 4. lépést a felhasználók végezhetik el, mint egy lehetséges szerepkör tisztázás. Ha másképp szeretnénk fogalmazni, az adatok migrációjának során a migrálandó adatok “követelménydefiníciója” és a követelményeknek megfelelő adatmigráció “átvételi eljárása” lehet a felhasználók együttműködési kötelezettsége. Vagy másik megközelítésként, ha a felhasználók között van olyan, aki jól ismeri a régi rendszert, akkor a 2. lépést is a felhasználók feladataként lehet kezelni.

Ha a régi rendszerrel kapcsolatos kérdéseket belsőleg is meg lehet oldani, akkor elképzelhető, hogy a szolgáltatót csak az új rendszerrel kapcsolatos kérdésekkel bízzák meg. Ilyen formában az adatmigrációs munka során a felhasználók és a szolgáltatók szerepköre gyakran homályossá válhat. Ezen túlmenően, ha a felhasználók rendszerfejlesztési feladatokat bíznak a szolgáltatóra, általában milyen szerepkör várható a szolgáltatótól, és milyen jogi kötelezettségek hárulnak rá, erről általános magyarázatot az alábbi cikkben találhat.

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

Előző bírósági ítéletek az új rendszerre történő átállással kapcsolatban

A rendszerátállítási projektekben is előfordulhatnak peres ügyek.

Az új rendszerre történő átállást célzó rendszerfejlesztési projektekben valóban előfordultak olyan esetek, amikor problémák merültek fel, és peres ügyekké váltak. Az alább idézett ítéletben egy olyan esetről van szó, ahol az adatok áttelepítése során hibák léptek fel, több adat nem volt összhangban az új rendszerrel, bugok jelentkeztek, és a projekt késésbe került. Ezekkel a problémákkal kapcsolatban vitatott kérdés volt, hogy a szolgáltató és a felhasználó milyen kötelezettségeket vállalt a projektben. A végső döntés szerint a bíróság a szolgáltatótól elvárt figyelmeztetési kötelezettségek megsértését állapította meg a következők szerint:

A vádlott, a jelen szerződésen alapuló adatátviteli feladatok keretében, nem csak egyszerűen átvitte az adatokat a régi rendszerből az újba, hanem kötelessége volt az új rendszer működtetése az átvitt adatokkal. Konkrétan, mielőtt megkezdte volna az adatátviteli munkálatokat, meg kellett volna vizsgálnia és elemeznie a régi rendszerben lévő adatokat, amelyek áttelepítésre kerülnek, meg kellett volna értenie az adatok jellegét és állapotát, meg kellett volna vizsgálnia, hogy az adatok áttelepítése után az új rendszer működését akadályozza-e, és ha igen, mikor és hogyan javítja az adatokat, majd ezután kellett volna megkezdenie az adatátviteli munkálatokat (átviteli tervezés, átviteli eszköz fejlesztés, adatátvitel), és végül kötelessége volt működtetni az új rendszert az áttelepített adatokkal.

Ez a megközelítés helyénvaló, és ebben az esetben, az adatátvitel során, a vádlottnak kötelessége volt kijavítani és megszüntetni az adatok összhangjának hiányát.

Tokiói Kerületi Bíróság, 2016. november 30. (Heisei 28)

Ebben az esetben a felhasználó vállalta az 1. és 4. lépést, míg a szolgáltató a 2. és 3. lépést. Tehát a szolgáltató vállalta, hogy egyszer átveszi az adatokat a régi rendszerből. Ezért a bíróság úgy ítélte meg, hogy ha a szolgáltató vállalta az adatok kivonását is, akkor (mint rendszerfejlesztési szakértő) előzetesen meg kellett volna vizsgálnia, hogy az adatkivonás zökkenőmentesen megtörténhet-e.

De mi történt volna, ha a 2. lépést (azaz az adatok kivonását) a felhasználó feladataként határozták meg előre, és ezen felül az adatkivonás hibás volt? Ebben az esetben elképzelhető, hogy a felhasználó nem vizsgálta meg előzetesen, hogy az adatkivonás zökkenőmentesen megtörténhet-e, és ez okozta a késést, így most fordítva a felhasználó köteles lett volna együttműködni a hibák kijavításában.

Ezenkívül ezeket a döntéseket nem csak a szerződés alapján hozzák meg, hanem a rendszerfejlesztés előrehaladásával készült jegyzőkönyvek is bizonyítékként szolgálnak. A jegyzőkönyvek fontosságát a következő cikkben részletesen ismertetjük:

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

Összefoglalás

A rendszerfejlesztési projektek olyanok, amelyekben mind a felhasználók, mind a szolgáltatók számos kötelezettséget vállalnak, és szoros kommunikációval haladnak előre. Emiatt a korábban említett bírósági ítéletekben is, csak néhány alapfeltétel változása esetén a felelősség könnyen áthelyezhető a felhasználók és a szolgáltatók között.

Az új rendszerfejlesztési projektek kockázatkezelése fontos, tekintettel arra, hogy a rendszer bonyolultsága és adatmennyisége a felületen láthatónál sokkal nagyobb lehet, és a legkisebb előfeltétel-eltérések is jelentősen befolyásolhatják a végső bírói döntést. Ezért fontos, hogy a régi rendszerek megszüntetésével együtt átfogóan kezeljük ezeket a kockázatokat.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Vissza a tetejére