Digitalise moi un processus

Digitalise moi un processus article Tribe IT Partners

Pascal est formateur. Il aide les gens à préparer des certifications. Pascal pose beaucoup de questions et obtient beaucoup de réponses. Toutes ces questions et toutes ces réponses, c’est beaucoup de travail dans des fichiers Excel. Il faut préparer des questions et faire vivre une base de plusieurs centaines d’entre elles, préparer des questionnaires, les diffuser aux apprenants, récolter leurs réponses, proposer les corrections pour finalement faire en sorte que cette certification à blanc aide l’apprenant à progresser.

Pascal me dit un jour : « Digitalise-moi un processus ».

« Je suis las de passer mon temps à manipuler des fichiers Excel par dizaine, à les dupliquer, à les maintenir en cohérence, à les diffuser, à les réintégrer… Ça prend tout mon temps, ce temps que je ne consacre plus à mes apprenants. De plus en plus de temps d’ailleurs, à mesure que mon activité augmente. »

Alors nous avons fait une application. Finalement assez simple, mais qui a permis à Pascal de consacrer moins de temps à gérer des fichiers Excel, et plus de temps à créer de nouvelles questions pour enrichir la base de données. Première valeur ajoutée. Puis, à proposer aux apprenants de nouveaux questionnaires, plus courts et plus nombreux permettant de constituer des parcours personnalisés pour l’apprenant selon son niveau et sa progression. Deuxième valeur ajoutée. Ensuite, l’application est devenue interactive et a permis le coaching de l’apprenant, mais aussi de la classe toute entière, en temps réel pendant les cours. Troisième valeur ajoutée.

Un point de départ

Nous sommes aujourd’hui convaincus que ce n’est pas terminé. Cette démarche que nous avons engagée va continuer à produire de la valeur et nous emmener encore plus loin. Pascal a quelques idées sur les prochaines étapes, mais la cible reste une Inconnue car toujours en mouvement. Elle est construite au fur et à mesure, au fil des enrichissements et des opportunités… Le chemin parcouru en 12 mois depuis les fichier Excel est gigantesque : les idées fourmillent, une nouvelle vision du métier est apparue.

Vous l’avez compris, ici le propos n’est pas de vanter les mérites de la méthode de développement agile (même si elle nous a beaucoup aidé), mais de constater que la digitalisation, partant d’un simple besoin d’optimisation de tâches, a ouvert un champ des possibles complètement insoupçonné au début des travaux. Nul besoin d’être spécialiste de l’IoT ou concepteur de voiture sans pilote pour bénéficier des bienfaits de cette innovation. Notre expérience a montré qu’une activité assez classique pouvait en bénéficier de manière exponentielle. Parce qu’en supprimant des tâches répétitives, on a pu passer à autre chose, libérer les idées et la créativité. Parce que cette créativité a transformé tout l’écosystème autour de Pascal.

Alors Digitalisez ! Proposez à vos directions métiers, à vos utilisateurs la démarche de Transformation Digitale. Il en ressortira des choses insoupçonnées qui vont révolutionner leurs activités, leurs métiers et au final l’Entreprise toute entière.

Et surtout n’oubliez pas ceci : la Transformation Digitale n’est pas une solution ou un produit fini, il s’agit bien d’une démarche, d’un état d’esprit.

Alan Turing avait introduit « l’état d’esprit de la machine ». Un peu plus de 80 ans après, il est temps de passer à la 2ème phase de la révolution numérique.

L’Architecture Technique, ou comment maîtriser la transition des infrastructures IT vers le Cloud ?

C’est devenu une évidence aujourd’hui : les infrastructures informatiques des entreprises migrent vers le Cloud.

