Privilégier une approche agile

Agilité: un avantage concurrentiel majeur
1. Réactivité et Agilité
  Servir rapidement un Client, faire rapidement tourner son stock, régler rapidement ses fournisseurs... s’appelle « Réactivité des Opérations» : une Entreprise est réactive si son Modèle d'Opération lui permet de réagir vite et bien aux sollicitations de ses Clients, Partenaires, Fournisseurs...
  Mais si le Modèle lui-même doit être transformé vite et bien, il ne s’agit plus d’Opérations mais de Transformation : la Réactivité est l’Art d’Opérer vite et bien alors que l’Agilité est l’Art de Transformer vite et bien.
2. Pourquoi plus d’agilité est requise ?
  
  L’Agilité est recherchée par toutes les Entreprises parce qu’elles sont confrontées à un environnement de plus en plus mouvant qui les contraint à un changement continu.
3. Etre capable de « Bouger Vite » est plus important que « Voir loin »
  
  Comme il est impossible de garantir que les innovations initiées dans l’Entreprise seront meilleures que celles des concurrents, il semble que la stratégie la plus sûre pour accroitre l’efficacité soit non seulement d’innover par soi-même, mais surtout de mettre au point des Processus de Transformation plus agiles que ceux des concurrents, pour implémenter rapidement les innovations venues d’ailleurs et corriger ses points faibles plus rapidement que ses concurrents. En ce sens, l’Agilité devient la qualité majeure d’une Entreprise : si la productivité ou la qualité ou la fiabilité sont faibles, si les produits sont trop classiques ou trop chers, … l’Agilité permet de les améliorer rapidement. Il suffit d’identifier ses faiblesses et de bénéficier de son Agilité pour corriger le tir.
  Pour être agile, la Grande Entreprise peut acquérir des start-up, copier des innovations réussies par certains concurrents, et obtenir un véritable avantage concurrentiel non pas parce qu’elle « voit loin », mais parce qu’elle « bouge vite ». La Stratégie n’est plus basée sur la prévision de plus en plus aléatoire du futur, mais sur la saisie d’opportunités dont l’Entreprise sait tirer parti plus rapidement que ses concurrents.
4. La difficulté des Transformations
  
  D'après les résultats des études publiées par le Standish Group, le taux de succès des projets informatique est toujours faible.
Comment être plus agile ?
1. L’agilité : une question rarement abordée
  
  Les Opérationnels identifient des domaines où ils recherchent plus de réactivité, plus de qualité de service. On affecte des budgets à des projets qui visent à optimiser le Modèle d’Opération.
  Par contre, on identifie mal que l’on peut aussi améliorer les Processus de Transformation pour davantage d’agilité, pour davantage de qualité. La raison essentielle en est que l’on n’imagine pas que l’on puisse Transformer plus rapidement, et que de toutes façons les processus budgétaires ne font pas de place à ce type d’investissement.
2. Adopter une Approche agile
  
  Ne pas contraindre le Métier à tout spécifier, procéder par versions successives, mettre l’accent sur la qualité de la Construction de la Solution pour qu’elle accepte rapidement des modifications dans les Versions ultérieures.
3. Accélérer la construction de Modèles
  1. Une vision globale de l’Architecture
    
    Plutôt que le recensement exhaustif des besoins, privilégier la Construction d’une Architecture de Solution capable d’accueillir des incréments successifs au fur et à mesure de la maturation des besoins.
  2. Construire à base de composants
    
    Une nouvelle forme de réutilisation: non plus réutiliser des Solutions-Progiciel que l’on peut adapter à la marge, mais réutiliser des Composants que l’on peut assembler pour construire des Solutions innovantes, différenciantes
  3. Des outils adaptés
    
    L’Approche Agile est plus efficace si elle s’appuie sur un Modèle unique de la Solution : toute modification qu’elle provienne d’un changement Métier ou d’un changement IT met à jour le Modèle unique et modifie instantanément les Vues offertes à chacun. On parle d’Outils « Round Trip »
  4. La puissance de configuration
    
    Isoler les parties de la Solution qui bougent fréquemment, pour permettre leur modification sous forme de configuration : il doit être possible de modifier un tarif, une règle d’éligibilité, un commissionnement… sans avoir de talents de développeur informatique.
  5. Le soin apporté à la facilité d’usage
    
    Puisque les utilisateurs recherchent un usage homogène, la meilleure façon de faire respecter cette homogénéité passe par la mise à disposition de composants d’usage standardisés dont la réutilisation par les constructeurs de Solutions, garantit la standardisation d’usage bien mieux que ne feraient la mise à disposition de normes documentaires.
