Nous avons travaillé à deux reprises sur la même problématique : transférer des données de manière régulière et précise entre deux SI ne pouvant pas communiquer. 

Sur chaque projet, la RPA a été la solution retenue pour traiter le besoin. Pour les non initiés à ce qu’est la RPA, je vous invite à lire ce précédent article présentant la technologie. Pour ceux familier du sujet, continuons ci-dessous.

Pour toute information complémentaire concernant la technologie RPA et la façon dont elle peut adresser vos besoins

Contactez nous :

01 84 76 24 50 / [email protected]

Un problème = une solution

Connecter deux systèmes d’information, ce n’est plus vraiment un problème avec les SI métiers développés récemment. La problématique est plus complexe lorsqu’il faut faire communiquer deux systèmes qui ne peuvent a priori pas interagir.

C’est une problématique fréquente dans le monde des PME et qui peut survenir, par exemple, lorsque :

  • L’un des deux systèmes ne dispose pas de connecteurs car développé spécifiquement pour votre activité,
  • Vous utilisez un logiciel daté,
  • Vous utilisez des systèmes incompatibles.

A ce stade, deux options s’offrent à vous :

  • Allouer des Cadres à la réalisation de processus de traitement long et répétitif, pour environ 100 k€ par an,
  • Développer un bot qui réalisera les mêmes tâches de manière plus cadencées, plus justes, plus vite, et qui coûte sensiblement moins cher que 100 k€ par an.

La RPA est une réponse adaptée puisqu’elle permet de capturer tout type de software et réaliser différents processus. Je vous propose de découvrir la démarche à suivre pour le développement de ces robots.

Pilotez votre projet en perte acceptable

Le développement d’un bot RPA s’effectue en plusieurs étapes :

La première étape est la phase de POC, dont l’objectif est de démontrer que l’outil de RPA retenu pourra développer les fonctionnalités principales attendues. 

La rédaction des spécifications la plus précise et granulaire possible doit être faite pour décrire les fonctionnalités à développer et le cartographie des données à collecter et transférer. L’enjeux est important, ce sera l’un des documents les plus consultés par l’équipe de développement.

Le développement ne commence qu’une fois les spécifications validées.

  • Sous forme de sprints, le développement couvrira les 3 fonctionnalités principales de la solution – une fonctionnalité développée par sprint 
    • Capture des applications,
    • Captures des données sur chaque application,
    • Transfert des données.

L’objectif est de réaliser un proof of concept en investissant en pertes acceptables et démontrant que le développement répond bien au besoin.

Si le projet est viable, il est alors possible d’engager un budget supplémentaire pour finaliser la solution. Si non, les pertes sont limitées aux premiers investissements, ce qui permet plus d’agilité budgétaire pour développer de nouveaux projets. 

Le POC est concluant, que faire ensuite ? 

Bonne nouvelle, pour ce type de projet la RPA semble adaptée pour vous permettre de transférer vos données simplement et automatiquement. Les fonctionnalités principales peuvent être améliorées et celles non-prioritaires, listées dans les specs, peuvent être ajoutées dans un second temps. 

Quelles fonctionnalités ajouter ? Là encore votre budget de développement influencera les décisions. Certaines seront simples à mettre en place et prendront quelques heures, d’autres seront complexes et prendront quelques jours, impactant de facto le nombre et la qualité des fonctionnalités incrémentales à votre projet.

Pour vous accompagner dans le cadrage de votre projet et vous permettre d’avoir une idée précise sur la manière de mettre en place la technologie RPA pour votre activité, je vous invite à consulter notre page d’offre ou à contacter le cabinet

Pour ceux qui souhaitent en apprendre davantage, je vous invite à cliquer sur les liens suivants pour découvrir les intérêts durables de la RPA et une illustration de ses cas d’usage.