Un mouvement progressif a été initié, plus rien ne l’arrêtera dorénavant. Les décideurs le ressentent, les utilisateurs le demandent et les informaticiens en ont peur. Même si le Cloud reste une notion abstraite pour le chef d’entreprise, il comprend bien que c’est une façon de se débarrasser de sa tuyauterie informatique, éternel centre de cout. Les directions métier n’attendent que de pouvoir utiliser les nombreuses applications SaaS disponibles sur les nouveaux terminaux, sans les contraintes classiques (investissements lourds, délais importants, arguments sécuritaires allant à l’encontre du business). De leur côté, les DSI se posent la question : que va-t-il rester demain des équipes informatiques ?

Puisque cette transformation est inéluctable, inutile de freiner des quatre fers. Il vaut mieux chercher à la comprendre et à la maîtriser. Dans un article précédent, nous avions évoqué l’une des conditions essentielles à l’externalisation des ressources humaines IT : la maîtrise de ce que l’on externalise. Il en est de même des infrastructures : ne pourra transiter vers le cloud que ce qui est parfaitement sous contrôle.

La maîtrise de l’Architecture Technique doit permettre d’exercer ce contrôle et de réguler la transition dans le nuage. Sans cela, on ne saura pas suivre le rythme effréné des évolutions proposées par les acteurs du Cloud, ni même construire un système d’information hybride, pour au final voir ses infrastructures rapidement et intégralement migrer dans le nuage (aboutissement du Shadow IT).

L’Architecture Technique (ou Technology Architecture) est l’une des phases de l’Architecture d’Entreprise telle que décrite par le standard TOGAF (The Open Group) : elle permet le recensement cartographique ainsi que la définition de normes et de standards approuvés. La cartographie pourra porter sur les composants techniques, mais aussi sur les activités humaines gravitant autour de ces composants (les process de la production informatique). Le référentiel des normes et standards sera homogène et cohérent. Enfin l’architecture technique s’inscrit dans la démarche plus globale d’urbanisation.

L’approche consiste à réaliser un état des lieux initial (cartographies, normes en vigueur) afin d’établir le référentiel, mais surtout à s’assurer qu’il va évoluer en permanence, sous peine de voir ce travail devenir très rapidement obsolète. C’est d’ailleurs l’un des risques majeurs d’un projet d’Architecture Technique : l’essoufflement des personnes impliquées dans le cycle de vie du référentiel (il y a toujours mieux à faire que de mettre à jour une documentation), voir le découragement si le périmètre de l’Architecture Technique est trop ambitieux. Ce sera le rôle de l’Architecte que d’animer cette activité.

Une fois le référentiel établi, l’Architecture Technique pourra non seulement soutenir les Projets d’Entreprise (en vérifiant l’application des normes et standards choisis, et en apportant la connaissance des infrastructures existantes), mais aussi proposer de nouveaux projets de mise aux normes.

Pour justifier d’un retour sur investissement, on constatera qu’au-delà de la transition vers le Cloud, cette démarche apporte quelques autres bénéfices :

  • La démarche est motivée par la croissance et l’augmentation de la complexité du SI (et en particulier l’infrastructure) liées à la digitalisation des métiers et au besoin grandissant de sécurité. La connaissance ne doit plus être seulement informelle, inscrite dans la mémoire de quelques techniciens. L’architecture technique permettra d’organiser et pérenniser cette connaissance.
  • Le contexte de récession budgétaire contraint à s’assurer de l’homogénéité des systèmes pour éviter la redondance inutile. L’architecture technique garantira cette homogénéité et l’optimisation des ressources offrira un gain de temps et financier.
  • La connaissance du SI est nécessaire pour s’engager sur des niveaux de service (SLA) et permettra de soutenir leur définition.
  • L’architecture technique permettra d’adopter facilement les innovations en cohérence avec la stratégie de l’Entreprise, sans mettre en péril l’existant (ou en maîtrisant l’impact), tout en respectant les exigences de sécurité. Ceci permettra aussi d’éviter de subir la « marche forcée » des évolutions imposée par les éditeurs et constructeurs.

