Il est de plus en plus courant pour les entreprises de passer par une case « PoC » avant de valider une technologie ou une approche et de la déployer dans toute l’entreprise.
Faux, c’est bien. Un PoC peut devenir plus important que le projet lui-même, ou du moins conduire à des situations où un PoC n’est pas approprié. Outre le report de la livraison des livrables du projet.
Un PoC (Proof of Concept) vous permet de tester votre approche de développement avant MVP (Minimum Viable Product) et de la piloter dans un processus agile.
Traité comme tel et limité à la portée de l’examen du concept. Vous pouvez voir le Poc où la liste des critères à tester est prête à être adaptée au projet final.
Définir un PoC comme une étape préliminaire dans le cadre d’un processus automatisé est une erreur à mon avis. Il doit être reconsidéré d’urgence pour trois raisons architecturales :
1) L’automation n’a plus rien à prouver
Demander à un logiciel d’imiter le comportement humain et d’automatiser un processus est impossible à tester. Les premiers bénéfices attendus sont connus, notamment lorsqu’on parle d’augmentation de la productivité et de l’expérience des collaborateurs.
L’une des valeurs fondamentales de l’automatisation avec RPA est des résultats plus rapides que le développement technologique traditionnel. Le simple fait de lui attribuer un PoC contredit cet objectif.
2) Est-ce important de faire un POC, même sur un projet externalisé ?
Nous préférons ne pas parler de robots, mais d’agents virtuels. L’entreprise devient un lieu où se côtoient trois types de travailleurs : la main-d’œuvre directe de l’entreprise, la main-d’œuvre numérique et la main-d’œuvre externalisée.
L’intégration des travailleurs temporaires ou numériques répond aux mêmes règles de gouvernance et de sécurité.
Si demain vous externalisiez tout ou partie de vos activités, envisageriez-vous de tester le concept ou l’intérêt de votre démarche ?
3) La réussite d’un POC dépend des tests en conditions réelles
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 :
Un PoC se fera dans un environnement de développement/test ne répondant que peu souvent aux conditions de production dès qu’il est question des systèmes cibles du processus à automatiser.
Les données utilisées dans le cadre du PoC ne seront jamais représentatives à 100% données que le processus rencontrera en production. De ce fait, le PoC ne permettra jamais de tester le concept sur les différents types d’exceptions que le processus pourra rencontrer.
Prioriser les systèmes et les données de production est une meilleure approche pour vérifier l’exhaustivité de l’approche. Dans le contexte des processus automatisés, donner la priorité aux tests minimaux et pousser les processus en production pour les phases temporaires « d’hypercare » afin de valider les configurations et d’identifier les exceptions potentiellement inattendues tend à le faire.
Trop de POC tue le POC
Ne pas codifier les PoC, les PoV et les prototypes n’empêche pas une approche maîtrisée de l’automatisation.
Par exemple, il est logique de démarrer un programme d’automatisation avec un pilote à plage réduite.
Le pilote permettra :
- Définir la version initiale de la stratégie d’automatisation
- Définir les niveaux organisationnels initiaux
- Identifier les rôles clés initiaux requis
- Définir et mettre en œuvre le plan de formation de l’équipe Faire la production
- Cette approche nous permet de tester et de tester avant qu’elle ne soit approuvée dans afin de prolonger nos décisions.
Des précautions doivent être prises pour s’assurer que le périmètre réduit du pilote est suffisamment large pour permettre la vérification de l’approche. Ainsi, au lieu de diriger le pilote au niveau du processus que vous souhaitez automatiser, dirigez le pilote au niveau du département ou de l’équipe.
La valeur découle de la mise en production du premier processus. Cette approche permet une itération facile pour inclure d’autres départements et équipes dans le programme.
Les modèles de franchise via la mise en place de centres de distribution sont simples lorsqu’une agence centrale de référence les incite à acquérir leur propre expertise avant de la diffuser aux nouvelles équipes embarquées.
Quelque soit la maturité de votre programme…
Une autre approche envisageable pour un PoC consiste à intégrer de nouvelles technologies (souvent liées à l’intelligence artificielle) dans des programmes d’automatisation. Puisque nous parlons ici d’une main-d’œuvre numérique, il est important de se rappeler que l’ensemble du processus peut ne pas être automatisé.
Avant d’envisager un test de concept, envisagez une approche pilote avec une attention particulière à la gestion des exceptions avec le travail humain.
L’intégration réussie de technologies supplémentaires repose sur l’expertise des équipes qui travaillent ensemble. Ne sous-estimez jamais l’éducation et la formation de tous les employés impliqués directement ou indirectement dans le programme. Il est logique ici de fournir un contenu de formation aligné sur leurs rôles et responsabilités.
La prochaine fois que vous parlerez de la mise en œuvre d’un PoC, défiez cette approche et osez suggérer une approche alternative :
