Management Agile et décisionnel

Comment le "cœur statistique" de l'entreprise, c'est-à-dire ses systèmes d'aide à la décision, peut-il bénéficier du management agile et des méthodes Agile ?

L'informatique décisionnelle ("business intelligence" en anglais, "intelligence d'affaires" en québécois) existe depuis 20 ans et on parle de management agile depuis également 20 années. Pourtant, ces deux disciplines semblent s'ignorer depuis deux décennies. Notons tout de même que la première rencontre entre les fondateurs du Scrum eut lieu dans les locaux de Vmark Corp. (Jeff Sutherland y travaillait et Ken Schwaber y réalisait une prestation), un éditeur de logiciels dédié à l'informatique décisionnelle qui deviendra un des leaders mondiaux des logiciels ETL sous la dénomination "Ascential Software".

Comment le "cœur statistique" (les systèmes d'aide à la décision) des entreprises (et les équipes informatiques impliquées) peut-il bénéficier du management agile et des méthodes Agile ? Une étude du groupe indépendant Forrester Consulting "La Business Intelligence agile" (publiée le 2 octobre 2009 et réalisée pour le compte de SAP Business Objects) a mis en valeur les problèmes qui restent à résoudre dans l'informatique décisionnelle (dans le cadre du développement spécifique au sein des TI).

Dans un premier temps, 30 décisionnaires des Ventes, du Marketing et des Finances (sur plusieurs continents) ont répondu à des questions portant sur l'utilisation des applications décisionnelles mises à leur disposition par les équipes informatiques. On peut résumer ainsi:
- un sur 3 n'utilise pas les applications et 9 sur 10 utilisent surtout un tableur (Excel),
- un sur 3 a des difficultés à se faire comprendre des équipes informatiques,
- un sur 3 passe plus de temps à chercher les informations à analyser plutôt qu'à les... analyser.

Dans un second temps, 82 responsables informatiques ont répondu à des questions portant sur l'autonomie des utilisateurs pour le développement de rapports ou de tableaux de bord. On peut encore résumer :
- plus de 70% des responsables ont reconnu que les rapports et les tableaux de bord des utilisateurs étaient développés par leurs ressources informatiques,
- près de 60% ont précisé que des utilisateurs avancés pourraient développer eux-mêmes leurs rapports et leurs tableaux de bord.

Enfin, le groupe Forrester Consulting a identifié des divergences entre les attentes des décisionnaires vis-à-vis des informaticiens et... réciproquement. Ces divergences peuvent être regroupées de cette façon (les attentes des décisionnaires sont citées en premier) :
- "Souplesse et agilité" contre "Contrôle et gestion du risque",
- "Impératifs métier" contre "Normes",
- "Réactivité" contre "Planification",
- "Interaction" contre "Recueil des besoins".

Ces oppositions ne signifient pas que la gestion du risque ou la planification sont futiles mais posent la question : comment les équipes informatiques peuvent-elles opérer pour que la gestion du risque et la planification ne pénalisent ni leur agilité ni leur réactivité ?

On peut synthétiser l'étude Forrester de la façon suivante :
- les applications sont sous-utilisées et cette sous-utilisation pénalise l'autonomie des décisionnaires,
- les attentes réciproques des parties concernées (décisionnaires et informaticiens) ne se rencontrent pas encore suffisamment.

Avant d'aborder la plus-value des méthodes Agile pour résoudre ces problèmes, dressons un rapide historique des méthodes (ou des "recueils de pratiques") du management informatique.
La première méthode ("System Development Methodology") date des années 60 et nous vient directement du secteur du Bâtiment et des travaux publics, sans adaptation pour l'informatique. L'approche est simple: on commence par les fondations et on finit par le toit, et le retour arrière (démonter le 3è étage pour refaire le 2è, par exemple) est hors de question. Cette approche est encore utilisée aujourd'hui sous l'appellation "Waterfall model" en Amérique du Nord et "SDM/S" (le plus souvent) en Europe. Cette méthode est classifiée dans la famille des méthodes dites "linéaires" (ou séquentielles ou "en cascade").

Il faudra attendre 1979 (et Barry Boehm) pour que le "linéaire" soit adapté à l'informatique sous la forme des cycles en V et des cycles en spirale. Dans le cycle en V, on s'autorise à revenir en arrière (dans le cadre de certains processus). Dans le cycle en spirale, on s'autorise à itérer un projet et à découper chaque itération en phases (on parle d'itérations longues : entre 6 et 24 mois chacune).

