Το αιώνιο ερώτημα για το αν θα αγοράσετε ή θα δημιουργήσετε το λογισμικό σας (James Monaghan)

Συγχαρητήρια. Έχεις πρόβλημα, έργο, προϋπολογισμό και προθεσμία. Αντί να πετάτε σώματα, το λογισμικό είναι η λύση, αλλά τώρα πρέπει να αποφασίσετε να κατασκευάσετε ή να αγοράσετε, αυτό είναι το ζητούμενο. Ή μήπως είναι? Δεν είμαι πια τόσο σίγουρος ότι είναι μια ξεκάθαρη απόφαση.
Χρησιμοποιήστε το Build για να αναφέρεται στην πρόσληψη προγραμματιστών στο σπίτι για να κωδικοποιήσουν οποιοδήποτε σύστημα ήταν απαραίτητο και να αγοράσετε αναφερόταν στα προϊόντα εκτός ραφιού που θα μπορούσαν να αγοραστούν και να εκτελεστούν. Αυτό είχε νόημα όταν μιλούσαμε για λογιστικά συστήματα, συστήματα συναλλαγών, CRM, αναφορές,
Δανεισμός, Συλλογές, CLM κ.λπ. Τώρα ζούμε στο περιβάλλον χαμηλού κώδικα όπου η κατασκευή κάτι δεν απαιτεί εμπειρία κωδικοποίησης. Μπορεί να γίνει μεταφορά και απόθεση. Συνδυάστε το με την αγορά των λύσεων στο ράφι που καταλήγουν να είναι τόσο προσαρμοσμένες ώστε να μπορείτε να το κάνετε
καλά το έχτισαν. Πού μας αφήνει λοιπόν αυτό να πάρουμε την απόφαση να κατασκευάσουμε ή να αγοράσουμε; Ας δούμε τι πραγματικά χρειαζόμαστε.

Κανένα σύγχρονο σύστημα δεν μπορεί πλέον να βασίζεται σε ένα μόνο σημείο εισόδου. Οι προσδοκίες των πελατών υπαγορεύουν ότι είναι απαραίτητα διάφορα κανάλια. Αυτοπροσώπως, απευθείας τηλεφωνικά ή τηλεφωνικό κέντρο, email, μέσα κοινωνικής δικτύωσης, SMS, web, κινητό, tablet – με δυνατότητα κινητού και εγγενή
εφαρμογές, όλα με την ανάγκη να είναι εναλλάξιμα χωρίς να χάνεται περιεχόμενο ή περιβάλλον. Ένας πελάτης που ξεκινά από υποκατάστημα/κατάστημα ή αυτοπροσώπως αλλά πρέπει να φύγει για ένα ραντεβού θέλει να μπορεί να συνεχίσει από εκεί που σταμάτησε όταν συνδεθεί αργότερα εκείνη την ημέρα στο διαδίκτυο. Ή
αν ξεκινήσουν διαδικτυακά αλλά απογοητευτούν και ζητήσουν βοήθεια, δεν θέλουν να ξεκινήσουν τη διαδικασία από την αρχή. Αυτό ισχύει και για εσωτερικά ενδιαφερόμενα μέρη. Η αλυσίδα πληροφοριών μέσα σε έναν οργανισμό πρέπει να είναι τόσο ευέλικτη όσο και ο πελάτης
επιλογές. 

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

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

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

Όλα αυτά απαιτούν συστηματική προσέγγιση. Η παλιά ιδέα ενός φακέλου manilla που βρίσκεται σε ένα συρτάρι μελών του προσωπικού για το χαρτοφυλάκιο πελατών τους είναι ξεπερασμένη και δημιουργεί έναν περιττό κίνδυνο. Οι πελάτες που υποβάλλονται σε επεξεργασία μεμονωμένα μπορεί να είναι περιοριστικοί και περιττοί
Την ίδια στιγμή. Εάν ένας εταιρικός πελάτης έχει διευθυντές που βρίσκονται σε πολλούς άλλους πελάτες, γιατί κάθε μεμονωμένη κριτική αγνοεί τη μεγαλύτερη εικόνα. Θα αναθεωρήσετε επίσης τον ίδιο σκηνοθέτη πολλές φορές σε κάθε σχέση ή θα μπορούσατε
να το κάνετε μία φορά και να επαναχρησιμοποιήσετε αυτές τις πληροφορίες σε ολόκληρο τον οργανισμό;

