Comment appliquer le lean-agile dans un projet Progiciel ou ERP ? Comment penser son projet avec l'agilité ? Quels sont les apports du lean-agile dans un contexte "on-th-shelf" Une présentation du cabinet Kraft Inside

1. kraft me up #2
Le Lean-Agile dans un contexte Progiciel
Les avantages de l’agilité pour l’intégration d’un
produit on-the-shelf

2. POURQUOI RÉALISER UN CAHIER DES CHARGES ?
 Pour s’assurer des engagements du soumissionnaire en terme de périmètre
 En définissant dès le départ l’ensemble des fonctionnalités requises
 Pour s’assurer de l’adéquation technique
 En définissant l’architecture cible compatible à date avec le SI
 Pour s’assurer du coût global
 En définissant le budget maximum nécessaire pour la réalisation du périmètre fonctionnel
défini
 Pour avoir le contrôle prédictif sur la solution déployée
 Pour piloter la relation avec le tandem éditeur-intégrateur
 Pour tenir l’engagement de délai de déploiement
LA DECISION SE BASERA SUR CES ENGAGEMENTS DEFINIS DES LE DEPART
POUR MINIMISER LES RISQUES INHERENTS A UN CHANGEMENT DE PRODUIT

3. POUR QUELLE TRAJECTOIRE ?
Décision
d’investissement
Déploiement
complet production
Temps d’intégration de
l’innovation dans le produit
Temps de l’intégration du
produit
Sélection
prestataires
Temps de sélection
2 - 3 ans 1-2
ans
Etat de
l’art
6 mois – 1 an
Délai global d’adoption de
l’innovation

4. VERS QUELS RÉSULTATS ?
• A périmètre fixe, la solution déployée est déjà dépréciée et datée !
• En contre mesure et pour réaligner le produit sur l’état de l’art il devient nécessaire de demander des
changements et des adaptations du périmètre avant même le déploiement.
• L’intégrateur s’accroche à son engagement initial et facture lourdement des changements qui remettent en
cause une partie du travail déjà réalisé
• L’architecture technique de la solution n’est plus conforme aux pratiques du SI, celui-ci ayant évolué
• Les coûts augmentent pour intégrer les demandes hors du périmètre initial et les adaptations techniques
correspondantes
• Les délais se sont allongés pour essayer de fournir une solution fonctionnelle juste convenable
• Les clients sont insatisfaits, ayant le sentiment d’obtenir un outil juste standard (alors même que le coût
est supérieur au budget provisionné)
BUDGET & DELAI SUPERIEURS
SATISFACTION CLIENT MOYENNE

5. RÉÉVALUONS LES ATTENTES … LIÉES AU CAHIER DES CHARGES
 Pour s’assurer des engagements du soumissionnaire en terme de périmètre
 En définissant dès le départ l’ensemble des fonctionnalités requises
 Pour s’assurer de l’adéquation technique
 En définissant l’architecture cible compatible à date avec le SI
 Pour s’assurer du coût global
 En définissant le budget maximum nécessaire pour la réalisation du périmètre fonctionnel défini
 Pour avoir le contrôle prédictif sur la solution déployée
 Pour piloter la relation avec le tandem éditeur-intégrateur
 Pour tenir l’engagement de délai de déploiement
ON FAIT QUOI ALORS ?

6. ON FAIT QUOI ALORS ?

7. COMMENT FAIRE DIFFÉREMMENT ?
 Adopter une démarche apprenante
 Abandonner le cahier des charges qui se construit sur la base de ce qui est déjà connu et non
ce qui pourrait être innovant
 Ne pas fixer le périmètre fonctionnel sur la base de connaissances à priori Donner la vision de
la cible plutôt qu’une liste de fonctionnalités
 Opérer la sélection des partenaires sur la base de leur ouverture et flexibilité plutôt que la
couverture fonctionnelle à date

8. COMMENT FAIRE DIFFÉREMMENT ?
 Conserver des options, retarder les décisions
 Démarrer rapidement pour rassembler des données et apprendre sur les partenaires et les
solutions
 Partir avec 2 à 4 possibilités, sélectionnées à partir d’un RFI et engagées sur un plan capacitaire
pour un premier incrément renouvelable selon résultat
 Réduire et décider le groupe de soumissionnaires à la fin de chaque incrément

9. COMMENT FAIRE DIFFÉREMMENT ?
 Laisser de la place à l’innovation au travers une démarche Agile
 Mettre en place un dispositif SAFe rassemblant l’ensemble des acteurs du programme
 Respecter un espace de réflexion et pour analyser les données et résultats recueillis
 favoriser l’expérimentation qui déclenche l’innovation en continu

10. POUR QUELLE TRAJECTOIRE ?
Décision
d’investissement
Prestataires
participants
R.F.I.
3 mois 3 mois 3 mois 3 mois
1erincrément
Sprintfonctionnalitésclés
Démo +
Sélection
2ndincrément
Sprintfonctionnalités
innovantes
3emeincrément
Démo +
Sélection
Sélection du
Partenaire
final
Démo +
Expérimentation
Démo +
Expérimentation
Démo +
Expérimentation
Déploiement continu
1er
Déploie
ment

11. RÉÉVALUONS LES ATTENTES
• Le périmètre fonctionnel répond aux vrais attentes des utilisateurs à la date de déploiement.
• L’architecture technique s’est adaptée aux expérimentations et les normes SI ont pu s’adapter.
• Les coûts sont maîtrisés par un budget capacitaire linéaire et constant.
• Les décisions impliquent tous les acteurs ce qui garantie la transparence et le partage des choix.
• La relation avec l’éditeur est saine en partageant les mêmes objectifs.
• Les délais sont respectés car le déploiement se réalise de façon continue.
• L’expérimentation est permise et l’échec accepté car les risques sont minimisés par la démarche
agile.