La bonne transition vers SolMan 7.2

Pour de nombreux responsables informatiques, la Conversion sur le Solution Manager 7.2 est toujours un livre aux sept sceaux.

En outre, tous les clients n'ont pas encore compris que la fin de la maintenance au 31.12.2017 est vraiment définitive. Il vaut mieux ne pas s'attendre à une prolongation de la maintenance par SAP, en raison de restrictions techniques.

La planification commence par se demander très concrètement sur quelle Plate-forme le SolMan sera exploité à l'avenir.

La licence Hana pour l'exploitation du SolMan est mise à disposition du client par SAP sans frais de licence, en particulier si l'utilisateur SAP n'a pas encore de licence Hana.

En 2020, la nouvelle S/4 Hana Business Suite sera lancée. D'ici 2025 au plus tard, les clients seront obligés de passer à Hana.

Avec l'introduction et le Saut quantique sur S/4 Hana, il y a de toute façon suffisamment de sujets à régler pour une IT, de sorte qu'une nouvelle technique serait alors un sujet de plus.

Il est donc judicieux de se pencher dès à présent sur la question de l'éducation. Conversion et de faire passer le Solution Manager à Hana. Outre les conditions purement techniques, il faut tenir compte du fait que SAP a établi une liste de fonctionnalités.

D'un point de vue technique, je recommanderais à chaque client d'effectuer une copie du gestionnaire de solutions existant en production. La mise à niveau peut ensuite être testée "en toute tranquillité" sur cette copie.

Certes, la copie du système SolMan est liée à de nombreuses retouches, mais cela a un sens dans le contexte actuel.

La plus grande partie des changements concerne la documentation des solutions. Mais cela est aussi clairement communiqué par SAP. Ce que certains utilisateurs ne connaissent certainement pas, c'est la forme de la Conversion et la conversion.

En principe, les artefacts et les documents peuvent être repris lors de la mise à niveau.

Après la mise à niveau, tout ce qui n'est pas repris n'est accessible qu'en mode lecture seule. La définition du contenu qui sera repris s'appelle le scoping.

Ce qui est piquant, c'est que le rapport de conversion ne peut être exécuté qu'une seule fois, à savoir pendant la mise à niveau. Si le scoping n'était donc pas correct, tous les documents doivent être recréés et reliés à la main.

Dans ce contexte, il vaut vraiment la peine pour les clients de s'entraîner à la mise à niveau sur une sandbox, afin de pouvoir revenir à un ancien snapshot en cas d'erreur de scoping.

Gestion des tests

Le deuxième grand domaine qui connaît des changements est celui de la gestion des tests.

Les documents et plans de test sont étroitement liés à la documentation de la solution. Comme la structure et la définition de la documentation de la solution changent, cela doit également faire l'objet d'un accord conceptuel en relation avec les plans de test et les procédures lors du test.

Eventuellement Interfaces vers des outils externes doivent être clarifiés avec les fabricants tiers en ce qui concerne la disponibilité et l'utilisation. Pour Demande de changement La gestion a certes subi des modifications, mais celles-ci ne concernent heureusement pas l'interface.

En ce qui concerne la nouvelle structure, la suppression de la Transactions SOLAR01 et SOLAR02, ainsi que les projets SolMan, modifient également le Gestion des versions.

Dans le cadre de la mise à niveau, il convient également de vérifier si les procédures définies et établies sont bien respectées. Processus ChaRM ne doivent pas, le cas échéant, être également adaptées à la nouvelle version 7.2.

Outre cette adaptation, les objets d'autorisation et les interfaces des Administration. Pour ce faire, il faudra certainement rédiger de nouveaux manuels d'exploitation et les responsables du changement devront se familiariser avec les nouvelles interfaces.

En ce qui concerne les changements ouverts, il convient également de planifier le moment de la mise à niveau de manière à ce qu'il y ait le moins de changements ouverts possible. Dans les domaines de l'exploitation des applications et de la surveillance, les changements ne sont pas aussi importants.

Dans ce cas, les adaptations ne concernent pas non plus un domaine spécialisé, mais peuvent être clarifiées dans le cercle d'une base SAP.
En résumé, la mise à niveau représente certainement un plus grand défi, mais elle est possible avec une sandbox et une bonne préparation et Inventaire de tous les processus est réalisable.

Les responsables informatiques ne devraient toutefois pas attendre trop longtemps avant de planifier. La fin de la maintenance approche et la mise à niveau doit être effectuée.