Le changement est permanent dans les systèmes d’information. Qu’il soit induit par une vision ou des ambitions stratégiques, par l’innovation, par l’amélioration de la qualité des produits et services dans le cadre d’une démarche de progrès continu, qu’il formalise les besoins du marché ou l’intégration de nouvelles contraintes, qu’il réponde aux nouvelles exigences ou aux réclamations de nos clients, le changement est un outil nécessaire à l’adaptation face aux besoins.
Accepter ou encourager le changement ne suffisent pas cependant. Une structure folle qui évolue sans cesse, hors de tout contrôle raisonné, n’a aucune chance d’atteindre un but prédéterminé. Et les structures ne jurant que par le changement sans en comprendre les subtilités existent, je les ai rencontré, pas vous ?
Définition de la gestion des changements
La discipline de Change Management fournit un cadre méthodologique à cette évolution continue. L’atteinte d’un bon niveau de performance dans cette gestion est un challenge majeur qui permettra une adaptabilité et une réactivité contrôlées face à un monde qui bouge vite.
Si le changement s’applique à tout, la gestion de configuration vient mettre un peu d’ordre préalable en définissant précisément le périmètre des changements : c’est le Produit que l’on souhaite gérer, qu’on l’appelle artefact, asset, système ou composant, que ce produit soit un processus, un logiciel, un serveur ou une organisation.
Pour le reste, la gestion du changement consiste principalement à identifier, sélectionner, réaliser et contrôler les actions à mettre en œuvre pour transformer une situation existante ( “as is” ou “current” ) en une situation future ( “to be” ou “target” ).
La gestion des changements au cœur de l’entreprise
L’amélioration de la qualité, la réduction des coûts, la productivité – en un mot l’optimisation – sont au centre des préoccupations des DSI.
- Les organisations élaborent désormais leurs processus de gestion à partir d’ensembles éprouvés de bonnes pratiques. Couvrant chacune une partie du cycle de vie du système d’information, ces approches méthodologiques ont toutes un point commun : intégrer la gestion du changement comme une bonne pratique majeure.
- Capability Maturity Model Integrated for Development (CMMi) du Software Engineering Institute (SEI) clarifie les processus et activités liés au développement de solutions informatiques et propose des bonnes pratiques pour l’ensemble du cycle de développement. Les exigences, les demandes de changements, les retours de test sont autant de changements au centre de la méthode. Le processus “Configuration Management” recommande une pratique fondamentale : “Track Change Request”. CMMi suggère en outre, dans ses niveaux de maturité élevés, des pratiques pour la gestion intrinsèque des processus et de leurs évolutions.
- Rational Unified Process (RUP) (IBM) définit des méthodes opérationnelles pour le développement itératif. Le cycle de vie de développement y est complètement traité. “Configuration and Change Management” est clairement décrit comme un des 3 processus support de la méthode.
- Les méthodologies Agile définissent une nouvelle approche du développement logiciel. Les cycles sont courts et basés sur des changements unitaires et identifiés (par exemple les User Stories de l’eXtreme Programming ou les Items de Backlog de SCRUM), groupés en releases ou en itérations flexibles, nécessitant une grande rigueur dans la gestion des changements.
- IT Infrastructure Library (ITIL) de l’OGC reconnait le “Change Management” comme un processus à part entière, et recommande une gestion des plus rigoureuses concernant les changements affectant les infrastructures IT. La gestion des changements IT est par ailleurs un maillon fondamental dans la chaîne d’un projet SI.
- La modularité des applications et la réutilisation de briques logicielles deviennent des points centraux de l’organisation des SI, concrétisés par la démocratisation de l’Enterprise Architecture, du SOA, et des technologies de mash-up. Ces solutions informatiques, s’orientant vers l’assemblage et la ré-utilisation de services applicatifs unitaires, nécessitent encore une fois la plus grande rigueur dans la gestion des dépendances, le versionning et la gestion des changements.
- Les entreprises améliorent la maturité de leurs processus métier et de leur système Qualité. On pense au Business Process Modeling, à l’analyse des systèmes piloté par les processus ou au niveau 5 du CMMi. Une fois encore, une identification précise de chaque élément (processus, procédure, document), de chaque changement et de ses impacts, accompagnée par des déploiements en release, deviennent la clé d’une gestion cohérente.
- Les politiques d’externalisation (exploitation, infrastructure, développement) vers des centres de services compliquent encore la problématique ; les organisations devant gérer les changements avec de plus en plus d’intervenants, géographiquement distant, voire dans des fuseaux horaires différents.
En résumé, les grands thèmes d’optimisation de l’entreprise cités ici impliquent tous l’identification, la traçabilité et le suivi des changements.
La gestion des changements des systèmes d’information
Concentrons-nous sur le cycle de vie du SI. Le diagramme ci-dessous en donne une vision simplifiée et illustre les principaux processus impactés par la gestion des changements.
- Les rectangles sur fond orange représentent les processus
- Les rectangles sur fond jaune représentent les assets
- Les flèches grises représentent les changements
Le tableau ci-dessous résume les changements à gérer par type d’artefact.
Artefact | Type de changement | Processus d’entrée | Origine des changements |
Processus Métier | Changement Process |
|
|
Services Applicatifs | Changement Logiciel |
|
|
Services IT | Changement Infrastructure |
|
|
Vu l’imbrication de la gestion de configuration et des changements tout au long du cycle de vie, une approche méthodologique débouchera sur l’établissement de ces disciplines en tant que processus à part entière pour l’ensemble de l’organisation.
Voici quelques exemples d’activités à mettre en œuvre, pouvant servir de base à l’élaboration du processus :
- Identifier les systèmes et les composants (configuration items)
- Gérer en configuration les systèmes et les composants
- Cartographier les dépendances entre les systèmes et les composants
- Identifier les changements et leurs dépendances
- Etudier les impacts des changements et approuver leur réalisation
- Assigner les changements au bon interlocuteur (y compris externe)
- Suivre l’avancement des changements jusqu’à leur réalisation
- Tracer les modifications réalisées dans le cadre d’un changement
- Créer des baselines
- Générer des release notes
- Déployer les baselines
Outiller la gestion des changements
Critères de sélection
En plus de couvrir les besoins fonctionnels du processus, un outil de gestion des changements doit être en mesure de gérer de nombreux problèmes :
- Sécurité des accès et propriété de l’information dans le cadre de prestations externes
- Responsabilité des traitements et traçabilité des actions
- Gestion de la communication et de la collaboration
- Recherche
- Génération de rapports et de tableaux de bord
- Personnalisation de la structure des données
- Ergonomie de l’interface
- Performance du système face aux volumes à traiter
- Accessibilité du système à distance
- Intégration avec des systèmes de gestion de configuration
- Intégration avec tout système externe
Une gageure supplémentaire consiste à fournir une solution suffisamment robuste d’une part, pour permettre aux grandes structures d’appréhender les différents domaines dans leur globalité ; et suffisamment flexible d’autre part, pour permettre aux petites organisations de bénéficier d’une solution légère directement opérationnelle.
Enfin la configurabilité est un élément clé. L’utilisation d’outils trop spécifiques (purement orienté sur le développement, le support ou la gestion des processus) ne cadre pas avec la souplesse requises par cette approche unifiée de la gestion des changements.
Couverture des besoins par JIRA
Reprenons nos différentes exigences pour estimer le taux de couverture offert par JIRA :
Exigence | Couverture | Description |
Identifier les systèmes et les composants (configuration items) |
|
|
Gérer en configuration les systèmes et les composants | JIRA ne propose pas de fonctionnalité de gestion physique des assets ni de versionning. Il faudra le coupler avec un système de gestion de source comme Subversion, ClearCase ou Mercurial. | |
Cartographier les dépendances entre les systèmes et les composants | JIRA ne fournit pas de fonctionnalité de gestion des dépendances entre les systèmes et les composants. Il faudra recourir à d’autres outils. On peut citer par exemple Maven pour la gestion des dépendances logicielles, ou RPM pour la gestion des packages OS. | |
Identifier les changements et leurs dépendances | C’est la fonction principale de JIRA.
|
|
Etudier les impacts des changements et approuver leur réalisation |
|
|
Assigner les changements au bon interlocuteur (y compris externe) |
|
|
Suivre l’avancement des changements jusqu’à leur réalisation |
|
|
Tracer les modifications réalisées dans le cadre d’un changement |
|
|
Créer des baselines |
|
|
Générer des release notes |
|
|
Déployer les baselines |
|
|
Sécurité des accès et propriété de l’information dans le cadre de prestations externes | Les possibilités de permissions de JIRA sont nombreuses :
|
|
Responsabilité des traitements et traçabilité des actions |
|
|
Gestion de la communication et de la collaboration |
|
|
Recherche | C’est encore un point fort de l’outil :
|
|
Génération de rapports et de tableaux de bord |
|
|
Personnalisation de la structure des données |
|
|
Ergonomie de l’interface |
|
|
Accessibilité du système à distance |
|
|
Performance du système face aux volumes à traiter |
|
|
Intégration avec des systèmes de gestion de configuration |
|
|
Intégration avec tout système externe |
|
Conclusion
En synthèse, face aux mastodontes coûteux et parfois décevant, Atlassian JIRA fournit toutes les briques de base pour modéliser, construire et personnaliser tout ou partie d’une solution de Change Management ; et offre de plus une excellente architecture technique pour un déploiement d’envergure.
- Structure orientée produit (projets, composants)
- Approche orientée processus (contextes, workflows et rôles)
- Gestion des versions
- Gestion des permissions étendues et hautement configurable, y compris au niveau des workflows
- Collaboration maximum (workflows, notifications, commentaires)
- Dashboard et rapports intégrés
- Fortes capacités de configuration (écrans, modèle de données)
- Interface Web dynamique
- Intégration native avec les outils de gestion de configuration leaders sur le marché
- Excellente extensibilité fonctionnelle (plugins, API, framework de développement Java)
- Extensibilité technique maximale avec une architecture J2EE
- Coût modique
Au delà de la gestion des changements, JIRA a également fait ses preuves dans la gestion d’un Service Desk et certains voient en lui un candidat pour la prochaine génération d’ERP.