4. Attitude
  
  Comme évoqué par ailleurs, d’autres facteurs jouent sur l’agilité :
  - Equipe de Transformation pluridisciplinaire et non équipes séparées
  - Savoir prendre des risques
  - Gouvernance adaptée
  - peu de bureaucratie
D’une approche linéaire à une approche agile
1. Une approche linéaire pour les Solutions de Commodité
  
  Dans l’Approche Linéaire, couramment pratiquée, on effectue toute la Modélisation Métier de la Solution avant de travailler sur sa Modélisation IT. C’est une manière efficace de s’assurer que la Solution IT répond bien aux besoins du Métier, ou que les « Fonctionnalités » sont Modélisées avant de développer le logiciel.
  C’est particulièrement le cas lorsque la partie IT est sous-traitée à une équipe externe. La Vérification est alors une Fonction qui ne peut avoir lieu que lorsque la partie Informatique est terminée. Cette approche conduit à bien séparer les équipes Métier et Informatique : le lien doit être fait sous forme d’un document contractuel appelé « cahier des charges », ou « spécifications détaillées ».
  
  Pour se doter de Solutions de Commodités, les Entreprises ont développé une Approche Linéaire qui privilégie la sécurité ou la fiabilité à l’agilité.
  On a commencé à déployer des « Solutions de Commodité » qui automatisaient les Processus bien définis de gestion de Ressources, de pilotage, de réglementation. Les objectifs essentiels étaient la productivité, la fiabilité, la visibilité.
  
  Les Processus de Transformation de l’Entreprise qui sont adaptés aux « Solutions de Commodité" ne sont pas toujours suffisamment agiles, souvent parce qu’ils ont été définis à une époque où la pression était moins forte, où les besoins étaient plus facilement prévisibles, où les technologies balbutiantes nécessitaient de lourds contrôles, où l’usage des outils de développement informatiques nécessitaient de définir tous les besoins avant de faire.
  
  Cette lenteur de la Transformation interne, qui a pour conséquences un accroissement des coûts associés, est caractérisée par l’établissement d’un Contrat qui contient le Modèle Métier à traduire en Modèle IT, la séparation des équipes Métier et IT, et une multiplicité de Rôles qui nécessitent de gérer leurs relations.
  
  Cette lourdeur a permis à une industrie du Progiciel de se développer rapidement en se présentant comme une alternative aux Solutions spécifiques. Les ERP ont résolu les besoins des financiers, des ressources humaines, de la gestion de production, de la productivité des back offices, du reporting,... parce que les besoins de commodité n’étaient pas très éloignés d’une Entreprise à l’autre, et que l’on pouvait donc construire une Solution commune à plusieurs Entreprises.
  L’Approche Linéaire est aujourd’hui plus diffusée que l’Approche Agile. Elle résout des Problèmes bien cernés tels que automatiser les Back Offices, la gestion des ressources, la Comptabilité, ... bref pour Construire des Solutions de Commodité.
