Das Schweizer Taschenmesser
Der SolMan wird oft mit dem Anspruch der „Single Source of Truth“ benannt. Die verschiedenen Einsatzszenarien lassen sich zwar zum Teil auch eigenständig betreiben, sobald jedoch ineinander sinnvoll greifende Prozesse gefragt sind, kommt man hier nicht mehr weiter.
Ein Service Desk kann durchaus standalone betrieben werden, sobald jedoch Themen wie Testmanagement oder ChaRM ins Spiel kommen, macht nur noch eine integrierte Sichtweise Sinn.
Jetzt ist es ja so, dass viele Unternehmen diverse Funktionen des Solution Manager bereits anderweitig abgebildet haben. Am häufigsten ist das Incident Management in anderen Händen, auch das Monitoring wird häufig über andere Tools wahrgenommen.
Spätestens dann, wenn jedoch aus einem Incident ein Change oder aus einem Monitoring Alert ein Incident entstehen soll, sind Schnittstellen gefragt.
Mit Schnittstellen ist der Solution Manager leider nicht ganz so reichlich ausgestattet. Das liegt wohl auch an dem etwas besitzergreifenden Anspruch. Letztendlich funktioniert ehrlicherweise ITIL und ein Tool auch nur dann gut, wenn es ganzheitlich zum Einsatz kommt.
Schnittstellen sind in einem Integrationsszenario immer nur die zweitbeste Wahl und müssen reichlich überlegt werden. Im Bereich des Incident Management existiert zwar eine sogenannte 3rd-Party-Schnittstelle zu anderen Service Desks, diese ist aber nicht unbedingt selbsterklärend.
Auch die Implementierungsaufwände sind nicht gerade nahezu null, sondern müssen wie in jeder Schnittstellenumgebung mühsam abgestimmt werden. Erst letzte Woche hatte ich wieder die Aufgabe, einen Kunden von der Aufwändigkeit dieser Schnittstelle zu überzeugen.
Dummerweise ist diese „offizielle“ Anbindung von außen auch die einzige Form der Schnittstelle. Alle anderen Integrationen müssen manuell gebaut werden.
In einem typischen Szenario einer IT, die den Solution Manager weitergehend implementieren möchte, ist ein Service Desk bereits vorhanden. Die erste Diskussionsgrundlage besteht nun darin, zu entscheiden, ob alle Incidents zentral erfasst werden.
Teilweise besteht der Wunsch, die SAP-Tickets weiterzuleiten an den Solution Manager und dort dann spezifisch zu implementieren. Solche Schnittstellen sind denkbar, allerdings darf der Implementierungsaufwand für die Übermittlung der Statuswerte eines Tickets nicht vernachlässigt werden.
Im Bereich des Change Request Management implementieren wir meist kundenspezifische Schnittstellen zum Service Desk des Kunden. So kann aus einem Incident eines anderen Werkzeugs direkt ein Change angelegt und bearbeitet werden. Entscheidet man sich für dieses Szenario, ist die nächste Schnittstelle nicht weit entfernt: Sobald sich eine IT für Testmanagement entscheidet, müssen die Meldungen aus Testfällen auch verwaltet werden.
Die klassische, standardisierte Integration sieht hier natürlich den Solution Manager Service Desk vor. Auf diese Weise muss dann natürlich eine Lösung geschaffen werden, Tickets in einem anderen Service Desk anzulegen. Für das Thema Lösungsdokumentation gibt es gar kein sinnvolles Schnittstellenszenario.
Einzig der Kunde kann entscheiden, ob die Dokumente nicht lokal oder über einen Link, z. B. auf einem Sharepoint, abgelegt werden können. Hier muss der Kunde sich letztendlich entscheiden, wo er dokumentieren möchte.
Je mehr Funktionalitäten im Solution Manager genutzt werden sollen, desto mehr greift natürlich der Solution Manager als „Datenkrake“ um sich und erwartet auch die sinnvolle Nutzung der entsprechenden Szenarien.
Generell ist eine Schnittstelle, um den Service Desk des Solution Manager anzuschließen. Dies ist ein gängiges Szenario, vor allem vor dem Hintergrund, dass ein Tool für das Incident Management in größeren IT-Umgebungen nicht einfach mal eben ausgetauscht werden kann.
Die genaue Form der Integration muss jedoch immer individuell konzipiert werden. Alle anderen Themen sollten weitestgehend im Solution Manager verbleiben, da Schnittstellen in der Implementierung sowie im Betrieb beliebig aufwändig werden können.