La seconde génération de méthodes naît en 1987 avec la méthode dite "Objectory Process" (qui survivra sous sa variante "Unified Process"). La troisième génération dite "semi-itérative" préfigure les méthodes Agile. Elle naît officiellement en1991 avec l'ouvrage "Rapid Application Development (RAD)" de James Martin. La même année, un franco-canadien résidant au Canada, Jean-Pierre Vickoff, l'implémente dans des projets et fera sa promotion en France sous l'appellation RAD2. Dans le "semi-itératif", toute la conception est définie en début de projet et, ensuite, les développements font l'objet d'itérations courtes (entre 2 jours et 2 semaines).

La dernière génération est celle des méthodes de management Agile (Scrum, XP, ...). C'est l'ère de l'itératif qui itère également la conception et qui augmente sensiblement la durée des itérations (4 ou 5 semaines le plus souvent). En 2001, 17 experts du développement logiciel rédigent un manifeste Agile qui constitue l'acte de naissance du mouvement Agile.

En quoi ce manifeste peut-il aider à résoudre les problèmes résiduels dans le décisionnel ? Dans son introduction, ce manifeste identifie des priorisations qui optimisent le développement :
- "Les individus et leurs interactions plus que les processus et les outils"
- "Des logiciels opérants (acceptés par l'utilisateur) plus qu'une documentation exhaustive"
- "L'adaptation au changement plus que le suivi d'un plan"

Ces priorisations ne signifient pas que l'outil ou le plan sont futiles mais que l'efficience d'un développement est étroitement liée à l'interaction entre les individus. Si on multiplie les interactions entre les informaticiens et les décisionnaires, ces derniers augmenteront leur autonomie et, du même coup, leur capacité d'adaptation au changement dans leurs secteurs respectifs (ventes, marketing, RH, ...).

Le corps du manifeste regroupe 12 principes applicables dans tout projet de développement et dont l'objectif est double : la satisfaction de l'utilisateur et l'efficience.
On ne les citera pas tous et on s'intéressera aux principes qui peuvent avoir une valeur ajoutée intéressante pour le décisionnel.

"Livrer (...) régulièrement des fonctionnalités à grande valeur ajoutée"
La statistique étant au cœur des décisions de l'entreprise, quelle équipe informatique peut se permettre de mettre en production tous les 9 ou 18 mois seulement ? Sur un marché très compétitif, cette fréquence de livraison est un frein à la capacité de décision et, du même coup, à la compétitivité de l'entreprise. Enfin, les efforts entre les fonctionnalités de base et les fonctionnalités à forte valeur ajoutée sont-ils toujours équilibrés ?

"Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif"
Dans le domaine de l'aide à la décision, tout changement sur un marché compétitif devient une opportunité à saisir. Lorsque la fréquence de livraison est trop basse, les demandes de changement forment une pile décourageante (et les priorités finissent par se diluer dans la masse). En augmentant la fréquence de livraison, tout changement de scope est une occasion de donner un avantage compétitif à l'entreprise.

"Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement"
On assiste de plus en plus à l'éclosion d'environnements de développement informatique fortement "matriciels" avec des ressources très réparties sur le plan administratif et géographique. Hors, dans l'informatique décisionnelle, la communication quotidienne entre les utilisateurs et les informaticiens reste nécessaire. Il est possible de couper la poire en deux : une "matrice" de ressources informatiques qui tourne autour d'une unité permanente de R&D décisionnelle (et opérationnelle...). La permanence d'une telle unité garantit aux décisionnaires de l'entreprise une disponibilité et une réactivité de l'informatique.

"La méthode la plus simple et la plus efficace pour transmettre de l'information à l'équipe de développement (...) est le dialogue en face à face."
Les besoins des utilisateurs dans le domaine de la décision sont souvent d'une complexité fonctionnelle tels que le courrier et le document électronique deviennent mal adaptés pour transmettre efficacement cette complexité.

Pour approfondir le sujet, on peut suggérer l'essai de Ralph Hughes "Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and Xp". C'est le premier ouvrage sur le sujet proposé par des librairies en ligne.

Enfin, on concluera avec les prospectives 2020 d'un groupe de travail dit "2020 Vision" (animé par Bob Lokken, directeur Business Intelligence chez Microsoft). Les principales conclusions de ce groupe sont :
- 90% des données restituées aux décisionnaires le seront sur des supports nomades,
- Les volumes de données exploseront au point de refondre nos plates-formes,
- L'information sera gérée ("lead") par les responsables utilisateurs,
- On oublie le "18 mois de délai de livraison" : il faut sortir des sentiers battus.


Liens
La Business Intelligence agile, Forrester Consulting, 2009
Manifeste pour le développement Agile, 2001

Autour du même sujet