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

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

Δεν μπορεί κάθε παραγωγή να ενταχθεί με ακρίβεια σε ένα έτοιμο σύστημα

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

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

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

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

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

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

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

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

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

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

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

Πρώτα ο σχεδιασμός της απόφασης, μετά ο κώδικας

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

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

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

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

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

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

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

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

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

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

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

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

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