SolMan 7.2 : plus que la somme des outils individuels

Je rencontre régulièrement des clients qui, par le passé, ont plutôt adopté une approche "best of breed" pour les outils de gestion des services informatiques. Or, avec Solution Manager 7.2, cette approche est inévitablement vouée à l'échec.

Tant que le Solution Manager n'est utilisé que comme un simple véhicule pour les alertes Early Watch, cela ne pose évidemment aucun problème.

Si le Solution Manager n'occupe que cette place dans l'informatique, les avantages de l'outil ne sont de loin pas utilisés et restent en friche. En outre, les utilisateurs devraient réfléchir à la manière dont ils veulent maîtriser le passage à S/4 Hana et aux outils qui devraient être utilisés à la place.

Si l'on souhaite développer le Solution Manager de manière judicieuse, la documentation des solutions et la gestion des changements et des demandes (ChaRM) sont au moins obligatoires.

En règle générale, je ne recommande aux utilisateurs SAP d'utiliser ces domaines que si la part de SAP et son importance au sein de l'informatique dépassent le seuil des cinquante pour cent. Car obliger les utilisateurs et les développeurs dans l'environnement Java à passer au Solution Manager n'est pas particulièrement amusant.

Si, par le passé, on travaillait encore avec deux outils différents dans le domaine de la gestion des changements ou dans celui de la documentation logicielle, cela n'a plus qu'un sens limité dans Solution Manager.

Certains clients que j'ai pu conseiller ces dernières semaines ont cherché des solutions pour relier un outil de gestion de projet, une facturation séparée des coûts et des prestations ainsi qu'un outil de documentation externe au Service Desk de Solution Manager et à la gestion des changements.

Une telle intégration peut certes être possible, mais elle ouvre à de nombreux endroits des interfaces supplémentaires que le Solution Manager ne possède pas en standard.

La seule interface officiellement disponible est le couplage d'un service desk externe avec la gestion des incidents du gestionnaire de solutions.

La solution globale pour la gestion de l'informatique dans Solution Manager n'est pas si éloignée avec la version 7.2. En raison de l'amélioration considérable du périmètre et des fonctions, cela ne pose plus guère de problèmes, même dans la mise en œuvre.

Le plus grand défi est d'aligner toute l'informatique sur l'outil. Bien entendu, cela n'a de sens que si SAP est majoritaire dans l'environnement informatique.

Dans le contexte global, tout commence par la documentation de la solution et la représentation des processus commerciaux et des étapes des processus commerciaux. Dans un premier temps, il n'est pas nécessaire que cela soit complet, mais une approche et une post-documentation devraient être effectuées, ne serait-ce que du point de vue de la conversion S/4.

Ce n'est que lorsque les processus sont représentés de manière judicieuse et conforme à la réalité en étapes de processus qu'il est possible d'en tirer un plan de test ainsi qu'une procédure de test.

Dans le cadre de la gestion des demandes de changement, la modification est bien entendu étroitement liée à la documentation ainsi qu'aux processus et étapes concernés. Il faut donc s'assurer que les modifications ne soient pas mises en production sans documentation.

Celui qui gère judicieusement son informatique dans l'environnement SAP opte inévitablement pour une gestion des versions qui s'appuie sur la gestion des changements. Si l'on souhaite un contrôle judicieux, la gestion des versions peut être reliée à la gestion de projet et de portefeuille dans Solution Manager.

Ainsi, les changements ne peuvent pas être gérés uniquement au niveau individuel. Il est également possible de saisir dans la partie gestion de projet des ensembles de tâches qui n'impliquent pas de modifications techniques du logiciel.

Si les responsables informatiques optent pour une saisie du temps en fonction de la cause, les charges peuvent être saisies directement sur les ensembles de tâches du projet. En comparant les chiffres planifiés, il est alors possible d'obtenir des indicateurs de gestion de projet typiques.

Au total, il en résulte donc une association judicieuse d'outils individuels. Une séparation de ces outils entraîne toujours des frais de maintenance, des interfaces coûteuses ainsi que des pertes de fonction massives.