SGPD spécial RPA
Le petit billet de l'Oiseau Rare
Le Data Service ou SGPD est l’un des derniers ajouts à la plateforme de UiPath. C’est aussi l’un de ceux pour lequel nous avons entendu les plus fortes interrogations quant à son utilité. Il est vrai que cet outil n’est pas comme Insights ou Test Manager qui peuvent être utiles pour tous les utilisateurs de UiPath. Non, cet outil est dans la même situation que Document Understanding ou Action Center. Il n’est intéressant que dans certains cas d’automatisation.
Article publié par Maxime Debuysschere, Consultant Lead Dev RPA chez l’Oiseau Rare.
CHAPITRE 1
OK Jamy ; mais justement quels sont ces cas ?
Minutes, j'y viens.
Les cas qui nous intéressent ici partagent une caractéristique commune. Il s’agit de situations où, parmi les processus automatisés, plusieurs utilisent le même ensemble de données. Chacun de ces processus nécessite soit d’extraire les mêmes informations depuis différents outils (base de données, CRM ou autres), soit d’utiliser les résultats de traitements précédents. C’est ce partage de données qui va mener à l’utilité de Data Service ; mais finissons d’abord notre contextualisation.
Au-delà de cette caractéristique commune, nos cas d’automatisation se distinguent par le mode de partage des données. Il y en a 3, qui ne sont pas mutuellement exclusifs.
Le premier mode est celui de la source unique. Dans ce cas, un même ensemble de données constitue l’entrée de plusieurs processus. Chaque traitement est indépendant ; mais tout le monde a le même point de départ.
Par exemple : un processus d’inboarding (créations de comptes, inscriptions aux services, etc.) peut être réparti entre plusieurs robots qui travailleront en parallèle. Ils récupèreront les informations du nouvel employé ou de la nouvelle employée depuis un même outil RH.
Le second est celui de la centralisation. Ici, plusieurs processus traitent des éléments de manière parallèle. Ensuite, les traitements sont rassemblés pour construire une synthèse, au hasard un tableau de bord.
Par exemple : dans une DSI, différents types de demandes matérielles et logicielles sont traités par différents robots. Ensuite, l’ensemble des demandes est centralisé dans un tableau de suivi des demandes.
Le troisième mode est celui de l’enchaînement. Désormais, plusieurs processus interviennent les uns après les autres pour traiter un même ensemble de données. Ainsi la sortie d’un processus devient l’entrée d’un autre.
Par exemple : le traitement des factures est classiquement divisé en une série d’étapes :
- L’intégration de la facture
- La comparaison avec la commande
- Le contrôle des données de paiement
Ces étapes sont réparties entre plusieurs robots. Chaque facture est traitée par chaque robot successivement.
CHAPITRE 2
Alors, merci pour le contexte ; mais ce type d’automatisation existe déjà. Nul besoin d’un Data machin pour ça
Data Service. Et oui, mais non… Attendez, je vous explique.
Comme nous venons de le voir, ces cas nécessitent un partage de données entre plusieurs robots. Cette nécessité pose un sérieux problème car les robots ne peuvent pas échanger directement des informations, en particulier lorsqu’ils ne sont pas synchrones. Il faut donc passer par un intermédiaire. Pour ce faire, 2 alternatives sont le plus souvent envisagées : la source métier et le fichier Excel..
1. Alternative : la source métier
Le principe de cette alternative est de se reposer sur l’existant. Puisque plusieurs robots traitent un même ensemble de données, autant que chacun retourne à la source primaire de l’information.
Le grand avantage de cette alternative est qu’elle garantit la cohérence, la conformité et la sécurité des données. En effet, les données proviennent d’une unique source de référence. Elles bénéficient ainsi des mesures déjà mises en place pour les métiers.
Le problème de cette alternative est qu’elle implique que chaque robot va faire peu ou prou les mêmes requêtes à chaque fois. Cette répétition des requêtes provoque des risques techniques, mais aussi métier.
Du côté technique, ces répétitions entraînent :
- Une charge de calcul pour le serveur
- Une consommation de bande passante
- Des délais de traitement pouvant se compter en dizaines de minutes…
De telles charges techniques peuvent impacter les performances du système source. Elles peuvent aussi impacter les performances des robots, voire leur stabilité. Ces problèmes de performance sont d’autant plus importants avec des sources métier ne permettant pas une extraction fine des données. En effet, avec ces outils les requêtes embarqueront une certaine quantité de données inutiles, qui seront manipulées, déplacées, copiées pour rien.
Du côté métier, ces répétitions ouvrent la porte à une perte de cohérence des données entre les robots. Pour rappel, les collaborateurs utilisent notre source primaire. Il est donc possible qu’entre deux requêtes automatisées, des données soient modifiées manuellement. Cette modification peut compromettre le bon déroulé des traitements. Ce risque est particulièrement critique à un stade précoce d’automatisation où les données sont encore régulièrement modifiées par les collaborateurs.
2. Alternative : le fichier Excel
Ici, seul le robot le plus en amont dans le processus est chargé de la requête de données. Ensuite, il enregistre ces données dans un fichier Excel. Ce fichier est lui-même enregistré dans un répertoire partagé accessible aux autres robots.
Le principal avantage de cette alternative est qu’elle permet d’éviter les désavantages de la précédente, surtout les pertes de temps dues aux répétitions. De plus, les robots peuvent travailler à partir d’une source de données qui leur est propre et qui ne contient donc que les informations qui leur sont utiles.
Cependant, cela implique de nouveaux risques. L’existence d’une source déconnectée de l’outil métier peut provoquer une perte de cohérence ou de conformité vis-à-vis des tâches restées aux mains des collaborateurs. Les fichiers Excel soulèvent des questions d’accès à des données sensibles ou critiques dans des répertoires potentiellement ouverts à un grand nombre de personnes. Par ailleurs, la gestion de ces fichiers est complètement dispersée. Chaque robot peut déplacer, renommer, copier et supprimer des fichiers dans le répertoire partagé, mais aussi sur son propre poste. Enfin, on peut ajouter les risques liés aux concurrences d’accès utilisateurs, aux latences du réseau, aux interventions humaines indésirables voire malveillantes, aux doublons, etc.
CHAPITRE 3
OK, on a compris. Et donc, Data Service ? C’est quoi ?
Le meilleur des deux mondes ? SGPD SPECIAL RPA
Presque… Vous allez voir.
UiPath présente le Data Service comme un outil qui, je cite, « vous permet de modéliser, gérer et stocker les données commerciales de manière centralisée et y accéder rapidement et de manière transparente ». En quatre mots, c’est un système de gestion de bases de données ; mais un SGBD spécial RPA.
Je vous rassure ; ce n’est pas pour faire concurrence aux bases de données métiers. En aucun cas, Data Service (SGPD) ne serait capable de les remplacer. En fait, cette base de données n’est pas vraiment utilisable par un humain. L’affichage des données fait le minimum et les outils de manipulation sont inexistants. De quoi faire quelques contrôles et des modifications ponctuelles, rien de plus. La seule intervention humaine prévue est le paramétrage de la base de données. Cela est très simple pour peu que l’on connaisse les bases du modèle relationnel.
CHAPITRE 4
Oula, attends. C’est quoi le modèle relationnel ?
Ah oui, j’avais failli oublier. Ne vous inquiétez pas, ce n’est rien de bien méchant.
Le modèle relationnel est un modèle mathématique qui permet de structurer un ensemble complexe de données en décrivant des relations. Ces relations sont matérialisées par des tables à deux-dimensions. Chose que nous connaissons tous assez bien, car la plupart des tableaux Excel sont des tables à deux dimensions. Dans une table, chaque colonne représente un attribut qui attend un type de valeur bien défini (nom, montant, date, etc.) ; et chaque ligne représente un uplet autrement dit l’enregistrement d’une combinaison précise de valeurs pour chaque attribut.
Exemple d’un modèle relationnel
Pour cet exemple, les tables « Employé » et « Employeur » contiennent chacune leurs attributs et des enregistrements.
Dans la table « Employeur », l’attribut « SIREN » est la clef primaire.
Dans la table « Employé », l’attribut « MATRICULE » est la clef primaire et l’attribut « EMPLOYEUR » est une clef étrangère faisant référence à l’attribut « SIREN » de la table « Employeur ».
Psst ! Je me posais une petite question. Avez-vous reconnu les
2 films qui m’ont servi à construire cet exemple ? Oui ? Alors mettez un petit commentaire sous la publication.
Pour parvenir au modèle relationnel, il ne reste qu’à ajouter à ces tables des clefs primaires et des clefs étrangères. Une clef primaire est tout simplement un attribut (ou un ensemble d’attributs) qui permet d’identifier sans équivoque un enregistrement dans une table. Une clef étrangère est un attribut qui fait référence à la clef primaire d’une autre table. Celle-ci permet donc de matérialiser une relation entre deux tables.
Ce système de clefs primaire et étrangère fait toute la force du modèle relationnel. Ainsi en partant d’un enregistrement dans une table, il est possible de retrouver toutes les informations qui lui sont reliées dans les autres tables. Par exemple, quel est le chiffre d’affaires de l’employeur de Mr Coffey ; ou bien combien de personnes sont employées par l’employeur Bay ?
Voici ce que vous aviez besoin de savoir sur le modèle relationnel. Naturellement, il n’y pas que ça ; mais vous ne n’avez pas besoin de connaître les 12 règles de Codd, l’algèbre relationnel ou la cardinalité des relations pour ce qui va suivre. J’ajouterai seulement que le modèle relationnel est la fondation sur laquelle repose la très grande majorité des bases de données qui sont couramment utilisées à ce jour.
CHAPITRE 5
Oui, c’est plus clair maintenant ; mais quel est le rapport entre le modèle relationnel, Data Service et les robots SUR LE SGPD SPECIAL RPA ?
Hé bien, c’est en fait très simple….
Data Service (SGPD) fonctionne grâce à une base de données relationnelle. Il est là le rapport. Cette base de données, pour être accessible aux robots, doit naturellement être installée sur un serveur. Cependant, inutile de s’embarrasser avec la connexion entre les robots et Data Service ; c’est l’Orchestrator qui s’en charge, comme souvent avec la plateforme UiPath.
La création d’une base de données commence par l’activation de Data Service (SGPD) pour un tenant de l’Orchestrator. Pour rappel, un tenant est une subdivision qui permet d’isoler des données et des automatisations à l’intérieur d’un même Orchestrator. Tous les utilisateurs, processus, machines, logs, alertes, etc. appartiennent à un tenant et ne sont donc pas accessibles depuis les autres. De la même manière, une base de données Data Service est attachée à un tenant. Elle n’est donc accessible que pour les utilisateurs (humains ou robots) de ce tenant ; et non pour les autres. Voilà un accès déjà nettement plus sécurisé que pour beaucoup de répertoires partagés. A propos de sécurité, j’évoquerai rapidement une fonctionnalité de Data Service (SGPD), l’accès par rôle. Avec cette fonctionnalité, il est possible de restreindre l’accès à une table et/ou à un attribut.
CHAPITRE 6
OK. Donc c’est plutôt bien sécurisé. Et c’est là qu’on en revient au meilleur des deux mondes, comme on disait avant ?
Tout à fait.
De l’emploi de la source métier, Data Service (SGPD) conserve l’unicité de la source de référence. Cette unicité garantit la cohérence et la conformité des données entre les robots. Comme la plupart des bases de données, Data Service permet de sécuriser les données et en particulier de protéger des données sensibles de lectures et/ou d’écritures indésirables.
De l’emploi de fichiers Excel, Data Service (SGPD) conserve l’adaptation du référentiel de données à l’usage des robots. Ne sont présentes que les informations utiles aux robots et seuls ces derniers les exploitent.
La combinaison de l’essentiel des avantages des 2 méthodes permet de prévenir l’essentiel des problèmes que nous avons listés précédemment. Pas de multiplication des requêtes aux outils métier, ni de multiplication des fichiers dans des répertoires partagés et des dossiers locaux.
De ces différents problèmes, il en reste un qui nécessite une attention particulière. En effet, avec Data Service (SGPD) nous créons une base de données propres aux robots qui est déconnectée de la base de données métier ; ce qui peut entraîner une perte de cohérence entre les deux. Pour être géré, ce risque doit être pris en compte durant l’automatisation des processus.
CHAPITRE 7
D’accord. C’est effectivement assez utile. Par contre, ça commence à faire pas mal d’info SUR LE SGPD
SPECIAL RPA.
Vous avez raison c'est l'heure du résumé.
Avec Data Service (SGPD), vous disposez :
- D’un système de gestion de bases de données prêt à l’emploi
- Conçu expressément pour assurer le stockage persistant et centralisé de données manipulées par plusieurs robots
- Constituant une alternative performante et avantageuse face aux solutions précédemment utilisées
- Facile à prendre en main
- Parfaitement intégré avec le reste des outils UiPath à travers l’Orchestrator
- Présentant des garanties de sécurité pour l’accès et l’administration
En somme, un outil qui fait la différence… Dès lors que vous avez plusieurs robots qui doivent s’échanger des informations.
Sans commentaire. Donc, on a fait le tour ?
La moitié ! Nous avons vu pourquoi l’utiliser, il reste à voir comment. J’ai hâte de vous parler des invocations d’entités dans Studio, mais je garde ça pour une autre fois.
Le mot de la fin ?
Anacoluthe.
Nos expertises en automatisation RPA
L’Oiseau Rare vous propose ses services d’accompagnement pour élaborer une stratégie d’automatisation personnalisée. Nous vous aidons à identifier les processus automatisables, à définir des objectifs clairs, et à évaluer les avantages liés à l’automatisation.
Lead Developper RPA chez SAFRAN
Au sein de la Direction financière de Safran SA, le Département SFS (Safran Financial Services) qui a pour vocation de consolider les résultats de l’ensemble des filiales du Groupe.
Safran SFS a pour objectif d’établir une ‘RPA Factory’ en vue d’automatiser les processus métiers de faible valeur ajoutée. Dans ce cadre, j’ai conçu et mis en place des Assistants Virtuels (AV) pour Safran SFS, tout en assurant la supervision et le soutien du développement de l’outil RPA.
Besoin d'accompagnement ?
Ne laissez pas les obstacles techniques entraver votre progression. Contactez-nous aujourd’hui pour discuter de vos besoins spécifiques et découvrez comment notre expertise en projet RPA peut transformer votre besoin technologique en réalité !