Extensions ChaRMante

Lorsque nous parlons avec des clients de la gestion des demandes de changement (ChaRM), nous mettons toujours en avant comme composante essentielle qu'il existe deux types essentiels de ce que l'on appelle les types d'opération, qui sont déjà inclus dans le Customizing de la livraison : la "correction normale" et la "correction urgente".

Les deux workflows représentent la gestion des changements de logiciels et sont parfaitement intégrés dans le système de transport.

La principale différence entre les deux types : Les modifications normales ne peuvent être mises en production que sous la forme d'une version. Les corrections urgentes, prévues par SAP pour des adaptations immédiates et critiques, peuvent être mises en production à tout moment sans affectation de release.

Dans une livraison initiale, ces deux "workflows" sont présents dans le système et peuvent encore être adaptés en fonction des besoins du client, mais la forme de la mise en production (en tant que version ou individuellement) est fixée par le système.

De nombreux clients ne peuvent pas vivre avec une vision orientée sur les relances. Cela s'explique d'une part par le fait que les responsables informatiques ne veulent pas se fâcher avec le domaine spécialisé et ne veulent mettre des fonctions en production qu'à des moments précis. D'autre part, ils utilisent l'excuse "nous sommes agiles et ne pouvons donc pas nous engager sur une version".

C'est pourquoi la majorité des utilisateurs de ChaRM utilisent exclusivement la correction urgente. Dans les projets de mise en œuvre, il existe toutefois plus d'un workflow, de sorte que ce type d'opération est représenté dans le système sous différentes variantes - par exemple comme Preapproved Change et Major Change.

Le contexte derrière tout cela reste toujours la correction urgente et la chance qui en découle de mettre les Changes individuellement de manière productive.

Si l'on présente aux responsables informatiques la correction normale et son déroulement logiciel, on constate généralement un avantage important par rapport à la correction urgente : On travaille avec des transports de copies.

Comme les développeurs ne disposent généralement pas des données de test sur le système de développement qui sont pertinentes pour un test plus étendu, les modifications doivent être apportées au système d'assurance qualité et y être testées.

Dans le contexte classique, cela signifie que le transport doit être validé et importé. Ce n'est pas un problème en soi, la plupart des entreprises ont mis en place un système d'autorisation de telle sorte que les transports puissent être validés par les développeurs, et ont défini une importation automatique pour la file d'attente d'importation du système d'assurance qualité.

Mais dans la pratique, cela conduit souvent à développer, tester, développer et tester à nouveau. J'ai déjà vu des cycles de ce type pour des exigences, au cours desquels plus d'une centaine de transports ont été générés.

Dans l'utilisation classique d'une correction urgente, cela peut certes être représenté par le flux de travail et la protection contre les dépassements fait le reste, mais les mises en production de tels changements sont néanmoins importantes.

Avec les transports de copies, la file d'attente d'importation reste légère, car les objets sont certes placés dans le système suivant au moyen du type d'ordre "transport de copies", mais ces "tentatives" n'atterrissent jamais dans la file d'attente d'importation du système productif. Dans un tel contexte, plus de cent tentatives ne posent aucun problème.

Une caractéristique importante doit être prise en compte : Le transport original reste ouvert jusqu'à la fin des activités de développement et les objets sont alors fermement bloqués pour ce changement. Cela a l'avantage d'empêcher également les dépassements.

Avec des gestes habiles et un peu de codage, cette procédure peut être appliquée à la correction urgente. En outre, nous configurons généralement le flux de travail de manière à ce que le transport original ne soit validé qu'une fois les tests terminés par l'utilisateur clé.

Dans ce flux de travail, les dépassements appartiennent alors totalement au passé. Dans les environnements où l'on ne travaille qu'avec la correction urgente, l'utilisateur clé souhaite voir immédiatement ses modifications dans le système de production une fois les tests terminés.

Comme le delta de temps entre la validation des objets sur le système de développement et leur importation dans le système de production est faible (généralement moins d'un jour), il n'existe plus de problème de dépassement.