Service Management
Von der Bestellung zur Installation: AppCloud365-Pakete im Servicekatalog von OpsCloud365
Zwei Produkte, getrennte Daten, ein Ablauf: Wie eine Softwarebestellung im Self-Service-Portal über Genehmigung und Erfüllungsgruppe zu einem Paket aus AppCloud365 führt, und wo die Grenze zwischen beiden Werkzeugen liegt.
Wir werden regelmäßig gefragt, ob OpsCloud365 und AppCloud365 „zusammenhängen“. Die ehrliche Antwort hat zwei Teile. Technisch: nein. Es sind zwei eigenständige Anwendungen mit getrennten Datenbanken, und jede läuft ohne die andere. Organisatorisch: ja, und zwar an einer Stelle, die im IT-Alltag ständig vorkommt. Jemand braucht eine Software auf seinem Gerät. Dieser Artikel beschreibt den Weg von der Bestellung bis zur Installation und wo welches Werkzeug seinen Teil erledigt.
Der Ablauf in fünf Schritten
Schritt 1: Die Bestellung im Portal
Im Self-Service-Portal von OpsCloud365 finden Mitarbeitende den Servicekatalog. Eine Position wie „Software installieren“ hat ein eigenes Bestellformular, in dem die gewünschte Anwendung und das Gerät angegeben werden. Preis, Lieferzeit und Genehmigungspflicht stehen an der Position, bevor jemand bestellt. Aus der Bestellung entsteht ein Service Request mit Nummer, den der Besteller unter „Meine Tickets“ verfolgt.
Schritt 2: Die Genehmigung
Jede Katalogposition hat eine Genehmigungsregel: keine, die Führungskraft des Bestellers, eine Genehmigergruppe oder eine benannte Person. Die Genehmigung wird beim Anlegen des Requests automatisch erzeugt und erscheint bei den Zuständigen unter „Meine Genehmigungen“. Wer ablehnt, muss einen Kommentar hinterlassen. Nach der Freigabe wechselt der Request in Bearbeitung und landet bei der Erfüllungsgruppe, die an der Katalogposition hinterlegt ist.
Schritt 3: Das Paket aus AppCloud365
Jetzt wechselt das Werkzeug. Die Erfüllungsgruppe, meist das Client-Team, sucht die Anwendung im gespiegelten WinGet-Katalog von AppCloud365, prüft Version und Installer und baut das Paket: als PSADT-Paket, als .intunewin oder als verifizierter Original-Installer. Bei Anwendungen, die häufig bestellt werden, existiert das Paket in der Regel schon, dann entfällt dieser Schritt.
Schritt 4: Die Bereitstellung
Das Paket wird in Microsoft Intune oder im Configuration Manager veröffentlicht und dem Gerät des Bestellers zugewiesen. Auf Wunsch richten wir diese Übergabe so ein, dass die in AppCloud365 gebauten Pakete direkt im Verteilsystem landen. Was auf dem Gerät passiert, steuert das Paket selbst: Prozesse schließen, installieren, Exit-Code melden.
Schritt 5: Der Request wird erfüllt
Zurück in OpsCloud365 setzt die Erfüllungsgruppe den Request auf erfüllt. Der Besteller sieht den Status im Portal, kann die Bearbeitung bewerten, und die Installation ist als Software am Asset des Geräts nachvollziehbar, falls die Installation dort erfasst wird. Für die Lizenz-Compliance zählt sie ab dann als Verbrauch.
Wo die Grenze liegt, und warum
Es gäbe die Möglichkeit, beide Produkte technisch zu verkoppeln: ein Request, der automatisch einen Paketierungsjob auslöst. Wir haben das bisher bewusst nicht gebaut. Die Erfüllungsgruppe trifft an dieser Stelle Entscheidungen, die ein Automat nicht treffen sollte: Welche Version, welcher Installer, ob das Paket schon existiert, ob die Anwendung überhaupt in dieses Unternehmen gehört. Die Übergabe ist eine Aufgabe für Menschen, die dafür gute Werkzeuge haben.
Was die beiden Produkte teilen, ist die Haltung: Bestellungen haben eine Genehmigung, Pakete haben einen Hash, und beides hat eine Historie. Wer beide einsetzt, hat einen durchgängigen Ablauf von der Frage „Kann ich bitte 7-Zip haben?“ bis zur Antwort „Ist installiert.“ Wer nur eines einsetzt, verliert nichts, was das andere nicht auch allein könnte.
Alle Abbildungen zeigen die tatsächliche Anwendung mit fiktiven Demodaten.