Quand l'expert-comptable vient deux fois

Presque tous les grands clients SAP ont en horreur la visite de l'expert-comptable. Le contrôle annuel régulier prévoit de déterminer au hasard, à partir de la file d'attente d'importation du système de production, un petit nombre à deux chiffres d'ordres de transport pour lesquels il s'agit de trouver la documentation des exigences, l'acceptation des tests ainsi que la validation pour la mise en production.

Certaines entreprises s'acquittent de cette noble tâche en essayant de rechercher de la documentation dans les boîtes aux lettres électroniques. La plupart du temps, l'auditeur découvre l'une ou l'autre de ces "trouvailles" et demande qu'il y soit remédié avant la prochaine date d'audit.

Outre le thème de la traçabilité des modifications, une gestion des changements dans Solution Manager a bien sûr bien d'autres avantages à offrir : une documentation rigoureuse et complète de toutes les modifications apportées au système, qui n'est pas seulement pertinente pour les auditeurs, mais qui peut également être d'une valeur inestimable pour le propre service informatique.

En outre, les responsables informatiques peuvent obtenir de précieux indicateurs de la gestion des changements et améliorer massivement la sécurité de la planification des versions, des modifications ainsi que des mises à niveau.

Gestion des incidents

La gestion des changements s'appuie toujours sur la gestion des incidents. Des changements peuvent certes être nécessaires en raison de la définition de nouveaux processus commerciaux, mais dans de nombreux cas, un changement est lié à une perturbation sous la forme d'un incident.

Il est préférable de le saisir dans un service desk interne à l'entreprise. La question de savoir si le Solution Manager est approprié ou non dépend des conditions internes.

Les interfaces permettent une intégration dans les outils de Service Desk existants, mais la devise est la suivante : plus la forme d'intégration est intensive, plus l'exploitation et le projet d'implémentation initial sont coûteux.

Les nouvelles interfaces web ont également fait leur entrée dans le Service Desk, de sorte que la gestion des incidents peut désormais être introduite sans crainte dans toute l'entreprise.

Par le passé, les responsables informatiques étaient encore réticents à l'idée de faire profiter les utilisateurs non SAP d'une interface ABAP spécifique et vieillotte et de l'utilisation d'un SAPGui.

Cela n'est désormais plus nécessaire avec les nouvelles interfaces, car la gestion des incidents ne se distingue guère des autres outils commerciaux en termes de confort d'utilisation.

Gestion des problèmes

La gestion des problèmes est une nouveauté de la version 7.1. Conformément à ITIL, un incident ne se transforme normalement pas immédiatement en modification, mais d'abord en problème. Ce n'est qu'à partir d'un problème que l'on peut ensuite créer un changement.

La gestion des problèmes n'a toutefois pas pour seule mission de faire passer les incidents, mais aussi d'identifier et d'adapter les problèmes structurels avant que les erreurs et les messages des utilisateurs finaux ne s'accumulent.

De nombreux clients de la classe moyenne sont déjà occupés à développer et à vivre la gestion des incidents et des changements dans l'entreprise et vont d'abord mettre la gestion des problèmes au second plan.

Gestion du changement

La gestion des changements dans Solution Manager fait la distinction entre les modifications normales et les corrections urgentes. Les deux types d'opérations sont intégrés dans un projet et y sont liés.

Outre la parenthèse logique des modifications, le projet remplit également une autre fonction essentielle. Le statut du projet ("en développement", "test", "productif") permet de contrôler quand et dans quelle infrastructure système les corrections normales sont importées.

La véritable force du Solution Manager réside dans l'intégration parfaite du transport avec la gestion des modifications. Un ordre de transport ne peut être créé que s'il existe un document de modification approuvé.

L'importation des ordres de transport se fait via la correction normale ou urgente qui y est liée. Les e-mails envoyés par les développeurs aux responsables de la base SAP pour leur demander d'importer un transport appartiennent donc au passé.

Par rapport à la version précédente 7.0, SAP a fait beaucoup de progrès. Le changement le plus important et le plus visible est sans doute le nouveau front-end compatible avec le web. L'utilisateur peut désormais mieux configurer l'affichage d'une modification et s'y retrouve mieux que dans l'ancienne interface CRM vieillotte.

En outre, des Business Add-Ins ont également été implémentés à de nombreux endroits, permettant aux clients d'adapter la gestion des changements à leurs propres besoins. Un exemple classique est l'attribution de désignations d'ordres de transport.

Une exigence courante est toujours que la désignation ne puisse pas être modifiée par l'utilisateur, mais qu'elle soit imposée par le système grâce à une nomenclature définie. Grâce à un nouveau Business Add-in créé par SAP, cette exigence peut être mise en œuvre rapidement et facilement.

La peur des dépassements

Tous les responsables de la base SAP connaissent le problème pénible des erreurs d'importation dues à l'absence de transports dépendants. La situation devient explosive lorsque plus de mille ordres de transport s'accumulent dans la file d'attente d'importation en attente de mise en production.

