L'éternelle question de savoir s'il faut acheter ou construire son logiciel (James Monaghan)

Toutes nos félicitations. Vous avez un problème, un projet, un budget et un délai. Au lieu de jeter des corps dessus, le logiciel est la solution mais maintenant il faut décider de construire ou d'acheter, telle est la question. Ou est-ce? Je ne suis plus sûr que ce soit une décision claire.
Construire l'utilisation pour faire référence à l'embauche de programmeurs internes pour coder tout système nécessaire et acheter en référence aux produits disponibles dans le commerce qui pourraient être achetés et exécutés. Cela avait du sens lorsque nous parlions de systèmes comptables, de systèmes de trading, de CRM, de reporting,
Prêts, collections, CLM, etc. Nous vivons désormais dans un environnement low code où construire quelque chose ne nécessite pas d'expérience en codage. Cela peut être un glisser-déposer. Ajoutez à cela l'achat de solutions prêtes à l'emploi qui finissent par être si personnalisées que vous pourriez aussi bien
nous l'avons bien construit. Alors, où cela nous amène-t-il pour prendre la décision de construire ou d’acheter ? Regardons ce dont nous avons réellement besoin.

Aucun système moderne ne peut plus compter sur un point d’entrée unique. Les attentes des clients exigent que différents canaux soient nécessaires. En personne, par téléphone directement ou via un centre d'appels, par e-mail, sur les réseaux sociaux, par SMS, sur le Web, sur mobile, sur tablette – à la fois mobiles et natifs
applications, toutes devant être interchangeables sans perdre de contenu ou de contexte. Un client qui commence en succursale/magasin ou en personne mais qui doit partir pour un rendez-vous souhaite pouvoir reprendre là où il s'est arrêté lorsqu'il se connecte en ligne plus tard dans la journée. Ou
s'ils démarrent en ligne mais sont frustrés et appellent à l'aide, ils ne veulent pas avoir à recommencer le processus depuis le début. Cela s’applique également aux parties prenantes internes. La chaîne d'information au sein d'une organisation doit être aussi flexible que la face-client
options. 

Alors, quelle est la prochaine étape pour nos entrées de données « commencer n'importe où » ? Eh bien, il y a une raison pour laquelle nous avons besoin de ces données en premier lieu. Qu'un nouveau client souhaite travailler avec l'organisation, qu'un client existant souhaite un nouveau produit ou service, ou même simplement des requêtes ou des plaintes quotidiennes.
ou des demandes d'informations. Tous ces éléments doivent lancer des processus définis mais flexibles pour répondre à la demande aussi efficacement et facilement que possible. Le processus est généralement défini et le personnel est généralement formé pour suivre une séquence de tâches afin de l'accomplir avec des délais prédéterminés.
actions basées sur certaines entrées de données. 

Ni les clients finaux ni les utilisateurs du système ne devraient avoir à ressaisir les informations si elles ont déjà été capturées quelque part. En fait, si les informations sont disponibles n'importe où au sein de l'organisation ou auprès de sources tierces telles que des fournisseurs de données, des agences d'évaluation du crédit,
prestataires de dépistage, etc., il doit être accessible tout au long du processus pour tous les utilisateurs qui en ont besoin. Le processus est défini mais les points de contact doivent être interchangeables tout au long et les données collectées doivent être intégrées lorsque cela est possible et structurées lorsque cela est possible.
Menus déroulants, valeurs de recherche, champs de date et valeurs de texte libre contrôlées pour garantir une capture optimale de la qualité des données dès le départ. Cela permet beaucoup plus d'automatisation tout au long du processus et moins de gestion des exceptions.

Maintenant que les données sont en train d’être activement capturées ou mises à jour, l’intelligence artificielle peut être appliquée. Le personnel n'a pas besoin de connaître tous les détails et même les nouveaux membres peuvent travailler sur des cas plus complexes car le système utilise des règles codées.
logique pour prendre automatiquement des décisions que le personnel devait auparavant avoir une formation et une expérience approfondies pour gérer. Fini les erreurs tout en permettant une surveillance et même des contrôles de qualité ou des files d'attente d'exceptions pour une intervention manuelle si nécessaire.

Tout cela nécessite une approche systématique. La vieille idée d’un dossier en papier manille placé dans le tiroir d’un membre du personnel pour son portefeuille de clients est dépassée et crée un risque inutile. Les clients traités de manière isolée peuvent être à la fois limitatifs et redondants
en même temps. Si une entreprise cliente a des administrateurs qui siègent chez plusieurs autres clients, pourquoi chaque avis individuel ignorerait-il la situation dans son ensemble. Allez-vous également revoir le même réalisateur plusieurs fois au cours de chaque relation ou pourriez-vous
le faire une fois et réutiliser ces informations dans toute l'organisation ?

Il n’est même pas nécessaire qu’ils aient des parties liées communes pour que les avantages soient apparents. Industries similaires, clients clients similaires, et si vos clients vendeurs/fournisseurs étaient également des clients eux-mêmes ? Cela nous amène à la manière dont vous devez traiter les informations
et pourquoi les organisations doivent aujourd'hui s'intéresser à l'ensemble de l'entreprise lorsqu'elles envisagent des logiciels. Si vous envisagez un problème isolément et le traitez comme tel, en établissant des budgets et en émettant des appels d'offres pour chaque composant CRM, Fincrime et Customer Outreach, vous finirez par
en dépensant plus de ressources pour essayer de tout intégrer ensemble que les économies potentielles initialement espérées. Appliquez maintenant cela à chaque région ou secteur d'activité susceptible de bénéficier de budgets et d'une surveillance distincts et vous obtiendrez 8 versions.
du même logiciel qui doit être intégré à lui-même en raison d'une forte personnalisation par domaine, éliminant toute économie d'échelle qu'ils pourraient réaliser.

