Les acteurs de la Transformation partagent approche et outils

1. Décomposition de l’approche de Transformation

   1. Il est plus difficile de Modéliser la Transformation que les Opérations

      La Transformation comporte des risques importants.
      Elle procède par itérations successives.
      Il est donc extrêmement difficile de Modéliser l’ensemble d’un Processus de Transformation : la Transformation ne consiste pas à dérouler un processus précis et pré-défini, mais plutôt à laisser jouer des acteurs dans un cadre qui définit un certain nombre de principes, de bonnes pratiques et décrit les conditions de succès d’une Transformation.

   2. Les Processus de Transformation

      Il existe différents Processus de Transformation : Concevoir un nouveau Produit, Construire une Solution, Construire une Solution innovante, mais aussi Modifier une Solution (évolution ou correction de « bug »), Construire des Fondations, Définir une Road-Map,...
      Ce document développe surtout le Processus de Construction ou de Modification de Solutions.

   3. Un Processus de Transformation est décomposé en Phases

      On sait bien formaliser les Processus Opérationnels comme le Processus de commande et on les automatise progressivement. C’est beaucoup plus difficile pour les Processus de Transformation comme le Processus de Construction d’une Solution, compte tenu des incertitudes de tout projet.

      De nombreux progrès ont néanmoins été accomplis : chaque Entreprise a défini son propre Processus de Transformation en le décomposant en Phases progressives.

      Chaque Phase a un objectif et un livrable. Un Jalon de fin de Phase permet de faire le point, de valider le Livrable et de passer à la phase suivante.

   4. Chaque Phase fait appel à des Fonctions

      Le schéma ci-dessous essaie de présenter les Processus de Transformation d’Air France, Axa, BNP Paribas et Total tels qu'ils existaient en 2010.
      Chacun de ces Processus est particulier : il a fait l’objet de longues discussions au sein de chacune de ces entreprises, et il appliqué par les différentes équipes de Projet.
      Mais bien que ces Processus soient différents, ils réutilisent tous des Fonctions de Transformation identiques.

      Par exemple la Phase « Pre Study » d’Air France utilise les Fonctions « Définir le Problème » et « Evaluer le coût d’investissement » qui sont aussi utilisées par les autres Processus.

      Chaque Fonction peut être activée plusieurs fois dans le même Processus: par exemple la Fonction « Évaluer le coût d’Investissement » est affinée dans chaque Phase pour donner des résultats de plus en plus précis. De même la Fonction « Modéliser les Processus » est utilisée dans plusieurs Étapes pour détailler progressivement les Processus concernés.

      

   5. Fonctions d’Ingénierie et Fonctions de Gestion

      On distingue deux types de Fonctions :
      • les Fonctions d’Ingénierie (comme « Modéliser les Processus ») pour bien Construire la Solution
      • les Fonctions de Gestion (comme « Planifier ») pour bien Gérer le Projet.

      Les Fonctions d’Ingénierie sont les Fonctions Métier de la Transformation : elles doivent être accomplies quelle que soit l’Organisation en place. Les Fonctions de Gestion sont les Fonctions Organisation de la Transformation : elles dépendent étroitement de l’Organisation et de l’Approche. Elles sont donc spécifiques à chaque Entreprise, alors que les Fonctions d’Ingénierie sont universelles.

   6. Progrès dans la Gestion mais insuffisances dans l’Ingénierie

      De nombreux projets souffrent d’une mauvaise gestion de projet : les Phases ne sont pas formalisées, les livrables ne sont pas fournis, le planning est incomplet, les affectations d’acteurs ne sont pas anticipées, le reporting est oublié, les décisions ne sont pas formalisées...

      Les organismes de définition des méthodologies comme CMMI ou Open Group (TOGAF®) ont bien approfondi les Fonctions de Gestion de la Transformation. Les Entreprises ont sensiblement progressé en tirant parti de leurs propositions et en maitrisant de mieux en mieux la Gestion de Projet. On est passé d’une période d’improvisation à une période d’amélioration continue qui est bien illustrée par les niveaux de maturité du CMMI qui définissent comment une Entreprise progresse dans sa gestion de projet.

      Les Progrès ont surtout porté sur la Gestion. A titre d’exemple, les recommandations du Standish Group sont essentiellement des recommandations de bonne Gestion :
      • L'engagement de la direction
      • L'implication des utilisateurs
      • L'expérience du chef de projets
      • La formulation des objectifs métiers
      • Une envergure limitée aux besoins essentiels
      • Une infrastructure technologique normalisée
      • Des spécifications précises et stables
      • Des méthodologies formelles et utilisées
      • Des estimations fiables et rigoureuses
      • Autres : découpage des livraisons, Compétence du personnel, etc.

      Il faut poursuivre dans cette voie d’amélioration de la Gestion, mais ne pas tomber dans l’excès : trop de tâches de Gestion empêchent le chef de projet de se consacrer aux Fonctions d’Ingénierie. On peut bien Gérer le projet d’une Solution mal Construite.

