Τα briefs των μεγάλων εταιρειών περιγράφουν ό,τι φαίνεται. Ένα portal για αντιπροσώπους, ένα app για τεχνικούς στο πεδίο, μια οθόνη επαναπαραγγελίας για αγοραστές. Αυτό που φαίνεται δεν είναι σχεδόν ποτέ η δουλειά. Η δουλειά βρίσκεται αλλού. Η τιμή είναι στο ERP, ο πελάτης στο CRM, το απόθεμα είναι σωστό μόνο για τέσσερα λεπτά κάθε φορά. Και κανένα από τα τρία συστήματα δεν θα αλλάξει, δεν θα αντικατασταθεί, ούτε καν θα επανεκκινηθεί για χάρη αυτού που φτιάχνετε. Αν δείτε το έργο ως οθόνες, θα καθυστερήσει. Αν το δείτε ως διασύνδεση, το χρονοδιάγραμμα θα βγει περίπου σωστό.
Η πρώτη συνάντηση πρέπει να απαντήσει ένα ερώτημα για κάθε είδος δεδομένων: ποιο σύστημα έχει τα σωστά στοιχεία. Για έναν πελάτη, μια τιμή, ένα απόθεμα, μια παραγγελία, ένα τιμολόγιο, ακριβώς ένα σύστημα είναι ο κάτοχος. Όλα τα άλλα κρατούν αντίγραφο. Ένα αντίγραφο μπορεί να μην είναι ενημερωμένο. Δεν είναι όμως ποτέ η επίσημη πηγή. Οι περισσότερες διαφωνίες που βγαίνουν τον τέταρτο μήνα έχουν την ίδια αιτία: δύο συστήματα θεωρούν και τα δύο ότι το ίδιο πεδίο είναι δικό τους, και δύο ομάδες έχουν ήδη χτίσει πάνω σε αυτή την παραδοχή, η καθεμία χωρίς να το ξέρει η άλλη.
Μετά έρχεται μια πεζή αλλά απαραίτητη δουλειά: να μάθετε πώς φτάνουν πραγματικά τα δεδομένα. Τα συστήματα των μεγάλων εταιρειών σπάνια έχουν το καθαρό REST API που υπέθετε η πρόταση. Αυτό που υπάρχει είναι ένα SOAP endpoint τεκμηριωμένο το 2011, ένα νυχτερινό CSV σε έναν server SFTP, μια όψη της βάσης μόνο για ανάγνωση πίσω από VPN, μια ουρά μηνυμάτων που κανείς δεν έχει επανεκκινήσει εδώ και χρόνια, ή ένας προμηθευτής που ευχαρίστως θα φτιάξει API με αμοιβή και αναμονή εννέα μηνών. Δεν έχει νόημα να παραπονιέστε γι' αυτό. Είναι δεδομένο που ο σχεδιασμός πρέπει να λάβει υπόψη, και πρέπει να το ξέρετε την πρώτη εβδομάδα, όχι την ένατη.
Αυτό που προστατεύει το νέο σύστημα είναι ένα ενδιάμεσο επίπεδο που «μεταφράζει» τα δεδομένα, και η πειθαρχία να μείνει αυτό το επίπεδο μικρό αλλά να μην αφήνει τίποτα απ' έξω. Ο τρόπος που το ERP οργανώνει τα δεδομένα του δεν περνά μέσα στην εφαρμογή. Τα ονόματα των πεδίων του, οι κωδικοί του, η αντίληψή του για το τι είναι πελάτης, η συνήθειά του να επιστρέφει κενό κείμενο αντί για αριθμό που λείπει: όλα μετατρέπονται στο σημείο εισόδου σε μια δομή γραμμένη για το προϊόν, αποθηκευμένη σε PostgreSQL, που ανήκει στο νέο σύστημα. Αν παραλείψετε αυτό το επίπεδο, η διασύνδεση δεν μένει ένα κομμάτι του συστήματος. Γίνεται το ίδιο το σύστημα. Πέντε χρόνια μετά, κανείς δεν μπορεί να αλλάξει μια οθόνη χωρίς να καταλαβαίνει ένα module του ERP.
Για τον συγχρονισμό υπάρχουν δύο σωστοί τρόποι και ένας που απλώς μοιάζει σωστός. Batch, όπου ένα πρόγραμμα τραβά και συμφωνεί τα δεδομένα σε τακτά διαστήματα: απλό, προβλέψιμο και πάντα λίγο πίσω. Με γεγονότα (event-driven), όπου η πηγή δημοσιεύει τις αλλαγές και το νέο σύστημα αντιδρά: πάντα ενημερωμένο, αλλά μόνο αν η πηγή μπορεί να δημοσιεύει τις αλλαγές της. Ο τρίτος τρόπος, που μόνο μοιάζει σωστός, είναι να καλείτε το ERP ζωντανά σε κάθε φόρτωμα σελίδας. Μοιάζει με πραγματικό χρόνο, μέχρι το ERP να έχει ένα αργό απόγευμα και να ρίξει μαζί του και το προϊόν σας. Ό,τι κι αν διαλέξετε, τρία πράγματα δεν είναι προαιρετικά. Εγγραφές που δεν διπλασιάζονται όταν επαναληφθούν (idempotent), γιατί το ίδιο μήνυμα θα έρθει δύο φορές. Πολιτική επανάληψης με ουρά για τα μηνύματα που αποτυγχάνουν (dead letter queue), γιατί θα αποτύχει. Και μια αναφορά συμφωνίας που τη διαβάζει άνθρωπος, γιατί η σιωπηλή απόκλιση είναι η αποτυχία που κανείς δεν εντοπίζει για μήνες.
Σχεδιάστε για την περίπτωση που η πηγή δεν είναι διαθέσιμη, γιατί θα συμβεί. Η σωστή συμπεριφορά δεν είναι σχεδόν ποτέ μια οθόνη σφάλματος. Μια παραγγελία που γίνεται όσο το ERP είναι εκτός πρέπει να μπαίνει σε ουρά, να φαίνεται καθαρά ως εκκρεμής και να ολοκληρώνεται όταν επιστρέψει η σύνδεση. Μια τιμή που δεν ανανεώνεται πρέπει να εμφανίζεται μαζί με ένδειξη για το πόσο παλιά είναι, όχι να κρύβεται. Το πώς δουλεύει το σύστημα με μειωμένες δυνατότητες, ώστε ο χρήστης να καταλαβαίνει τι συμβαίνει, είναι απόφαση που παίρνεται από πριν. Αυτή ξεχωρίζει ένα σύστημα που οι άνθρωποι συνεχίζουν να χρησιμοποιούν κατά τη διάρκεια μιας διακοπής από ένα που σταματούν να εμπιστεύονται μετά.
Στην Ελλάδα υπάρχει ένα ακόμη επίπεδο που δεν είναι προαιρετικό και συνήθως υποτιμάται. Η διαβίβαση στο myDATA και οι κανόνες τιμολόγησης. Οι διασυνδέσεις με courier, με τις δικές τους μορφές και τους δικούς τους τρόπους να αποτυγχάνουν. Οι απαιτήσεις των τραπεζών και των παρόχων πληρωμών. Τα feeds για marketplaces. Στις νοικιασμένες πλατφόρμες, το καθένα από αυτά είναι ένα plugin με συνδρομή και έναν ιδιοκτήτη που μπορεί να χάσει το ενδιαφέρον του. Σε ένα custom σύστημα είναι κώδικας που σας ανήκει. Αυτό σημαίνει περισσότερη δουλειά στην αρχή, και είναι ο λόγος που το λειτουργικό κόστος σταματά να μεγαλώνει τον τρίτο χρόνο.
Το τελευταίο δεν είναι καθόλου τεχνικό, και είναι αυτό που μετακινεί τα χρονοδιαγράμματα. Η δουλειά της διασύνδεσης εξαρτάται από άλλες ομάδες: κωδικούς πρόσβασης, ένα δοκιμαστικό περιβάλλον που μοιάζει με την παραγωγή, αυξημένα όρια αιτημάτων, έναν λογαριασμό VPN, την έγκριση ενός υπευθύνου συστήματος που έχει εννέα άλλες προτεραιότητες. Βάλτε τα στο πλάνο ως ονομαστικές εξαρτήσεις, με ημερομηνίες και υπεύθυνους από την πλευρά του πελάτη. Το πιο αργό κομμάτι ενός έργου διασύνδεσης δεν είναι σχεδόν ποτέ ο κώδικας.
Common questions
- Γιατί οι διασυνδέσεις με ERP αργούν περισσότερο απ' ό,τι περιμένουμε;
- Γιατί η καθυστέρηση σπάνια βρίσκεται στον κώδικα. Βρίσκεται στο να βρεθούν κωδικοί πρόσβασης και ένα δοκιμαστικό περιβάλλον που δουλεύει, στο να ανακαλύψετε ότι η διαθέσιμη διεπαφή είναι ένα νυχτερινό αρχείο ή μια παλιά υπηρεσία SOAP και όχι API, και στο να ξεκαθαρίσει ποιο σύστημα έχει κάθε πεδίο. Αυτές είναι οργανωτικές εξαρτήσεις με άλλους υπεύθυνους, και πρέπει να μπαίνουν στο πλάνο με ονόματα και ημερομηνίες, όχι να θεωρούνται δεδομένες.
- Πρέπει ένα app να καλεί απευθείας το ERP;
- Όχι. Οι κλήσεις πρέπει να περνούν από ένα επίπεδο μετάφρασης, που μετατρέπει το μοντέλο του ERP σε μια δομή που ανήκει στο νέο σύστημα και αποθηκεύεται στη δική του βάση. Έτσι το προϊόν μένει χρήσιμο όταν η πηγή είναι αργή ή εκτός, το παλιό μοντέλο δεδομένων δεν απλώνεται μέσα στην εφαρμογή, και το ERP μπορεί κάποτε να αντικατασταθεί χωρίς να ξαναγραφτεί το προϊόν.
- Συγχρονισμός batch ή με γεγονότα (event-driven);
- Batch όταν η πηγή δεν μπορεί να δημοσιεύει γεγονότα και λίγα λεπτά καθυστέρηση είναι αποδεκτά. Είναι πιο απλό και πιο προβλέψιμο. Με γεγονότα όταν η πηγή το υποστηρίζει και η επιχείρηση χρειάζεται πραγματικά τρέχοντα δεδομένα, όπως το απόθεμα σε μια προσφορά. Και τα δύο απαιτούν εγγραφές idempotent, πολιτική επανάληψης με dead letter queue, και μια αναφορά συμφωνίας που τη διαβάζει πραγματικά κάποιος.
- Τι πρέπει να γίνεται όταν το ERP δεν είναι διαθέσιμο;
- Το προϊόν πρέπει να συνεχίζει να δουλεύει με περιορισμούς που φαίνονται, όχι να σταματά. Οι παραγγελίες μπαίνουν σε ουρά και σημειώνονται ως εκκρεμείς, οι τιμές εμφανίζονται με ένδειξη για το πόσο παλιές είναι, και το σύστημα ολοκληρώνει τις εκκρεμότητες μόνο του όταν επιστρέψει η σύνδεση. Αυτή η συμπεριφορά ορίζεται στον σχεδιασμό, δεν αυτοσχεδιάζεται στην πρώτη διακοπή.
The service behind it
Custom Web Development
Κατασκευή ιστοσελίδων στην Αθήνα με custom web development: μοναδικά, πολύ γρήγορα websites, γραμμένα από το μηδέν σε React και Next.js για το brand στο οποίο ανήκουν. Χωρίς templates.