Με αφορμή διάφορες συζητήσεις που έγιναν στο forum της τελευταίες μέρες μου δημιουργήθηκε πάλι η επιθυμία να γράψω έναν οδηγό. Τους τελευταίους μήνες απέκτησα μεγάλη εμπειρία στο σχεδιασμό ενός συστήματος enterprise resource planning (ERP) ή όπως μεταφράζεται στα ελληνικά ενός συστήματος επιχειρησιακού σχεδιασμού (θα δημοσιεύσω τον κώδικα υπό κάποια ελεύθερη άδεια λείαν συντόμως). Ο λόγος που ξεκίνησα να γράφω ένα τέτοιο σύστημα από την αρχή είναι η αδυναμία μου να προσαρμόσω τα υπάρχοντα συστήματα στις ανάγκες μου. Τα συστήματα ERP είναι πολύπλοκα. Ξεκίνησα σχεδιάζοντας κάτι απλό, αλλά τελικά συνειδητοποίησα ότι η πολυπλοκότητα είναι απαραίτητη. Τελικά έμαθα πάρα πολλά στο ταξίδι αυτό.
Τι είναι, καταρχήν, ένα σύστημα επιχειρησιακού σχεδιασμού;
Αναλοίωντας τις λέξεις μία μία έχουμε ένα σύστημα, δηλαδή δεν είναι απλώς ένα πρόγραμμα, αλλά μια οικογένεια προγραμμάτων που έχουν ως στόχο τον επιχειρησιακό σχεδιασμό. Επιχειρησιακός δηλώνει οτιδήποτε έχει να κάνει με την επιχείρηση, δηλαδή πελάτες, προμηθευτές, μεταφορείς, ανθρώπινο δυναμικό, πρώτες ύλες, προϊόντα, προσφορές και παραγγελίες, κ.ο.κ. Στα αγγλικά υπάρχει και ο όρος πόρος (resource) ο οποίος δηλώνει ακριβώς τους πόρους, οι οποίοι μπορούν να διαχειριστούν. Τέλος, υπάρχει η έννοια του σχεδιασμού, που σημαίνει καταγραφή, έλεγχος, πρόβλεψη, με στόχο τη βελτιστοποίηση (οικονομική ή χρονική).
Ένα τέτοιο σύστημα θα πρέπει να είναι προσβάσιμο από όλα τα μέλη της επιχείρησης άρα το σύστημα θα πρέπει να λειτουργεί σε τοπικό δίκτυο. Φυσικά κάποιος θα μπορούσε να σχεδιάσει μια client-server αρχιτεκτονική που θα βασίζεται στο πρωτόκολλο TCP-IP με κλασικό GUI για το client, όπως είναι πολλά συστήματα ERP. Κατά τη γνώμη κάτι τέτοιο είναι περιττό αφού υπάρχουν ήδη πολλά clients που μπορούν να κάνουν αυτή τη δουλειά (μιλάω για τους browsers). Για τη δημιουργία του GUI μπορούμε να χρησιμοποιήσουμε HTML, CSS και Javascript. Αυτό σημαίνει ότι ο server θα είναι ένας τυπικός web server. Επειδή όμως αναφέρθηκα σε σύστημα, μπορεί να υπάρχουν πολλοί web servers, οπότε χρειάζονται και scripts που τρέχουν στο server για να ανταλλάσουν πληροφορίες μεταξύ των διαφόρων βάσεων δεδομένων. Και μιας και μίλησα για βάσεις δεδομένων χρειαζόμαστε φυσικά και βάσεις δεδομένων για να αποθηκεύουμε τις πληροφορίες. Χρειαζόμαστε; Θεωρητικά θα μπορούσε να γίνει η δουλειά μας με απλά αρχεία ή XML ή ό,τι άλλο μπορεί να αποθηκευτει στον υπολογιστή. Γιατί να έχουμε πολλούς web server; Γιατί μπορεί ο ένας να είναι υπεύθυνος για τη διαχείρισης της αποθήκης, ενώ ο άλλος για τη διαχείρησης των online παραγγελιών οι οποίες εκτελούνται αυτόματα από την ιστοσελίδα, ενώ το σύστημα που χρησιμοποιούν οι πωλήτες να είναι διαφορετικό.
Πολύ ωραία. Τώρα χρειαζόμαστε μια δομή για τη βάση δεδομένων. Θα χρειαστούμε σίγουρα έναν πίνακα για τους πελάτες, έναν για τους προμηθευτές, για τα προϊόντα, για τους υπαλλήλους (με τους λογαριασμούς τους στο σύστημα), για τις παραγγελίες. Αρχίζοντας έχουμε 5 πίνακες. Προχωρώντας στο σχεδιασμό συνειδητοποιούμε ότι χρειαζόμαστε επαφές, κατηγορίες, λεπτομέριες προϊόντων, προσφορές, αλλά και προσθήκες ή αλλαγές στις στήλες των προηγούμενων πινάκων. Άρα χρειαζόμαστε ένα αρκετά αυτοματοποιημένο σύστημα για το λεγόμενο migration της βάσης δεδομένων μας.
Αλλά τα πράγματα δεν είναι τόσο απλά. Μόνο σε επιχειρήσεις που κάνουν καθαρό εμπόριο μια πρωτή ύλη είναι και το προϊόν που πωλείται στον αγοραστή. Οι μεταποιητικές επιχειρήσεις αγοράζουν φύλλα λαμαρίνας και δημιουργούν μορφοποιημένους δοκούς, αγοράζουν σιτάρι και καλαμπόκι και πουλούν αλεύρι και διάφορα άλλα. Αυτό σημαίνει ότι στο σύστημα πρέπει να υπάρχει τρόπος μεταποίησης των πρώτων υλών. Και όχι μόνο αυτό. Ένα μηχάνημα είναι ένα προϊόν, αποτελούμενο από διάφορα άλλα προϊόντα (μέρη). Ο πελάτης μπορεί να αγοράσει το μηχάνημα, αλλά και κάποιο μέρος ως ανταλλακτικό. Άρα χρειαζόμαστε και κατάσταση υλικών (BOM: bill of materials), έναν ακόμη πίνακα δηλαδή που θα αποθηκεύει αυτή την πληροφορία.
Και για να πάω ακόμη παραπέρα, ο πωλητής εισάγει μια παραγγελία, ενημερώνεται από το σύστημα ο υπεύθυνος της παραγωγής ή της αποθήκης, αλλά ξαφνικά ο πελάτης ενημερώνει τον πωλητή ότι θέλει κάτι ελαφρώς διαφορετικό. Άρα η παραγγελία πρέπει να τροποποιηθεί. Αυτό σημαίνει ότι οι αλλαγές πρέπει να αποθηκεύονται επίσης στο σύστημα (ένας ακόμη πίνακας).
Αλλά ένα ERP δεν είναι μόνο αυτά. Είναι πρόβλεψη αποθεμάτων και προγραμματισμός παραγωγής. Τι σημαίνει αυτό; Ότι με βάση τις πωλήσεις των τελευταίων 11 μηνών να μπορώ να προβλέψω την κατανάλωση το 12ο μήνα ώστε να ελαχιστοποιήσω το κόστος αποθήκευσης, να πετύχω καλύτερη τιμή με μαζική παραγγελία και χίλια δυο άλλα πράγματα. ERP επίσης σημαίνει να χρησιμοποιήσω τεχνικής γραμμικού προγραμματισμού ώστε να μειώσω το κόστος των μεταφορικών από το κέντρο παραγωγής στα κέντρα κατανάλωσης. Σημαίνει επίσης, σε μία γραμμή αναμονής, πχ. φόρτωση φορτηγών, τη ελαχιστοποίηση του κόστους λόγω αναμονής των φορτηγών για φόρτωση με βάση τις πιθανότητες του χρόνου αναμονής.
Και ακόμη δεν απαντήσαμε το καίριο ερώτημα: πόσο κοστίζει ένα προϊόν που παράγουμε; Είναι το σύνολο των πρώτων υλών συν των εργατωωρών; Τότε το λογισμικό θα έπρεπε να ήταν πολυ πιο ακριβό απ'ότι είναι τώρα. Μήπως είναι μόνο των πρώτων υλών; Τότε το λογισμικό θα πρέπει να κοστίζει ελάχιστα και οι προγραμματιστές να αρχίσουν να λιμοκτονούν (μη αρχίσετε κάποιο flame war, δεν είναι αυτός ο στόχος του άρθρου τούτου). Απλά, κι αυτή είναι μια ερώτηση για την οποία ένα σύστημα ERP πρέπει να προσφέρει τουλάχιστον προτάσεις.
Όπως καταλαβένετε η δημιουργία ένος τέτοιου συστήματος εμπλέκει μια πληθώρα ειδικοτήτων, από προγραμματιστές φυσικά, μηχανικούς (για την παροχή γνώσεων σχετικά με διαχείριση της παραγωγής, αποθεμάτων, κλπ) αλλά και οικονομολόγους (και δεν ασχολήθηκα καθόλου με το φοροτεχνικό κομμάτι).
Τώρα ίσως είναι η στιγμή να περάσω στις τεχνικές λεπτομέριες. Καταρχήν, αποφάσισα να χρησιμοποιήσω τη γλώσσα προγραμματισμού ruby, αλλά εν τέλει έμπλεξα πολλές γλώσσες γιατί ένα πρωτότυπο για την πρόβλεψη των αποθεμάτων, ελαχιστοποίηση του κόστους των μεταφορικών, και της γραμμής αναμονής το είχα γράψει παλιότερα σε python (με ένα system call σε octave). Για το HTML GUI πολύ λίγη Javascript, η οποία στο μέλλον να αυξηθει ώστε να γίνει το πρόγραμμα πιο φιλικό προς το χρήστη. Για τη βάση δεδομένων διάλεξα τη MySQL, μιας και είναι ένα αρκετά αποδεκτή παγκοσμίως. Ως web server διάλεξα τον apache για τον ίδιο λόγο. Αντίστοιχα τα web frameworks είναι rails και django, με τη χρήση του phusion passenger και mod_wsgi για την επικοινωνία της ruby/python με τον apache. Έτσι έχουμε ruby on rails, python and django, javascript, octave, MySQL, Apache, phusion passenger, και mod_wsgi.
Και ακόμη είμαστε στην αρχή. Ένα τέτοιο μεγαλεπίβολο project, ακόμη κι αν δουλεύει ένα άτομο μόνο, χρειάζεται reversion control, χρησιμοποιώ το git (τοπικό αποθετήριο), και bug tracking, χρησιμοποιώ το trac. Τα συστήματα αυτά αν και παλιότερα τα θεωρούσα λιγο-πολύ περιττά, αποδεικνύονται άκρως απαραίτητα και χρήσιμα. Γιατί μπορείς να έχεις ανά πάσα στιγμή όλες τις εκδόσεις του κώδικα διαθέσιμες, ώστε να μπορείς να πειραματίζεσαι άνετα χωρίς να φοβάσαι να χαλάσεις το build. Το bug tracking είναι επίσης σημαντικό γιατί ξέρεις πάνω σε τι έχεις να δουλέψεις και δε χρειάζεται να τα θυμάσαι όλα, αφήνωντας έτσι χώρο για τα σημαντικά.
Άλλα μικρότερα κομμάτια είναι η δημιουργία αναφορών ως pdf (με τη βοήθεια της βιβλιοθήκης prawn) και η δημιουργία γραφημάτων (ακόμη δεν έχω αποφασίσει ποια βιβλιοθήκη θα χρησιμοποιήσω. Βασικά η απόφαση είναι δύσκολη, γιατί υπάρχουν server-based λύσεις και client-based λύσεις με javascript.)
Αυτά προς το παρόν. Φυσικά όλα στα ελληνικά. Μην περιμένετε όμως πολλά από αισθητική. Και δυστυχώς δεν υπάρχει (ακόμη) ένα script εγκατάστασης. Και όπως υποσχέθηκα στην αρχή ο κώδικας θα είναι διαθέσιμος λίαν συντόμως, μετά τις 4 Νοεμβρίου αλλά πριν το τέλος του χρόνου.
ΥΓ. Και σαν bonus θα δημοσιεύσω και ένα απλό σύστημα για online shop.