2. Comment Transformer le Modèle de Transformation ?

   De façon surprenante, de nombreuses Entreprises qui ont su si bien optimiser leurs Processus Opérations de back office ou de Production, n’imaginent pas qu’il soit possible de progresser fortement dans l’Agilité et beaucoup n’envisagent pas de refondre des Processus de Transformation qu’elles ont eu tant de mal à faire respecter.

   1. Une approche pluridisciplinaire

      Définir une seule Approche partagée par tous les participants à la Transformation, en particulier le Métier et l’IT, ce qui n’est pas encore le cas dans toutes les Entreprises.
      Cette Approche sera d’autant mieux acceptée que l’on aura au préalable défini le langage de la Transformation et le langage du Métier.

   2. Des outils de Modélisation partagés

      La Transformation doit être Outillée comme les Opérations: aussi bien pour gérer que pour construire.
      • Des outils pour gérer : gérer le planning, les ressources, les incidents, le budget, la communication…
      • Des outils d’ingénierie : outils de conception et de simulation 3D, outils de cartographie, outils pour modéliser des produits, des exigences, des processus, des logiciels, des interfaces utilisateurs, outils pour contrôler la qualité du Modèle, tester, documenter, analyser les performances, outils collaboratifs, outils de gestion de configuration…
      
      Le choix de ces Outils est primordial pour l’efficacité des Transformations.
      Sans entrer dans les détails nous recommandons de privilégier
      • Les outils qui collent à l’Approche
      • Un minimum d’outils compatibles à périmètre large plutôt qu’une grande variété d’outils qui nuit à l’approche pluridisciplinaire
      • Des outils « round trip » qui permettent une approche itérative: on Modélise le Métier et il génère automatiquement une partie du Logiciel, on Modifie le Logiciel et il met à jour automatiquement le Modèle Métier.
      • Des outils qui incluent la gestion de l’évolution dans le temps (versioning)
      • Des outils qui s’appuient sur un Modèle d’Entreprise unique mais offrent différentes visions adaptées à chaque profil d’Acteur.