Un dossier dans un tiroir qui doit être révisé chaque année ou autrement, le personnel devant être formé sur ce qu'il faut faire et quand le faire. L'ensemble de l'examen (ou l'intégration d'un nouveau produit/service supplémentaire/etc.) peut être décomposé en parties composites qui peuvent ou
ne peut pas être géré par d’autres personnes/équipes. Le système peut alors déterminer quand une tâche est terminée ou quand suffisamment de données sont capturées pour être envoyées à la personne suivante pour saisie. Tous ces éléments sont structurés en cas et sous-cas. De cette façon, chaque élément de
le dossier peut avoir son propre délai, sa propre voie d'escalade, son cessionnaire et ses approbateurs. Au lieu d'une tâche de grande envergure qu'un membre du personnel doit être suffisamment expérimenté pour savoir comment l'accomplir et à qui s'adresser pour les différents éléments, le système attribue désormais le travail
et garantit son achèvement dans les délais dans l'ensemble de l'entreprise avec autant de tâches automatisées que possible pour permettre aux décideurs de se concentrer sur ce qui est important.

Tout cela est bien beau d’un point de vue commercial. Le travail est connu et ce qui doit être fait. Mais lorsque nous essayons de décider si nous devons acheter ou créer le logiciel nous-mêmes, comment cela entre-t-il en compte ? Eh bien, supposons qu'il existe plusieurs sources
de données sur plusieurs systèmes. Tout système moderne devrait être piloté par API et avoir des capacités low code/no code. Une hypothèse raisonnable pour un logiciel plus rapide et flexible. De nos jours, tout doit être traité comme une sorte de microservice pour éviter
les monolithes logiciels à l’ancienne. Le logiciel doit être installé et utilisé car il s’agit du meilleur disponible et évolutif pour s’adapter aux changements selon les besoins. Trop d'offres sont ancrées et maintenues uniquement parce qu'elles sont trop difficiles et prennent trop de temps.
remplacer. Cela est dû en grande partie au fait que les règles sont codées en dur, probablement liées aux données elles-mêmes, que les données sont non seulement intégrées mais répliquées plusieurs fois pour chaque élément logiciel distinct de la chaîne d'information et que si vous essayez de remplacer un élément, le
tout le système pourrait tomber en panne. Trop de vieux processus de pensée, s'il n'est pas brisé, ne le réparez pas. Ce qu'il faut vraiment, c'est que tous ces composants soient des microservices, prenant les données nécessaires, appliquant des règles automatisées ou des entrées/avis des utilisateurs et
en le transmettant au microservice suivant. Les données ne doivent pas être stockées à plus d’un endroit. Il peut être fédéré mais non répliqué en dehors des sauvegardes. Vos systèmes CRM, d'intégration, KYC, de sensibilisation des clients, etc. ne doivent accéder qu'aux données dont ils ont besoin et non
être eux-mêmes des référentiels de données, à moins que vous n’en ayez choisi un. Répliquer les mêmes données sur plusieurs emplacements et les règles qui les régissent est un exercice futile, car chaque système supplémentaire ajouté multipliera les complexités impliquées.

Cela nous amène à la considération finale. Que vous disposiez d'une seule source de vérité/Golden Copy ou de plusieurs enregistrements et systèmes redondants et concurrents capables de les mettre à jour, vous vous retrouverez toujours dans un autre niveau d'exigences basé sur la ligne de
entreprise, juridiction, types de clients et produits/services. Un individu est traité différemment d'une entreprise ou d'une fiducie et diffère selon les secteurs d'activité de consommation/de détail, commerciaux ou d'entreprise en termes d'exigences et d'adéquation. Au plus élémentaire des exemples si
nous avons 10 types de clients (particulier – célibataire, marié, etc., entreprise privée, entreprise publique, fiducie, organisme de bienfaisance, etc.) et vous pouvez opérer dans 10 régions, et vous pouvez proposer 10 types de produits/services, nous y sommes déjà potentiellement plus de 1000 règles qui pourraient
sois appliqué. Ne serait-il pas tellement plus simple de définir des règles pour une région, pour un secteur d'activité, pour un type de client et des produits ou services et de laisser le système résoudre les exigences à la place ? Suppression des doublons et réutilisation des points de données précédemment
fourni. C'est l'avantage d'abstraire votre processus et vos règles de votre couche de données. 

Alors maintenant, lorsque nous examinons la vieille question de l'achat ou de la création de logiciels, nous savons que nous avons besoin d'une orchestration omnicanal, d'une automatisation des processus lorsque cela est possible, d'une logique de règles flexibles, d'une gestion de cas pour la surveillance et l'auditabilité, d'un low code et d'une API, d'un résumé.
couche de données et un moteur de règles intelligent qui peut hériter de différentes couches logiques. Le marché de la technologie regorge d'innovateurs qui sont heureux de répondre à tous les problèmes de niche auxquels on peut penser, mais à quel moment cela n'a-t-il plus de sens d'avoir du « prêt à l'emploi »
des produits qui doivent tous être personnalisés et intégrés les uns aux autres au lieu de les construire vous-même. Les plates-formes low code peuvent vous permettre de disposer de 80 % de vos besoins et il vous suffit de configurer ce delta de 20 %. Le meilleur des deux mondes est un faible
plate-forme de code pour laquelle d'autres ont également construit des composants réutilisables afin que vous puissiez obtenir des produits « prêts à l'emploi » comme accélérateurs pour votre entreprise tout en donnant la possibilité à votre personnel ou à des tiers certifiés de créer le reste des exigences spécifiques.
à votre organisation. Acheter ou construire ? Il faudrait vraiment que ce soit les deux.