Νομικά Ζητήματα που Συνδέονται με τη Μετάβαση από Παλαιά Συστήματα στην Ανάπτυξη Συστημάτων

Η δημιουργία νέων IT συστημάτων σε μια επιχείρηση αποτελεί έναν χαρακτηριστικό τομέα εργασίας για τους IT μηχανικούς. Ωστόσο, όταν μιλάμε για την “δημιουργία νέων συστημάτων”, συχνά περιλαμβάνεται ταυτόχρονα και η διαδικασία “κατάργησης των παλαιών συστημάτων” που χρησιμοποιούνταν μέχρι τώρα. Σε αυτό το άρθρο, θα εξετάσουμε το έργο ανάπτυξης νέων συστημάτων από την προοπτική της “κατάργησης των παλαιών συστημάτων” και θα αναλύσουμε τα συναφή νομικά ζητήματα που συνεπάγεται αυτή η διαδικασία.

Τι σημαίνει η μετάβαση σε ένα νέο σύστημα

Η διάρκεια ζωής των IT συστημάτων δεν είναι αιώνια

Όσον αφορά τα IT συστήματα που χρησιμοποιούνται στις επιχειρήσεις, δεν είναι αλήθεια ότι μόλις δημιουργηθούν μπορούν να χρησιμοποιηθούν για πάντα. Επιπλέον, δεν είναι πάντα καλό να συνεχίζεις να χρησιμοποιείς τα παλιά συστήματα για πάντα. Αν και υπάρχουν διαφορές ανάλογα με την επιχείρηση και τη χρήση του συστήματος, ως γενικός κανόνας, τείνει να υπάρχει η διοικητική απόφαση ότι είναι καλύτερο να ανανεώσεις ένα σύστημα με κάτι καινούργιο μετά από περίπου δέκα χρόνια χρήσης.

Σε διάστημα δέκα ετών, η απόδοση των κομπιούτερ που κυκλοφορούν στην αγορά μπορεί να έχει αλλάξει δραματικά. Έτσι, προγράμματα που πριν από δέκα χρόνια δεν ήταν πρακτικά λόγω των περιορισμών στην ταχύτητα επεξεργασίας των υπολογιστών, μπορεί τώρα να είναι εφικτά. Επιπλέον, αν ένα σύστημα έχει χρησιμοποιηθεί για δέκα χρόνια, είναι πιθανό ότι οι εργασιακές διαδικασίες και οι εσωτερικοί κανόνες της εταιρείας έχουν αλλάξει σημαντικά. Ο κώδικας που έχει προστεθεί στο σύστημα για να ανταποκριθεί σε αυτές τις αλλαγές μπορεί να έχει γίνει τόσο περίπλοκος και ενσωματωμένος που δεν είναι εμφανής από την όψη του χρήστη. Αυτό μπορεί να οδηγήσει στην κατάσταση όπου, ακόμη και αν οι χρήστες θέλουν νέες λειτουργίες, οι προγραμματιστές μπορεί να βρουν αδύνατο να τις προσθέσουν.

Ένα παλιό σύστημα μπορεί να αρχίσει να απαιτεί αυξημένη «χειροκίνητη» εργασία από τους IT μηχανικούς, όπως για παράδειγμα την εκτέλεση ερωτημάτων για την εξαγωγή δεδομένων. Ειρωνικά, το ίδιο το σύστημα, καθώς γερνάει, μπορεί να οδηγήσει σε «προσωποκεντρική» εργασία. Όταν ένα σύστημα γίνει πολύ παλιό και οι προσωποκεντρικές εργασίες αυξηθούν, η προσπάθεια για περαιτέρω «συστηματοποίηση» μπορεί να οδηγήσει στην έναρξη ενός νέου πρότζεκτ για την ανάπτυξη ενός νέου συστήματος που θα αντικαταστήσει το παλιό.

Η ανάπτυξη του νέου συστήματος προχωρά παράλληλα με την κατάργηση του παλιού

