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 :

1) Le concept d’automatisation est plus que validé

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.

2) Passeriez-vous par la case PoC quand vous menez un projet de sous-traitance ou d’externalisation ?

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 ?

3) Testez 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% des 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.

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.

Arrêter de systématiser les PoC

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 :

• Définir une première version de la stratégie d’automatisation
• Définir un premier niveau d’organisation
• Identifier les premiers rôles clés nécessaires
• Définir et mettre en œuvre un plan de formation des équipes
• Mettre en œuvre une méthodologie de déploiement et de maintien en production

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.

Même dans les programmes matures

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 !