La bonne manière de travailler semble être de :
- prévoir une liste de fonctionnalités (backlog) et d'estimer le budget correspondant
- définir des sous ensembles de ces fonctionnalités, avec un cycle de livraisons fréquent (qq semaines)
=> l'utilisateur peut concrétiser son besoin et réagir rapidement
=> on décide de modifier certaines fonctionnalités, d'en ajouter ou d'en retrancher
=> on ré-estime le budget et le planning
si il dépasse ce qui était prévu (ce qui est majoritairement le cas), on a 2 choix : - conserver le budget initial => il faut enlever d'autres fonctionnalités ou les retarder (les placer sur le budget de l'année suivante)
- accroître le budget (c'est souvent la première solution qui est choisie)
- industrialiser les développements et les livraisons pour que les livraisons ne soient pas chronophages mais de qualité
Ces méthodes commencent à se répandre de plus en plus dans les services informatiques des entreprises, les sociétés de services, et de manière moins visible chez les éditeurs (bien que les nouvelles applications web aient tendance à suivre ce rythme élevé de livraisons fréquentes, initié par Google depuis qq années).
Il me semble que les projets concernant le décisionnel, qui souffrent d'une réputation de projets lourds et coûteux, auraient tout intérêt à rapidement adopter ces méthodes, d'autant que les nouveau outils BI me semblent plus adaptés (cf. l'article sur ce sujet : Les nouveaux outils de pilotage de l'entreprise).
De la même manière que pour les projets de développement classiques, la rigueur dans la conception et le développement, l'outillage et l'industrialisation des développements et des livraisons sont les conditions du succès.
Prenons un projet "classique" décisionnel :
- des besoins identifiés avec les utilisateurs : comment les valider si ce n'est en leur mettant sous les yeux un tableau de bord affichant les indicateurs
=> identifier le domaine fonctionnel prioritaire (en général celui qui va faire gagner rapidement de l'argent à l'entreprise) et dans ce domaine les indicateurs critiques (idem)
=> construire le modèle de données
=> identifier les données source
=> construire l'alimentation
=> construire le tableau de bord, les rapports
=> les montrer aux utilisateurs - Réactions, retours des utilisateurs : 2 cas :
- nouveaux indicateurs, nouveaux axes d'analyse
=> rebelote : analyse des données sources, modif du schéma du datawarehouse, modif des alimentations, modif des tableaux de bord - détail supplémentaire dans les tableaux ou ajout de donnée déjà présente dans les tables du datawarehouse : la modif peut même se faire "en live" avec l'utilisateur
Tout ceci, bien outillé, normé, industrialisé, peut se faire rapidement, je dirais même plus rapidement qu'un projet classique car
- les modèles de données décisionnels sont plus simples que les modèles des applis transactionnelles
- le "code source" est structuré par les outils et on peut en général rapidement identifier les impacts d'une modification
Cela fait aussi l'objet d'un article récent sur le blog : Un outil décisionnel disponible en quelques semaines ?
Et c'est le principe de base du pack Performance, dédié aux métiers de la supply chain : http://www.6it.fr/static9/pack-performance.htm
Et c'est le principe de base du pack Performance, dédié aux métiers de la supply chain : http://www.6it.fr/static9/pack-performance.htm
Aucun commentaire:
Publier un commentaire