Όπως αναφέρθηκε προηγουμένως, πολλά έργα ανάπτυξης συστημάτων (αν και όχι όλα) συνοδεύονται ταυτόχρονα από την πτυχή της μετάβασης από ένα παλιό σύστημα. Συχνά, τα ίδια τα συστήματα μπορεί να αλλάζουν απότομα μια συγκεκριμένη ημέρα.

Ωστόσο, η καθημερινή πρόοδος των εργασιών πρέπει να είναι συνεχής, από το παρελθόν προς το παρόν και από το παρόν προς το μέλλον. Ενώ διατηρούμε τα απαραίτητα δεδομένα από το παρελθόν, η πρόοδος των τρεχουσών εργασιών δεν πρέπει να διακόπτεται και παράλληλα πρέπει να προωθούμε την ιδέα μιας ανώτερης «συστηματοποίησης» για το μέλλον. Η μετάβαση σε ένα νέο σύστημα συχνά συνοδεύεται από πολλές προκλήσεις. Οι περιστάσεις αυτές, όταν συνδυάζονται, καθιστούν την ανάπτυξη ενός νέου συστήματος και την λειτουργία και συντήρηση του υφιστάμενου συστήματος περίπλοκα και αλληλένδετα, δημιουργώντας μια αδιάσπαστη σχέση μεταξύ τους.

Βήματα Μετάβασης σε Νέο Σύστημα

Κατά τη μετάβαση από ένα παραδοσιακό σε ένα νέο σύστημα, ιδιαίτερα σημαντικό είναι να μεταφέρετε τα δεδομένα σωστά. Τα βήματα για τη μεταφορά δεδομένων συνήθως ακολουθούν την παρακάτω διαδικασία:

1. Να καθορίσετε ποια δεδομένα που αποθηκεύονται στο παλιό σύστημα πρέπει να μεταφερθούν στο νέο → Πρέπει να καθορίσετε ποια δεδομένα πρέπει να είναι εύκολα αναζητήσιμα από την πλευρά της οθόνης του νέου συστήματος και ποια δεδομένα, ακόμη κι αν δεν είναι αναζητήσιμα από την οθόνη (όπως για ανταπόκριση σε ελέγχους), πρέπει να είναι διαθέσιμα για ανάκτηση κατά περίπτωση.
2. Να εξάγετε τα δεδομένα που έχετε καθορίσει στο βήμα 1 σε μορφή αρχείου CSV ή άλλης μορφής.
3. Να εισάγετε τα δεδομένα που εξάγατε στο βήμα 2 στο νέο σύστημα.
4. Να επαληθεύσετε αν τα δεδομένα που εισήχθησαν στο βήμα 3 αντανακλώνται σωστά στο νέο σύστημα και να επιβεβαιώσετε ότι η μετάβαση έχει γίνει σωστά. → Η επαλήθευση της σωστής μετάβασης συνήθως γίνεται μέσω της εμφάνισης στην οθόνη ή της εκτύπωσης αναφορών, αφήνοντας έτσι υλικό αποδεικτικό (το λεγόμενο στάδιο δοκιμών).

Η μετάβαση σε νέο σύστημα δυσκολεύει την αποσαφήνιση των ρόλων χρηστών και προμηθευτών

Στα βήματα μεταφοράς δεδομένων που αναφέρθηκαν προηγουμένως, συχνά προκύπτει το πρόβλημα του κατά πόσον οι χρήστες πρέπει να διαχειρίζονται τη διαδικασία ως εσωτερικό ζήτημα της εταιρείας τους. Για μια πιο γενική επισκόπηση της “υποχρέωσης συνεργασίας των χρηστών” σε έργα ανάπτυξης συστημάτων, παρακαλούμε ανατρέξτε στο παρακάτω άρθρο.

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

