Tous vos concurrents peuvent louer le même modèle. Votre avantage est ailleurs.
Matías Bonvin· Mis à jour le
De nombreuses entreprises peuvent acheter le même modèle. La question utile est ce qui vous reste après la première mise en œuvre : données rapprochées, règles métier, connexions testées et équipe capable d’exploiter le processus.
Rendre le contexte de l’entreprise réutilisable
Ontologie est un mot conçu pour perdre l'auditoire, alors voici la version qui survit à un comité de direction. Une ontologie est une carte écrite de votre entreprise. Quelles choses existent, comment elles se relient, et quelles combinaisons sont interdites. Un paiement solde une facture. Cette facture appartient à un fournisseur. Une remise au-dessus d'un seuil exige une signature. Écrivez ces règles avec assez de précision et un logiciel peut les suivre sans vous dans la pièce.
Les modèles diffèrent par leur qualité, leur latence, leur coût et leurs contraintes de déploiement. Un remplacement exige une évaluation. Un contexte et des interfaces portables préservent vos options quand ces arbitrages évoluent.
La qualité des données est une dépendance concrète. Vérifiez le responsable des sources, le rapprochement des identités, les droits et la fréquence des mises à jour avant de confier les enregistrements à un agent.
Vous possédez déjà une ontologie, au passage. Vous la tenez juste très mal.
Un paiement a quitté votre compte mardi et solde une facture. La facture appartient à un fournisseur. Le fournisseur est l'entreprise dont vous écrivez au responsable de compte depuis deux ans. Sauf que le nom est orthographié de trois façons différentes entre votre boîte mail, votre flux bancaire et votre ERP, et que le contrat qui fixe le prix dort dans un fil que quelqu'un devrait aller retrouver. Les liens, c'est vous qui les tenez, dans votre tête. Voilà pourquoi vous savez dire si le paiement était correct et pas votre logiciel.
C'est ici qu'il faut être prudent, parce que deux produits complètement différents se vendent aujourd'hui sous le même mot, et la réputation du moins cher fait la vente du plus cher.
Le premier produit est un dossier de notes. Des documents, des conventions, des décisions, découpés et vectorisés pour qu'un modèle puisse les fouiller. Posez une question et il récupère ce qui ressemble le plus à une réponse. Le second a des entités typées, des contraintes métier, et des règles vérifiées à l'arrivée des données plutôt qu'au moment où quelqu'un demande. Client rattaché à un contrat, commande contenant des pièces, pièces produites sur une machine couverte par le même contrat. Long à construire. Ça survit au contact d'une entreprise qui change.
Un acheteur qui compare des devis n'a aucun moyen de savoir lequel des deux est dans la pièce, parce que le vocabulaire ne l'aide en rien.
Une couche de recherche fournit des éléments de preuve sans garantir l’intégrité des transactions. Éviter un remboursement en double exige autorisation, idempotence et validation dans le système exécutant. Un modèle métier structuré aide, sans remplacer ces contrôles.
Maintenant, la partie du discours commercial qui devrait vous faire ralentir.
L'argumentaire dit ceci. Vos données sont votre avantage durable. Les modèles ne peuvent pas les répliquer. Donc apportez-les-nous, et nous les modéliserons en une ontologie qui reflète le fonctionnement de votre entreprise. Chaque étape est vraie, sauf le donc.
Il saute une couche. Entre "vous possédez des données précieuses" et "donc confiez-les-nous" se trouve le vrai travail : nettoyer, résoudre quel fournisseur du flux bancaire est la même entreprise que celui du grand livre, enrichir les enregistrements, incorporer vos règles métier pour qu'elles s'appliquent à l'arrivée. Cette couche est l'endroit où la valeur se fabrique. Et si elle se fabrique dans le format d'un fournisseur, de son côté de la clôture, la valeur part avec les données. Vous n'avez rien sécurisé. Vous avez loué votre propre avantage, auprès de la partie la mieux placée pour augmenter le loyer.
J'ai déjà écrit sur les entreprises qui louent une capacité et appellent ça une transformation. C'est le même piège avec un meilleur vocabulaire. Un architecte dessine la carte, y construit les premières structures, et vous remet les clés et les plans. Un locataire paie tous les mois pour continuer à habiter la carte de sa propre entreprise.
Une entreprise de taille intermédiaire peut disposer d’une petite équipe informatique, d’un partenaire externe ou des deux. Dimensionnez le premier processus selon la capacité d’exploitation qui restera après le lancement.
Refusez le big bang. Personne n'a besoin de modéliser toute son entreprise la première année. Prenez la seule opération qui fait déjà mal, le rapprochement qui mange les vendredis de votre équipe finance ou le chiffrage qui dépend de la mémoire d'un seul homme, et modélisez celle-là. Quelles entités, quels liens, quelles règles, quelles combinaisons interdites. Livrez. Laissez-la se rembourser. Gardez la partie modélisée, parce que l'opération suivante coûte moins cher une fois que le contexte partagé existe.
Deux conditions la rendent vôtre. Les données résolues atterrissent dans votre base, dans un format que vous contrôlez, sur une infrastructure que vous pourriez déménager. Et la couche modèle au-dessus reste interchangeable, pour prendre la mise à niveau quand la génération suivante arrive au lieu de renégocier votre propre mémoire auprès d'un prestataire.
Prévoyez au contrat l’export, les accès et un transfert testé. Un support géré facultatif doit préserver ces droits, sans les faire dépendre d’un renouvellement.
Une session stratégique de 30 minutes peut examiner le premier processus et recommander ce qui doit ensuite être cartographié ou testé.
Examiner votre cas
Apportez un problème de savoir ou de contrôle. Une session stratégique de 30 minutes aide à définir ce qui doit être cartographié ou testé.
Demander une session stratégique →