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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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