Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenJedes Ticket, jede Störung und jede Änderung meldet sich selbst bei den Betroffenen
Status, Störung, Änderung: gemeldet, bevor jemand fragt
Eine Statusänderung, eine erklärte Störung und eine freigegebene Änderung erzeugen eine Nachricht aus der Vorlage an den ermittelten Empfängerkreis in Microsoft Teams, mit einer Freigabe für alles Unternehmensweite.
Kurzfassung für die Geschäftsführung
Die Störungsmail geht nach der Störung raus, und jeder fünfte Ticketkommentar besteht aus denselben zwei Wörtern.
Die Ereignisse gibt es bereits.
Statusfragen entfallen, weil jeder Statuswechsel die anfragende Person in Teams erreicht, mit dem nächsten Schritt dabei.
Microsoft Teams; Outlook und Exchange Online; die SharePoint-Statusseite
Geschäftsproblem
IT-Kommunikation
Kommunikation über IT-Ereignisse ist manuell, spät und ungezielt. Der Ticketstatus lebt im Ticketsystem, in das Anfragende nicht schauen, also fragen sie stattdessen. Eine Störungsmeldung braucht jemanden, der die Störung bemerkt, jemanden, der den Text schreibt, und jemanden Ranghöheren, der ihn freigibt, und jeder Schritt wartet auf den vorigen.
Empfängerkreise werden geraten. Die Meldung geht an alle, weil niemand weiß, wer die betroffene Anwendung nutzt, und der CMDB-Eintrag, der sie mit Standorten und Benutzergruppen verbindet, wurde nie für den Versand genutzt. Änderungshinweise gehen einmal raus, eine Woche vorher, und am Tag der Änderung erinnert sich niemand daran.
Die Folgen trägt der Servicedesk: Statusanrufe, doppelte Störungstickets zu einem Ausfall, Beschwerden über Änderungen, an deren Ankündigung sich niemand erinnert. Das Problem hält sich, weil die Information in drei Systemen liegt und der Empfängerkreis in einem vierten, und niemand hat beides verbunden. Der Versand bleibt die Aufgabe eines Menschen und geschieht deshalb dann, wenn dieser Mensch Zeit hat.
Wie es heute läuft
- SystemEin Ticket wechselt in ServiceNow den Status, und außerhalb des Systems bemerkt es niemand
- MenschDie anfragende Person schreibt „Gibt es Neuigkeiten?“ als Kommentar oder ruft den Servicedesk mit derselben Frage an
- MenschEin Analyst tippt eine Antwort, die wiederholt, was der Datensatz ohnehin enthält
- MenschEine Störung wird an der Zahl der Anrufe erkannt; der Incident Manager öffnet Word und beginnt zu schreiben
- WartezeitDer Entwurf wartet auf die Formulierungsprüfung des IT-Leiters in einem Teams-Chat
- FehlerrisikoDie Mail geht nach der Wiederherstellung an alle Beschäftigten, sodass die nächste noch weniger gelesen wird
- FehlerrisikoDer Änderungshinweis geht einmal raus, eine Woche vorher; die Werke erfahren am Tag davon, aus der Halle
Warum der heutige Prozess mehr kostet, als es scheint
Die Rechnung, die im Budget nie auftaucht.
- Doppelte Störungstickets verzerren die Vorfallsdaten und den SLA-Bericht, sodass Kapazität auf Zahlen geplant wird, die die Verwirrung beschreiben und nicht den Bedarf.
- Ungezielte Rundmails erziehen die Belegschaft dazu, IT-Meldungen zu übergehen, sodass auch die wichtige untergeht; die für einen Routinehinweis verbrauchte Glaubwürdigkeit fehlt beim ernsten Fall.
- Werkleitungen verlieren Planungszeit, wenn sie von einer Änderung aus der Halle erfahren, und bezahlt wird das mit dem Schichtplan, der eine Woche zuvor entstand.
- Während einer laufenden Störung ist die Aufmerksamkeit des Incident Managers die knappste Ressource im Raum, und das Formulieren verbraucht sie im schlechtesten Moment.
- Von Hand versandte Meldungen hinterlassen keinen Nachweis: Nach einer Störung kann niemand zeigen, wer wann was erfahren hat, also streitet die Nachbetrachtung über Erinnerungen.
Kosten des Nichtstuns
Jeder übernommene Standort und jedes neue Werk fügt einen Empfängerkreis hinzu, den niemand zugeordnet hat, sodass Meldungen breiter und weniger gelesen werden, und je breiter sie werden, desto seltener fällt die wichtige auf. Statuskontakte wachsen mit dem Ticketaufkommen, das Ticketaufkommen wächst mit Belegschaft und Systemen, und formuliert wird weiterhin mitten in der Störung. Zwölf Monate später können die Nachbetrachtungen noch immer nicht zeigen, wer wann informiert wurde, die Werke sagen weiterhin, niemand habe es ihnen gesagt, und die IT antwortet weiterhin, ein Hinweis sei versandt worden. Eine kleine Abgabe, täglich erhoben, die in keinem Budget als Position auftaucht.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein Fertigungsunternehmen mit 4.500 Beschäftigten an drei Werken und einer Zentrale; ServiceNow für Tickets, Störungen und Änderungen; Microsoft 365; eine CMDB, deren Zuordnung von Anwendungen zu Standorten existiert, aber nicht für den Versand genutzt wird.
Rund 840 statusbezogene Kontakte im Monat (Kommentare, Anrufe, Teams-Nachrichten) sowie 24 Störungen und Änderungsfenster, die eine Meldung brauchen, mit je etwa 50 Minuten Aufwand des Incident Managers für Entwurf, Freigabe und Verteilung.
Status wird erfragt statt gesendet; Störungsmeldungen entstehen in Word, werden im Chat geprüft und an alle gemailt; Änderungshinweise gehen einmal raus. Die Werkleitungen haben zweimal um frühere und engere Hinweise gebeten.
Jede Meldung wartet darauf, dass ein Mensch ein Ereignis bemerkt und Text schreibt, und jeder Empfängerkreis wird geraten, sodass Meldungen zugleich zu breit und unvollständig sind.
Orchestrator-Ereignistrigger auf den ServiceNow-Datensätzen; ein Robot, der die freigegebene Vorlage wählt, den Empfängerkreis aus CMDB und Microsoft-Entra-ID-Gruppen ermittelt und eine Adaptive Card in Microsoft Teams sendet; eine Freigabe für alles Unternehmensweite; eine SharePoint-Statusseite und ein Zustellnachweis am Ereignis.
Im modellierten Fall erreichen drei von vier Statuskontakten den Servicedesk nicht mehr, eine Störungsmeldung geht binnen Minuten nach der Erklärung heraus statt danach, und jedes Änderungsfenster trägt drei Hinweise an die betroffenen Standorte. Illustrativ, kein Kundenergebnis.
Vorgeschlagene Lösung
Die Ereignisse gibt es bereits. Ein Ticket wechselt den Status, eine Störung wird erklärt, eine Änderung wird für einen Termin freigegeben: Jedes davon ist ein Datensatz in ServiceNow, und jedes ist eine Meldung, die jemand hätte erhalten sollen. Orchestrator-Ereignistrigger lesen diese Datensätze über UiPath Integration Service, sodass die Meldung dem Ereignis folgt und nicht der Verfügbarkeit einer Person.
Für jedes Ereignis wählt ein UiPath Robot die freigegebene Vorlage und ermittelt den Empfängerkreis: die anfragende Person bei einem Ticketupdate, bei einer Störung oder Änderung die Nutzer der betroffenen Anwendung, aus der CMDB-Beziehung und den passenden Microsoft-Entra-ID-Gruppen nach Werk und Rolle, ausgewertet im Moment des Versands statt aus einer handgepflegten Liste. Ticketupdates gehen als Adaptive Cards in Microsoft Teams heraus, mit Status, nächstem Schritt und erwartetem Termin; wer Teams gerade nicht offen hat, erhält denselben Text per E-Mail.
Alles Unternehmensweite und jede Meldung zu einer schweren Störung hält beim Incident Manager an, der sie als UiPath-Action-Center-Aufgabe in Microsoft Teams freigibt oder bearbeitet. Routineupdates zu einer bereits erklärten Störung gehen ohne Freigabe, und eine SharePoint-Statusseite trägt dieselben Fakten. Änderungshinweise laufen zu den Terminen aus dem Änderungsdatensatz: fünf Tage vorher, am Vortag und nach Abschluss, an die betroffenen Gruppen. Alles Gesendete wird am Ereignis festgehalten, und genau das liest später die Nachbetrachtung.
Ereignis- und Zeittrigger, Warteschlangen und Prüfpfad in UiPath Orchestrator; UiPath-Action-Center-Aufgaben, die in Microsoft Teams erledigt werden; Adaptive Cards in Teams; Microsoft-Entra-ID-Gruppen; eine SharePoint-Seite für den Status
Die Vorlagenbibliothek samt Versionierung, die Empfängerregeln gegen CMDB und Verzeichnisgruppen, den sendenden Robot und sein Ersatzverhalten bei fehlender Zuordnung, den Erinnerungsplan, den Freigabeschritt und den Zustellnachweis
Lesen von Tickets, Störungen, Änderungen und CMDB sowie Zurückschreiben der Zustellung in ServiceNow über den UiPath-Integration-Service-Konnektor; Microsoft-Teams- und Microsoft-Outlook-365-Konnektoren für den Versand; Gruppen über den Integration-Service-Konnektor gelesen, der weiterhin den früheren Namen „Microsoft Azure Active Directory“ trägt
So läuft der automatisierte Prozess
- AutomatisierungEin Ereignis in ServiceNow, ein Statuswechsel, eine erklärte Störung oder eine freigegebene Änderung, löst einen Orchestrator-Trigger aus
- AutomatisierungEin Robot wählt die freigegebene Vorlage und ermittelt den Empfängerkreis aus der CMDB-Beziehung und den passenden Entra-ID-Gruppen
- MenschUnternehmensweite Meldungen und solche zu schweren Störungen erreichen den Incident Manager als Freigabeaufgabe in Teams, Text vorbereitet und editierbar
- AutomatisierungDie Meldung geht als Adaptive Card in Microsoft Teams heraus und per E-Mail an alle, die gerade nicht in Teams sind
- AutomatisierungDie SharePoint-Statusseite trägt dieselben Fakten und den Zeitpunkt der nächsten Aktualisierung
- AutomatisierungÄnderungshinweise folgen dem Änderungsdatensatz: fünf Tage vorher, am Vortag und nach Abschluss, an die betroffenen Gruppen
- AutomatisierungWer wann was erfahren hat, wird am Ereignis festgehalten; eine fehlende Empfängerzuordnung oder ein fehlgeschlagener Versand geht an den Servicedesk
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Das Erkennen der Ereignisse: Statuswechsel, erklärte Störungen, freigegebene Änderungsfenster
- Das Ermitteln des Empfängerkreises aus CMDB und Verzeichnisgruppen im Moment des Versands
- Das Zusammenstellen der Meldung aus der freigegebenen Vorlage und den Fakten des Ereignisses
- Versand, Aktualisierung der Statusseite, Erinnerungen und den Zustellnachweis
Menschen entscheiden
- Das Erklären der Störung sowie Freigabe oder Bearbeitung von allem Unternehmensweiten
- Die Verantwortung für Vorlagen, Tonalität und Empfängerregeln
- Wann ein ungewöhnliches Ereignis eine Meldung braucht, die keine Vorlage abdeckt
Vorher und nachher
Systeme und Integrationen
Wo eine Regel reicht, nutzen wir kein Modell. Wo Urteilsvermögen nötig ist, entscheidet ein Mensch.
Eingänge
- ServiceNow-Datensätze zu Tickets, Störungen und Änderungen
- die CMDB-Zuordnung von Anwendungen zu Standorten und Benutzergruppen
- Microsoft-Entra-ID-Gruppen nach Werk und Rolle
Automatisierungsschicht
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Zielsysteme
- Microsoft Teams
- Outlook und Exchange Online
- die SharePoint-Statusseite
- ServiceNow, wo der Zustellnachweis liegt
Berührungspunkte für Menschen: die Freigabeaufgabe des Incident Managers in Teams; die Vorlagenbibliothek in der Hand der internen Kommunikation; die Durchsicht der Empfängerregeln; der monatliche Kommunikationsbericht
Eingesetzte Technologien
Ereignistrigger auf den ServiceNow-Datensätzen, Zeittrigger für die Erinnerungen, Warteschlangen und Prüfpfad
AEmpfängerkreis ermitteln, Vorlage füllen, senden, Statusseite aktualisieren und den Zustellnachweis schreiben
AServiceNow-Ereignisse und -Abfragen; Microsoft-Teams-, Microsoft-Outlook-365- und Identitätskonnektoren
Adie Freigabeaufgabe des Incident Managers, in Microsoft Teams erledigt, mit dokumentiertem Freigebenden
AStatus-, Störungs- und Änderungsmeldungen mit Zustand, nächstem Schritt und Schaltfläche
Adie Werk-, Standort- und Rollengruppen, die bestimmen, wer als betroffen gilt
Adieselbe Meldung per E-Mail für alle ohne Teams
Adie Statusseite, die während einer Störung aktuell bleibt
AIllustratives Wirtschaftlichkeitsmodell
Beginnen Sie damit, die Annahmen zu hinterfragen.
Die in den Werken während einer Störung verlorene Arbeitszeit ist die größte Zahl dieses Falls und diejenige, die wir nicht erfinden; sie gehört in ein Gespräch mit dem COO, nicht in diese Zeilen. Der Kalkulator bepreist allein den Servicedesk: Von 840 Statuskontakten im Monat werden drei von vier entbehrlich, sobald Status gesendet wird, und das sind die 630, mit denen das Volumen startet, zu je 8 Minuten und 42 € Vollkosten je Stunde. Der zweite Posten steht in Abschnitt 14: 24 Meldungen im Monat zu je 50 Minuten Aufwand des Incident Managers, zu 71 € pro Stunde, sind 20 Stunden und 1.420 € im Monat; beides zusammen ergibt 4.948 € im Monat. Lizenzen und Einführung liegen außerhalb des Modells, und nichts davon wurde bei einem Kunden gemessen.
Rechnen Sie mit Ihren Zahlen
Eine illustrative Schätzung aus Ihren Eingaben. Sie modelliert freigesetzte Kapazität und verspricht keine Einsparung.
Geschäftlicher Nutzen
- Statusfragen entfallen, weil jeder Statuswechsel die anfragende Person in Teams erreicht, mit dem nächsten Schritt dabei
- Doppelte Störungstickets gehen zurück, weil die Betroffenen Bescheid wissen, bevor sie anrufen
- Störungsmeldungen gehen binnen Minuten nach der Erklärung heraus: Der Entwurf ist eine Vorlage, die Freigabe ein Tippen
- Meldungen erreichen die tatsächlich betroffenen Standorte und Rollen, und genau das führt dazu, dass IT-Meldungen wieder gelesen werden
- Jede Meldung trägt einen Zustellnachweis, sodass die Nachbetrachtung Belege liest statt Erinnerungen
Aus Sicht der Geschäftsführung
- Kommunikation hängt nicht mehr davon ab, wer Zeit hat; das Ereignis sendet die Meldung, und die Meldung hinterlässt einen Nachweis
- Statuskontakte werden zu einer messbaren Zahl, und ihr Rückgang ist der unmittelbare Beleg dafür, dass Anfragende informiert werden
- Werke erhalten Hinweise, um die herum sie planen können, was eine IT-Änderung von einer Störung zu einem Terminpunkt macht
KPIs für die Geschäftsführung
Sicherheit und Governance
Sicherheit wird mit dem Prozess entworfen, nicht danach.
- Der Robot sendet unter einer eigenen Dienstidentität, die in benannten Teams-Kanälen posten und aus einem IT-Kommunikationspostfach senden darf, mehr nicht; ihr Geheimnis liegt im Credential Store von Orchestrator
- Empfängerkreise entstehen im Moment des Versands aus Gruppenmitgliedschaft und CMDB-Beziehungen, nie aus handgepflegten Verteilern, sodass Austritte und Wechsel von selbst herausfallen
- Unternehmensweite Meldungen und solche zu schweren Störungen können ohne dokumentierte Freigabe des Incident Managers nicht hinausgehen; die Freigabe wird in Microsoft Teams samt Identität erfasst und ist in Microsoft Purview nachvollziehbar
- Vorlagen sind versioniert und gehören der internen Kommunikation; eine Änderung der Tonalität ist eine Änderung an einer Stelle, und die gesendete Version bleibt am Ereignis hängen
- Der Inhalt der Meldungen enthält keine personenbezogenen Daten über das eigene Ticket der anfragenden Person hinaus; die Verarbeitung läuft in der EU-Region der UiPath Automation Cloud, Microsoft 365 innerhalb der EU-Datengrenze
Warum jetzt
Beschäftigte lesen Teams, nicht das Intranet, und eine Adaptive Card trägt Zustand, nächsten Schritt und Schaltfläche; in einem Werk, das Schichten eine Woche im Voraus plant, gilt eine Rundmail nicht mehr als informiert haben
Der Webhook-Versandweg, den viele Unternehmen für automatische Meldungen in Microsoft Teams nutzten, wurde im Mai 2026 abgeschaltet, also muss dieser Weg ohnehin neu gebaut werden; ihn auf Ereignistrigger statt auf die Aufmerksamkeit einer Person zu stellen, kostet dasselbe Projekt
Servicedesk-Minuten und Incident-Manager-Minuten zusammen sind im modellierten Fall 4.948 € im Monat, ausgegeben für Meldungen, deren Fakten die beteiligten Systeme längst haben
Relevante Führungsrollen
Der Ruf der IT im Unternehmen entscheidet sich daran, wie sie während einer Störung kommuniziert, und das wird damit schnell und belegbar
Der Servicedesk beantwortet keine Fragen mehr, deren Antwort im Ticketsystem steht
Die Werke erhalten gezielte und rechtzeitige Hinweise auf Störungen und Änderungen, um die herum sie planen können
Tonalität und Vorlagen bleiben in ihrer Hand, ohne dass ihr Team bei jeder Störung in Bereitschaft ist
Häufige Fragen und Einwände
Es versendet E-Mails bei Statuswechseln, und das ist nicht dasselbe. Hinzu kommen hier die Zielgruppenbildung aus der CMDB, Karten in Teams mit dem nächsten Schritt, eine Freigabestufe für schwere Fälle und Erinnerungen, die zu den Terminen des Änderungsdatensatzes laufen.
Sie bekommen weniger. Gezielte Meldungen ersetzen Rundmails, und eine Statuskarte ersetzt die Antwort, die ein Analyst sonst tippt; weg fällt das Volumen, das niemand wollte.
Dann startet der Pilot mit den zwei Anwendungen, deren Nutzer Sie kennen, und die dabei sichtbaren Lücken werden zur Bereinigungsliste für die CMDB, sortiert danach, wie viele Menschen jede betrifft.
Wann diese Lösung nicht passt
- Die Organisation ist klein genug, dass ein Kanalbeitrag alle erreicht, auf die es ankommt
- Es gibt weder CMDB noch Gruppenstruktur, aus der sich Empfängerkreise ableiten ließen, und keine Bereitschaft, beides aufzubauen
- Das Ticketsystem wird innerhalb eines Jahres abgelöst; dann nach der Migration bauen, nicht davor
Eine Frage für die nächste Sitzung
Warum haben unsere Werke von der letzten Änderung aus der Halle erfahren, obwohl der Datensatz mit Termin, Service und betroffenen Standorten seit der Freigabe in ServiceNow lag?
Vorgehen bei der Umsetzung
Wir starten mit einem Ausschnitt und erweitern erst nach dem Nachweis.
Wir liefern
- Den Zielprozess für Status-, Störungs- und Änderungskommunikation, hergeleitet aus den Störungsmails des letzten Quartals und dem Änderungskalender
- Eine mit der internen Kommunikation abgestimmte Vorlagenbibliothek, versioniert und in ihrer Verantwortung belassen
- Empfängerregeln gegen CMDB und Microsoft-Entra-ID-Gruppen, mit definiertem Ersatzverhalten bei fehlender Zuordnung
- Ereignis- und Zeittrigger, den sendenden Robot, die Freigabeaufgabe in Teams, die Statusseite und den Zustellnachweis
- Tests neben dem manuellen Prozess, Einführung, eine kurze Anleitung für Incident Manager und einen monatlichen Bericht
Wir brauchen von Ihnen
- Die CMDB-Zuordnung von Anwendungen zu Standorten und Benutzergruppen, in dem Zustand, in dem sie ist
- Die Struktur der Microsoft-Entra-ID-Gruppen nach Werk und Rolle
- Einen Incident Manager als Verantwortlichen des Ablaufs und die interne Kommunikation als Verantwortliche der Vorlagen
- Die Störungsmails des letzten Quartals, den Änderungskalender und eine Stichprobe von Statuskommentaren
Etappen
Analyse
Eine Woche Lesen: Störungsmails, Änderungskalender, Statuskommentare und die CMDB-Zuordnung im Ist-Zustand
Design
Vorlagen, Empfängerregeln, Freigabeschwellen und der Erinnerungsrhythmus, jeweils mit den Verantwortlichen abgestimmt
Bau
Ereignistrigger, sendender Robot, Freigabeaufgabe in Teams, Statusseite und Zustellnachweis
Pilot
Statuskarten für eine Zuweisungsgruppe und Störungsmeldungen für zwei Anwendungen mit bekannten Nutzergruppen, neben dem manuellen Prozess
Skalierung
Weitere Anwendungen, sobald ihre CMDB-Zuordnung bestätigt ist, danach die Erinnerungen über den Änderungskalender
Optimierung
Ein monatlicher Bericht zu Statuskontakten, doppelten Störungstickets und Zeit bis zur ersten Meldung; Regeln nach dessen Befund justiert
Quick Win. Der Aufwand folgt dem Zustand der CMDB-Zuordnung und der Zahl unterschiedlicher Empfängerkreise, nicht der Automatisierung selbst; das Ticketsystem ändert daran wenig.
Jeder fünfte Kommentar in Ihrer Ticketwarteschlange besteht aus denselben zwei Wörtern.
Senden Sie uns die Störungsmails des letzten Quartals und eine Woche Ticketkommentare. Sie erhalten eine Empfängerkarte für Ihre fünf meistgenutzten Anwendungen und eine schriftliche Einschätzung, welche Meldungen sich selbst hätten senden können.
Störungsmails des Quartals sendenDer Nachbarprozess hat meist dasselbe Problem
Jeder dritte Kundenkontakt fragt nach dem Auftrag; die Antwort steht längst in SAP und im Portal des Frachtführers.
Lösung ansehen Weitere LösungenTickets eingeordnet und zugewiesen, bevor jemand sie liestDie Priorität folgt den Großbuchstaben des Anfragenden, und ein P1 wartet, bis ein Dispatcher Zeit hat, es zu lesen.
Lösung ansehen Weitere LösungenStörungen und Änderungen in einem einzigen AblaufDas Werkzeug protokolliert. Verantwortliche suchen, Status nachhalten und freitags nichts lesen erledigen Menschen.
Lösung ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieTransport & LogistikDienstleistungen & ITShared Services