Étude de cas
Certas Energy traite les factures fournisseurs 93 % plus rapidement grâce à l'automatisation intelligente
Contact
Il devient courant de voir des organisations passer par la case « PoC », avant de valider une technologie, une approche et la déployer à l’échelle de l’organisation.
Cela en devient même un toc. Le PoC peut devenir plus important que le projet en lui-même, ou à minima il en résulte des situations ou ledit PoC n’est pas adapté. A part décaler la livraison des bénéfices du projet.
Un PoC, Proof of Concept, permet de tester une approche de développement avant le MVP (Minimum Viable Product) et le piloter en démarche agile.
Il doit être traité comme tel et être cantonné au périmètre de test du concept. On peut voir des Poc où la liste des critères à tester est telle, qu’il peut être assimilé au projet final.
Dans le cadre d’une démarche d’automatisation, définir un PoC comme une étape préliminaire est à mes yeux une erreur. Il doit être reconsidéré de façon urgente pour 3 raisons structurantes :
Automatiser des processus en demandant à un logiciel de répliquer des actions humaines n’est plus à tester. Les bénéfices premiers attendus sont connus, notamment quand on évoque l’augmentation de la productivité des collaborateurs.
Une des valeurs premières de l’automatisation, de la RPA, est de livrer des résultats plus rapidement qu’un développement technique traditionnel. Le simple fait d’y associer un PoC est contradictoire avec cet objectif.
Nous ne parlons pas de robots chez Blue Prism, on leur préfère le terme d’agents virtuels. L’entreprise devient donc par extension le lieu de collaboration de 3 types de main d’œuvre : la main-d’œuvre directe de l’entreprise, la main-d’œuvre numérique ainsi que la main-d’œuvre sous traitée.
Embarquer une main-d’œuvre sous-traitée ou une main-d’œuvre numérique répond aux mêmes règles de gouvernance et de sécurité.
Si demain vous sous-traitiez tout ou partie d’une activité, seriez-vous dans l’idée de tester le concept ou même la valeur de l’approche ?
Il est toujours difficile de tester en conditions réelles. Effectuer un PoC en conditions réelles devient illusoire.
Il est peu crédible de pouvoir penser que l’on pourra tester un concept en conditions réelles pour plusieurs raisons :
Afin de valider la complétude de l’approche, préférer des systèmes et données de production est une approche plus appropriée. Dans le cadre d’un processus à automatiser, nous tendons à préférer des tests minimaux et pousser le processus en production, dans une phase temporaire d’ « hypercare », afin de valider la configuration et d’identifier les exceptions potentiellement non prévues.
Ne pas systématiser les PoC, PoV, Prototype n’empêche pas d’avoir une approche contrôlée de l’automatisation.
Démarrer son programme d’automatisation par un pilote sur un périmètre réduit à tout son sens par exemple.
Le pilote permettra de :
Cette approche permettra de tester et éprouver les choix avant de les entériner pour les passer à l’échelle.
Il faudra faire attention à ce que le périmètre réduit du pilote soit suffisamment large pour permettre de valider l’approche. En d’autres termes, ne menez pas votre pilote à l’échelle d’un processus à automatiser, mais plutôt à celle d’un département ou d’une équipe.
Le résultat générera de la valeur dès que les premiers processus seront en production et l’approche permettra d’itérer aisément pour inclure d’autres départements ou équipes dans le programme.
Il est plus facile de franchiser un modèle en introduisant des centres de delivery si l’autorité référente centrale a gagné ses galons et acquis l’expertise en son nom propre avant de la diffuser aux nouvelles équipes embarquées.
Une autre approche où l’ou souhaitera envisager un PoC est l’intégration d’une nouvelle technologie, souvent des technologies liées à l’intelligence artificielle, dans un programme d’automatisation. Il convient de conserver à l’esprit ici que nous parlons de main-d’œuvre numérique et que potentiellement, l’ensemble du processus ne pourra pas être automatisé.
Avant de considérer un test du concept, il faut envisager une approche sous forme de pilote en apportant une attention toute particulière à la gestion des exceptions par une main-d’œuvre humaine.
Le succès de l’intégration d’une technologie additionnelle est facilitée par le niveau d’expertise des équipes qui vont collaborer dessus. Il ne faut jamais sous-estimer la formation initiale et continue de l’ensemble des collaborateurs impliqués, de près ou de loin, dans le programme. Il convient ici de proposer un contenu de formation adapté aux rôles et responsabilités de chacun.
La prochaine fois que l’on vous parle de lancer un PoC, challengez l’approche et osez proposer une approche alternative, comme un pilote réunissant toutes les conditions d’un passage à l’échelle , et délivrant plus rapidement de la valeur !
Étude de cas
Certas Energy traite les factures fournisseurs 93 % plus rapidement grâce à l'automatisation intelligente
Blog
Services de rapprochement et de rééquilibrage automatiques des portefeuilles
Livre blanc
Automatisation intelligente pour l’administration et le secteur public
Si votre administrateur réseau bloque YouTube, il se peut que vous ne puissiez pas voir la vidéo sur cette page. Dans ce cas, utilisez un autre appareil. En appuyant sur le bouton « Play », YouTube pourra placer des cookies tiers sur votre appareil. Rendez-vous sur notre Politique relative aux cookies pour plus d'informations.