Ποιες είναι οι μέθοδοι αντιμετώπισης σε περίπτωση διακοπής της ανάπτυξης συστημάτων λόγω των συνθηκών του χρήστη;

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

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

Η σημασία της σκέψης για τη διακοπή λόγω των συνθηκών του χρήστη

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

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

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

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

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

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

Αρχικά, οργανώστε τους λόγους που προτάθηκαν για την ακύρωση

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

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

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

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

Επιβεβαίωση των νομικών διατάξεων για αιτήματα αμοιβής και αποζημίωσης ζημίας

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

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

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Και στις δύο περιπτώσεις, το Ιαπωνικό Αστικό Κώδικα (Japanese Civil Code) προβλέπει τα εξής:

a.) Σε περίπτωση σύμβασης παροχής υπηρεσιών
Αίτημα αμοιβής: Άρθρο 648, παράγραφος 3 του Ιαπωνικού Αστικού Κώδικα
Όταν η εκτέλεση της σύμβασης τερματίζεται στη μέση για λόγους που δεν μπορούν να αποδοθούν στον αναθέτοντα, ο αναθέτοντας μπορεί να ζητήσει αμοιβή ανάλογη με το ποσοστό της εργασίας που έχει ήδη εκτελεστεί.
Αίτημα αποζημίωσης ζημίας: Άρθρο 651 του Ιαπωνικού Αστικού Κώδικα
1. Η σύμβαση μπορεί να ακυρωθεί από κάθε μέρος ανά πάσα στιγμή.
2. Εάν ένα από τα μέρη ακυρώσει τη σύμβαση σε μια περίοδο που είναι αντίξοη στο άλλο μέρος, αυτό το μέρος πρέπει να αποζημιώσει το άλλο μέρος για τη ζημία του. Ωστόσο, αυτό δεν ισχύει εάν υπάρχουν αναπόφευκτες συνθήκες.

b.) Σε περίπτωση σύμβασης υποεργολάβησης
Αίτημα αποζημίωσης ζημίας: Άρθρο 641 του Ιαπωνικού Αστικού Κώδικα
Ο πελάτης μπορεί να ακυρώσει τη σύμβαση ανά πάσα στιγμή, αποζημιώνοντας τον εργολάβο για τη ζημία του, εφόσον ο εργολάβος δεν έχει ολοκληρώσει την εργασία.

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

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

Προχωρώντας περαιτέρω στην απόδειξη του όγκου εργασίας και της ζημίας

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

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

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

Τι πρέπει να εξετάσουν οι χρήστες από τη δική τους πλευρά;

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

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

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

https://monolith.law/corporate/system-development-contract[ja]

Περίληψη

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

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