Δεν χρειάζεται καν να έχουν κοινά συνδεδεμένα μέρη για να είναι εμφανές το όφελος. Παρόμοιοι κλάδοι, παρόμοιοι πελάτες-πελάτες, τι θα συμβεί αν οι πωλητές/προμηθευτές των πελατών σας είναι και οι ίδιοι πελάτες; Αυτό μας οδηγεί στο πώς πρέπει να επεξεργαστείτε τις πληροφορίες
και γιατί οι οργανισμοί πρέπει να κοιτάζουν σε όλη την επιχείρηση όταν εξετάζουν το λογισμικό αυτές τις μέρες. Εάν δείτε ένα πρόβλημα μεμονωμένα και το αντιμετωπίσετε ως τέτοιο, καθορίζοντας προϋπολογισμούς και εκδίδοντας RFP για κάθε στοιχείο CRM, Fincrime, Client Outreach, θα καταλήξετε
με τη δαπάνη περισσότερων πόρων προσπαθώντας να ενσωματωθούν τα πάντα μαζί από οποιαδήποτε πιθανή εξοικονόμηση που αρχικά ελπίζαμε. Εφαρμόστε τώρα αυτό για κάθε περιοχή ή κλάδο επιχείρησης που ενδέχεται να έχει ξεχωριστούς προϋπολογισμούς και επίβλεψη και θα καταλήξετε με 8 εκδόσεις
του ίδιου λογισμικού που πρέπει να ενσωματωθεί με τον εαυτό του λόγω της μεγάλης προσαρμογής ανά περιοχή εξαλείφοντας τυχόν οικονομίες κλίμακας που θα μπορούσαν να επιτύχουν.

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

Όλα αυτά είναι καλά και καλά από επιχειρηματική άποψη. Η δουλειά είναι γνωστή και τι πρέπει να γίνει. Αλλά όταν προσπαθούμε να αποφασίσουμε εάν πρέπει να αγοράσουμε ή να κατασκευάσουμε το λογισμικό μόνοι μας, πώς επηρεάζει αυτό τα πράγματα; Λοιπόν, ας υποθέσουμε ότι υπάρχουν πολλές πηγές
δεδομένων σε πολλαπλά συστήματα. Οποιοδήποτε σύγχρονο σύστημα αναμένεται να βασίζεται σε API και να έχει δυνατότητες χαμηλού κώδικα/χωρίς κώδικα. Μια λογική υπόθεση για ταχύτερο και ευέλικτο λογισμικό. Όλα αυτά τις μέρες πρέπει να αντιμετωπίζονται ως μικροϋπηρεσίες που πρέπει να αποφεύγονται
τους παλιούς μονόλιθους λογισμικού. Το λογισμικό θα πρέπει να εγκατασταθεί και να χρησιμοποιηθεί επειδή είναι το καλύτερο διαθέσιμο και μελλοντικά επαληθευμένο για προσαρμογή στις αλλαγές όπως απαιτείται. Πάρα πολλές προσφορές είναι παγιωμένες και διατηρούνται μόνο επειδή είναι πολύ δύσκολες και χρονοβόρες
αντικαθιστώ. Τα περισσότερα από αυτά είναι επειδή οι κανόνες είναι κωδικοποιημένοι, πιθανώς συνυφασμένοι με τα ίδια τα δεδομένα, τα δεδομένα όχι μόνο ενσωματώνονται αλλά αναπαράγονται πολλές φορές για κάθε ξεχωριστό κομμάτι λογισμικού στην αλυσίδα πληροφοριών και αν προσπαθήσετε να αντικαταστήσετε ένα κομμάτι, το
ολόκληρο το σύστημα μπορεί να σπάσει. Υπερβολικά μεγάλο μέρος της παλιάς διαδικασίας σκέψης, αν δεν έχει σπάσει, μην το διορθώσετε. Αυτό που πραγματικά χρειάζεται είναι όλα αυτά τα εξαρτήματα να είναι μικροϋπηρεσίες, λήψη δεδομένων που χρειάζονται, εφαρμογή αυτοματοποιημένων κανόνων ή εισροών/κριτικών χρηστών και
περνώντας το στην επόμενη microservice. Τα δεδομένα δεν πρέπει να αποθηκεύονται σε περισσότερες από μία τοποθεσίες. Μπορεί να είναι ενοποιημένο αλλά να μην αναπαράγεται εκτός των αντιγράφων ασφαλείας. Τα συστήματα CRM, Onboarding, KYC, Client Outreach κ.λπ. θα πρέπει να έχουν πρόσβαση μόνο στα δεδομένα που χρειάζονται και όχι
να είναι οι ίδιοι αποθετήρια δεδομένων, εκτός και αν έχετε επιλέξει ένα να είναι. Η αναπαραγωγή των ίδιων δεδομένων σε πολλές τοποθεσίες και των κανόνων που τη διέπουν είναι μια ματαιότητα, καθώς κάθε επιπλέον σύστημα που προστίθεται θα πολλαπλασιάζει την πολυπλοκότητα που εμπλέκεται.