3. Modèle de Transformation pour un Projet

   Ce schéma décrit succinctement le Processus de Transformation pour un Projet simple.
   • Définir le But du Projet de Transformation (doit tenir en une ou deux pages)
   • Définir le périmètre et la volumétrie associée : géographique, Ligne Produit, Domaine de Processus, segment de clientèle…
   • Définir les objectifs et les indicateurs associés pour vérifier le résultat obtenu à l’issue du programme
   • Nouvelle gamme de Produit
   • Nouveaux Processus : productivité, qualité de service, nouveaux canaux de distribution, nouvelle réglementation
   • Remplacer une Solution obsolète
   • Gagner en agilité : time to market…
   • Définir les contraintes sur le Projet de Transformation
   • Contraintes sur les budgets, les délais, l’utilisation de ressources internes
   • Contraintes liées aux Solutions existantes : on ne peut pas faire moins bien en fonctionnalités et en interfaces
   • Définir la Fondation
   • Choisir ou confirmer un Modèle de Transformation et former les équipes de Transformation
   • Approche et Outils
   • Composants : Comprendre les Composants réutilisables pour économiser la charge du Projet et standardiser l’utilisation de la Solution
   • Concevoir l’Architecture : les échanges entre Solutions et l’Architecture interne de la Solution
   • Définir le planning du Projet et son budget
   • Construire (ou Modifier) le Modèle de Solution ou le Modèle de Produit (par développement ou configuration)
   • Construire le Modèle (Documentation et Logiciel)
   • Pour Modèles d’Acteurs : Organisation, Rôles, affectation des Activités aux Rôles
   • Pour Modèles d’Actions : définir les Processus Métier, les décomposer en Fonctions Métier, puis définir les Processus Organisés et les Activités
   • Pour Modèles d’Information : définitions Métier et IT des Objets Métiers, des Relations, des Héritages, des Attributs, des Types
   • Interfacer la Solution et intégrer les différents logiciels
   • Vérifier la Solution : tests puis recette
   • le « quoi » : les fonctionnalités offertes et les performances
   • le « comment » : qualité de construction de la Solution
   • Déployer la Solution ou le Modèle Produit
   • Migrer les informations
   • Réorganiser Unités et locaux
   • Affecter et Former les Acteurs Opérationnels
   • Affecter, installer, configurer les Acteurs-IT
   • Préparer la hot line

4. Modèle de Transformation pour un Programme composés de plusieurs Projets

   Lorsque l’ambition de la Transformation est grande, on doit découper le Programme en Projets pour éviter l’effet tunnel et isoler des Projets de durée courte.
   On distingue alors
   • le But global du Programme et le But individuel de chaque Projet qui contribue au But global
   • la Fondation du Programme qui va donner la cohérence d’ensemble

   En outre on doit décomposer le Programme en Projets ce qui permet de fournir une première estimation de coût et de délai pour l’ensemble du Programme. Ces couts et délais sont ensuite précisés Projet par Projet.

   Comme les Projets sont exécutés par des équipes dispersées, il est nécessaire d’intégrer les résultats de chaque équipe pour s’assurer que l’ensemble fonctionne bien en respectant les conditions de fiabilité et de performance.

   Enfin, on doit Déployer : soit Projet par Projet, soit en regroupant les résultats de plusieurs Projets.

   Remarque : pour les Programmes les plus complexes on peut envisager plus de 2 niveaux (Programme, Projet), mais le principe est le même : pour obtenir un découpage en unité de Transformation maitrisable il faut une Fondation : Modèle de Transformation, Composants et Architecture.

   Il est recommandé de faire un bilan des Programmes et Projets :
   • Est-ce que le But a bien été atteint ? vérifier avec les indicateurs
   • Quelles leçons en tirer ?
   • Est-ce que l’Approche de Transformation peut être améliorée
   • Bilan de l’architecture
   • Quels nouveaux Composants sont réutilisables pour la Fondation

5. L’approche Devops pour accélérer les mises en production

   La démarche "devops" vise à accélérer le processus complet de transformation qui est freiné par les mises en production informatique. Dans certaines grandes entreprises on met un mois à fabriquer un nouveau Modèle et 6 mois pour le mettre en Production et l’offrir aux utilisateurs.
   Voir Wikipedia sur DevOps

   ll ne s'agit pas de fusionner les équipes de développement (la « Transformation ») et de production (« les Opérations ») mais de prendre en compte de façon plus efficace les processus de mise en production lorsque l'on développe de nouvelles applications.
   Plus on automatise la mise en production, plus on déploie rapidement les nouveaux Modèles. Le rythme et la fréquence des Transformations s’accélère pour devenir un flux continu d’améliorations.