Clustering avec ChaRM

Certains responsables informatiques ont tenté par le passé d'introduire la gestion des demandes de changement. Le credo que je prêche toujours ici est le suivant : une demande d'un département spécialisé est approuvée par le biais d'une demande de changement et donne ensuite lieu à un ou plusieurs changements.

Cette déclaration contient déjà la première question :

Pourquoi plusieurs changes ?

Il est vrai que le Solution Manager maîtrise également plusieurs types de processus dans la gestion des demandes de changement. Par type d'opération, on entend essentiellement une construction composée d'un workflow, d'une définition du formulaire de changement, c'est-à-dire de l'interface et, en particulier pour les changements dans l'environnement SAP, bien sûr aussi de la connexion au système de transport.

Aucun autre outil de gestion des changements ne représente aussi bien ce lien entre le flux de travail et la mécanique d'importation via le STMS et ne dispose des mêmes fonctions que Solution Manager.

Les types d'opération "modification normale" et "modification urgente" ont été créés à cet effet. Or, il est évident que des exigences particulièrement complexes nécessitent des modifications non seulement dans un environnement SAP, mais aussi dans d'autres environnements système.

Pour cela aussi, le Solution Manager permet de définir un workflow et de l'utiliser. Le raccordement au système de transport n'existe évidemment pas ici et n'est d'ailleurs pas nécessaire.

Cette construction permet par exemple de représenter les modifications qui nécessitent des adaptations dans une interface SAP ainsi que sur une interface web. Les adaptations sur l'interface web seraient représentées de manière classique comme des changements "non-SAP".

Ce concept fonctionne très bien, car la demande de modification constitue toujours le lien entre les différents changements. Ainsi, la coordination des différentes modifications est assurée.

Sans demande de modification, cette mise entre parenthèses et cette coordination nécessaire dans le processus de modification ne peuvent se faire que très difficilement par le biais de champs supplémentaires sur le formulaire.

SAP a déjà mis à disposition dans la version 7.1 avec SP10 le thème selon lequel un client veut alimenter plusieurs lignes de système via un Change avec connexion de transport. C'est précisément ce composant qui s'appelle un cluster.

Un cluster peut ainsi être formé à partir d'un paysage BW et d'un paysage ERP. Ce cluster permet ensuite de gérer les changements qui ont lieu dans les deux paysages. Ainsi, il n'est pas nécessaire de gérer et de coordonner manuellement les modifications dans plusieurs paysages de transport.

Dans Solution Manager 7.1, cette technique en était encore un peu à ses débuts. Les clusters devaient toujours être identiques. Celui qui possède un paysage ERP avec trois systèmes avait donc aussi besoin de trois systèmes Business Warehouse pour réaliser cette logique. Avec Solution Manager 7.2, cela a changé et des clusters "inégaux" sont également possibles.

Tout cela sonnait tellement bien sur les diapositives que j'ai toujours défendu ce mode de fonctionnement auprès des clients. Ce qui m'a toujours étonné, c'est qu'il n'y avait que peu de discussions à ce sujet sur Internet, en particulier dans le SDN.

Depuis la dernière mise en œuvre, j'ai également compris pourquoi : ce que SAP ne dit pas ici, c'est que la "modification urgente", que la plupart des clients utilisent exclusivement, ne peut pas du tout utiliser cette fonction.

SAP n'a implémenté cette fonctionnalité de cluster que pour la "correction normale", laissant ainsi de côté en particulier les utilisateurs qui n'effectuent pas de développement orienté version. Même les clients qui effectuent un développement orienté version sont pénalisés : tous les changements au sein de la version maîtrisent le cluster.

Tous les autres changes de type "modification urgente" ne le sont pas. Un changement massif de mentalité s'impose donc ici.

Malheureusement, cela était si mal documenté que je suis moi aussi tombé dans le piège. Pour sortir de cette impasse, nous avons activé la collection de clusters également pour les "modifications urgentes" au moyen de spots d'amélioration et de quelques petites modifications.

J'espère que SAP comprendra et agira rapidement. Si nous, en tant que société de conseil, parvenons à activer cette fonctionnalité par le biais d'adaptations, SAP devrait y parvenir à plus forte raison.