Prêt pour Hana avec SAP Solution Manager

Pour de nombreux responsables informatiques, la mise à niveau de Solution Manager 7.1 et la menace de la fin de la maintenance au 31 décembre 2017 sont encore un grand épouvantail.

En particulier, les utilisateurs SAP qui utilisent déjà de nombreux scénarios sont confrontés à des défis importants lors de la mise à niveau.

Tous les scénarios déjà mis en place doivent être réadaptés, réautorisés, testés, formés et implémentés. Il s'agit ici de commencer le projet de mise à niveau suffisamment tôt afin de disposer d'une marge de manœuvre suffisante.

D'abord SolMan, puis Hana

Les utilisateurs qui prévoient une migration vers Hana en 2017 devraient envisager de mettre à jour Solution Manager au préalable.

Dans le cadre d'une conversion à Hana, mais aussi en préparation à la nouvelle S/4 Hana Business Suite, il existe quelques modules utiles qui facilitent massivement la transition.

Au début d'une migration vers Hana, les départements informatiques sont toujours confrontés à la même souffrance : les tests doivent être préparés et convenus avec les départements spécialisés.

Chez de nombreux clients qui n'utilisent le Solution Manager que de manière très rudimentaire, ces tests sont déposés sous forme de documents Excel sur un partage de fichiers et sont impitoyablement obsolètes.

Certains clients sont allés plus loin et ont utilisé la documentation de la solution pour décrire les processus et les cas de test nécessaires associés, mais n'ont pas mis à jour leur documentation depuis la dernière mise à jour du Support Package ou même la dernière mise à niveau et se retrouvent avec une documentation obsolète.

Inventorier les processus

Dans les deux cas, il est judicieux d'utiliser les nouvelles fonctionnalités du gestionnaire de solutions dans la documentation de la solution afin d'inventorier dans un premier temps tous les processus commerciaux.

Le fait que le nombre de niveaux puisse être choisi par l'utilisateur - contrairement à ce qui se passait auparavant - permet de documenter même les maisons de processus les plus complexes.

Une fois cette base établie, il est possible de construire sur celle-ci. Si la structure pure ne suffit pas, le nouvel éditeur graphique permet également de modéliser les diagrammes de processus et de les stocker dans Solution Manager.

Une documentation renouvelée

L'étape suivante consiste à relier les documents de test déjà existants, généralement des fichiers Excel, aux différents processus.

Le cas échéant, un document doit être scindé en plusieurs. L'étape suivante consiste à créer une base judicieuse pour une documentation de processus à partir de la documentation de processus créée ou remaniée, qui devrait bien entendu être poursuivie.

Une mise à jour de la documentation des processus peut être imposée par le biais de la composante de gestion des changements.

En plus de ces activités préparatoires, il est certainement judicieux - à condition que l'entreprise soit soutenue - d'utiliser le Custom Code Management Cockpit pour éliminer le code inutilisé.

Tout ce qui peut être retiré du système diminue naturellement les cas de test à réaliser.

Formation & test

Certes, les nouvelles surfaces et les nouveaux outils impliquent que les utilisateurs doivent être formés et que les nouvelles techniques doivent être apprises.

L'avantage pour le thème de la gestion des tests et le chemin vers une documentation complète sont cependant indispensables. Comme je l'ai déjà décrit dans une autre chronique, la transition de la documentation de la solution n'est certainement pas facile, surtout si des documents sont déjà disponibles.

Au plus tard à la fin de la maintenance, il faudra toutefois passer par cette voie, car l'"ancienne" documentation de la solution ne sera plus disponible qu'en mode lecture seule après la mise à niveau.

Une planification précoce du projet est indispensable.