Το βάρος ενός προϊόντος καταγράφεται στη διαχείριση υλικών. Το ποσοστό ανακυκλωμένων υλικών καταγράφεται στο σύστημα συνταγών. Το πιστοποιητικό του προμηθευτή βρίσκεται σε μορφή PDF σε έναν δικτυακό δίσκο. Το δελτίο προϊόντος απαιτεί και τις τρεις πληροφορίες σε ένα ενιαίο σύνολο δεδομένων, και ακριβώς σε αυτό έγκειται το έργο της ενοποίησης, όχι στη σύνδεση δύο συστημάτων.
Η «απρόσκοπτη ενσωμάτωση ERP» είναι μια τυπική υπόσχεση, η οποία στην πράξη ακολουθείται από ένα έργο διάρκειας τριών μηνών. Δημοσιεύουμε τον οδηγό μας, ώστε το τμήμα πληροφορικής της εταιρείας σας να μπορεί να ελέγξει, πριν από την υπογραφή της σύμβασης, ποια στοιχεία ζητούνται πραγματικά. Αυτό το άρθρο παρουσιάζει ποια δεδομένα χρειάζεται το δελτίο από τα συστήματά σας, με ποιους τρεις τρόπους μας παραδίδονται και γιατί αυτό μπορεί να γίνει σε δύο εβδομάδες.
Τι πρέπει στην πραγματικότητα να παρέχει το ERP σας
Για να δημιουργηθεί ένα δελτίο προϊόντος (DPP), χρειαζόμαστε για κάθε προϊόν:
- Βασικά δεδομένα - κωδικός προϊόντος, ονομασία, παραλλαγές, βάρη, διαστάσεις, εικόνες
- Δεδομένα λίστας εξαρτημάτων - συστατικά με ποσότητες και ποσοστά ανακυκλωμένων υλικών
- Δεδομένα προέλευσης - τόπος παραγωγής, αριθμός παρτίδας, ημερομηνία παραγωγής
- Περιβαλλοντικά δεδομένα - ισοδύναμο CO₂ ανά μονάδα, κατανάλωση νερού, κατανάλωση ενέργειας
- Δεδομένα προμηθευτών - ποιος προμηθεύει ποιο συστατικό (για τις υποχρεώσεις δέουσας επιμέλειας)
Στο ERP σας, όλα αυτά τα δεδομένα υπάρχουν θεωρητικά. Στην πράξη, όμως, είναι κατανεμημένα σε 4 έως 7 ενότητες: Διαχείριση υλικών, Παραγωγή, Ποιότητα, Βάση προμηθευτών, μερικές φορές μια ξεχωριστή ενότητα για περιβαλλοντικά δεδομένα, μερικές φορές ένα ξεχωριστό σύστημα για συνταγές και λίστες εξαρτημάτων.
Το ερώτημα της ενσωμάτωσης δεν είναι: «Παρέχει το ERP σας δεδομένα σε ένα DPP;» Είναι: «Πώς συγκεντρώνετε τα δεδομένα από 5 υποσυστήματα σε ένα συνεκτικό σύνολο δεδομένων;»
Τρεις δοκιμασμένοι τρόποι
Τρόπος 1: Λήψη των δεδομένων από το ERP
Λειτουργεί καλά με σύγχρονα ERP (SAP S/4HANA Cloud, Dynamics 365, Odoo). Ο πάροχος του DPP ανακτά τα δεδομένα μέσω της διεπαφής του ERP (τεχνικά OData ή REST). Μόνο οι αλλαγές, σύμφωνα με χρονοδιάγραμμα ή όταν ενεργοποιούνται από κάποιο γεγονός.
Πλεονεκτήματα: ελάχιστη ανάπτυξη από την πλευρά σας, παρέχετε πρόσβαση ανάγνωσης, ο πάροχος αναλαμβάνει τη μετατροπή.
Μειονεκτήματα: δεν λειτουργεί με παλαιότερες εγκαταστάσεις SAP ECC χωρίς πρόσθετο επίπεδο διεπαφής. Χρειάζεστε σαφείς κανόνες σχετικά με το ποιος έχει δικαίωμα ανάγνωσης ποιων δεδομένων.
Μέθοδος 2: Διαβίβαση αλλαγών
Το ERP σας αναφέρει κάθε αλλαγή ως συμβάν (μέσω SAP Event Mesh, Apache Kafka ή RabbitMQ), και ο πάροχος DPP την λαμβάνει.
Πλεονεκτήματα: σχεδόν σε πραγματικό χρόνο, εξελίσσεται παράλληλα, τα συστήματα δεν εξαρτώνται το ένα από το άλλο.
Μειονεκτήματα: Η εγκατάσταση είναι απαιτητική και απαιτεί υποδομή που δεν διαθέτει κάθε τμήμα πληροφορικής. Για μικρότερες εταιρείες είναι συνήθως υπερβολική.
Τρόπος 3: Χρήση του υπάρχοντος επιπέδου ενσωμάτωσης
Διαθέτετε ήδη ένα επίπεδο ### ενσωμάτωσης(Mulesoft, Boomi, Informatica, Azure Data Factory) μεταξύ του ERP και των εξωτερικών συστημάτων. Αυτό το επίπεδο αποτελεί τη «σύμβαση»: ο πάροχος DPP επικοινωνεί μαζί του, ποτέ απευθείας με το ERP.
Πλεονεκτήματα: οι υπάρχουσες επενδύσεις αξιοποιούνται, οι κανόνες παραμένουν σταθεροί, δεν υπάρχει άμεση πρόσβαση τρίτων στο ERP.
Μειονεκτήματα: τα έξοδά σας για το επίπεδο ενσωμάτωσης αυξάνονται αντίστοιχα.
Τι κάνουμε διαφορετικά σε συγκεκριμένα έργα
Πολλοί πάροχοι επιθυμούν να συνδεθούν απευθείας με το ERP σας. Εμείς ενσωματώνουμε πάντα ένα ενδιάμεσο βήμα: η διεπαφή μας δέχεται μια ουδέτερη μορφή δεδομένων (ένα σχήμα JSON), την οποία συμπληρώνετε με ένα εργαλείο της επιλογής σας. Αυτό σημαίνει:
- Μπορείτε να κάνετε την προετοιμασία των δεδομένων μόνοι σας, με τα εργαλεία που γνωρίζει η ομάδα σας
- Μπορείτε να μας αντικαταστήσετε - η ουδέτερη μορφή είναι μεταφερόμενη
- Μπορείτε να ανακτήσετε ολόκληρο το απόθεμά σας ανά πάσα στιγμή - ως CSV, XLSX, JSON-LD και SQL, καθώς και μέσω του REST-API
- Παρέχουμε έναν επαληθευτή εισαγωγής, ο οποίος ελέγχει τα δεδομένα σας πριν από τη μεταφόρτωση
Η πλήρης μορφή και όλες οι ερωτήσεις περιγράφονται δημόσια στο Τεκμηρίωση API, ως περιγραφή διεπαφής σύμφωνα με το OpenAPI. Το τμήμα IT της εταιρείας σας μπορεί να ελέγξει τη διεπαφή πριν από την υπογραφή της σύμβασης - συμπεριλαμβανομένων παραδειγμάτων ερωτήσεων, απαντήσεων σφαλμάτων και λεπτομερειών πιστοποίησης.
Χρονοδιάγραμμα αυτής της προσέγγισης στην πράξη:
- Ημέρα 1 έως 2: Εργαστήριο αντιστοίχισης. Ποιο πεδίο του ERP αντιστοιχεί σε ποιο πεδίο του DPP;
- Ημέρα 3 έως 5: Πρώτες εξαγωγές JSON από το ERP, μέσω του εργαλείου επικύρωσης μας.
- Ημέρα 6 έως 8: Διόρθωση σφαλμάτων (ελλείποντα πεδία, ασυνεπείς κωδικοποιήσεις).
- Ημέρα 9 έως 10: Τα πρώτα DPP είναι σε λειτουργία.
Δύο εβδομάδες, όχι τρεις μήνες. Το κρίσιμο σημείο είναι το εργαστήριο αντιστοίχισης - εκεί αποφασίζεται η ποιότητα των δεδομένων.
Τι μπορεί να πάει στραβά: οι πιο συνηθισμένες παγίδες
Δεδομένα βάσης προϊόντων σε πολλά συστήματα: το SAP έχει τον κωδικό προϊόντος, το PIM έχει τις εικόνες και τα κείμενα μάρκετινγκ, το PLM έχει τη λίστα εξαρτημάτων. Κανείς δεν έχει μια συνεπή εικόνα. Λύση: καθορίστε πριν από το έργο ποιο σύστημα είναι το κύριο για κάθε πεδίο.
Πιστοποιητικά σε μορφή PDF: οι προμηθευτές παρέχουν πιστοποιητικά GOTS, OEKO-TEX ή REACH ως σαρωμένα αρχεία PDF. Αυτή δεν αποτελεί δομημένη πηγή δεδομένων. Λύση: Οι φορείς πιστοποίησης προσφέρουν όλο και περισσότερο τη δυνατότητα αναζήτησης μέσω διεπαφής (το OEKO-TEX προηγείται, το GOTS υστερεί). Ή: καταχώρηση χειροκίνητα, αλλά με ημερομηνία ισχύος, ώστε να μην εμφανίζονται στο DPP πιστοποιητικά που έχουν λήξει.
Απόρρητο της σύνθεσης: ειδικά στους τομείς των καλλυντικών, των τροφίμων και των φαρμάκων: η πλήρης σύνθεση αποτελεί εμπορικό μυστικό. Το DPP πρέπει να τη δημοσιοποιήσει; Λύση: Το μοντέλο τριών επιπέδων του ESPR. Η κατηγορία προϊόντος είναι δημόσια, ενώ οι αρχές έχουν πρόσβαση στην πλήρη σύνθεση. Σχεδόν ποτέ δεν αποτελεί εμπόδιο, αλλά πρέπει να διευκρινιστεί νωρίς.
Δεδομένα CO₂ βάσει προμηθευτών: ο προμηθευτής σας παρέχει μια μέση τιμή για το σύνολο του χαρτοφυλακίου του, όχι ανά παρτίδα. Λύση: προσωρινή αποδοχή, μακροπρόθεσμη προσαρμογή των συμβάσεων με τους προμηθευτές. Το ESPR απαιτεί τιμές συγκεκριμένες για κάθε προϊόν από μια συγκεκριμένη ημερομηνία, αλλά η τρέχουσα πρακτική αποτελεί συμβιβασμό.
Τοπικές γλωσσικές εκδόσεις: Το ERP σας περιέχει μόνο την ονομασία του προϊόντος στα γερμανικά και τα αγγλικά. Για τις 27 χώρες της ΕΕ χρειάζεστε περισσότερα. Λύση: Μηχανική μετάφραση με βάση δεδομένων ορολογίας· διαθέτουμε ένα ξεχωριστό άρθρο σχετικά με αυτό.
Τα ερωτήματα που πρέπει να θέσετε πριν από το έργο
Πριν στείλετε ένα RFP σε τρεις προμηθευτές, απαντήστε εσωτερικά:
- Πόσα προϊόντα/κωδικούς ειδών πρέπει να έχουν DPP; (10, 10.000, 1 εκατομμύριο;)
- Ποια συστήματα διατηρούν σήμερα δεδομένα σχετικά με τα DPP;
- Ποιο τμήμα διαχειρίζεται κάθε ένα από τα συστήματα;
- Διαθέτετε ένα επίπεδο ενσωμάτωσης που θα πρέπει να χρησιμοποιηθεί;
- Υπάρχει ήδη μια λειτουργική διεπαφή μέσω του ERP σας;
Οι απαντήσεις καθορίζουν ποια από τις τρεις μεθόδους είναι κατάλληλη για εσάς.
Οι απαντήσεις καθορίζουν αν ένα έργο θα διαρκέσει δύο εβδομάδες ή έξι μήνες.
Ερωτήσεις σχετικά με αυτό το άρθρο
Αρκεί η διεπαφή REST ή χρειαζόμαστε ένα middleware;
Η διεπαφή είναι επαρκής. Τα τρία πρότυπα διαφέρουν ως προς το πού πραγματοποιείται ο μετασχηματισμός, όχι ως προς το τι λαμβάνουμε - η διεπαφή μας δέχεται ένα ουδέτερο σχήμα JSON, ανεξάρτητα από το με ποιο εργαλείο το δημιουργήσατε. Μια ανάκτηση δεδομένων από ένα σύγχρονο ERP, μια ροή συμβάντων και ένα υπάρχον επίπεδο ενσωμάτωσης καταλήγουν όλα στο ίδιο τελικό σημείο. Η χρήση ενδιάμεσου λογισμικού (middleware) αξίζει τον κόπο αν ήδη χρησιμοποιείτε κάποιο και θέλετε αυτό να παραμείνει ως σύμβαση έναντι τρίτων. Αν δεν υπάρχει σήμερα, μην αγοράσετε κανένα για το «Product Pass».
Τι αποφασίζεται στο εργαστήριο χαρτογράφησης;
Ποιο πεδίο του ERP αντιστοιχεί σε ποιο πεδίο του Pass - και ποιο σύστημα αποτελεί την κύρια πηγή, όταν περισσότερα συστήματα περιέχουν την ίδια τιμή. Το εργαστήριο πραγματοποιείται την 1η και τη 2η ημέρα και αποτελεί το κρίσιμο σημείο ολόκληρου του έργου, καθώς εκεί λαμβάνονται οι αποφάσεις σχετικά με την ποιότητα των δεδομένων και όχι αργότερα στον κώδικα. Φέρτε μαζί σας τα άτομα που συντηρούν τα συστήματα, όχι μόνο εκείνους που είναι υπεύθυνοι για το έργο - τα τμήματα βασικών δεδομένων, παραγωγής, ποιότητας και προμηθειών σπάνια βρίσκονται στο ίδιο τμήμα. Όλα τα επόμενα στάδια, δηλαδή οι εξαγωγές, η επικύρωση και η διόρθωση σφαλμάτων, είναι θέμα τεχνικής δεξιότητας.
Τα πιστοποιητικά μας υπάρχουν μόνο ως σαρωμένα αρχεία PDF. Τι να τα κάνουμε;
Ένα σκαναρισμένο έγγραφο δεν αποτελεί δομημένη πηγή δεδομένων και, ως εκ τούτου, είναι άχρηστο για το διαβατήριο. Υπάρχουν δύο τρόποι για να το επιτύχετε: οι φορείς πιστοποίησης προσφέρουν όλο και περισσότερο ερωτήματα μέσω API, ενώ όπου δεν υπάρχουν τέτοια, καταχωρείτε τις τιμές χειροκίνητα, πάντα όμως με την ημερομηνία ισχύος, ώστε να μην παραμείνει κανένα πιστοποιητικό που έχει λήξει σε ένα δημοσιευμένο διαβατήριο. Προγραμματίστε τη χειροκίνητη διαδικασία ως επαναλαμβανόμενη εργασία και όχι ως εφάπαξ εργασία.
Μπορεί το τμήμα πληροφορικής μας να ελέγξει τη διεπαφή πριν υπογράψουμε οτιδήποτε;
Ναι. Το πλήρες σχήμα και όλα τα τελικά σημεία διατίθενται ως προδιαγραφή OpenAPI στη διεύθυνση Τεκμηρίωση API, μαζί με παραδείγματα αιτημάτων, απαντήσεις σφάλματος και λεπτομέρειες πιστοποίησης. Τίποτα από αυτά δεν κρύβεται πίσω από μια εμπορική συζήτηση, οπότε η ομάδα ενσωμάτωσής σας μπορεί να εκτιμήσει τον απαιτούμενο κόπο πριν ακόμη υπογραφεί κάποια σύμβαση. Εάν ένας πάροχος δεν παρουσιάσει τη διεπαφή του σε αυτό το στάδιο, αυτό αποτελεί επίσης μια απάντηση.
Τι συμβαίνει με τα δεδομένα μας όταν αλλάζουμε πάροχο;
Μπορείτε να τα μεταφέρετε. Η διεπαφή δέχεται ένα ουδέτερο σχήμα JSON αντί για μια ιδιόκτητη μορφή, και ολόκληρο το απόθεμά σας εξάγεται σε μορφή CSV, XLSX, JSON-LD και SQL ή μέσω του REST-API. Αυτό είναι σκόπιμο - η μορφή στην οποία εισάγετε τα δεδομένα είναι μεταφερόμενη, οπότε μια αλλαγή απαιτεί μόνο μια εξαγωγή και όχι την εκ νέου δημιουργία του αρχείου. Θέστε την ίδια ερώτηση σε κάθε πάροχο πριν από το εργαστήριο αντιστοίχισης, καθώς μετά από αυτό τα ονόματα των πεδίων σας θα περιλαμβάνονται στο μοντέλο του.
Πόσο διαρκεί πραγματικά μια σύνδεση;
Στα έργα που συντονίζουμε, δύο εβδομάδες - δύο ημέρες χαρτογράφησης, τρεις ημέρες μέχρι τις πρώτες εξαγωγές μέσω του Validator μας, τρεις ημέρες διόρθωσης σφαλμάτων, δύο ημέρες μέχρι τη δημοσίευση των πρώτων «διαβατηρίων». Η χρονοβόρα διαδικασία δεν είναι ποτέ ο κώδικας, αλλά αυτά που εντοπίζει ο επικυρωτής: πεδία που λείπουν, ασυνεπείς κωδικοποιήσεις, τιμές για τις οποίες κανείς δεν αισθάνεται υπεύθυνος. Προγραμματίστε αυτές τις ημέρες, αντί να τις μειώσετε. Ένα έργο που τις παραλείπει, δημοσιεύει και τα κενά.
Πρέπει να συνδέσουμε όλα τα προϊόντα ταυτόχρονα;
Όχι. Ξεκινήστε με τα προϊόντα που χρειάζονται πρώτα ένα «πάσο» και με ένα σύστημα προέλευσης - το ουδέτερο σχήμα δέχεται τόσο έναν μερικό κατάλογο όσο και έναν πλήρη, και οι εισαγωγές είναι επαναλήψιμες, οπότε οι μεταγενέστερες εκτελέσεις ενημερώνουν το απόθεμα. Αυτό διατηρεί επίσης το εργαστήριο αντιστοίχισης αρκετά μικρό, ώστε να μπορεί να ολοκληρωθεί σε δύο ημέρες. Η επέκταση που θα ακολουθήσει αποτελεί εργασία αντιστοίχισης, όχι νέο έργο.