Ως γενικός κανόνας στα έργα ανάπτυξης συστημάτων, οι προμηθευτές συχνά υπερτερούν των χρηστών σε εξειδικευμένη τεχνογνωσία για την ανάπτυξη συστημάτων – ή μάλλον, αυτός είναι συχνά ο λόγος που τους ανατίθεται η εργασία. Ωστόσο, η συζήτηση για την “ιδανική κατάσταση” του συστήματος μιας εταιρείας μπορεί συχνά να γίνει μόνο από την πλευρά των χρηστών.

Αν λάβουμε υπόψη αυτά τα στοιχεία, μπορούμε να σκεφτούμε την ανάθεση των βημάτων 1 και 4 στους χρήστες ως μια δυνατή διαχωριστική γραμμή των ρόλων. Αν το δούμε από άλλη σκοπιά, κατά τη διαδικασία μεταφοράς δεδομένων, η “οριστικοποίηση των απαιτήσεων” των δεδομένων που πρέπει να μεταφερθούν και ο “έλεγχος” εάν η μεταφορά έγινε σύμφωνα με τις απαιτήσεις, μπορεί να θεωρηθούν ως υποχρεώσεις συνεργασίας των χρηστών. Εναλλακτικά, αν στην πλευρά των χρηστών υπάρχουν άτομα με εκτενείς γνώσεις για το παλιό σύστημα, τότε μπορεί να αναλάβουν και το βήμα 2.

Εάν είναι δυνατόν να αντιμετωπιστεί εσωτερικά η διαχείριση του παλιού συστήματος, χωρίς να χρειάζεται εξωτερική ανάθεση, τότε μπορεί να δοθεί εντολή μόνο για το νέο σύστημα στους προμηθευτές. Με αυτόν τον τρόπο, στη διαδικασία μεταφοράς δεδομένων, η διασαφήνιση των ρόλων μεταξύ χρηστών και προμηθευτών μπορεί πολλές φορές να γίνει ασαφής. Για μια γενική επισκόπηση των ρόλων που αναμένονται από τους προμηθευτές και των νομικών υποχρεώσεων που τους αναλογούν όταν οι χρήστες αναθέτουν εργασίες ανάπτυξης συστημάτων, παρακαλούμε ανατρέξτε επίσης στο παρακάτω άρθρο.

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

Παραδείγματα από παλαιότερες δίκες που αφορούν τη μετάβαση σε νέο σύστημα

Στα πλαίσια ενός έργου ανάπτυξης συστήματος με στόχο τη μετάβαση σε νέο σύστημα, υπάρχουν πραγματικά περιστατικά που οδήγησαν σε δικαστικές διαμάχες. Το παρακάτω απόσπασμα από μια απόφαση αναφέρεται σε μια υπόθεση όπου κατά τη διάρκεια της μεταφοράς δεδομένων, η διαδικασία απέτυχε και προκλήθηκαν πολλαπλές ασυνέπειες και σφάλματα στα δεδομένα του νέου συστήματος, προκαλώντας καθυστερήσεις στην παράδοση. Η διαμάχη επικεντρώθηκε στο ποιες υποχρεώσεις είχε αναλάβει ο προμηθευτής και ο χρήστης αντίστοιχα στο έργο. Τελικά, το δικαστήριο κατέληξε στο συμπέρασμα ότι ο προμηθευτής παραβίασε τις υποχρεώσεις προσοχής που του αναλογούσαν, όπως παρακάτω αναφέρεται:

Ο κατηγορούμενος, στο πλαίσιο της σύμβασης ανάθεσης, είχε την υποχρέωση όχι μόνο να μεταφέρει τα δεδομένα από το παλιό σύστημα στο νέο αλλά και να εξασφαλίσει τη λειτουργία του νέου συστήματος με τα μεταφερθέντα δεδομένα, συγκεκριμένα, πριν αρχίσει τη μεταφορά δεδομένων, έπρεπε να ερευνήσει και να αναλύσει τα δεδομένα που θα μεταφέρονταν από το παλιό σύστημα, να κατανοήσει τη φύση και την κατάστασή τους, να εξετάσει εάν η μεταφορά τους στο νέο σύστημα θα προκαλούσε προβλήματα στη λειτουργία του και, σε περίπτωση που θα προκαλούσαν προβλήματα, να αποφασίσει πότε και με ποια μέθοδο θα διορθώνονταν τα δεδομένα πριν προχωρήσει στη μεταφορά δεδομένων (σχεδιασμός μεταφοράς, ανάπτυξη εργαλείων μεταφοράς, μεταφορά δεδομένων) και τελικά να φέρει την ευθύνη για τη λειτουργία του νέου συστήματος με τα μεταφερθέντα δεδομένα

και αυτό θεωρείται σωστό, στην παρούσα υπόθεση, η μεταφορά δεδομένων έπρεπε να συνοδεύεται από την υποχρέωση διόρθωσης και επίλυσης των ασυνεπειών των δεδομένων.

Απόφαση του Δικαστηρίου του Τόκιο, 30 Νοεμβρίου 2016 (Έτος Χέισει 28)

Στην υπόθεση αυτή, ο χρήστης ανέλαβε τα βήματα 1 και 4, ενώ ο προμηθευτής τα βήματα 2 και 3, δηλαδή η εξαγωγή δεδομένων από το παλιό σύστημα (βήμα 2) έγινε από τον προμηθευτή. Έτσι, το δικαστήριο κατέληξε ότι ο προμηθευτής, ως ειδικός στην ανάπτυξη συστημάτων, έπρεπε να έχει εξετάσει εκ των προτέρων εάν η εξαγωγή δεδομένων θα μπορούσε να γίνει ομαλά.

Ωστόσο, αν το βήμα 2 (δηλαδή η εξαγωγή δεδομένων) είχε οριστεί ως ευθύνη του χρήστη και εκείνος απέτυχε στην εκτέλεσή του, τι θα συνέβαινε; Σε αυτή την περίπτωση, θα μπορούσε να θεωρηθεί ότι ο χρήστης παρέλειψε την απαραίτητη προκαταρκτική έρευνα για την εξαγωγή δεδομένων, προκαλώντας καθυστερήσεις στην παράδοση, και έτσι θα μπορούσε να κατηγορηθεί για παραβίαση της υποχρέωσης συνεργασίας.

Επιπλέον, τέτοιες αποφάσεις δεν βασίζονται μόνο στη συμβατική τεκμηρίωση, αλλά και σε πρακτικά συνεδριάσεων που συνοδεύουν την πρόοδο της ανάπτυξης του συστήματος ως αποδεικτικά στοιχεία. Η σημασία των πρακτικών εξηγείται αναλυτικά στο παρακάτω άρθρο.

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

Συνοπτικά

Τα έργα ανάπτυξης συστημάτων απαιτούν από τόσο τους χρήστες όσο και τους προμηθευτές να αναλάβουν πολλές υποχρεώσεις και να διατηρούν λεπτομερή επικοινωνία καθ’ όλη τη διάρκεια της προόδου τους. Ως εκ τούτου, ακόμη και στην προαναφερθείσα νομική υπόθεση, μια μικρή αλλαγή στις προϋποθέσεις μπορεί εύκολα να ανατρέψει τον φορέα ευθύνης, είτε αυτός είναι ο χρήστης είτε ο προμηθευτής.

Δεδομένης της πιθανότητας τα συστήματα να κρύβουν πίσω από την απλή εμφάνιση της οθόνης τους τεράστια ποσά δεδομένων και περίπλοκες δομές, καθώς και της πιθανότητας μια μικρή διαφορά στις προϋποθέσεις να αλλάξει σημαντικά την τελική δικαστική απόφαση, είναι σημαντικό να αντιμετωπίζουμε τη διαχείριση κινδύνων ενός νέου έργου ανάπτυξης συστημάτων σε συνδυασμό με την κατάργηση του παλιού συστήματος, με έναν ολιστικό τρόπο.