La plupart du temps, l'ensemble de la file d'attente n'est pas importé avec le fameux gros camion pour des raisons de cohérence. Au contraire, certains ordres de transport sont importés au préalable en tant que "dépasseurs".

Si un ordre de transport plus ancien est mis en production un jour, il peut arriver que le code qui fonctionne soit réinitialisé ou, pire encore, que les adaptations des tables soient annulées.

La protection contre le déclassement du gestionnaire de solutions avertit les responsables informatiques de telles situations critiques avant l'importation. Cela fonctionne grâce à l'extension de la gestion classique du blocage des objets du workbench. Le Solution Manager sait à tout moment quelle version d'un objet de transport est actuellement importée dans quel système.

L'embarras de la gestion des versions

La plupart des clients de taille moyenne ont souvent du mal à discipliner leurs départements spécialisés vers des versions d'entreprise ou au moins des versions trimestrielles de SAP.

Souvent, les exigences naissent spontanément et doivent être mises en œuvre d'autant plus rapidement. Les responsables informatiques considèrent souvent qu'une planification et une mise à disposition des fonctionnalités à des dates définies sont trop rigides.

La correction normale n'est donc que rarement utilisée, la plupart du temps les clients utilisent exclusivement l'instrument de la correction urgente. La correction urgente permet à tout moment un transport dans le système de production et offre donc la flexibilité souhaitée, contrairement au fonctionnement orienté sur les versions de la correction normale.

Pour trouver un compromis, SAP a introduit le concept de pré-correction. Les corrections normales peuvent être mises en production à l'avance au moyen d'un workflow d'approbation séparé, c'est-à-dire avant la date de la version proprement dite.

Les gestionnaires de changement et les responsables du développement disposent ainsi de la flexibilité nécessaire pour mettre à disposition rapidement les modifications non planifiées et ne pas renvoyer le département spécialisé à la prochaine fenêtre de release.

En résumé, l'utilisation de versions est dans tous les cas recommandée, ne serait-ce que pour miser sur une gestion cohérente des tests. Si les modifications sont transportées en continu dans le système d'assurance qualité et mises en production en fonction de la situation, on ne teste jamais ce qui est également importé dans le système de production.

La gestion du changement devient particulièrement complexe lorsqu'un paysage de projet doit être mis en place parallèlement à un paysage de maintenance à trois systèmes. Cela n'a de sens que si des fonctionnalités supplémentaires doivent être mises à disposition à certaines dates clés et si la maintenance doit être séparée du développement du projet, même du point de vue du système.

Les adaptations de format auxquelles les fournisseurs d'énergie sont toujours confrontés le 1er avril et le 1er octobre en sont un exemple concret. Un paysage à cinq systèmes, tel qu'il est désormais recommandé par SAP, exige également une discipline dans la gestion du changement.

En particulier, toutes les modifications implémentées dans l'environnement de maintenance doivent également être appliquées dans l'environnement de projet. Cela peut bien sûr se faire manuellement, mais cela ne devrait pas durer longtemps avant que l'un ou l'autre ordre de transport ne soit perdu et, dans le pire des cas, que la nouvelle version ne soit mise en production de manière incohérente.

Retrofit, en tant que composant du Solution Manager, permet d'importer toutes les adaptations de l'environnement de maintenance dans l'environnement de projet par une voie automatisée.

Pour les ordres de Customizing, cela se fait à l'aide de BC-Sets, pour les ordres de workbench, le code est transféré à l'aide de liaisons RFC. Bien entendu, tout cela ne fonctionne que si les entrées de table concernées ou les artefacts du workbench n'ont pas encore été modifiés dans l'environnement de projet.

Si une modification a été effectuée dans les deux environnements système, un éditeur d'écran partagé est présenté à l'utilisateur et le développeur doit décider comment traiter les modifications.

Le processus de rétrofit a encore été massivement amélioré dans la version 7.1 du gestionnaire de solutions et peut désormais être recommandé sans restriction. Une comparaison manuelle dans un environnement à cinq systèmes est quasiment impossible pour les grands projets. Dans ce contexte, il est dommage que la fonctionnalité Retrofit ne soit accordée qu'aux clients disposant de SAP Enterprise Support.

Conclusion

Avec Solution Manager 7.1, un outil professionnel est disponible pour la gestion des changements et des versions. Malgré tout, il faut tenir compte de l'adage informatique classique "there is no silver bullet" (il n'y a pas de balle d'argent).

Un outil ne peut jamais être considéré comme une panacée. Il est d'abord essentiel de définir des processus de changement et de release et d'adapter les procédures organisationnelles.

Q-Partners Consulting et Management accompagne les clients, entre autres, dans la définition d'une feuille de route, l'introduction de processus et l'implémentation de processus de gestion des changements et des versions dans Solution Manager.

En plus des standards SAP, Q-Partners met à disposition ses propres add-ons pour la gestion des changements, qui simplifient et optimisent le travail avec les corrections urgentes et normales.