TL;DR :
Lors de la sélection d’un partenaire pour vos projets RPA, il est essentiel de tenir compte de plusieurs éléments clés pour garantir une collaboration fructueuse. Assurez-vous tout d’abord que le partenaire possède une solide expérience dans votre domaine et demandez des références vérifiables pour éviter de simples promesses basées sur des sites web impressionnants. Il est également crucial de connaître l’équipe qui travaillera sur votre projet, en privilégiant les équipes composées de membres permanents et en s’assurant que le consultant principal reste dédié du début à la fin.
Bien que le monde d’aujourd’hui soit tourné vers le numérique, la présence physique d’un développeur RPA peut être un atout, en particulier pour une collaboration étroite avec les experts métier. Faites attention aux technologies utilisées et préférez des solutions reconnues dans le domaine. Réfléchissez également aux implications des choix infrastructurels, en particulier en ce qui concerne la sécurité des données. Pensez à l’avenir : souhaitez-vous gérer les adaptations mineures en interne ou préférez-vous dépendre d’un support externe ? Assurez-vous que votre partenaire a une vision à long terme dans le secteur de la RPA et, enfin, ne négligez pas la question de la sécurité des données, d’autant plus avec la montée des régulations comme la RGPD. En somme, une approche minutieuse et des questions approfondies vous aideront à établir une collaboration RPA solide et durable.
Article complet :
Les 13 questions à poser à votre partenaire RPA !
Le fournisseur a-t-il de l’expérience dans votre domaine ?
L’expérience est primordiale dans tous les domaines, mais je dirais que cela est particulièrement pertinent en matière de RPA. N’oublions pas que les projets de RPA sont délicats car ils ont un impact direct sur les individus et sont inextricablement liés aux systèmes de production essentiels aux entreprises.
Il est donc impératif que votre partenaire ait une bonne connaissance de votre domaine ou, à tout le moins, une solide expérience avec des projets RPA d’envergure. Pour ma part, je serais réticent à travailler avec des entreprises qui ne sont pas véritablement spécialisées en RPA.
Le fournisseur a-t-il des références ?
Ne vous fiez pas uniquement à l’apparence séduisante du site internet d’un partenaire. De nos jours, il est facile de raconter des histoires impressionnantes et de se présenter comme l’expert ultime. Cependant, un examen plus approfondi et une vérification approfondie révèlent souvent une réalité différente.
Par exemple, un site web peut prétendre que le partenaire a de l’expérience avec l’intelligence artificielle (IA) et son intégration dans la RPA (ce qu’on appelle l’IPA), mais en réalité, il n’a peut-être fait qu’un simple laboratoire lorsqu’il avait du temps libre et ne dispose pas d’une expérience solide en projets clients.
Adoptez l’approche de Saint Thomas : demandez des références, vérifiez les projets qu’il a réalisés. Certes, il y a toujours une première fois et tout le monde mérite une chance. Cependant, quand il s’agit de RPA, une certaine prudence est nécessaire.
Qui sont les membres de leur équipe ?
N’hésitez pas à vous renseigner sur les personnes qui seront affectées à votre projet, et consultez leur profil LinkedIn pour avoir une idée de leur expérience et de leur parcours professionnel.
J’ai créé une vidéo pour vous aider à comprendre ce qui fait un bon développeur RPA – un profil plutôt rare à trouver. Voici le lien vers cette vidéo, je vous invite à la regarder.
Leur personnel est-il permanent ou s’agit-il de travailleurs externes ?
Nous abordons ici un aspect essentiel : les personnes qui vont mener à bien votre projet sont-elles des membres permanents de l’équipe de ce partenaire ? Par permanent, je veux dire des personnes engagées sur le long terme avec ce partenaire. Ou bien s’agit-il d’individus qui vont réaliser votre projet puis s’éclipser à la première opportunité, laissant le soin à leur successeur de gérer les conséquences ?
Idéalement, il s’agit d’employés permanents qui vont mener votre projet à bien puis assurer le support. En général, quand quelqu’un doit assumer ses actions, il est plus attentif et prudent dans son travail !
Le consultant principal restera-t-il avec vous pendant toute la durée du projet ?
Cette question est en réalité une extension de la précédente. Demandez-vous simplement : qui va exécuter votre projet ? Est-ce le vendeur ? Est-ce la personne qui était présente lors de l’analyse ou toutes ces personnes se sont-elles éclipsées à la fin de leur travail, laissant l’apprenti prendre le relais ?
Je force un peu le trait, certes, mais c’est une considération importante pour votre projet. Soyez bien conscient de qui va réellement mettre les mains à la pâte. Il est inutile d’avoir l’expert ultime pour vous présenter l’offre si c’est finalement le premier venu qui va réaliser le projet pour le compte du partenaire.
Est-ce que les consultants viendront sur place pour réaliser les automatisation ?
Il est indéniable que le télétravail offre du confort et permet d’éviter les déplacements coûteux et chronophages. Cependant, tôt ou tard, un développeur RPA aura besoin de collaborer directement avec les experts du domaine. Il ne peut pas rester isolé dans sa bulle ! Cela conduirait sans aucun doute à des complications.
Il arrive un moment où les informations des spécialistes du domaine sont nécessaires, tout comme leur validation en fin de processus. Un développeur RPA progressera beaucoup plus vite s’il est sur site.
Quelles technologies utilisent-ils pour leur projet ?
Le monde de la RPA est riche en diverses technologies. Le choix est large et varié ! Évitez de collaborer avec des acteurs marginaux, restez dans le bon quadrant de Gartner.
Certaines technologies sont plus matures que d’autres. Naturellement, les adeptes du système D pourraient être tentés par des solutions gratuites, en promettant des merveilles. Cependant, l’expérience a montré que lorsqu’il s’agit de mettre en œuvre la RPA à l’échelle de l’entreprise, il ne faut pas se contenter de solutions bricolées. Les impacts d’un tel choix pourraient être bien plus importants.
Est-ce que le fournisseur travaille avec sa propre infrastructure ou utilise-t-il le cloud ?
Oui, les robots fonctionneront localement chez vous, mais ils dépendront souvent de ce que l’on appelle un orchestrateur. Il s’agit d’un élément centralisé pour la gestion des automatisations. Les fournisseurs technologiques ont cherché à simplifier la vie des clients et proposent tous une solution cloud. Parfois, ils proposent même exclusivement une solution cloud.
On peut vous assurer que ce n’est pas un problème car il s’agit juste d’un élément de commande centralisé. Cependant, cette vision est un peu trop simpliste, car cet élément central reçoit également les journaux de bord. C’est là que réside le danger et potentiellement l’illégalité. En effet, c’est un moyen facile de se retrouver en infraction avec la LPD ! Une grande prudence est nécessaire lors du développement, surtout dans la phase de gestion des erreurs, en particulier lorsqu’il s’agit de remonter des informations sensibles.
C’est pourquoi, pour certains domaines sensibles en termes de données, il est nettement préférable de travailler en mode on-premise.
Va-t-il fournir un transfert de connaissances après le projet ?
En réalité, la question sous-jacente ici est : souhaitez-vous être capable de gérer vous-même les adaptations mineures ou non ?
Honnêtement, les deux options sont viables. Si vous travaillez sur un grand projet d’automatisation et que vous disposez d’une personne compétente, vous pouvez développer ses compétences, lui fournir le logiciel nécessaire et la laisser prendre en charge les adaptations mineures.
Ou bien, vous estimez que votre équipe informatique ou les personnes en charge du processus sont déjà suffisamment occupées et que vous ferez appel à votre partenaire pour tout gérer.
L’essentiel est que vous et votre partenaire soyez sur la même longueur d’onde à ce sujet.
A-t-il suffisamment de projets pour rester actif proche de vous ?
Votre partenaire a-t-il suffisamment de projets pour continuer à offrir ses services dans votre région, voire parfois dans votre pays ? Si ce n’est pas le cas, le partenaire pourrait abandonner la RPA pour se concentrer sur des domaines plus rentables pour lui, ce qui pourrait évidemment poser un problème majeur pour vous. La question est donc de savoir si votre partenaire a l’intention de rester dans le domaine de la RPA sur le long terme, ou si c’est simplement le buzz du moment qui l’a attiré sur ce marché.
Quels types de soutien recevez-vous après le projet ?
Avez-vous discuté d’un support après la fin du projet ? Votre partenaire propose-t-il un service d’assistance ? Si oui, à quelles conditions (SLA) ? Est-ce un service payant ? Est-ce inclus dans l’offre ?
Dans la plupart des cas, l’assistance pour ce type de projet est facturée séparément. En réalité, cela dépend souvent de la nature du problème.
Ne négligez pas cet aspect, surtout si vous n’avez pas internalisé de compétences. C’est également pour cette raison qu’un partenaire stable est nécessaire.
Les solutions sont-elles maintenables et évolutives à l’avenir ?
Cela devient particulièrement crucial à mesure que vous augmentez la complexité des automatisations que vous implémentez. Il existe des bonnes pratiques en matière de développement RPA, mais ces pratiques imposent un certain nombre de principes, ce qui entraîne un certain coût. C’est pourquoi, pour les petits projets, certains développeurs peuvent se montrer moins rigoureux. Ce qui n’est pas un problème pour des processus simples et clairs, mais qui peut devenir un obstacle majeur pour des automatisations plus complexes.
C’est pourquoi je recommande toujours de mettre le coût en perspective avec le retour sur investissement. Car plus la pression sur les coûts est importante, plus le travail devra être réalisé rapidement. Et du bon travail nécessite du temps. De plus, si une automatisation vous permet d’économiser 200 000 CHF, êtes-vous vraiment prêt à sacrifier la qualité pour 10 000 CHF ?
Comment gère-t-il la sécurité des données ?
Cette question est devenue essentielle dans la plupart des domaines à cause de la nLPD et du RGPD ! Et cela est d’autant plus vrai dans certains secteurs tels que les domaines publics, parapublics et de la santé. Les conséquences sont désormais significatives. Ce n’est plus un sujet qui peut être traité avec légèreté en supposant que nos données n’ont de toute façon aucune valeur pour personne !
À mon avis, chaque partenaire doit disposer d’un cadre de sécurité et de protection des données pour le développement de la RPA.
Pour finir et pour conclure …
Ces questions sont essentielles pour éviter des complications avec un nouveau partenaire dans vos projets de RPA ! Et n’oubliez pas, si un doute persiste, c’est qu’il n’y a probablement pas lieu d’hésiter !