La gestion des versions sous un nouveau jour

Ceux qui me connaissent savent que j'ai toujours été un adepte de la gestion des versions et que j'en parle régulièrement à mes clients lors d'ateliers et de journées de conseil. Malheureusement, il ne m'est pas si facile de convaincre les utilisateurs lors des ateliers et des journées de conseil.

Les contre-arguments habituels sont que le domaine spécialisé ne peut pas attendre les exigences, mais qu'il doit les mettre en production dès qu'elles sont prêtes.

Si l'on creuse un peu plus, on s'aperçoit que le service spécialisé pouvait parfois attendre très longtemps avant de procéder au test. En résumé, dans l'environnement SAP, nous sommes malheureusement habitués, de par notre histoire, à importer des modifications presque quotidiennement.

Certains utilisateurs SAP parlent alors volontiers d'une "version quotidienne" dans ce contexte. Alors que nous sommes habitués à attendre des versions ou des Support Packages dans d'autres applications - personne n'installerait au hasard des fonctionnalités individuelles dans son bureau -, dans SAP, c'est souvent une idée nouvelle pour les utilisateurs et les services informatiques.

Cela a eu pour conséquence que la "correction normale" n'a généralement pas été utilisée par les clients, car la "correction urgente" est plus pratique. Il n'est pas nécessaire de planifier des versions, mais il est toujours possible de mettre en production des modifications individuelles - si le service le souhaite.

Le passage d'un "continuous development" à une release ne se fait évidemment pas immédiatement et en appuyant sur un bouton. Les changements nécessaires en termes d'organisation sont généralement beaucoup plus profonds.

Jusqu'à présent, la gestion des versions a toujours été très rigide. On me demandait toujours ce qui se passerait si, pendant la mise en œuvre, on décidait de ne pas mettre en ligne certaines exigences ou de les reporter à la prochaine version.

SAP a réagi à tous ces thèmes. Alors qu'auparavant, il y avait différents projets Solution Manager auxquels étaient attribués des changements individuels, la version 7.2 est une véritable version.

Auparavant, chaque modification demandée et approuvée via un workflow devait être attribuée à un projet avant d'être validée. Malheur à celui qui avait mal attribué une modification à un projet.

Une fois que le changement était déjà en cours de développement, cela ne pouvait être corrigé qu'au prix d'un travail manuel important. Les clients ont parfois eu recours à des modules complémentaires pour transférer le changement dans un autre projet.

Heureusement, la création d'une version a lieu lorsque nous parlons d'une véritable mise en production. Ce n'est pas tout à fait conforme à ce que nous connaissons dans l'environnement non-SAP. Mais c'est probablement l'une des possibilités de convaincre les utilisateurs de la gestion des versions dans SolMan. Un changement organisationnel est toujours nécessaire.

L'IT est appelé à discuter avec les départements spécialisés, à établir un planning des releases et aussi à se mettre d'accord sur une véritable distinction entre les exigences urgentes et les modifications qui doivent faire partie d'une release.

J'ai toujours des clients qui craignent précisément ce conflit et qui commencent à regrouper les projets sous forme de versions. Tout ce qui n'est pas un projet, c'est-à-dire qui ne dépasse pas un certain volume de travail, est traité comme une "modification urgente".

Au premier abord, cela semble simple. Mais si l'on considère le contexte de la commande de transport, les choses sont nettement plus compliquées.

Comme les "modifications urgentes" doivent toujours être attribuées à un projet, elles sont importées une nouvelle fois lors de la mise en production afin de garantir la synchronisation. Cela signifie toutefois que les clients qui gèrent plusieurs projets en parallèle doivent toujours attribuer toutes les "modifications urgentes" au projet qui sera ensuite mis en production.

Dans la pratique, c'est plus que compliqué. Le gestionnaire de changement se retrouve comme un caniche arrosé lorsque deux projets jouent à la roulette à court terme. Il faut alors réorganiser les changements, ce qui n'est pas possible aujourd'hui dans la version 7.1 en appuyant sur un bouton.

Avec SolMan 7.2, le client peut désormais soit développer entièrement "en urgence" et toujours tout mettre en production, soit procéder à une véritable mise en version au moment de la mise en production.

Au total, il s'agit d'une extension réelle et extrêmement précieuse. Le défi pour les responsables informatiques est maintenant d'ancrer la réflexion sur les versions dans leur propre entreprise, y compris dans le contexte SAP.