The Swiss Army Knife
SolMan is often referred to as the "single source of truth". The various application scenarios can be operated independently to some extent, but as soon as interlocking processes are required, this is no longer the case.
A service desk can certainly be operated standalone, but as soon as topics such as test management or ChaRM come into play, only an integrated view makes sense.
The fact is that many companies have already mapped various Solution Manager functions elsewhere. Incident management is most frequently in other hands, and monitoring is also often handled by other tools.
However, interfaces are required at the latest when an incident is to be turned into a change or a monitoring alert into an incident.
Unfortunately, Solution Manager is not quite as richly equipped with interfaces. This is probably also due to the somewhat possessive claim. Ultimately, ITIL and a tool only work well if it is used holistically.
Interfaces are always only the second-best choice in an integration scenario and require plenty of thought. In the area of incident management, there is a so-called 3rd party interface to other service desks, but this is not necessarily self-explanatory.
Also the implementation efforts are not exactly close to zero, but have to be painstakingly tuned as in any interface environment. Just last week I had the task again to convince a customer of the complexity of this interface.
Unfortunately, this "official" connection from the outside is also the only form of interface. All other integrations have to be built manually.
In a typical scenario of an IT that wants to implement Solution Manager further, a service desk is already in place. The first basis for discussion is now to decide whether all incidents should be recorded centrally.
In some cases, there is a desire to forward the SAP tickets to Solution Manager and then implement them there specifically. Such interfaces are conceivable, but the implementation effort for transmitting the status values of a ticket must not be neglected.
In the area of change request management, we usually implement customer-specific interfaces to the customer's service desk. This means that a Change can be created and processed directly from an Incident from another tool. If this scenario is chosen, the next interface is not far away: as soon as IT decides to use test management, the messages from test cases must also be managed.
The classic, standardized integration naturally provides for the Solution Manager Service Desk here. In this way, of course, a solution must then be created to create tickets in another service desk. There is no meaningful interface scenario at all for the topic of solution documentation.
Only the customer can decide whether the documents can be stored locally or via a link, e.g. on a sharepoint. Here, the customer must ultimately decide where he wants to document.
The more functionalities are to be used in Solution Manager, the more Solution Manager naturally takes hold as a "data octopus" and also expects the meaningful use of the corresponding scenarios.
Generally, an interface to connect the Service Desk of the Solution Manager. This is a common scenario, especially in light of the fact that an incident management tool cannot simply be replaced in larger IT environments.
However, the exact form of integration must always be designed individually. All other topics should remain in Solution Manager as far as possible, since interfaces can become arbitrarily complex in implementation as well as in operation.
