Πώς να οργανώσετε τη συνεργασία του integrator, του software house και του τμήματος συντήρησης σε ένα ενιαίο έργο;

Γιατί αυτό το θέμα έχει σήμερα σημασία

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

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

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

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

Πού αυξάνεται συχνότερα το κόστος ή ο κίνδυνος

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

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

Ένα τυπικό πρακτικό παράδειγμα είναι μια υλοποίηση όπου η ανώτερη εφαρμογή πρέπει να διαχειρίζεται τις εντολές παραγωγής, τη συνταγή και την αναφορά, ενώ ο integrator είναι υπεύθυνος για τον ελεγκτή, τις κινήσεις και την ακολουθία της μηχανής. Αν το όριο ευθύνης περιγραφεί μόνο λειτουργικά, χωρίς να οριστούν οι ενδιάμεσες καταστάσεις, οι συνθήκες σφάλματος και η συμπεριφορά μετά από απώλεια επικοινωνίας, κάθε πλευρά θα διαμορφώσει τις δικές της «ασφαλείς» παραδοχές. Το software house θα θεωρήσει ότι η έλλειψη επιβεβαίωσης σημαίνει επανάληψη της εντολής, ο integrator θα θεωρήσει ότι η εντολή δίνεται μία μόνο φορά, και η συντήρηση θα παραλάβει ένα σύστημα που δεν μπορεί να διαγνωστεί κατά τη διάρκεια στάσης. Το αποτέλεσμα είναι προβλέψιμο: μακρά εκκίνηση, ασαφή σφάλματα, διορθώσεις στις διεπαφές και ένταση γύρω από το ερώτημα ποιος ευθύνεται για τη μη προγραμματισμένη διακοπή. Κατά την αξιολόγηση μιας τέτοιας κατάστασης, αξίζει να μετρώνται όχι μόνο η προθεσμία παράδοσης, αλλά και ο αριθμός αλλαγών στις διεπαφές μετά την έγκριση του σχεδίου, ο αριθμός βλαβών που εντοπίστηκαν μόνο επιτόπου, καθώς και ο χρόνος που απαιτείται για την ανασύσταση της αιτίας της αστοχίας. Αν αυτοί οι δείκτες αυξάνονται παρά την πρόοδο των εργασιών, το πρόβλημα συνήθως βρίσκεται στην οργάνωση της συνεργασίας και όχι στην απόδοση ενός μεμονωμένου προμηθευτή.

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

Πώς να προσεγγίσετε το θέμα στην πράξη

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

Γι’ αυτό, η πρώτη απόφαση δεν θα πρέπει να είναι η επιλογή εργαλείου ούτε το χρονοδιάγραμμα των workshops, αλλά η υιοθέτηση ενός κοινού μοντέλου ευθύνης για ολόκληρο τον κύκλο ζωής της λύσης. Για τον manager, το πρακτικό κριτήριο είναι απλό: κάθε λειτουργία που επηρεάζει τη λειτουργία της μηχανής ή της γραμμής πρέπει να έχει ορισμένο ιδιοκτήτη σε τέσσερις καταστάσεις του έργου — σχεδιασμός, εκκίνηση, παραλαβή και συντήρηση. Αν για μια συγκεκριμένη λειτουργία δεν μπορεί να δοθεί σαφής απάντηση στο ποιος εγκρίνει την απαίτηση, ποιος υλοποιεί την αλλαγή, ποιος δοκιμάζει τις επιπτώσεις και ποιος φέρει την ευθύνη για την αποκατάσταση της λειτουργίας μετά από βλάβη, τότε το αντικείμενο δεν είναι έτοιμο για υλοποίηση. Σε αυτό το σημείο αναδεικνύεται φυσικά ο ρόλος του τεχνικού project manager: όχι ως του ανθρώπου «των προθεσμιών», αλλά ως του υπεύθυνου για την τάξη στη λήψη αποφάσεων μεταξύ ειδικοτήτων και προμηθευτών.

Τα περισσότερα προβλήματα εμφανίζονται στο σημείο επαφής ανάμεσα στον έλεγχο και το εξειδικευμένο λογισμικό. Χαρακτηριστικό παράδειγμα είναι μια εφαρμογή που αλλάζει τον τρόπο επιλογής συνταγών, παραμετροποιεί τη σειρά λειτουργίας ή επηρεάζει τα δικαιώματα του χειριστή. Για ένα software house αυτό μπορεί να φαίνεται ως μια συνηθισμένη λειτουργική αλλαγή, όμως για τον integrator και τη συντήρηση της εγκατάστασης αποτελεί παρέμβαση στη συμπεριφορά του συστήματος, στη διάγνωση και στις διαδικασίες αλλαγής παραγωγής. Αν πριν από την υλοποίηση δεν έχει καθοριστεί πού τελειώνει η ευθύνη για το interface και πού αρχίζει η ευθύνη για τη λογική της διεργασίας, μια διόρθωση που γίνεται «πάνω στην παραγωγή» μπορεί να απαιτήσει νέες δοκιμές, επικαιροποίηση οδηγιών και, σε ορισμένες περιπτώσεις, ανασχεδιασμό των διαδικασιών service. Ακριβώς εδώ το θέμα συνδέεται και με τον προϋπολογισμό: το κόστος του εξειδικευμένου λογισμικού για τη βιομηχανία δεν προκύπτει μόνο από τη συγγραφή κώδικα, αλλά και από το πόση ευθύνη μεταφέρει το έργο στο στάδιο της επικύρωσης, της τεκμηρίωσης και της μετέπειτα συντήρησης.

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

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

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

Τι να προσέξετε κατά την υλοποίηση

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

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

Χαρακτηριστικό παράδειγμα είναι μια φαινομενικά μικρή τροποποίηση: η αλλαγή της ακολουθίας λειτουργίας ενός σταθμού, η οποία από την οπτική του software house είναι διόρθωση λογικής, για τον integrator σημαίνει διαφορετικούς χρόνους απόκρισης του εξοπλισμού, ενώ για τη συντήρηση επηρεάζει τη διάγνωση και τις διαδικασίες μετά από βλάβη. Αν μια τέτοια αλλαγή φτάσει στην εγκατάσταση χωρίς κοινή ανασκόπηση των συνεπειών, τότε μετά την εκκίνηση είναι δύσκολο να διαπιστωθεί αν η πηγή του προβλήματος είναι ο κώδικας, η διαμόρφωση του controller, οι παράμετροι του drive ή ο τρόπος χειρισμού από τον operator. Τότε το κόστος αυξάνεται όχι μόνο λόγω της ίδιας της διόρθωσης, αλλά και λόγω του χρόνου διακοπής, των πρόσθετων δοκιμών και της εμπλοκής προσώπων που προηγουμένως δεν χρειαζόταν να συμμετέχουν στην ανάλυση. Γι’ αυτό αξίζει να μετριέται όχι μόνο ο χρόνος έναρξης λειτουργίας, αλλά και ο αριθμός των αλλαγών υλοποίησης χωρίς πλήρη διαδρομή έγκρισης, ο χρόνος επαναφοράς της προηγούμενης έκδοσης και το ποσοστό των αστοχιών που εντοπίζονται μόνο μετά την παράδοση του συστήματος σε λειτουργία. Αυτό δίνει πραγματική εικόνα για το αν η συνεργασία των τριών πλευρών ελέγχεται συστηματικά ή απλώς διατηρείται αποσπασματικά.

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