Start · Lösungen · Weitere Lösungen
Lösung · Weitere LösungenDie Platte war vor drei Wochen fast voll. Intune wusste es; niemand hat die Liste gelesen.
Der Laptop repariert, bevor der Nutzer anruft
Ein geplanter Roboter liest Intune, Defender for Endpoint, Postfächer und Zertifikate, führt bei Routinefällen die freigegebene Korrektur aus, informiert in Microsoft Teams und öffnet ein Ticket nur für den Techniker.
Kurzfassung für die Geschäftsführung
Die Platte läuft voll, das Zertifikat läuft ab, das Update scheitert erneut, und der Desk erfährt es vom Nutzer.
Der Entwurf beginnt mit einem Zeitplan statt mit einem Postfach.
Routinefehler werden behoben, wenn das Signal erscheint, und nicht wenn der Nutzer anruft.
Geräteaktionen in Microsoft Intune; Tickets und Problemdatensätze in ServiceNow; das monatliche Behebungsprotokoll
Geschäftsproblem
Geräte
Endpoint-Management erzeugt Daten, keine Arbeit. Intune meldet Compliance, Speicherplatz, Update- und Verschlüsselungsstatus; Defender for Endpoint meldet Alarme und verwundbare Software; Exchange Online weiß, welche Postfächer am Limit stehen; die Zertifizierungsstelle weiß, welche Maschinenzertifikate nächste Woche ablaufen. Etwas davon zu nutzen verlangt einen Menschen, der filtert, priorisiert, den Nutzer kontaktiert und die Korrektur anwendet, und der Desk hat keine Kapazität für Arbeit, die noch kein Ticket ist.
Die Routineausfälle werden deshalb von hinten aufgezogen. Eine volle Platte wird zur Störung, wenn Outlook nicht mehr synchronisiert, ein abgelaufenes Zertifikat wird zur Störung, wenn ein Standort am Montagmorgen aus dem WLAN fällt, ein Postfach am Limit wird zur Störung, wenn eine Kundin sagt, die Antwort sei nie angekommen. Techniker beheben denselben Fehler am selben Laptop-Modell zwanzigmal, ohne dass jemand bemerkt, dass es ein Problem ist und nicht zwanzig.
Die Nutzer ziehen den naheliegenden Schluss, die Laptops seien unzuverlässig und die IT sei langsam, was beiden unrecht tut. Das Muster hält, weil Überwachung und Behebung in verschiedenen Werkzeugen verschiedener Teams liegen, jede einzelne Korrektur für sich günstig ist und niemand an Prävention gemessen wird.
Wie es heute läuft
- SystemDie Telemetrie hält die ausfallende Platte fest, das dritte gescheiterte Update und das Zertifikat, das in elf Tagen abläuft
- WartezeitNiemand ist zum Lesen eingeteilt, also liegt der Befund auf einem Dashboard, bis das Symptom auftritt
- MenschDer Nutzer bemerkt, dass Outlook nicht mehr synchronisiert, behilft sich zwei Tage lang und ruft dann beim Desk an
- MenschDie Servicekraft erhebt Gerätename, Modell und Fehlertext, die der Tenant längst hatte
- WartezeitDas Ticket geht an einen Techniker und wartet auf ein Rückrufzeitfenster, das zu einem Schichtmitarbeiter passt
- SystemDer Techniker wendet eine bekannte Korrektur an, gibt Speicher frei oder wiederholt das Update, und schließt das Ticket
- FehlerrisikoDerselbe Fehler am selben Modell kommt nächste Woche zurück; kein Muster wird festgehalten, und das Gerät wird zu früh oder zu spät ersetzt
Warum der heutige Prozess mehr kostet, als er scheint
Das Budget zeigt Stellen, nicht wofür sie draufgehen.
- Die Desk-Minuten sind die Hälfte der Rechnung. Der Nutzer verliert ungefähr noch einmal so viel, und zwar im schlechtesten Moment: vor einem Kundentermin, während einer Schichtübergabe, im Umspannwerk mit den Sicherheitsunterlagen auf einem toten Laptop.
- Ein Gerät, das eine Compliance-Prüfung nicht besteht oder einen Patch verpasst, bleibt ungeschützt, bis jemand handelt, womit der Abstand zwischen Signal und Korrektur eine Sicherheitszahl ist und keine Servicezahl.
- Der Zertifikatsablauf kommt nicht Gerät für Gerät. Er nimmt einem Standort an einem Vormittag das WLAN, und der Desk hört ihn als zwanzig gleichzeitige Anrufe.
- Ersatzentscheidungen folgen Beschwerden statt Zustandsdaten, sodass das Budget Geräte kauft, die eine zwanzigminütige Korrektur erhalten hätte, während Techniker qualifizierte Stunden mit Skripten verbringen, die sie schon ausgeführt haben.
Kosten des Nichtstuns
Keine der ersten beiden Zeilen bewertet die Exposition: ein Gerät, das einen Patch verpasst oder eine Compliance-Prüfung nicht besteht, bleibt in diesem Zustand, bis jemand handelt, und der Abstand zwischen Signal und Korrektur ist die Zahl, nach der ein Sicherheitsaudit fragt. Die mittlere Zeile ergänzt 300 verhinderte Störungen pro Monat zu je 40 Minuten, also 200 Stunden zu 36 € je Stunde; die Stunde eines Technikers im Umspannwerk ist mehr wert, und keine Zeile bewertet die Sicherheitsunterlagen auf dem toten Laptop.
Ein Jahr davon lässt den Desk voller werden statt ruhiger: der Bestand altert, also steigen die Ausfälle, und Personalwachstum bringt gleichzeitig mehr Geräte. Zertifikate laufen weiter überraschend ab, Standorte verlieren weiter für einen Vormittag das WLAN, und das Budget kauft weiter Ersatzgeräte, die eine zwanzigminütige Korrektur vermieden hätte.
Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.
Ein Energieversorger mit 6.000 Beschäftigten, rund 7.500 Windows- und macOS-Geräten, verwaltet in Microsoft Intune mit Microsoft Defender for Endpoint, und einem Service-Desk auf ServiceNow.
Rund 600 gerätebezogene Störungen pro Monat: wenig Speicherplatz, gescheiterte Updates, Compliance- und Verschlüsselungsfehler, Akku- und Hardwaredefekte, Zertifikatsprobleme und Postfächer am Limit. Techniker in Umspannwerken sind für die Sicherheitsunterlagen auf ihre Laptops angewiesen.
Jede Störung kommt als Ticket an, nachdem der Nutzer das Symptom bemerkt hat; der Desk erhebt erneut Daten, die der Tenant schon hat, und ein Techniker wendet eine bekannte Korrektur an.
Etwa 34 Minuten Desk- und Technikerzeit je Störung und etwa 40 Minuten Zeit des Nutzers drumherum; die IT-Leitung schätzt, dass die Hälfte in der Telemetrie sichtbar war, bevor es jemand bemerkte.
Ein geplanter UiPath Robot liest Intune, Defender for Endpoint, Postfachnutzung und Zertifikatsablauf, wendet die Schwellenwerte des Versorgers an und sortiert jeden Befund auf drei Wege: ein freigegebenes Runbook, das läuft und den Nutzer danach in Microsoft Teams informiert, eine Teams-Karte mit der Bitte um zwei Schritte, oder ein ServiceNow-Ticket mit Telemetrie und Korrekturvorschlag, eröffnet bevor der Nutzer anruft.
Im modellierten Fall kommt die Hälfte der 600 monatlichen Störungen nicht mehr als Ticket an, Techniker öffnen Tickets, die die Belege bereits enthalten, und wiederkehrende Fehler werden als Probleme festgehalten. Die Zahlen sind ein Modell, keine Messung.
Vorgeschlagene Lösung
Der Entwurf beginnt mit einem Zeitplan statt mit einem Postfach. Ein UiPath Robot läuft auf einem Orchestrator-Zeitauslöser und liest Compliance- und Bestandsdaten aus Microsoft Intune, Alarme und Schwachstellenstatus aus Microsoft Defender for Endpoint, die Postfachnutzung aus Exchange Online und die Ablaufdaten aus dem Bericht Ihrer Zertifizierungsstelle. Danach wendet er Ihre eigenen Schwellenwerte an: fünf Prozent freier Speicher, drei gescheiterte Updates in Folge, vierzehn Tage bis zum Zertifikatsablauf, neunzig Prozent des Postfachlimits.
Jeder Befund über einem Schwellenwert bekommt eines von drei Ergebnissen, und diese Aufteilung ist der ganze Entwurf. Routine und sicher: der Roboter führt ein freigegebenes Runbook aus, gibt temporären Speicher frei, wiederholt das Update oder beantragt eine Zertifikatserneuerung, und sagt dem Nutzer danach in Microsoft Teams, was geschehen ist. Nutzeraktion nötig: eine Teams-Karte mit den zwei Schritten und einer Erinnerungsfunktion, und der Desk bleibt außen vor, solange die Karte nicht verfällt. Techniker nötig: ein Ticket entsteht über UiPath Integration Service in ServiceNow und trägt Telemetrie, Verlauf und einen Korrekturvorschlag, bevor der Nutzer angerufen hat.
Wo derselbe Fehler wiederkehrt, liest ein UiPath Agent das Behebungsprotokoll des Monats und entwirft eine Ursachennotiz: dieses Modell mit dieser Dockingstation-Firmware, dieses Büro mit dieser Zertifikatsvorlage. Der Entwurf bleibt ein Entwurf: er erreicht den Problem-Manager als UiPath Action Center Aufgabe in Teams und wird nur dann ein Problemdatensatz, wenn ein Mensch ihn annimmt. Das Sprachmodell liest das Protokoll; es führt nie eine Korrektur aus und rührt nie ein Gerät an.
Bestand, Compliance-Status und Geräteaktionen in Microsoft Intune; Alarme und Schwachstellenstatus in Microsoft Defender for Endpoint; Adaptive Cards in Microsoft Teams; Zeitauslöser, Credential Store und Prüfpfad in UiPath Orchestrator; UiPath Action Center Aufgaben, die in Teams erledigt werden; Modell-Allowlist und PII-Maskierung des AI Trust Layer für den Agenten
Das Schwellenwertmodell und die Klassifizierungsregeln, die Behebungs-Runbooks als Roboter-Workflows, die Nutzerkarten samt Nachfasslogik, die Ticketvorlage mit angehängten Belegen, das Behebungsprotokoll und den Präventionsbericht
Lesen der verwalteten Geräte aus Intune, der Postfachnutzung aus Exchange Online und des Defender-for-Endpoint-Status über Microsoft Graph unter einer eng gefassten Identität; der ServiceNow-Konnektor in UiPath Integration Service für Tickets und Problemdatensätze; der Ablaufbericht Ihrer Zertifizierungsstelle
So läuft der automatisierte Prozess
- AutomatisierungNach Zeitplan liest ein Roboter Intune-, Defender-for-Endpoint- und Postfachsignale über Microsoft Graph sowie die Ablaufdaten der Zertifizierungsstelle
- AutomatisierungJedes Gerät wird an Ihren Schwellenwerten gemessen; Befunde darunter werden festgehalten, und sonst geschieht nichts
- AutomatisierungRoutinefälle lösen ein freigegebenes Behebungs-Runbook aus, das läuft und danach sein eigenes Ergebnis prüft
- SystemDer Nutzer erhält eine kurze Nachricht in Microsoft Teams darüber, was behoben wurde, oder eine Karte mit den zwei Schritten, die nur er gehen kann
- SystemAlles, was ein Techniker sehen muss, entsteht als ServiceNow-Ticket mit Telemetrie, Geräteverlauf und angehängtem Korrekturvorschlag
- MenschDer Techniker löst die Fälle außerhalb der Routine und beginnt bei Belegen statt bei Fragen
- AutomatisierungJeder Lauf, jedes Runbook und jedes Ergebnis wird in das Orchestrator-Protokoll und den Monatsbericht geschrieben
- MenschEin UiPath Agent entwirft daraus Ursachennotizen; der Problem-Manager nimmt jede davon als Action-Center-Aufgabe in Teams an oder verwirft sie
Zusammenspiel von Mensch und Automatisierung
Die Automatisierung übernimmt
- Das Lesen von Geräte-, Sicherheits-, Postfach- und Zertifikatssignalen nach Zeitplan und das Anwenden Ihrer Schwellenwerte
- Die Einordnung jedes Befunds als Routine, Nutzeraktion oder Technikerfall, danach den Lauf des freigegebenen Runbooks und die Bestätigung, dass die Korrektur gegriffen hat
- Nachrichten und Karten für Nutzer in Teams sowie Tickets mit bereits angehängten Belegen
- Den Entwurf von Ursachennotizen aus dem monatlichen Behebungsprotokoll
Menschen entscheiden
- Welche Runbooks unbeaufsichtigt laufen dürfen, auf welchen Gerätegruppen, einzeln freigegeben
- Jede Diagnose, die die Runbooks nicht abdecken, und jede Änderung an einem Produktivgerät außerhalb davon
- Ob eine entworfene Ursache ein Problemdatensatz wird oder verworfen wird
- Schwellenwerte, Richtlinien und den Zeitpunkt, an dem ein Gerät ersetzt statt repariert wird
Vorher und nachher
Systeme und Integrationen
Wir fügen keine Technologie hinzu, damit eine Architektur seriös aussieht. Jedes Element unten hat hier eine konkrete Aufgabe.
Eingänge
- Bestand und Compliance-Status aus Microsoft Intune
- Alarme und Schwachstellen aus Microsoft Defender for Endpoint
- Postfachnutzung in Exchange Online
- Zertifikatsablauf aus der Zertifizierungsstelle
- die Zuordnung von Gerät zu Person in Microsoft Entra ID
Automatisierungsschicht
- UiPath Orchestrator
- UiPath Robots
- UiPath Agents
- UiPath Action Center
- UiPath Integration Service
Zielsysteme
- Geräteaktionen in Microsoft Intune
- Tickets und Problemdatensätze in ServiceNow
- das monatliche Behebungsprotokoll
- der Präventionsbericht
Kontaktpunkte für Menschen: Nachrichten und Karten für Nutzer in Microsoft Teams; Action-Center-Aufgaben in Teams für den Problem-Manager; die ServiceNow-Warteschlange des Technikers
Eingesetzte Technologien
Bestand, Compliance-Status und die Geräteaktionen, die die Runbooks aufrufen
AAlarme und Schwachstellenstatus, die die Priorität eines Geräts anheben
Aliest Geräte-, Postfach- und Sicherheitsdaten unter einer eng gefassten Anwendungsidentität
Ader geplante Lauf, die Runbooks, Credential Store, Wiederholungen und Prüfpfad
ANutzernachrichten und Karten mit den zwei Schritten, die nur der Nutzer gehen kann
Aproaktive Tickets und Problemdatensätze mit angehängter Telemetrie
Aentwirft Ursachennotizen aus dem Behebungsprotokoll unter einer Modell-Allowlist
Ader Problem-Manager nimmt jede entworfene Ursache an oder verwirft sie
AIllustratives Wirtschaftlichkeitsmodell
Was es wert ist, mit offener Rechnung.
Der vermeidbare Anteil ist die einzige Annahme, die dieses Modell wirklich bewegt, und er ist auf die Hälfte gesetzt: 300 der 600 monatlichen Störungen gelten als früh genug in der Telemetrie sichtbar, um ohne Ticket erledigt zu werden, weshalb der Rechner bei 300 ansetzt und nicht bei 600. Vierunddreißig Minuten sind die Desk- und Technikerzeit je Störung, 51 € der gemischte vollbelastete Stundensatz. Die Zeit der Nutzer ist im nächsten Abschnitt bewertet, nicht hier. Lizenzen, Bau und Runbook-Entwicklung liegen außerhalb dieser Zahlen, 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
- Routinefehler werden behoben, wenn das Signal erscheint, und nicht wenn der Nutzer anruft, sodass ein ganzer Strom von Störungen den Desk nicht mehr erreicht
- Nutzer erfahren in einer Teams-Nachricht, was geschehen ist oder was zu tun ist, was den überraschenden Ausfall durch dreißig Sekunden Lesen ersetzt
- Tickets, die einen Techniker erreichen, kommen mit Telemetrie, Verlauf und Korrekturvorschlag, sodass die Diagnose bei Belegen beginnt und nicht bei Fragen
- Wiederkehrende Fehler an einem Modell oder an einem Standort werden zu benannten Problemen, was die zwanzigste identische Reparatur beendet und das Gefährdungsfenster ungepatchter Geräte verkürzt
Sicht der Geschäftsführung
- Prävention wird messbar: Befunde je Lauf, Korrekturen ohne Ticket, erledigte Nutzeraktionen, Tickets, die vor dem Anruf entstanden sind
- Patch- und Compliance-Exposition wird zu einer täglichen Zahl mit einem Verantwortlichen, nicht zu einem Monatsbericht, der nach Schließen des Fensters eintrifft
- Die Zeit der Techniker verschiebt sich von Skriptreparaturen zu echter Diagnose, und das zeigt sich in Zahlen statt in einem Eindruck
- Die Antwort auf „was läuft auf unseren Geräten ohne Menschen“ ist eine versionierte Liste freigegebener Runbooks mit benannten Verantwortlichen
KPIs für die Geschäftsführung
Sicherheit und Governance
Sicherheit wird mit dem Prozess entworfen, nicht danach.
- Der Roboter liest über Microsoft Graph mit einer Anwendungsidentität, die auf Geräte-, Sicherheits- und Postfachlesezugriffe sowie die Geräteaktionen seiner Runbooks begrenzt ist; Geheimnisse werden zur Laufzeit aus einem Credential Store bezogen, dem eigenen des Orchestrator oder Ihrem Azure Key Vault
- Jedes Runbook hat einen benannten Verantwortlichen, eine Version und eine Liste der Gerätegruppen, die es berühren darf. Eines, das scheitert, hält an und öffnet ein Ticket, statt blind zu wiederholen, und der Pilot läuft zuerst im reinen Erkennungsmodus
- Der Agent liest das Behebungsprotokoll und sonst nichts. Er läuft hinter dem AI Trust Layer mit Modell-Allowlist, PII-Maskierung und eigenem Prüfpfad, und sein Ergebnis bleibt ein Entwurf, bis der Problem-Manager ihn annimmt
- Karten für Nutzer tragen nur das, was zum Handeln nötig ist; die Verarbeitung bleibt in den EU-Regionen von UiPath Automation Cloud und Microsoft 365, und jeder Lauf und jede Korrektur lässt sich aus dem Orchestrator-Protokoll rekonstruieren
Warum jetzt
Der Anstoß kommt meist von außen: ein Sicherheitsaudit mit der Frage, wie lange eine bekannte Schwachstelle offen stand, eine Außendienstmannschaft, die nicht auf Rückrufe warten kann, oder ein Hardwarebudget für Ersatzgeräte, die eine Korrektur verhindert hätte
Intune und Defender for Endpoint stellen über Microsoft Graph heute das meiste bereit, was ein Techniker früher von Hand erhoben hat, und die Geräteaktionen für die Routinezustände sind auf demselben Weg erreichbar, unter einer eng gefassten Identität
Ein Roboter führt diese Aktionen unter Freigabe und Prüfpfad aus, und ein Sprachmodell kann einen Monat Behebungsprotokolle lesen und die darin liegenden Muster vorschlagen; allein die Desk- und Technikerzeit ist mit 8.670 € pro Monat modelliert
Relevante Führungsrollen
Der Gerätebestand wird zu etwas, das die IT vor dem Ausfall steuert, mit einer Präventionszahl für das Gremium statt einer Ticketzahl
Ein Strom vermeidbarer Störungen verlässt den Desk, und Techniker wiederholen keine Skriptkorrekturen mehr an denselben drei Modellen
Außendienst und Betrieb verlieren weniger Stunden an einen Laptop, der an einem Tag ausfiel, den die Telemetrie längst angezeigt hatte
Häufige Fragen und Einwände
Das kann es, für bestimmte Skriptprüfungen. Hinzu kommt hier die Einordnung über Intune, Defender for Endpoint, Exchange Online und Ihre Zertifizierungsstelle in einem Lauf, die Nachricht an den Nutzer, das Ticket mit Belegen und ein Freigabepfad für jedes Runbook.
Jedes Runbook wird von einem benannten Verantwortlichen freigegeben, auf Gerätegruppen begrenzt und versioniert, und der Pilot läuft im reinen Erkennungsmodus, bis der Desk der Einordnung zustimmt. Die Alternative ist nicht „keine Korrekturen“: es sind dieselben Korrekturen von Hand, ohne Aufzeichnung.
Alarme ohne angehängte Handlung ertränken jeden. Hier verlässt jeder Befund den Lauf als Runbook, Nutzerkarte oder Ticket, und die Zahl von jedem sagt Ihnen, ob ein Schwellenwert richtig gesetzt ist.
Wann diese Lösung nicht passt
- Weniger als einige hundert Geräte, wo ein Techniker den ganzen Bestand überblickt und eine Quartalskontrolle weniger kostet als ein Ablauf
- Die Geräte werden nicht in Intune oder Gleichwertigem verwaltet, es gibt also keine Telemetrie zu lesen; das erste Projekt ist dann Endpoint-Management und nicht dieses
- Ein Dienstleister für verwaltete Endgeräte verantwortet proaktive Behebung bereits vertraglich, oder Gerätestörungen sind selten und die Zeit des Desks geht anderswohin
Eine Frage für die nächste Sitzung
Möchten wir von den 212 Geräten, die kurz vor dem Ausfall stehen, lieber heute Abend aus dem Dashboard erfahren oder im nächsten Monat von ihren Nutzern?
Umsetzungsansatz
Was wir liefern und was wir für den Start brauchen.
Wir liefern
- Einen Abgleich eines Monats Gerätetickets mit der Telemetrie derselben Geräte, der den vermeidbaren Anteil mit Ihren Daten klärt
- Das Schwellenwertmodell und die Klassifizierungsregeln, abgestimmt mit dem Desk und mit der Sicherheit
- Die ersten Behebungs-Runbooks, typischerweise Speicherplatz, Update-Wiederholung und Postfachlimit, jedes freigegeben und auf eine Gerätegruppe begrenzt
- Nutzerkarten und Nachrichten in Teams, die ServiceNow-Ticketvorlage mit Telemetrie und Korrekturvorschlag sowie den Weg von einer validierten Ursache zum Problemdatensatz
- Das Behebungsprotokoll, den Präventionsbericht und die Agentenkonfiguration für den Ursachenentwurf
Wir brauchen von Ihnen
- Eine Microsoft Graph Anwendungsidentität für den Roboter, begrenzt auf Geräte-, Sicherheits- und Postfachlesezugriffe sowie die Geräteaktionen, die seine Runbooks aufrufen
- Eine benannte Person für die Runbook-Freigabe und einen Problem-Manager sowie einen Monat Gerätetickets für den Abgleich mit der Telemetrie
- Ihre Schwellenwerte oder einen ersten Entwurf davon aus dem Desk und die Gerätegruppen, auf denen der Pilot handeln darf
Etappen
Analyse
Einen Monat Tickets mit der Telemetrie derselben Geräte abgleichen und den vermeidbaren Anteil bestimmen
Nur Erkennung
Die Klassifizierung läuft und berichtet; nichts wird behoben, und der Desk prüft die Befunde gegen die Wirklichkeit
Erste Runbooks
Drei Routinekorrekturen gehen für eine Gerätegruppe live, jeder Lauf wird geprüft
Skalierung
Mehr Runbooks und Gerätegruppen, Schwellenwerte nachgeschärft aus dem, was die Läufe finden
Muster
Der Agent entwirft Ursachen, sobald das Protokoll lesenswert ist, und der Problem-Manager validiert sie
Abteilungsweit. Der Aufwand folgt der Zahl der Telemetriequellen, der Zahl der Runbooks, die der Desk automatisieren will, und der Strenge Ihres Änderungsprozesses für ein Produktivgerät.
Der Ausfall stand drei Wochen vor dem Anruf schon auf dem Dashboard.
Schicken Sie uns einen Intune-Compliance-Export und einen Monat Gerätetickets. Wir gleichen beides ab und geben Ihnen die Störungen zurück, die in der Telemetrie sichtbar waren, bevor jemand sie gemeldet hat, samt den drei Runbooks, die sie zuerst geschlossen hätten.
Intune-Export mit Ihren Tickets abgleichenDer Nachbarprozess hat meist dasselbe Problem
Vier von zehn IT-Tickets folgen einer bekannten Prozedur, und jedes wartet trotzdem in der Schlange auf einen Analysten.
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ö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