Les organisations ont souvent grandi sans structurer leur Architecture Technique. Ceci ne les a pas empêchés jusqu’à présent de prospérer, alors pourquoi s’y intéresser maintenant ? La transition vers le Cloud va bouger les lignes : les experts techniques vont suivre le mouvement et progressivement déserter les services informatiques. Si l’on ne veut pas y voir là une perte de compétences, mieux vaut organiser le désengagement sur l’exploitation des infrastructures, au profit de leur conception. C’est bien là le rôle de l’Architecture Technique.

Le Chef de projet cet inconnu …

Qui est le Chef de projet ? Combien sont ils sur un même projet ?

Si l’on observe attentivement les principes issus du PMI ou de Prince2, un projet ne doit avoir qu’un seul chef de projet. C’est un rôle unique. Or, il est courant de rencontrer plusieurs chefs de projet (du moins les nomme-t-on ainsi) au sein d’un même projet. Cette situation est pourtant un défaut dans l’organisation du projet. Mais alors, qui doit remplir ce rôle ? Le maître d’ouvrage ou le maître d’œuvre, le client ou le fournisseur ? La réponse est peut-être aucun d’entre eux…

Engagement au résultat

Prenons un cas que nous avons tous rencontré : un projet formé suite à une consultation (publique ou privée) où l’engagement demandé par le client est un engagement au résultat. Dès lors, le client considère souvent que le projet doit être porté par le fournisseur. Alors que ce dernier s’en arrange, ou, dans le meilleur des cas, proteste mollement de cet état de fait.
L’organisation de ce projet est alors constituée de 2 blocs : celui du client et celui du fournisseur. Éventuellement avec une organisation côté client, et éventuellement une organisation côté fournisseur (« éventuellement » car malheureusement il est aussi courant de voir que l’organisation n’a été pensée ni d’un côté ni de l’autre).
Dans ce cas, on arrive à un non-sens : deux organisations projet pour un même projet. Et une accentuation de ce non-sens : deux (parfois plus !) chefs de projet…
La question n’est plus seulement de désigner le chef de projet mais également : « qui doit faire partie de l’organisation du projet ? ».

Arrêtons-nous sur ce principe de l’Organisation

Considérons que notre organisation projet est une émanation du client (que nous désignerons par « l’Entreprise »). L’Entreprise met en place l’organisation du projet en désignant un groupe de personnes responsables du résultat (ou produit) de celui-ci. Ce groupe, que l’on appellera le Comité de Pilotage est formé dès l’origine du projet et existe avant même l’arrivée d’éventuels fournisseurs tiers.

Un premier niveau

Il constitue le premier niveau de l’organisation dans le projet : la Direction de projet.
Son rôle est de prendre les décisions dans le respect des contraintes et tolérances imposées par l’Entreprise. Le comité de pilotage est suffisant pour diriger le projet. En conséquence, il est inutile d’inventer des comités à tort et à travers : comité de direction, comité projet, comité de suivi, comité technique, comité de suivi des comités… Le comité de pilotage dirige le projet et est là pour prendre les décisions. Il est auto-suffisant.
Le comité de pilotage est lui-même constitué de manière formelle. Un exécutif (le représentant de la Direction de l’Entreprise au sein du projet), les représentants des utilisateurs  et les représentants des fournisseurs.

Nous pouvons donc en revenir à nos questions initiales, maintenant que ce premier niveau décisionnaire est posé. Où se situe le chef de projet par rapport au comité de pilotage ? Où est le fournisseur dans l’organisation ?
Commençons par le chef de projet : il ne fait pas partie du comité de pilotage. Attention, le Chef de Projet se réunit avec le Comité de Pilotage mais il ne fait pas partie de cette instance décisionnelle (cessons de confondre comité et réunion). Le chef de projet n’est pas là pour décider, mais pour gérer. Il dispose des 4 attributions du gestionnaire : planifier, déléguer, surveiller et contrôler (on pourra rapprocher ces attributions de la roue de Deming). Mais il n’a pas pour rôle de Décider.

C’est le 2ème niveau de l’organisation dans le projet

