uSMS, das universal Service Management System, führt Ihre Services und die Menschen um sie herum: wer einen Service nutzt, wer ihn erbringt und wer ihn verantwortet. Wenn etwas ausfällt, sehen Sie mehr als ein Ticket. Sie sehen, was auf dem Spiel steht und wer handeln kann.
Die meisten Werkzeuge ordnen Arbeit nach Tickets und Warteschlangen. uSMS ordnet sie nach Beziehungen. Jeder Service hat drei davon.
Die Organisation, die die Vereinbarung hält, und die Menschen darin, die den Service täglich nutzen. uSMS hält beide auseinander, weil sie verschiedene Rechte haben.
Der Desk, der antwortet, und die Technical Owner, die Schicht für Schicht in den Service hineinliefern.
Die Person, die für den Service einsteht, für seine Güte und seine Zusagen. Benannt im Katalog, bevor etwas passiert.
Fünf echte Bildschirme aus uSMS. Keine Anmeldung, etwa zwei Minuten.
Alle Abbildungen zeigen den Entwicklungsstand vom 22. September 2026. Ob die gezeigten Funktionen in dieser Form Bestandteil einer künftigen Fassung sind, sagen wir nicht zu.
Wir führen nur auf, was Sie heute in einer Vorführung sehen können.
Melden, zuordnen, koordinieren, lösen. Immer gegen einen Service, mit der Prüfung auf bekannte Fehler schon bei der Aufnahme und einem Major-Incident-Pfad mit Koordinator und festem Meldetakt.
Jeder Service hat einen benannten Service Owner und, Schicht für Schicht, die Technical Owner, die in ihn hineinliefern. Besetzt wird an einer Stelle, sichtbar ist es dort, wo die Rolle wirkt.
Einen Service oder einen Zugriff aus dem Katalog anfragen, auf den man berechtigt ist. Die Berechtigung wird vor der Erfüllung geprüft, nicht danach.
Wiederkehrende Störungen werden zu Kandidaten; ein Problem endet als bekannter Fehler oder als Change. Standard, Normal und Emergency haben je einen eigenen Weg zur Genehmigung.
Zusagen, Angebote und Anfragetypen stehen im Katalog. Die Störung erbt sie. Deshalb kann uSMS sagen, was auf dem Spiel steht, ohne dass es jemand ins Ticket tippt.
Der Service-Level-Bericht entsteht aus den Zusagen und den Ereignissen, wird dem Kunden zugestellt und von ihm quittiert. Die Quittung ist ein Prüfereignis.
Ereignisprotokoll, Zeitgeber und Jobs, Postausgang, Last je Bereich, Lizenzen. Wonach Enterprise-Käufer im zweiten Gespräch fragen.
Das Modell kennt die Konsumenten eines Service. Diese Liste von der Störung aus in einer Ansicht zu sehen, ist das, was als Nächstes entsteht.
Fragen zu den eigenen Services in normaler Sprache stellen und einen empfohlenen nächsten Schritt bekommen. Mit einer bewussten Grenze: Ein Assistent legt nichts an und ändert keinen Status. Er antwortet und schlägt vor.
Die Prozesse, die Sie im Rundgang gesehen haben, stehen nicht für sich. Sie sind Teil eines Systems, in dem jede Leistung einen Owner hat, jeder Vorgang einen Weg und jede Änderung einen Ursprung im Katalog. Das Bild zeigt diesen Zusammenhang vollständig. Es ist unsere Landkarte, kein Werbebild.
Die Abbildung zeigt das Ordnungsmodell, nicht den Funktionsumfang einer bestimmten Fassung. Was davon heute in uSMS gebaut ist, steht oben unter „Was uSMS kann".
uCRM und uRMS nennen wir, angeboten werden sie noch nicht. Sie sind der Beleg dafür, dass die Architektur wirklich universal ist, ehrlich gezeigt, mit ihrem Baustand. Wie Cognie sie verbindet, steht auf der HRX-Seite →
Sie müssen nicht Ihre ganze Landschaft bewegen, um herauszufinden, ob das trägt. Nehmen Sie einen Servicebereich und führen Sie ihn vollständig in uSMS: Ihr Katalog, Ihre Owner, Ihre Zusagen, Ihre Kunden. Dort wird der Unterschied nachweisbar, und die Entscheidung ist umkehrbar.
Fragen Sie uns, wo Ihre Daten liegen, wie der Zugriff geregelt ist und wo wir bei Zertifizierungen stehen. Sie bekommen den Stand schriftlich, einschließlich dessen, was noch offen ist.
In einer halben Stunde bilden wir einen Ihrer Services ab, mit denen, die ihn nutzen, denen, die ihn erbringen, und der Person, die ihn verantwortet, und gehen eine Störung darauf durch.