L’arrivée d’une version finalisée au vocabulaire adapté de CMMI for Services est une bonne nouvelle pour les entreprises de services, mais également pour toutes les organisations qui font des projets…
Avant l’arrivée du modèle CMMI for Services (CMMI-SVC), les organisations qui mettaient en place CMMI devaient faire face à des choix particulièrement délicats :
- Doit-on privilégier les projets (et n’impliquer qu’une partie des collaborateurs) ou décliner le mode projet sur les autres activités (et impliquer tout le monde) ?
- Doit-on différencier projet et maintenance au risque d’être incompréhensible pour des collaborateurs qui font les deux à la fois ?
- Quel seuil se donner pour séparer la maintenance et les projets ?
- Comment traiter l’assistance aux clients ?
- Comment intégrer les SLA existants avec les clients ?
En conjuguant CMMI-DEV et CMMI-SVC, l’organisation va progressivement trouver des réponses à ces questions.
Il est généralement facile de cerner les services proposés par la fonction informatique :
- Assistance (à plusieurs niveaux)
- Corrections d’urgence
- Maintenance corrective
- Maintenance évolutive
- Petits projets.
Les petits projets sont souvent vécus comme du service :
- Nombre de fonctionnalités limité (quelques dizaines)
- Fonctionnalités exprimées par rapport à un existant (déjà plus des solutions que des besoins « purs ») ; on va alors parler de « créer une interface », « ajouter la donnée », « transmettre les données de l’appli par telle interface », « compléter le rapport avec », « se connecter au Portail », …
- Répartition sur plusieurs applicatifs avec, parfois, des livraisons désynchronisées,
- Pas ou très peu de modifications d’architecture,
- Pas ou très peu de migration de données,
- Risques limités de non régression.
Quoique déclarés « petits », les charges induites par ces projets peuvent être significatives : jusqu’à plusieurs centaines de jours.
Les services définis, CMMI-SVC devient un outil facile à mettre en œuvre :
- s’appuyant essentiellement sur l’existant,
- ne demandant qu’une mise en forme un peu plus poussée (définition de SLA sur la base de l’existant, mise en place d’outils de suivi) pour un peu plus de rigueur,
- facile éventuellement à outiller avec l’offre actuelle du marché.
Les gains associés à cette mise en forme sont :
- visibilité,
- identification des difficultés résiduelle,
- convergence entre le management (« savoir ce qui se passe ») et les équipes (« partager les problèmes »),
- et finalement un meilleur service.
Ceci cadré, on peut se concentrer sur les « vrais projets » avec CMMI for Development :
- la compréhension de CMMI devient rapidement beaucoup plus aisée ;
- les pratiques délicates prennent plus facilement du sens (par exemple appliquer la traçabilité puis détecter les incohérences dans le cadre d’un gros projet, ou revoir les estimations en cours de route, faire des revues qualité, auditer les configurations ou surveiller des indicateurs) ;
- faisant sens, la mise en place des outils et documents est plus rapidement appliquée ;
- le recours aux outils pour automatiser devient aussi plus rentable.
En étant plus adapté sur chaque activité, l’obtention des niveaux 2 puis 3 devient plus facile et plus rapide.
