Η ανάπτυξη του εργοστασίου και η αρχιτεκτονική IT/OT – γιατί οι πρόχειρες ενοποιήσεις γυρίζουν μπούμερανγκ έπειτα από λίγα χρόνια;

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

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

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

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

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

Γι’ αυτό το θέμα απαιτεί απόφαση τώρα και όχι μετά την ολοκλήρωση της εκκίνησης. Όχι επειδή κάθε διασύνδεση πρέπει εξαρχής να είναι εκτεταμένη, αλλά επειδή ήδη από την αρχή πρέπει να διακρίνεται η προσωρινή λύση από τη λύση που προορίζεται να ενταχθεί στη μόνιμη αρχιτεκτονική της μονάδας. Αυτή η διάκριση πρέπει να έχει συνέπειες σε επίπεδο έργου: ξεχωριστό ιδιοκτήτη της απόφασης, όρους απόσυρσης της παράκαμψης, απαιτήσεις τεκμηρίωσης και κριτήρια επαναξιολόγησης κατά την επέκταση. Αν η μονάδα σχεδιάζει επόμενα επενδυτικά στάδια, εκσυγχρονισμό μηχανημάτων ή προετοιμασία για αξιολόγηση συμμόρφωσης, η έλλειψη αυτής της διάκρισης σχεδόν πάντα αυξάνει το κόστος της αλλαγής και διευρύνει το πεδίο ευθύνης από την πλευρά του επενδυτή. Ακριβώς γι’ αυτό η αρχιτεκτονική IT/OT δεν είναι σήμερα ένα πρόσθετο στοιχείο του έργου, αλλά μία από τις προϋποθέσεις για να διατηρηθεί ο έλεγχος του κόστους, του χρονοδιαγράμματος και του κινδύνου.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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