Logiciel existant, automatisation ou IA sur mesure?

Une file de courriels peut réunir plusieurs types de travail. Quelqu’un lit une demande, comprend ce que veut l’expéditeur, réclame les renseignements manquants et copie les détails approuvés dans un système de gestion. Vue de loin, c’est une seule tâche répétitive. De près, chaque étape suggère une façon différente de réduire l’effort.

Imaginons une équipe qui traite cette file. Un formulaire pourrait éviter la ressaisie. Une règle pourrait acheminer une demande dès que l’équipe responsable est connue. L’IA pourrait aider à interpréter un long message dont les détails utiles se trouvent dans une pièce jointe. Cet exemple hypothétique donne au choix entre acheter et construire un point de départ plus précis : l’étape qui a encore besoin d’aide.

Selon nous, cette question passe avant toute comparaison de produits. Les sections qui suivent examinent trois options pour cette file : le logiciel que l’équipe possède déjà, une règle fixe et une intégration d’IA sur mesure. Elles décrivent ensuite une comparaison qui soumet chaque option au même essai. Elles ne classent pas de produits et ne recommandent aucun fournisseur.

Les demandes difficiles montrent quelle étape a besoin d’aide

Une demande incomplète et une demande qui pourrait relever de deux équipes en disent plus qu’un exemple sans difficulté. La personne qui les traite prend des décisions avant de créer un dossier. Ces décisions montrent ce que le logiciel devrait faire, ou ce qu’une personne continuerait à faire avec lui.

Le produit existant recueille peut-être déjà les demandes, mais ne peut pas transmettre les champs approuvés à destination. Il manque alors une connexion. Ou il achemine parfaitement les demandes une fois qu’une personne a interprété le message. C’est alors l’interprétation qui mérite un examen. Il manque parfois un réglage. Dans d’autres cas, c’est le processus lui-même qui laisse une décision sans réponse.

Si personne ne sait qui approuve une exception, le nouveau système héritera de cette ambiguïté. C’est pourquoi nous partons du travail actuel : il permet de distinguer une limite du logiciel d’une décision que l’organisation n’a pas encore prise.

Une fonction annoncée doit encore fonctionner dans votre compte

Un formulaire de demande et une connexion à destination sont peut-être déjà offerts par le logiciel de l’équipe. Leur disponibilité dans cette organisation est une autre question. Une fonction annoncée peut dépendre d’un autre forfait, de la permission d’un administrateur ou d’un connecteur qui n’a pas été activé.

Nous ferions un essai dans le compte réellement utilisé, avec des entrées représentatives, parce qu’il fait apparaître ces conditions. Cet essai montre aussi comment le produit traite les exceptions, quelles données il peut consulter, ce qui peut être exporté et qui s’occupe des changements ou des incidents.

L’achat d’un logiciel peut laisser des travaux de configuration et d’intégration. Les décrire aide à comprendre ce que l’achat résoudrait et ce qui resterait à l’équipe ou à un partenaire d’implantation.

Quand une règle suffit, un modèle ajoute un comportement à maintenir

Si un formulaire demande de choisir l’équipe responsable, une règle peut y acheminer la demande. Une autre peut la retenir tant qu’un champ obligatoire reste vide. La raison de chaque décision apparaît dans la règle elle-même.

Pour cette étape, ajouter un modèle introduit un comportement supplémentaire à évaluer et à maintenir. Les règles ordinaires ont aussi besoin de tests, de permissions et d’un traitement des défaillances, mais on peut inspecter directement la décision qu’elles produisent. Si une règle peut traiter l’étape, nous choisirions la règle, car une IA sur mesure peut ajouter des coûts inutiles.

Les règles et l’IA peuvent aussi travailler ensemble. Un modèle pourrait lire le courriel et proposer une équipe, une personne vérifier le choix, puis du code classique acheminer la demande approuvée. Seule l’étape d’interprétation dépendrait du modèle.

