Offensive ChaRM

Avec la version 7.2 de s, SAP modifie également certaines choses dans la gestion des demandes de changement, notamment dans le lien entre les demandes de changement et la documentation.

Jusqu'à présent, c'est un point qui m'a toujours étonné lorsque j'ai parlé avec des clients de la gestion du changement et de la gestion de la documentation qui y est liée.

L'introduction d'un ChaRM est certainement judicieuse, mais elle doit aussi être bien planifiée. Il est impossible de le lancer comme un sous-marin dans la base SAP et de le laisser apparaître à un moment donné.

Étant donné que la gestion du changement couvre toutes les disciplines, de la demande à la mise en production, via un workflow, il va de soi que différents secteurs sont impliqués, de l'informatique aux services spécialisés.

La première étape commence par un objectif essentiel. Pourquoi un service informatique veut-il introduire la gestion des demandes de changement en premier lieu ?

Quels sont les objectifs associés ? Ces dernières années, j'ai vu ici tout un portefeuille d'objectifs. De la prévention des ruptures de médias à la question des exigences réglementaires, de nombreux objectifs sont légitimes.

Il est toutefois important de fixer cette consigne, idéalement associée à des garde-fous, car il est toujours possible, lors d'une discussion ultérieure sur les processus et les procédures, de se rappeler dans quelle mesure les différentes variantes contribuent à l'objectif.

Les introductions ChaRM qui remplacent simplement un outil existant - même s'il s'agit d'Excel sur un Windows Share - sont généralement vouées à l'échec. Avec une introduction ChaRM, il convient également de discuter des procédures existantes.

Il est donc important d'élaborer un concept de processus. Je considère que les prototypes ChaRM, qui sont ensuite utilisés dans un environnement système productif une fois le customizing de base terminé, n'ont pas beaucoup de chances d'aboutir, car on y renonce généralement aux processus et à la documentation.

Ce n'est qu'une fois le concept établi qu'il est judicieux de le mettre en œuvre. Pour ce faire, les points suivants devraient notamment être considérés et détaillés pour l'élaboration :

• Quels sont les processus de changement actuellement en place pour les modifications SAP ?
• Comment documenter à l'avenir une modification de logiciel ?
• À quoi ressemblent les paysages cibles ?
• Comment le blocage d'objets inter-systèmes est-il géré ?
• Comment les exigences sont-elles décrites et par qui sont-elles approuvées et planifiées ?
• Une gestion des versions est-elle souhaitée ?

Il existe donc de nombreux points en suspens qui ne peuvent certainement pas être résolus dans le cadre d'un atelier. Ils nécessitent au contraire une discussion animée, même au sein d'un service informatique.

Comme les processus informatiques ne peuvent pas non plus être définis de manière démocratique à la base, il faut ici que la direction informatique les définisse. Le sujet qui m'a le plus surpris ces derniers mois est celui d'un client qui voulait certes mettre en place un processus de changement général, mais qui souhaitait reproduire un workflow spécial pour deux utilisateurs clés. C'est précisément ce genre de tresses qu'il est judicieux de couper.

Les autorisations sont un sujet très apprécié. Malheureusement, un client qui ne dispose pas d'un flux de travail ChaRM ne documente généralement ses exigences et ses changements que de manière très rudimentaire.

Pourtant, ces mêmes clients craignent que chaque utilisateur clé puisse lire les demandes de modification du service voisin. Il est certes possible de mettre en place des constructions d'autorisations approfondies dans le Solution Manager, mais il faut alors bien se demander si cela vaut vraiment la peine d'investir dans l'administration.

Il n'est pas difficile de faire en sorte que seul le collaborateur informatique affecté au changement puisse le traiter. Mais je me demande toujours comment le client veut agir si ce collaborateur tombe malade.

Comme le thème de la documentation est également étroitement lié à ChaRM, cet aspect doit également être clarifié. Il est important de définir des modèles et de les exiger dans les workflows respectifs pour une demande de changement ou une modification.

En somme, un concept et une feuille de route sont les éléments les plus importants pour une introduction réussie. Comme c'est souvent le cas dans le domaine des outils de cycle de vie des applications, la mise en œuvre technique est celle qui demande le moins d'efforts.

Les changements organisationnels ne doivent pas être négligés et sont souvent les garants d'une introduction réussie.