Αυτό μας φέρνει στην τελική εξέταση. Είτε έχετε μία μόνο πηγή αλήθειας/Χρυσό αντίγραφο είτε πολλά περιττά και ανταγωνιστικά αρχεία και συστήματα που μπορούν να τα ενημερώσουν, θα εξακολουθείτε να βρίσκεστε σε ένα άλλο επίπεδο απαιτήσεων με βάση τη σειρά
επιχείρηση, δικαιοδοσία, είδη πελατών και προϊόντα/υπηρεσίες. Ένα άτομο αντιμετωπίζεται διαφορετικά από μια εταιρεία ή μια εμπιστοσύνη και διαφέρει ανάλογα με τις επιχειρηματικές δραστηριότητες των καταναλωτών/λιανικών, εμπορικών ή εταιρικών ως προς τις απαιτήσεις και την καταλληλότητα. Στο πιο βασικό από τα παραδείγματα αν
έχουμε 10 τύπους πελατών (ιδιώτες – ανύπαντρος, έγγαμος, κ.λπ., ιδιωτική εταιρεία, δημόσια εταιρεία, καταπίστευμα, φιλανθρωπία κ.λπ.) και μπορείτε να δραστηριοποιηθείτε σε 10 περιοχές και να προσφέρετε 10 τύπους προϊόντων/υπηρεσιών, είμαστε ήδη στο δυνητικά 1000+ κανόνες που θα μπορούσαν
να εφαρμοστεί. Δεν θα ήταν πολύ πιο εύκολο να οριστούν κανόνες για μια περιοχή, για μια επιχειρηματική γραμμή, για έναν τύπο πελάτη και προϊόντα ή υπηρεσίες και αντ' αυτού το σύστημα επιλύει τις απαιτήσεις; Αφαίρεση διπλότυπων και επαναχρησιμοποίηση σημείων δεδομένων που υπήρχαν προηγουμένως
υπό την προϋπόθεση. Αυτό είναι το πλεονέκτημα της αφαίρεσης της διαδικασίας και των κανόνων σας από το επίπεδο δεδομένων σας. 

Έτσι τώρα, όταν εξετάζουμε το παλιό ζήτημα της αγοράς ή κατασκευής λογισμικού, ξέρουμε ότι χρειαζόμαστε ενορχήστρωση όλων των καναλιών, αυτοματοποίηση διεργασιών όπου είναι δυνατόν, ευέλικτη λογική κανόνων, διαχείριση περιπτώσεων για επίβλεψη και δυνατότητα ελέγχου, χαμηλό κώδικα και βάσει API, μια περίληψη
επίπεδο δεδομένων και μια έξυπνη μηχανή κανόνων που μπορεί να κληρονομήσει από διαφορετικά λογικά επίπεδα. Η αγορά τεχνολογίας είναι γεμάτη από καινοτόμους που ικανοποιούν με ευχαρίστηση κάθε εξειδικευμένο πρόβλημα που μπορεί να σκεφτεί κανείς, αλλά σε ποιο σημείο δεν έχει νόημα να έχουμε "εκτός ράφι"
προϊόντα που όλα πρέπει να προσαρμόζονται και να ενσωματώνονται μεταξύ τους αντί να τα κατασκευάζετε μόνοι σας. Οι πλατφόρμες χαμηλού κώδικα μπορούν να σας επιτρέψουν να έχετε διαθέσιμο το 80% των απαιτήσεών σας και χρειάζεται μόνο να διαμορφώσετε αυτό το δέλτα 20%. Το καλύτερο και των δύο κόσμων είναι ένα χαμηλό
πλατφόρμα κωδικών για την οποία άλλοι έχουν κατασκευάσει επίσης επαναχρησιμοποιήσιμα εξαρτήματα, ώστε να μπορείτε να αποκτήσετε τα προϊόντα "από το ράφι" ως επιταχυντές για την επιχείρησή σας, ενώ έχετε επίσης τη δυνατότητα για το προσωπικό σας ή τα πιστοποιημένα τρίτα μέρη να δημιουργήσουν τις υπόλοιπες συγκεκριμένες απαιτήσεις
στον οργανισμό σας. Να αγοράσω ή να χτίσω; Πραγματικά θα έπρεπε να είναι και τα δύο.