Des demandes sans format imposé peuvent justifier une intégration d’IA sur mesure

Imaginons maintenant que les demandes doivent continuer d’arriver par courriel, sans format imposé. Une personne place l’adresse de service dans une pièce jointe. Une autre décrit deux problèmes dans le même message. Si le logiciel existant ne peut pas en tirer un dossier utilisable, un brouillon préparé par l’IA peut mériter un essai.

Comment l’équipe saurait-elle si ce brouillon l’aide? La personne qui connaît le travail est au centre de cet essai. Elle peut juger si le brouillon est exact et si sa vérification est praticable. Un brouillon trop long à vérifier peut apporter peu d’aide, même s’il paraît convaincant.

La conception dépend aussi de l’accès aux systèmes, de l’autorisation d’utiliser les données et d’une personne qui exploitera le résultat. Un outil de rédaction peut avoir moins de responsabilités qu’un outil qui envoie des messages ou modifie des dossiers. Si un agent choisit des actions, les outils disponibles et leurs limites doivent être encadrés hors de ses instructions. L’approbation humaine doit porter sur l’action réellement exécutée. Les conditions d’arrêt ou de demande d’aide font aussi partie de la conception convenue.

Une comparaison équitable repose sur les mêmes exemples de demandes

Les mêmes exemples de demandes permettent de comparer chaque option. Nous suggérons de poser ces questions pour chacune, parce qu’elles relient les résultats au travail quotidien de l’équipe :

• Peut-elle traiter les formats et les exceptions que vous recevez réellement?
• Quelles erreurs une personne peut-elle corriger et quelles actions le système doit-il empêcher?
• Peut-elle accéder aux bonnes données avec des permissions que vous pouvez autoriser?
• Qui vérifie le résultat et aura-t-on le temps de le faire au volume prévu?
• Que faut-il modifier quand le processus ou l’interface d’un fournisseur change?
• Qui surveillera le système, corrigera les défaillances et paiera les coûts récurrents?

Les réponses peuvent favoriser un petit changement au produit existant ou faire apparaître une raison de construire. Si aucune option n’a de responsable ou de façon acceptable de traiter les erreurs, nous pensons que poursuivre avec le processus actuel est un résultat raisonnable. Cela laisse le temps de résoudre ces questions avant un changement plus large.

Une courte description aide à repérer les fonctions inutiles

Pour la file de courriels, une courte description peut suffire à définir les travaux : lire les demandes d’une seule boîte, préparer un brouillon de dossier et transmettre les champs à une destination après leur approbation. S’il manque des renseignements, la demande revient à la personne qui la vérifie. Un doublon ne doit pas créer un deuxième dossier. Si la destination échoue, le travail approuvé doit rester disponible pour la reprise.

Cette description rend aussi les fonctions inutiles plus faciles à repérer. Lire d’autres boîtes ou prendre des décisions sans rapport avec la demande ajouterait des accès et des responsabilités sans aider à cette tâche. Si un formulaire et une règle d’acheminement répondent aux besoins, le système proposé peut être encore plus petit.

Lequel de nos mandats convient à chaque point de départ

Nous ne pouvons pas choisir entre ces options sans voir le travail. La réponse dépend du compte, des demandes et des exceptions qu’une équipe a réellement.

Lorsque l’utilité de l’IA reste incertaine, notre preuve de concept examine si un cas d’usage fonctionne sur les données de l’organisation. Le prototype et l’évaluation éclairent la décision suivante. La production exige une portée distincte.

Une intégration d’IA relie un processus à des systèmes nommés. Un projet d’application en production mène un cas d’usage éprouvé jusqu’à une application déployée. Les cinq mandats couvrent ces points de départ et d’autres besoins, et le guide des coûts d’intégration explique comment le travail autour du modèle se retrouve dans un devis.

Une conversation sur la tâche permet de déterminer si un mandat payant défini serait utile. Une description non sensible suffit pour commencer. Les documents confidentiels et les identifiants doivent rester hors du courriel.