Le couteau suisse


Le SolMan est souvent désigné par l'expression "Single Source of Truth". Les différents scénarios d'utilisation peuvent certes être exploités en partie de manière autonome, mais dès qu'il s'agit de mettre en place des processus qui s'imbriquent judicieusement les uns dans les autres, on ne peut plus s'en sortir.
Un service desk peut tout à fait être exploité de manière autonome, mais dès que des thèmes comme la gestion des tests ou le ChaRM entrent en jeu, seule une vision intégrée a du sens.
Il est vrai que de nombreuses entreprises ont déjà reproduit diverses fonctions de Solution Manager par d'autres moyens. La gestion des incidents est le plus souvent confiée à d'autres outils.
Toutefois, les interfaces sont nécessaires au plus tard lorsqu'un incident doit se transformer en changement ou une alerte de surveillance en incident.
Malheureusement, Solution Manager n'est pas aussi riche en interfaces. Cela s'explique sans doute par son côté un peu possessif. En fin de compte, l'ITIL et un outil ne fonctionnent bien que s'ils sont utilisés de manière globale.
Dans un scénario d'intégration, les interfaces sont toujours le deuxième meilleur choix et doivent faire l'objet d'une réflexion approfondie. Dans le domaine de la gestion des incidents, il existe certes une interface dite "3rd party" avec d'autres Service Desks, mais elle n'est pas forcément évidente à comprendre.
L'effort d'implémentation n'est pas non plus proche de zéro, mais doit être laborieusement ajusté, comme dans tout environnement d'interface. La semaine dernière encore, j'ai dû convaincre un client de la complexité de cette interface.
Malheureusement, cette connexion "officielle" depuis l'extérieur est aussi la seule forme d'interface. Toutes les autres intégrations doivent être construites manuellement.
Dans un scénario typique d'un service informatique qui souhaite aller plus loin dans la mise en œuvre de Solution Manager, un service desk est déjà en place. La première base de discussion consiste alors à décider si tous les incidents doivent être enregistrés de manière centralisée.
Il existe parfois le souhait de transmettre les tickets SAP au Solution Manager et de les y implémenter spécifiquement. De telles interfaces sont envisageables, mais il ne faut pas négliger le travail d'implémentation nécessaire pour transmettre les valeurs de statut d'un ticket.
Dans le domaine de la gestion des demandes de changement, nous implémentons généralement des interfaces spécifiques au client avec le service desk du client. Ainsi, un changement peut être créé et traité directement à partir d'un incident d'un autre outil. Si l'on opte pour ce scénario, l'interface suivante n'est pas loin : dès qu'un service informatique opte pour la gestion des tests, les messages issus des cas de test doivent également être gérés.
L'intégration classique et standardisée prévoit naturellement le Solution Manager Service Desk. De cette manière, il faut bien sûr créer une solution pour créer des tickets dans un autre Service Desk. Il n'existe pas de scénario d'interface pertinent pour la documentation des solutions.
Seul le client peut décider si les documents ne peuvent pas être déposés localement ou via un lien, par exemple sur un Sharepoint. Ici, c'est au client de décider en fin de compte où il souhaite documenter.
Plus les fonctionnalités à utiliser dans Solution Manager sont nombreuses, plus Solution Manager s'impose comme une "pieuvre de données" et attend une utilisation judicieuse des scénarios correspondants.
En général, une interface pour connecter le Service Desk de Solution Manager. Il s'agit d'un scénario courant, surtout si l'on considère qu'un outil de gestion des incidents dans les grands environnements informatiques ne peut pas être remplacé d'un coup de baguette magique.
La forme exacte de l'intégration doit cependant toujours être conçue individuellement. Tous les autres thèmes devraient rester dans la mesure du possible dans le gestionnaire de solutions, car les interfaces peuvent devenir coûteuses à l'implémentation ainsi qu'à l'exploitation.