2. Une approche Agile pour les Solutions Métier
  
  Dans l’Approche Agile, on ne détaille pas toute la Vision Métier du Modèle avant d’entamer la Modélisation Informatique. La définition des Fonctionnalités est progressivement affinée au fur et à mesure des itérations. Cette approche est préférable lorsque les spécifications sont incertaines et que l’on souhaite construire des Solutions Évolutives plutôt que des Solutions définitives, c'est-à-dire des Solutions Métier et non des Solutions de Commodité. Cette approche est plus rapide, elle gomme l’effet tunnel, elle ne contraint pas le Métier à définir tout son Modèle avant de passer la main à l’Informatique, elle fluidifie la relation Métier-IT, elle permet une vérification progressive, elle permet d’associer Métier et IT dans une équipe mixte seule responsable de la Solution, mais elle ne peut être choisie que si le Modèle global de la Solution supporte les adjonctions ultérieures.
  
  L‘Approche Linéaire est mal adaptée aux nouveaux Problèmes extensibles tels que l’automatisation du Marketing, de la relation Client, des Solutions Web ou mobiles offertes aux Clients, de la Gestion des campagnes commerciales ou de la Business Intelligence, de la multiplicité des canaux de distribution, de la conception de produit et du time to market: la Modélisation Métier de ces domaines est progressive, chaque nouvelle version de la Solution aide à préciser les contours de la version suivante. Elles sont toutes caractérisées par l’impossibilité a priori de définir tous les besoins.
  1. Comment réussir ?
    
    Pour réussir, il faut respecter les règles suivantes
    - dissocier le Cœur-Métier et l’Organisation : on définit le « quoi » avant de définir le « qui »
    - suivre la séquence « Objets, Fonctions, Processus»,
    - réutiliser un maximum de Composants.
    - prévoir que tous les éléments du Modèle vont évoluer (tous les éléments du Modèle doivent intégrer une gestion de Version)
    - demander aux meilleurs « Modeleurs » de se consacrer à la Construction des Modèles de Solutions ou Fondations; ne pas les surcharger par des tâches de pure gestion, ils représentent une ressource rare
    - faire certifier la qualité du Modèle Global par des experts
    - limiter les spécifications fonctionnelles par la date et non par le périmètre fonctionnel.
    Remarque : pour ceux qui souhaitent aller plus loin, voir les Livres Blancs du CEISAR sur Modélisation des Entités du Métier et Modélisation des Processus.
  2. Savoir arrêter une version
    
    Comme l’a évalué un des Sponsors du CEISAR, il faut avoir consommé 40% de la charge de Modélisation pour obtenir une évaluation précise à 10% : plus on souhaite être précis dans l’estimation, plus il faut s’avancer dans le projet.
    Comme on ne définit pas tout ce qu’il faut faire avant de faire, il faut définir une règle pour arrêter une Version.
    Le perfectionnisme est dangereux : de nombreux projets ont des difficultés parce que les Maitrises d’Ouvrage craignent d’oublier des exigences et ne savent quand arrêter d’en ajouter pour livrer une première Version. Ils se rappellent l’approche : « si vous oubliez des exigences, il sera coûteux et long de les prendre en compte dans les versions suivantes ».
    Il faut les aider à appliquer la règle suivante : « comme il est aisé de passer à une nouvelle version incrémentale, livrons rapidement une première version pour offrir un premier niveau de service aux Acteurs». Naturellement, s’’il s’agit du remplacement d’une Solution ancienne, il faut au moins reprendre les Fonctions qui étaient offertes par l’ancienne Solution.
    La bonne règle est de fixer une date limite réaliste pour la première version, ce qui a pour conséquence que les Maitrises d’ouvrage doivent désigner un leader capable de faire le tri entre les exigences progressives pour tenir la bonne date. Ce principe de sobriété est la clé d’une approche agile réussie. La première version doit livrer :
    - L’Architecture de la nouvelle Solution qui doit permettre des incréments rapides
    - Les Fonctionnalités qui étaient déjà offertes par l’ancienne Solution
    - Quelques Fonctionnalités supplémentaires séduisantes pourvu qu’elles soient compatibles avec l’échéance fixée.
La méthode agile pour concevoir des Biens

La méthode agile est aujourd’hui massivement utilisée pour Construire des Solutions ou des Services. Certains ont décidé de Construire aussi des Modèles de Biens en s’inspirant des méthodes agiles.
On doit être capables de concevoir de nouveaux Biens comme on conçoit des logiciels (voir Le Monde - Méthodes agiles, gérer les entreprises comme des logiciels).
Cet article présente le projet Wikispeed dont l’objectif est de construire une voiture rapide, consommant peu (2,5 L/km) et répondant à toutes les normes de sécurité, en utilisant une méthode agile. Le véhicule est décomposé en huit modules qui évoluent chacun par itérations rapides d’une semaine. Le Client assiste à une démonstration des nouveautés chaque semaine.
Le résultat est spectaculaire : cette voiture a concouru aux X-prize et a fini dixième sur 136 compétiteurs dont la majorité disposait de budget à plusieurs millions de dollars... face à un budget de quelques dizaines de milliers de dollars.
Les plans, fichiers 3D, documentation du premier véhicule de Wikispeed, le SGT01ont été publiés dans une licence libre accessible à tous : le Modèle devient accessible à tous les « Opérateurs ».