Le Management de projet est responsable de la gestion au quotidien selon les objectifs et tolérances définis par la Direction de projet.
Au tour du fournisseur maintenant. Il est responsable de la fabrication d’un composant du livrable final du projet (disons sous-produit). L’ensemble de ces sous-produits formeront le livrable final (disons le produit). On constate dès lors qu’il existe probablement plusieurs fournisseurs dans un projet, qui devront chacun fournir un ou plusieurs sous-produit.

C’est le 3ème niveau de l’organisation

Le niveau responsable de la Livraison des produits selon les objectifs et tolérances définis par le Management de projet.
Le fournisseur ne peut dès lors pas fournir directement le Produit du projet, sinon on se trompe de niveau. Dans ce cas, ce qu’on appelle le fournisseur serait alors le vendeur d’un produit fini, et il n’y aurait pas de projet ! Lorsque vous achetez une voiture, vous n’avez pas participé au projet de sa conception.

Mais alors où est ce fournisseur externe qui a remporté le marché et dont on aimerait bien qu’il prenne la responsabilité du projet ? Là encore entendons-nous sur les termes. On confond bien trop souvent le fournisseur des sous-produits dans un projet, et le fournisseur au sens de la relation commerciale.
La langue française utilise le même terme, l’anglais nous aide à mieux faire la différence entre « supplier » et « contractor ».

Le rôle du fournisseur

Le fournisseur (celui qui livre les sous-produits) met à disposition une équipe. En ce sens il apporte des équipiers et un chef d’équipe pour les encadrer. Il se situe au niveau Livraison de l’organisation. Le fournisseur (celui qui a remporté le marché) fait partie de cette organisation (il livre des sous-produits), mais ce n’est probablement pas le seul fournisseur. L’entreprise peut apporter des fournisseurs internes ou faire intervenir d’autres tiers pour certains sous-produits.

Par exemple, l’accompagnement au changement est souvent porté en interne ou confié à des prestataires spécialisés. En conclusion, le fournisseur « titulaire d’un marché » auprès de l’Entreprise est uniquement l’un des fournisseurs du projet dont le Chef d’Equipe rapporte au Chef de Projet. Nous avons vu précédemment que le groupe des fournisseurs est représenté au sein du comité de pilotage. Cette représentation devrait toujours faire partie de l’Entreprise, et ne pas être assurée par un fournisseur externe. C’est bien un des rôles de la DSI d’être le fournisseur des Directions Métiers, elle ne peut pas s’en décharger.
La DSI doit piloter ses fournisseurs externes et reste le fournisseur principal du projet.

Un rôle multiple

Cela nous amène au nœud originel de notre débat : ce qu’on appelle trop souvent « chef de projet » (du fournisseur) est en fait un chef d’équipe. Son rôle et ses objectifs dans le projet sont très différents du chef de projet. Il n’est pas là pour planifier, déléguer, surveiller et contrôler. Il est là pour Délivrer. Et surtout, ce n’est pas un rôle unique : il y aura autant de chefs d’équipes que d’équipes / sous-produits.
Ceci ne met nullement en cause la notion d’engagement du fournisseur tiers : il peut être en engagement de moyens ou de résultat. Mais quelle que soit la situation, il est nécessaire de bâtir l’organisation « cliente » (ou Entreprise). Il faut y incorporer le fournisseur et non pas créer deux organisations parallèles.

Faire partie intégrante de l’organisation 

Ainsi si l’on se place du côté du fournisseur, il devrait « exiger » de son client d’être incorporé dans une organisation formalisée. Si l’on se place du côté du client, entendu que le besoin de fournir un chef de projet est communément admis, celui-ci devrait se contraindre à mettre sur pied un comité de pilotage bien constitué.

Les trois niveaux d’organisation discutés ici sont explicitement proposés dans la méthode PRINCE2. Notre expérience nous a montré que leur mise en œuvre est une condition nécessaire à la communication. Notamment par la définition d’une terminologie commune et des relations entre les parties, et constitue l’un des leviers pour réussir un projet.