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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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