Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenDer Störungsraum öffnet mit seinen Verantwortlichen, Änderungen werden auf Nachweis freigegeben
Störungen und Änderungen in einem einzigen Ablauf
Eine Großstörung öffnet ihren eigenen Teams-Kanal mit Verantwortlichen, Services und laufendem Runbook; Änderungen werden bewertet, und nur hohes Risiko erreicht das Gremium.
Kurzfassung für die Geschäftsführung
Das Werkzeug protokolliert. Verantwortliche suchen, Status nachhalten und freitags nichts lesen erledigen Menschen.
Zwei Abläufe setzen auf dem Werkzeug auf, das Sie bereits besitzen; keiner ersetzt es.
Die ersten zwanzig Minuten einer Großstörung gehen in die Behebung, weil Verantwortliche, Services und Runbook von Beginn an im Raum sind.
ServiceNow; Jira; Microsoft Teams
Geschäftsproblem
ITSM
Störung, Problem und Änderung teilen sich ein Werkzeug und sonst wenig. In den ersten zwanzig Minuten einer Großstörung klären Menschen, wem die Datenbank gehört und welche Kunden betroffen sind, während ein Störungsmanager dieselbe Meldung aus dem Gedächtnis in drei Kanäle tippt. Der Eintrag in ServiceNow entsteht danach; die Arbeit passiert in einem Chat-Thread, den später niemand nachlesen kann.
Abschlussnotizen umfassen zwei Zeilen, also beginnt der Problemprozess bei null und dieselbe Störung kehrt mit der Saisonspitze zurück. Das Änderungsmanagement hat den umgekehrten Fehler: Jeder Antrag erhält dieselbe fünfundvierzig Sekunden lange Prüfung, eine Firewall-Regel und eine geänderte Schriftart werden gleich behandelt, Änderungen mit geringem Risiko warten eine Woche auf ein Treffen, und nach dem Einspielen sieht niemand ins Monitoring.
Das hält sich, weil das Werkzeug Einträge erfasst und nicht Arbeit, und weil die Menschen, die die Übergaben automatisieren könnten, gerade die Störungen bekämpfen. Nichts verbindet eine Änderung mit der Störung, die ihr folgt, also kann die Organisation ihre eigene Änderungsfehlerquote nicht nennen, und elf Führungskräfte verbringen wöchentlich eine Dreiviertelstunde damit, Unterlagen freizugeben, die sie nicht gelesen haben.
Wie es heute läuft
- SystemEin Alarm aus Azure Monitor oder eine Nutzermeldung eröffnet ein Ticket in ServiceNow
- MenschDas Ticket landet in einer Warteschlange und wird zweimal weitergereicht, bevor es jemanden erreicht, der handeln kann
- MenschJemand erklärt die Störung für groß, startet eine Teams-Besprechung, und die Service-Verantwortlichen werden durch Herumfragen gefunden
- WartezeitDie Brücke wartet, bis der Datenbank-Verantwortliche gefunden und die Kundenwirkung geklärt ist
- MenschStatusmeldungen werden aus dem Gedächtnis in drei Kanäle getippt, wann immer der Manager einen Moment hat
- FehlerrisikoDie Korrektur geht ein, das Ticket schließt mit zwei Zeilen, und der Problemeintrag hat nichts, womit er arbeiten könnte
- WartezeitDer Änderungsantrag bleibt halb ausgefüllt bis Freitag, wenn das Gremium das Paket in einer Sitzung abräumt
- FehlerrisikoDie Änderung wird eingespielt, das Monitoring prüft niemand, und eine Ausfallzeit wird ihr Wochen später zugeschrieben
Warum der heutige Ablauf mehr kostet, als er scheint
Hinter jeder Ausnahme steht eine Stunde, die niemand erfasst hat.
- Jede Minute einer Großstörung trägt im Omnichannel-Handel einen Warenkorbwert, und die ersten zwanzig gehen in Logistik statt in die Behebung.
- Ingenieure, die auf die Brücke geholt werden und sich als überflüssig erweisen, arbeiten in dieser Zeit an nichts anderem, und keine Zeiterfassung hält diese Stunde fest.
- Dünne Abschlussnotizen führen dazu, dass dieselbe Störung mehrfach bezahlt wird, weil der Problemprozess nie genug Material für eine dauerhafte Lösung bekommt.
- Änderungen mit geringem Risiko warten hinter einem Wochentermin, während die riskanten keine echte Prüfung erhalten, und genau daher kommen die Ausfälle.
- Durch Änderungen verursachte Ausfälle bleiben ungezählt, weil nichts die beiden Einträge verbindet, und dem Vorstand wird berichtet, Ausfälle seien zufällig.
Kosten des Nichthandelns
Eine Großstörung im Handel wird in Warenkörben bewertet, nicht in Analystenstunden, und diese Zahl gehört Ihrer eigenen Störungshistorie, nicht irgendeinem Modell. Die Zeilen zählen die Koordination rund um die Behebung und die Verwaltung rund um die Änderung, also den Teil, der sich wie Gehaltsarbeit verhält und sich redlich diskutieren lässt.
Sich selbst überlassen, bewegt sich die Warteschlange nur in eine Richtung. Jede neue Integration, jeder Lieferant und jeder Kanal bringen zusätzliche Störungen, und jede große zahlt dieselbe zwanzigminütige Logistiksteuer. Der Problemrückstand schrumpft nicht, weil ihn nichts speist. Schnellere Releases drücken mehr Änderungen in die Freitagsschlange, sodass der Druck zur Sammelfreigabe mit dem Risiko steigt, und die Ingenieure, die ihre Woche auf Brücken verbringen, haben die meisten Alternativen.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein Omnichannel-Händler mit einer IT-Organisation von 240 Personen. ServiceNow führt Störungen, Probleme und Änderungen; die Entwicklungsteams arbeiten in Jira; die Handelsplattform läuft auf Azure mit Azure Monitor; die Arbeit selbst passiert in Microsoft Teams.
Rund 620 Störungen und 95 Änderungen pro Monat, davon etwa 14 Störungen als groß erklärt. Ein elfköpfiges Änderungsgremium tagt jeden Freitag fünfundvierzig Minuten und liest einen Anhang von zehn.
Großstörungen laufen aus einer spontanen Teams-Besprechung: Verantwortliche durch Herumfragen, Status aus dem Gedächtnis, Abschlussnotizen von zwei Zeilen. Änderungen werden in einer Vorlage vorbereitet und freitags im Paket abgeräumt, und das Monitoring danach gehört niemandem.
Die ersten zwanzig Minuten jeder Großstörung gehen in das Suchen von Menschen und das Öffnen eines Raums, und eine risikoarme Änderung wartet eine Woche auf ein Treffen. Nachbetrachtungen schreiben ein Drittel der Großstörungen Änderungen zu; die Einträge zeigen das nicht, weil nichts sie verbindet.
Eine Großstörung startet einen UiPath-Prozess, der einen Teams-Kanal mit den betroffenen Services, den Bereitschaftsverantwortlichen und dem bereits laufenden Runbook öffnet, während ein UiPath Agent den Entwurf der Zusammenfassung und die Liste ähnlicher Störungen für den Störungsmanager vorbereitet. Änderungen laufen durch einen UiPath Maestro Prozess, der das Risiko mit DMN-Regeln bewertet, Standardänderungen mit vollständigen Nachweisen automatisch freigibt, normale an die Verantwortlichen in Teams schickt und das Gremium für hohes Risiko reserviert.
Im modellierten Fall bestehen Kanal, Verantwortliche und erstes Runbook binnen einer Minute nach der Erklärung, die Hälfte aller Änderungen wird ohne Treffen auf Nachweis freigegeben, und jedes Einspielen wird einen Tag lang gegen das Monitoring beobachtet; diese Zahlen modellieren das Szenario, sie messen nichts.
Vorgeschlagene Lösung
Zwei Abläufe setzen auf dem Werkzeug auf, das Sie bereits besitzen; keiner ersetzt es. Sobald eine Störung in ServiceNow als groß markiert wird, erzeugt ein Ereignis-Trigger im UiPath Integration Service einen Microsoft Teams Kanal, holt die Bereitschaftsverantwortlichen aus der Konfigurationsdatenbank dazu und postet eine Adaptive Card mit den betroffenen Services, der Kundenwirkung, dem Link zur Brücke und dem Stand des Runbooks.
Ein UiPath Agent entwirft die Lagezusammenfassung und listet ähnliche frühere Störungen aus einem Context Grounding Index über Ihren abgeschlossenen Tickets, mit den Ticketnummern, die er verwendet hat; der Störungsmanager korrigiert und veröffentlicht, sodass nichts einen Stakeholder erreicht, hinter dem kein Mensch mit Namen steht. Parallel führen Robots das Diagnose-Runbook des Service aus, und Aktualisierungen folgen einem Takt aus der Zeitleiste des Tickets statt aus jemandes Erinnerung. Beim Abschluss schreibt ein Robot die Zeitleiste in den Eintrag und eröffnet ein Problemticket, sobald die Wiederholungsregel erfüllt ist.
Änderungen laufen durch einen UiPath Maestro Prozess, dessen DMN-Regeln jede von ihnen nach Kritikalität des Elements, Wirkungsradius, Einspielfenster, Testnachweisen und der Historie dieses Änderungstyps bewerten. Standardänderungen mit vollständigen Nachweisen gibt die Regel frei; normale erreichen den Verantwortlichen am Tag des Antrags als UiPath Action Center Aufgabe in Teams; nur hohes Risiko erreicht das Gremium, mit Bewertung und Nachweisen. Danach beobachtet ein Robot Azure Monitor und ServiceNow vierundzwanzig Stunden lang und verknüpft jede Störung mit der Änderung, die ihr vorausging. Power BI berichtet Wiederherstellungszeit, Erfolgsquote der Änderungen und durch Änderungen verursachte Störungen.
Störungs-, Problem- und Änderungseinträge in ServiceNow; Kanäle und Adaptive Cards in Microsoft Teams; Alarme und Aktionsgruppen von Azure Monitor; UiPath Maestro BPMN mit DMN-Regeln und Instanzverwaltung; UiPath Action Center Aufgaben in Microsoft Teams; UiPath Context Grounding Indizes; Power BI
Den Prozess für den Störungskanal, die Diagnose-Runbooks, die Wiederholungs- und Risikoregeln, den Änderungsprozess in Maestro, die Monitoring-Prüfung nach dem Einspielen und die Berichte
ServiceNow und Jira über Konnektoren des UiPath Integration Service mit Ereignis-Triggern; die Konnektoren Microsoft Teams und Microsoft Azure für Kanal und Plattformdaten; Aktionsgruppen in Azure Monitor, die die API von UiPath Orchestrator aufrufen
So läuft der automatisierte Prozess
- SystemEine Störung in ServiceNow wird als groß markiert, und ein Ereignis-Trigger des Integration Service startet den Prozess binnen einer Minute
- AutomatisierungEin Teams-Kanal öffnet sich mit den betroffenen Services, den Bereitschaftsverantwortlichen, dem Link zur Brücke und dem Stand des Runbooks
- AutomatisierungEin UiPath Agent entwirft die Zusammenfassung und listet ähnliche frühere Störungen aus der indizierten Ticket-Historie, mit den Ticketnummern dahinter
- MenschDer Störungsmanager korrigiert den Entwurf, veröffentlicht ihn und führt die Brücke; Ingenieure beheben, was das Runbook nicht abdeckt
- AutomatisierungAktualisierungen folgen einem Takt aus der Zeitleiste; beim Abschluss schreibt der Robot sie in den Eintrag und eröffnet ein Problemticket, sobald die Regel erfüllt ist
- AutomatisierungEine in ServiceNow beantragte Änderung wird in Maestro von DMN-Regeln nach Kritikalität, Wirkungsradius, Fenster, Nachweisen und Historie bewertet
- MenschNormale Änderungen gibt der Verantwortliche in einer Action Center Aufgabe in Teams frei; riskante gehen mit der Bewertung an das Gremium
- AutomatisierungDanach beobachtet ein Robot Azure Monitor und ServiceNow vierundzwanzig Stunden und verknüpft jede Störung mit der Änderung oder schließt sie als erfolgreich
Modell der Zusammenarbeit von Mensch und Automatisierung
Die Automatisierung übernimmt
- Das Anlegen des Störungskanals mit seinen Services, Bereitschaftsverantwortlichen und dem Link zur Brücke
- Den Entwurf der Zusammenfassung und das Finden ähnlicher früherer Störungen zur Prüfung durch einen Menschen
- Die Ausführung der Diagnose- und Nachweis-Runbooks sowie die Aktualisierungen im Takt der Zeitleiste
- Die Risikobewertung der Änderung, die Freigabe von Standardänderungen auf Nachweis und die Monitoring-Beobachtung nach dem Einspielen
Menschen entscheiden
- Der Störungsmanager prüft die Zusammenfassung vor der Veröffentlichung und führt die Brücke
- Ingenieure diagnostizieren und beheben alles, was das Runbook nicht abdeckt
- Die Verantwortlichen geben normale Änderungen frei; das Gremium entscheidet hohes Risiko und besitzt die Liste der Standardänderungen
- Der Problemmanager entscheidet über Grundursache und dauerhafte Lösung
Vorher und nachher
Systeme und Integrationen
Der Stack ist bewusst kurz: eine Engine, eine Ausführungsschicht, ein Ort für menschliche Entscheidungen.
Eingaben
- Störungen, Probleme und Änderungen aus ServiceNow
- Vorgänge der Entwicklungsteams aus Jira
- Alarme aus Azure Monitor und Signale aus Application Insights
- die Konfigurationsdatenbank mit Service-Verantwortlichen und Bereitschaftsplänen
- der Änderungskalender mit seinen Sperrfenstern
Automatisierungsschicht
- UiPath Orchestrator
- UiPath Robots
- UiPath Maestro
- UiPath Integration Service
- UiPath Action Center
- UiPath Agents
Zielsysteme
- ServiceNow
- Jira
- Microsoft Teams
- Power BI
Berührungspunkte für Menschen: der Störungskanal in Teams; Action Center Freigaben in Teams für Verantwortliche und Gremium; die Prüfung der Zusammenfassung durch den Störungsmanager; die Grundursachen-Entscheidung des Problemmanagers
Eingesetzte Technologien
Ereignis-Trigger auf Störungs- und Änderungseinträgen; legt den Kanal an, schreibt in das Werkzeug zurück
Aführen die Runbooks aus; Warteschlangen, Wiederholungen, Anmeldeinformationsspeicher und Prüfpfad
Ader Änderungsprozess: Risikobewertung, automatische Freigabe auf Nachweis, Weiterleitung, Instanzverwaltung
Aentwirft die Störungszusammenfassung und findet ähnliche Fälle in Ihren abgeschlossenen Tickets, mit Quellenangabe
AFreigaben der Verantwortlichen und des Gremiums sowie die Prüfaufgabe des Störungsmanagers
Ader Störungsraum, die Besetzungskarte und die Freigabekarten
AAlarme, die über Aktionsgruppen Runbooks starten; die vierundzwanzigstündige Beobachtung nach jedem Einspielen
AWiederherstellungszeit, Erfolgsquote der Änderungen, durch Änderungen verursachte Störungen, Gremiumsminuten je Änderung
AIllustratives Wirtschaftlichkeitsmodell
Zahlen, die Sie an Ihren eigenen Daten prüfen können.
Brücken und Gremien sind die zwei Orte, an die dieses Geld fließt, und im Kalkulator steht nur der erste. Der Koordinationsaufwand beträgt 16 Minuten je Störung: Verantwortliche suchen, den Raum öffnen, Status tippen und den Eintrag im Anschluss schreiben, bei Vollkosten von 56 € je Stunde. Der Ablauf nimmt ihn bei den 60 % der Störungen weg, die einen Service mit Verantwortlichem und Runbook betreffen, und dieser Anteil ist in das Volumen eingerechnet, sodass 620 Störungen pro Monat als 372 in den Kalkulator eingehen. Die Änderungsverwaltung steht außerhalb des Kalkulators, weil ihr Satz abweicht: 95 Änderungen pro Monat zu 55 Minuten über Antragsteller und Gremium hinweg, 71 € je Stunde, davon die Hälfte als nachweisbasierte Standardänderungen, rund 37.098 € pro Jahr. Nichts davon wurde bei einem Kunden gemessen, und Diagnose, Behebung und entgangener Umsatz bleiben außerhalb des Modells.
Rechnen Sie mit Ihren Zahlen
Eine illustrative Schätzung aus Ihren Eingaben. Sie modelliert freigesetzte Kapazität und verspricht keine Einsparung.
Geschäftlicher Nutzen
- Die ersten zwanzig Minuten einer Großstörung gehen in die Behebung, weil Verantwortliche, Services und Runbook von Beginn an im Raum sind
- Stakeholder erhalten Aktualisierungen im Takt des Eintrags, sodass niemand die Brücke mit der Frage unterbricht, was dem Geschäft zu sagen ist
- Wiederkehrende Störungen werden per Regel zu Problemen, mit angehängten Belegen, und werden damit behoben statt wiederholt
- Risikoarme Änderungen gehen am Tag des Antrags produktiv, während hohes Risiko ein Gremium trifft, das die Bewertung gelesen hat
- Durch Änderungen verursachte Störungen werden automatisch verknüpft, sodass die Organisation ihre echte Änderungsfehlerquote kennt
Sicht der Geschäftsleitung
- Jede Großstörung trägt eine Zeitleiste, die niemand rekonstruieren musste, sichtbar bereits während sie läuft
- Der Änderungskalender zeigt Risiko statt Termine, und die Agenda schrumpft auf das, wofür elf Personen nötig sind
- Ingenieurzeit auf Brücken und in Freigaben wird messbar und damit planbar
- Erfolgsquote der Änderungen und durch Änderungen verursachte Störungen werden berichtete Zahlen, der erste Schritt zu ihrer Verbesserung
KPIs für die Geschäftsführung
Sicherheit und Governance
Sicherheit wird mit dem Prozess entworfen, nicht danach.
- Runbook-Robots führen Dienstkonten, die auf die Diagnose- und Neustartaktionen ihrer eigenen Services begrenzt sind, und nichts Destruktives läuft unbeaufsichtigt; Geheimnisse kommen zur Laufzeit aus Azure Key Vault über den Anmeldeinformationsspeicher des Orchestrator
- Die automatische Freigabe gilt nur für Änderungstypen, die das Gremium als standard eingestuft hat, und jede von ihnen wird mit der auslösenden Regelversion nach ServiceNow zurückgeschrieben
- Ein Antragsteller kann seine eigene Änderung nicht freigeben, und die Freigabewege liegen im Prozess, nicht in einer Gewohnheit
- Der Agent liest die indizierte Ticket-Historie unter Richtlinien des UiPath AI Trust Layer, mit erlaubtem Modell, PII-Maskierung und EU-Routing, nennt seine Quellen und veröffentlicht nie ohne benannte Person
- Der Prüfpfad des Orchestrator und die ServiceNow-Historie ergeben den vollständigen Nachweis; die Verarbeitung bleibt in Ihrem Microsoft 365 Tenant und in der EU-Region von UiPath Automation Cloud
Warum jetzt
Der Release-Takt steigt schneller, als ein Wochentermin lesen kann: Quartal für Quartal treffen mehr Einspielungen auf dieselben fünfundvierzig Minuten, also wächst der Druck zur Sammelfreigabe mit dem Risiko
ITSM-Werkzeuge veröffentlichen heute die Ereignisse und APIs, die diese Übergaben ohne Werkzeugwechsel automatisierbar machen, und Störungen werden ohnehin in Microsoft Teams geführt, sodass Eintrag und Arbeit endlich zusammenkommen; der modellierte Koordinationspool beträgt 5.555 € pro Monat, bevor eine einzige Änderung vorab freigegeben ist
Die Suche über Ihre eigenen abgeschlossenen Tickets macht aus dem Finden ähnlicher Störungen eine Konfiguration statt eines Projekts, und Kunden fragen heute nach Nachweisen der Änderungskontrolle statt nach Sitzungsprotokollen
Relevante Führungsrollen
Ausfälle werden kürzer und seltener, und die Änderungskontrolle liest sich für einen Prüfer als Kontrolle und nicht als Ritual
Ingenieure gehen nur auf die Brücke, wenn sie gebraucht werden, das Gremium liest, was es freigibt, und beides kommt als Zahl zurück
Störungen, die Bestellungen berühren, werden im festen Takt kommuniziert, und ihre Ursachen werden behoben statt wiederholt
Häufige Fragen und Einwände
Es hält die Einträge und die Freigaben und soll sie behalten. Es öffnet nicht den Teams-Raum, findet nicht den Bereitschaftsverantwortlichen, schreibt keine Zusammenfassung, führt keinen Neustart aus und prüft danach kein Monitoring; genau dort liegen die Stunden, und wir ergänzen sie ohne Werkzeugwechsel.
Der Agent entwirft und nennt die Tickets, die er verwendet hat; veröffentlicht wird durch den Störungsmanager. Nichts geht hinaus, was eine benannte Person nicht gelesen hat, und die Liste ähnlicher Störungen ist eine Suche in Ihrer eigenen Historie, keine Meinung.
Der Weg in den Ausfall ist die Freigabe ohne Lesen. Eine Standardänderung wird nur mit Testnachweisen, gültigem Fenster, ohne Sperrfrist und mit sauberer Historie automatisch freigegeben, und jedes Einspielen wird danach gegen das Monitoring geprüft, was der Freitagstermin nie getan hat.
Wann dies nicht die richtige Lösung ist
- Kein ITSM-Werkzeug mit API: Ein Änderungsverzeichnis in einer Tabelle braucht zuerst ein Werkzeug, nicht eine Automatisierung
- Weniger als etwa hundert Störungen pro Monat, wo ein guter Bereitschaftsplan und ein disziplinierter Manager das meiste bereits leisten
- Vollständig ausgelagerte IT im Service-Management-Prozess des Dienstleisters, wo die Arbeit eine Frage des Vertrags ist
Eine Frage für die nächste Sitzung
Die Ausfälle des letzten Quartals: Kann dieses Unternehmen die Änderung hinter jedem einzelnen benennen, und wenn nicht, was genau steuert dann der Freitagstermin?
Vorgehen bei der Umsetzung
Ein Umfang ohne Unklarheiten, noch vor der Unterschrift.
Wir liefern
- Die Großstörungen und Gremiumsentscheidungen des letzten Quartals vollständig gelesen, mit den daraus abgeleiteten Runbooks, der Wiederholungsregel und den Risikofaktoren
- Den Prozess für den Störungskanal: Kanalanlage, Besetzungskarte, Aktualisierungen im Takt und die beim Abschluss in den Eintrag geschriebene Zeitleiste
- Diagnose- und Nachweis-Runbooks für die drei Services hinter den meisten Ihrer Großstörungen
- Den Änderungsprozess in Maestro: Risiko-Entscheidungstabelle, Nachweisregeln für Standardänderungen und Freigaben in Teams
- Die Monitoring-Prüfung nach dem Einspielen und die Power BI Berichte zu Wiederherstellungszeit und Änderungserfolg
Wir benötigen von Ihnen
- Eine Konfigurationsdatenbank oder eine funktionierende Liste mit Service-Verantwortlichen und Bereitschaftsplänen
- Die Großstörungen und Gremiumsagenden des letzten Quartals samt Ergebnissen
- Nach Service getaggte Alarme in Azure Monitor, damit ein Runbook ohne Raten gewählt werden kann
- Einen Änderungsmanager und einen Problemmanager, die die Regeln besitzen und vertreten
Etappen
Analyse
Störungen und Änderungsentscheidungen des letzten Quartals gelesen; Runbooks, Wiederholungsregel und Risikofaktoren mit ihren künftigen Eignern abgestimmt
Konzeption
Kanalprozess, Entscheidungstabelle, Nachweisregeln für Standardänderungen, Freigaben und Sicherheitsmodell
Aufbau
Kanalprozess, Runbooks, Maestro-Prozess, Agent, Monitoring-Prüfung und Berichte in Ihrer Umgebung
Schattenbetrieb
Zusammenfassungen entworfen, aber nicht veröffentlicht, Änderungen bewertet, aber nicht geroutet; Regeln an echten Entscheidungen korrigiert
Start und Skalierung
Kanäle laufen für Großstörungen, Standardänderungen gehen auf nachweisbasierte Freigabe über, Runbooks kommen Service für Service hinzu
Abteilungsweit. Den Aufwand bestimmen der Zustand Ihrer Konfigurationsdatenbank, die Zahl der Services mit eigenem Runbook und wie viele Änderungstypen das Gremium als standard einstuft.
Elf Personen, fünfundvierzig Minuten, einundzwanzig ungeöffnete Anhänge.
Bringen Sie die Agenda Ihres letzten Änderungsgremiums und die Zeitleisten Ihrer fünf jüngsten Großstörungen mit. Zurück kommen die Änderungen, die auf Nachweis vorab freigegeben werden konnten, und der Punkt in jeder Zeitleiste, an dem die Störungsuhr verloren ging.
Letztes Änderungsgremium prüfenDer Nachbarprozess hat meist dasselbe Problem
Die 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ösungenStatus, Störung, Änderung: gemeldet, bevor jemand fragtDie Störungsmail geht nach der Störung raus, und jeder fünfte Ticketkommentar besteht aus denselben zwei Wörtern.
Lösung ansehen Weitere LösungenWer Bereitschaft hat und was ausgefallen ist, in TeamsWährend einer Störung ist die Person, die sie behebt, auch die Einzige, die weiß, welche Kunden betroffen sind.
Lösung ansehenBranchen, in denen wir das am häufigsten umsetzenProduktion & IndustrieTransport & LogistikDienstleistungen & ITShared Services