WEBVTT 00:00:00.000 --> 00:00:03.420 Ticketing sieht auf dem Papier sauber aus. Man erhält die Zahlen, die Warteschlangen, die Dashboards. 00:00:04.200 --> 00:00:07.660 Doch in der Realität misst dieses Modell den Schmerz erst, wenn das System bereits versagt hat. 00:00:08.260 --> 00:00:10.560 Der kostspielige Teil des Problems beginnt meist viel früher. 00:00:11.060 --> 00:00:14.460 Er beginnt, wenn ein Mitarbeiter 10 Minuten verliert, dann 20 und schließlich einfach aufgibt. 00:00:14.740 --> 00:00:15.300 Die Versuchungssinn. 00:00:16.240 --> 00:00:19.480 Sie verpassen das Meeting oder teilen die falsche Datei, weil der richtige Weg nicht mehr funktioniert. 00:00:19.940 --> 00:00:22.200 Und genau das ist der Teil, den die meisten Support-Teams noch immer nicht sehen. 00:00:22.580 --> 00:00:25.300 Beim besten internen Support-Modell von heute geht es nicht um schnellere Triage. 00:00:25.760 --> 00:00:28.100 Es geht darum, die Notwendigkeit einer Triage komplett zu beseitigen. 00:00:28.100 --> 00:00:33.020 Stellen Sie sich einen autonomen Agenten in Microsoft 365 vor, der den Kontext überwacht, 00:00:33.200 --> 00:00:36.520 Reibungspunkte früh erkennt und handelt, bevor jemand überhaupt daran denkt, ein Portal zu öffnen. 00:00:37.420 --> 00:00:40.200 In dieser Episode zeige ich Ihnen, warum das Helpdesk-Modell versagt, 00:00:40.620 --> 00:00:43.520 was es tatsächlich ersetzt und wie Sie es steuern können, ohne Chaos zu stiften. 00:00:44.360 --> 00:00:47.660 Wenn dieser Wandel für Ihre Arbeit wichtig ist, abonnieren Sie im Trat 65 FM, 00:00:47.820 --> 00:00:51.160 denn eine Ebene tiefer ist das eigentliche Problem nicht die Warteschlange, sondern das Modell dahinter. 00:00:52.080 --> 00:00:52.900 Das Ende des Tickets. 00:00:53.340 --> 00:00:55.020 Der alte Support-Ablauf ist noch überland zu treffen. 00:00:55.380 --> 00:00:57.120 Etwas geht kaputt. Ein Benutzer bemerkt es. 00:00:57.120 --> 00:00:58.580 Der Benutzer versucht es zu erklären. 00:00:59.020 --> 00:01:03.660 Dann übersetzt die IT diese Erklärung in eine Kategorie, eine Priorität und vielleicht eine Zuweisungsgruppe. 00:01:04.000 --> 00:01:05.220 Das Problem landet in einer Warteschlange. 00:01:05.560 --> 00:01:06.180 Jemand sichtet es. 00:01:06.560 --> 00:01:07.940 Jemand anderes fragt nach weiteren Detailn. 00:01:08.180 --> 00:01:09.200 Ein weiteres Team wird hinzugezogen. 00:01:09.560 --> 00:01:11.580 Die Zeit läuft weiter, während die eigentliche Arbeit stecken bleibt. 00:01:11.960 --> 00:01:14.140 Dieser Prozess fühlt sich normal an, weil er vertraut ist. 00:01:14.320 --> 00:01:16.180 Aber vertraut und effektiv sind nicht dasselbe. 00:01:16.660 --> 00:01:17.400 Ein Ticket ist kein Support. 00:01:17.940 --> 00:01:19.820 Ein Ticket ist der Beweis dafür, dass der Support zu spät kann. 00:01:20.260 --> 00:01:23.880 Bis ein Ticket überhaupt existiert, ist der Mitarbeiter bereits auf ein Hindernis gestoßen und hat seinen Kontext verloren. 00:01:23.880 --> 00:01:27.500 Er hat seine Aufmerksamkeit bereits von der Arbeit abgewendet, die er eigentlich erledigen wollte. 00:01:27.920 --> 00:01:28.740 Die verlangt es nicht der Service. 00:01:29.180 --> 00:01:30.360 Die Warteschlange ist ein Protokollschalter. 00:01:30.600 --> 00:01:34.560 In großen Microsoft 365 Umgebungen wird die manuelle Triage zum eigentlichen Flaschenhals. 00:01:34.920 --> 00:01:36.500 Das passiert nicht, weil Support-Teams faul wären. 00:01:37.120 --> 00:01:40.900 Es passiert, weil von Menschen Dinge verlangt werden, die nicht mehr zum Maßstab der Umgebung passen. 00:01:41.400 --> 00:01:43.700 Sie haben mehr Benutzer, mehr Geräte, mehr Apps, mehr Richtlinien. 00:01:44.540 --> 00:01:49.140 Sie haben mehr Grenzfälle, die gleichzeitig Teams SharePoint, Exchange, Intune und Entra betreffen. 00:01:50.100 --> 00:01:51.040 Das Volumen wächst nicht nur. 00:01:51.380 --> 00:01:52.280 Die Kombinationen wachsen. 00:01:52.720 --> 00:01:54.040 An diesem Punkt bricht das alte Modell zu sein. 00:01:54.400 --> 00:01:56.320 Die meisten Teams reagieren, indem sie mehr Struktur hinzufügen. 00:01:56.660 --> 00:01:59.340 Sie bauen ein weiteres Portal, einen weiteren Bot oder eine weitere Routing-Regel. 00:01:59.720 --> 00:02:03.300 Doch in der Realität fügt das nur eine weitere Ebene zwischen dem Mitarbeiter und der Lösung hinzu. 00:02:03.920 --> 00:02:08.780 Das System wartet immer noch darauf, dass der Benutzer das Problem bemerkt, es beschreibt und auf die richtige Weise um Hilfe bittet. 00:02:08.780 --> 00:02:17.120 Arbeit beginnt nicht in einem Support-Portal, sie beginnt in Teams, in Outlook, in einem Dokument, das jemand gerade braucht oder einem Meeting, das in 30 Sekunden startet. 00:02:17.820 --> 00:02:21.720 Genau dort entsteht der Support-Bedarf tatsächlich und das Ticket-Modell ist von diesem Moment völlig entkoppelt. 00:02:22.480 --> 00:02:24.860 Die versteckten Kosten sind viel höher, als es ihr Warteschlangen-Bericht sei. 00:02:25.260 --> 00:02:26.300 Die Leute wechseln ständig im Kontext. 00:02:26.680 --> 00:02:28.640 Doppelte Vorfälle stapeln sich unter verschiedenen Bezeichnungen. 00:02:29.300 --> 00:02:29.940 Wissensartikel verhalten. 00:02:30.740 --> 00:02:34.680 Analysten verbringen ihren ganzen Tag mit Sortieren, Zuweisen und Klären, anstatt die Dinge tatsächlich zu reparieren. 00:02:34.680 --> 00:02:40.940 Die Lösungszeit zieht sich in die Länge, da jede Übergabe eine Verzögerung verursacht und jede Verzögerung den ursprünglichen Kontext schmälert. 00:02:41.500 --> 00:02:44.700 Forschung zu agentischer KI- und IT-Betrieb deutet auf dasselbe strukturelle Problem hin. 00:02:45.280 --> 00:02:48.640 Mindestens 80% des Aufwands stecken immer noch in reaktiver Arbeit nach IT-Lat fest. 00:02:49.200 --> 00:02:51.720 Diese Zahl ist wichtig, weil sie ihnen genau sagt, wohin die Arbeit fließt. 00:02:52.300 --> 00:02:54.920 Sie fließt nicht in Resilienz oder Prävention, sondern in Reaktion. 00:02:55.380 --> 00:02:59.420 Sobald man das erkennt, wirkt das Ticket weniger wie ein Betriebsmodell und mehr wie ein Symptom. 00:02:59.420 --> 00:03:02.320 Es ist das Symptom eines Systems, das erst reagiert, wenn der Schaden sichtbar ist. 00:03:02.320 --> 00:03:07.280 Die nächste Frage ist also nicht, wie man Tickets schneller bearbeitet, sondern was das System tun sollte, bevor überhaupt ein Ticket nötig ist. 00:03:08.120 --> 00:03:09.340 Das Modell des unsichtbaren Mitarbeiters. 00:03:09.640 --> 00:03:10.840 Was ersetzt also das Ticket tatsächlich? 00:03:11.460 --> 00:03:16.960 Es ist nicht einfach ein weiterer Chatbot, der auf demselben Chaos aufbaut und ganz sicher keine schönere Fassade für dieselbe alte Warteschlange. 00:03:17.480 --> 00:03:23.200 Der Wandel geht viel tiefer, denn der unsichtbare Mitarbeiter ist eine operative Kraft, die in ihrer Microsoft 365 Umgebung lebt. 00:03:24.180 --> 00:03:30.520 Dieser Agent hat eine eigene Identität, einen definierten Aufgabenbereich, ein Gedächtnis für das, was er gestern getan hat und strikte Regeln für seine Befugnisse. 00:03:31.260 --> 00:03:32.200 Dieser Unterschied ist entscheidend. 00:03:32.660 --> 00:03:36.780 Ein Chatbot wartet darauf, dass sie einen Prompt eingeben, aber ein unsichtbarer Mitarbeiter achtet auf sich ändernde Bedingungen. 00:03:37.100 --> 00:03:39.580 Er geht vom Kontext aus, anstatt von einem Gespräch. 00:03:40.280 --> 00:03:45.620 Da er Anmeldestatus, Gerätezustand, Lizenzstatus und Dateifreigaben sieht, muss er nicht warten, bis Probleme auftreten. 00:03:46.680 --> 00:03:51.200 Anstatt zu fragen, wie er helfen kann, nachdem etwas kaputt gegangen ist, stellt er im Hintergrund ständig eine andere Frage. 00:03:51.900 --> 00:03:55.300 Was weicht von dem Zustand ab, den dieser Mitarbeiter braucht, um seine Arbeit jetzt zu erledigen? 00:03:55.980 --> 00:03:57.120 Genau hier verändern sich die Dinge. 00:03:57.520 --> 00:03:59.480 Das Modell ist direkt in die Arbeit selbst eingebettet. 00:03:59.480 --> 00:04:07.820 Wenn jemand einem Meeting beitritt und das Audio-Routing fehlt, schlägt oder ein Gast eine gerade gesendete Datei nicht öffnen kann, erstellt die alte Welt einen Bericht und eine Übergabe. 00:04:08.740 --> 00:04:15.000 Im neuen Modell erkennt der Agent das Muster sofort, prüft, ob die Bedingung einem bekannten Problem entspricht und führt die nächste sichere Aktion zur Behebung aus. 00:04:15.000 --> 00:04:21.520 Vielleicht setzt der Entfahrt zurück, löst eine Richtlinienprüfung aus oder leitet eine Anfrage um und fordert eine MFA an, bevor er die Korrektur dokumentiert. 00:04:22.180 --> 00:04:22.800 Der Punkt ist einfach. 00:04:23.260 --> 00:04:27.300 Die erste Reaktion erfordert keinen Menschen mehr, der eine vage Beschreibung liest und raten muss, was passiert ist. 00:04:27.840 --> 00:04:32.780 Wenn es gut funktioniert, wirkt es unsichtbar, denn es gibt kein Wartezimmer und kein Formular, bei dem man eine Kategorie auswählen muss. 00:04:33.140 --> 00:04:34.800 Support zeigt sich als wiederhergestellter Arbeitsfluss. 00:04:34.800 --> 00:04:39.620 Der Mitarbeiter kann einfach weiterarbeiten und sieht in vielen Fällen nicht einmal den Mechanismus, der im Hintergrund abläuft. 00:04:40.340 --> 00:04:42.600 Sie sehen bereits, wie dies ihre Personalplanung verändert. 00:04:43.540 --> 00:04:48.580 Im alten Modell stellt man Leute ein, um das Volumen aufzufangen, Anfragen zu sortieren und fehlerhafte Zusammenhänge zwischen Teams zu bereinigen. 00:04:49.120 --> 00:04:56.220 Das neue Modell benötigt weniger Personal für die Triage und mehr Leute, die Leitplanken entwerfen, soll Zustände definieren und das Verhalten dieser Agenten dauerhaft überwachen. 00:04:56.660 --> 00:05:00.420 Menschen bleiben im System, aber die gesamte Struktur ihrer täglichen Arbeit verschiebt sich. 00:05:01.000 --> 00:05:03.780 Die Forschung zu agentischer KI im Support weist immer wieder in diese Richtung. 00:05:03.780 --> 00:05:11.420 Routinesupport kann sich in Richtung ausnahmebasierter Abwicklung bewegen, was bei gut definierten Umgebungen und Richtlinien enorme Effizienzgewinne bringt. 00:05:12.080 --> 00:05:14.060 Dieser letzte Teil ist entscheidend, denn das ist keine Zauberei. 00:05:14.600 --> 00:05:19.580 Wenn Ihre Daten schwach oder Ihre Prozesse chaotisch sind, wird der Agent nicht allein dadurch intelligent, dass Sie ihn autonom nennen. 00:05:20.520 --> 00:05:26.080 Mir wurde das klar, als ich aufhörte, den Agenten als Softwarefunktion zu sehen und anfing, ihn als nichtmenschlichen Mitarbeiter mit Dienstausweis zu betrachten. 00:05:26.680 --> 00:05:30.760 Ein echter Mitarbeiter benötigt eine Identität, eine Stellenbeschreibung, Berechtigungen und einen Vorgesetzten. 00:05:30.760 --> 00:05:37.220 Der Agent benötigt genau dasselbe, denn der Wert entsteht durch zuverlässiges Handeln innerhalb eines Systems, nicht durch kluge Formulierungen in einem Chatfenster. 00:05:37.900 --> 00:05:39.760 Der unsichtbare Mitarbeiter ist kein UI-Trick. 00:05:40.260 --> 00:05:49.360 Es ist eine neue Support-Ebene, die Reibungsverluste in der gesamten Microsoft 365 Umgebung überwacht, innerhalb der Richtlinien agiert und menschliche Aufmerksamkeit auf die Ausnahmen lenkt, die tatsächlich ein Urteilsvermögen erfordern. 00:05:49.360 --> 00:05:52.240 Sobald dieses Modell klar ist, wird die nächste Frage sehr praxisnah. 00:05:52.740 --> 00:05:53.840 Wie funktioniert Prävention eigentlich? 00:05:54.440 --> 00:05:55.440 Die Architektur der Prävention. 00:05:56.220 --> 00:05:58.840 Wie funktioniert Prävention also eigentlich innerhalb von Microsoft 365? 00:05:59.540 --> 00:06:02.640 Der Wandel vollzieht sich von Anfrage und Antwort hin zur Ereignisanalyse und Orchestrierung. 00:06:03.180 --> 00:06:05.660 Das klingt technisch, aber das Modell ist einfach, wenn man es in seine Einzelteile zerlegt. 00:06:06.220 --> 00:06:11.560 Zuerst ändert sich etwas in der Umgebung, dann interpretiert das System, ob diese Änderung ein Risiko oder eine Abweichung darstellt, 00:06:11.560 --> 00:06:14.540 und schließlich führt es die genehmigte Aktion mit den bereits vorhandenen Tools aus. 00:06:15.100 --> 00:06:16.180 Beginnen wir mit der Ereignis-E... 00:06:16.180 --> 00:06:19.180 Microsoft 365 erzeugt bereits überall Signale. 00:06:19.660 --> 00:06:23.520 Entra erfasst Anmeldeverhalten, während Intune den Gerätestatus und die Compliance überwacht. 00:06:24.520 --> 00:06:29.100 Defender achtet auf verdächtige Aktivitäten und Teams zeigt ihnen genau, wann ein Meeting-Field schlägt oder die Anrufqualität sinkt. 00:06:29.800 --> 00:06:32.860 SharePoint und Exchange legen Zugriffsmuster und Inhaltsaktivitäten offen, 00:06:33.300 --> 00:06:35.980 während Service Health Signale melden, wenn die Plattform selbst das Problem ist. 00:06:36.440 --> 00:06:39.520 Wenn man die Benutzeraktion hinzunimmt, erhält man einen konstanten Strom an Kontextinformation. 00:06:39.680 --> 00:06:44.400 Die meisten Unternehmen erfassen diese Signale, aber nur wenige nutzen sie tatsächlich als Unterstützungssystem. 00:06:44.400 --> 00:06:48.760 Rohe Ereignisse allein helfen nicht, da sie eine Analyse-Ebene benötigen, um aus dem Rauschen einen Sinn zu ergeben. 00:06:49.280 --> 00:06:53.400 Hier hört der unsichtbare Mitarbeiter auf, nur Automatisierungstheater zu sein und beginnt, wie ein echter Operator zu handeln. 00:06:53.760 --> 00:06:58.780 Der Agent betrachtet das Signal, vergleicht den aktuellen Zustand mit dem Zielzustand und entscheidet, welche Art von Aktion sicher ist. 00:06:59.340 --> 00:07:02.300 Ein Audioproblem in einem Meeting ist nicht dasselbe wie eine riskante Anmeldung, 00:07:02.380 --> 00:07:04.820 und ein defekter Freigabelink unterscheidet sich von einer Lizenz in Conway. 00:07:04.820 --> 00:07:09.600 Der Agent muss das Problem zuerst klassifizieren, denn Handeln ohne Klassifizierung führt nur schneller zu Fehlern. 00:07:10.340 --> 00:07:11.220 Dann kommt die Orchestrierung. 00:07:12.060 --> 00:07:15.360 Sobald der Agent das Problem versteht, kann er den richtigen Mechanismus zur Reaktion nutzen. 00:07:15.740 --> 00:07:20.560 Das könnte Power Automate für Workflows, Copalette Studio für Logik oder Microsoft Graph für Systemaktion und Kontext sein. 00:07:21.100 --> 00:07:24.040 Die Werkzeuge sind wichtig, aber der entscheidende Punkt ist, wie sie miteinander verbunden sind. 00:07:24.560 --> 00:07:29.260 Sie bauen nicht einen einzelnen intelligenten Prompt, sondern eine Kette, die er kennen, entscheiden, handeln und verifizieren kann. 00:07:29.760 --> 00:07:31.060 Dieser letzte Teil wird ständig übersehen. 00:07:31.060 --> 00:07:34.360 Ein selbstkorrigierendes System stoppt nicht, sobald die Aktion ausgeführt wurde. 00:07:35.000 --> 00:07:38.740 Es durchläuft eine Schleife, es erkennt das Problem, prüft den Zustand, wendet die Korrektur an 00:07:38.740 --> 00:07:41.080 und verifiziert das Ergebnis, bevor es alles protokolliert. 00:07:41.640 --> 00:07:46.240 Die Forschung zur selbstkorrigierenden Logik macht deutlich, dass diese Systeme durch Feedback und Korrekturmuster arbeiten, 00:07:46.360 --> 00:07:48.820 statt durch eine isolierte Antwort eines Sprachmodells. 00:07:49.640 --> 00:07:52.320 Wenn die erste Aktion fehlschlägt, muss das System bewerten können, warum, 00:07:52.320 --> 00:07:55.760 um den nächsten Schritt anzupassen und dabei innerhalb definierter Grenzen zu bleiben. 00:07:56.300 --> 00:07:58.920 Sie können sich das an einigen Microsoft-Raven von 60 Beispielen gut vorstellen. 00:07:58.920 --> 00:08:02.300 Wenn ein Benutzer blockiert wird, weil Lizenz und Richtlinienumfang nicht übereinstimmen, 00:08:02.520 --> 00:08:05.720 erkennt der Agent die Abweichung und prüft das vorgesehene Rollenprofil und Profil. 00:08:06.260 --> 00:08:11.320 Er wendet die zulässige Korrektur an, bestätigt den Benutzerzugriff und protokolliert die Änderung, ohne jemanden fragen zu müssen. 00:08:11.900 --> 00:08:15.220 Wenn eine riskante Anmeldung in Entra auftritt, sieht der Agent das Risikoereignis 00:08:15.220 --> 00:08:17.300 und prüft sofort ihre Richtlinien für den bedingten Zugriff. 00:08:17.540 --> 00:08:21.220 Er fordert eine stärkere Verifizierung an oder blockiert den Zugriff gemäß ihrer Richtlinie 00:08:21.220 --> 00:08:23.660 und zeichnet das Ergebnis zur späteren Überprüfung durch einen Menschen auf. 00:08:23.660 --> 00:08:29.940 Wenn ein veralteter Freigabelink in SharePoint ständig fehlschlägt, vergleicht der Agent den aktuellen Berechtigungspfad mit den erwarteten Freigaberegeln. 00:08:30.520 --> 00:08:35.120 Er ersetzt den defekten Pfad durch den korrekten und sendet den funktionierenden Link direkt in den Kontext, 00:08:35.220 --> 00:08:39.380 noch bevor ein Support-Mitarbeiter ein Ticket mit der Überschrift dringendes Zugriffsproblem lesen muss. 00:08:39.780 --> 00:08:39.960 Muss. 00:08:40.640 --> 00:08:42.120 Meeting Support ist ein weiteres großartiges Beispiel. 00:08:42.760 --> 00:08:45.980 Wenn ein Raumgerät ausfällt oder eine Verbindung kurz vor Beginn eines Anrufs abbricht, 00:08:46.080 --> 00:08:48.400 kann der Agent den Zustand erkennen und den Fehler validieren. 00:08:48.400 --> 00:08:54.180 Er versucht einen risikoarm Wiederherstellungsschritt und benachrichtigt den Organisator in Teams mit einem Status-Update genau dort, wo die Arbeit stattfindet. 00:08:54.580 --> 00:08:56.900 Diese Kommunikationsebene ist ein wesentlicher Teil des Designs. 00:08:57.360 --> 00:08:59.120 Support muss dort stattfinden, wo die Unterbrechung auftritt. 00:08:59.720 --> 00:09:05.220 Wenn Ihre Arbeit in Teams, Outlook und im M365 Arbeitsbereich stattfindet, sollte der Support Sie auch dort erreichen. 00:09:05.760 --> 00:09:09.380 Sie sollten den Benutzer nicht woanders hinlotsen müssen, wenn Sie das Problem direkt im Kontext lösen können. 00:09:09.860 --> 00:09:13.640 Das bedeutet nicht, dass jede einzelne Aufgabe vollautomatisiert wird, denn das wäre leichtsinnig. 00:09:13.640 --> 00:09:18.860 Risikoarme Aktionen können automatisch ausgeführt werden, aber Änderungen mit großen Auswirkungen benötigen immer noch die Genehmigung der Person. 00:09:19.000 --> 00:09:23.840 Dieser Genehmigungspfad muss von Anfang an Teil der Architektur sein, anstatt ihn später nachträglich hinzuzufügen. 00:09:24.180 --> 00:09:27.340 Der Agent sollte wissen, wann er handeln, wann er nachfragen und wann er genau aufhören muss. 00:09:27.900 --> 00:09:31.640 Und sobald Sie dies in den Ablauf integrieren, geht es in der Diskussion nicht mehr nur um Automatisierungsfunktionen. 00:09:32.300 --> 00:09:36.120 Es geht dann um Kontrolle, Governance, Vertrauen und die Identität des Agenten. 00:09:36.400 --> 00:09:39.980 Wenn der Support beginnt, eigenständig zu handeln, taucht sofort eine schwierige Frage auf. 00:09:40.540 --> 00:09:41.580 Wer erledigt eigentlich die Arbeit? 00:09:41.580 --> 00:09:44.700 Wenn diese Antwort vage bleibt, bricht das gesamte Modell zusammen. 00:09:45.180 --> 00:09:49.320 Ein Agent darf in Ihrer Umgebung nicht als unklarer Helfer mit weitreichenden Zugriffen und ohne klaren Besitz existieren. 00:09:49.640 --> 00:09:51.240 Er benötigt eine echte Identität in Entra. 00:09:51.620 --> 00:09:56.460 Er braucht einen namentlich genannten Besitzer, einen definierten Aufgabenbereich und einen Lebenszyklus, der aus einem bestimmten Grund beginnt und endet. 00:09:56.820 --> 00:10:02.780 Wenn dieser Agent Daten lesen, Workflows auslösen oder Nachrichten an Ihre Benutzer senden kann, müssen Sie ihn wie einen aktiven Teilnehmerantennen steuern. 00:10:03.360 --> 00:10:05.960 Sie dürfen ihn nicht wie ein Feature behandeln, das jemand aktiviert und dann vergessen. 00:10:05.960 --> 00:10:09.020 Deshalb ist die Agentenidentität zu entscheiden für das System. 00:10:09.540 --> 00:10:14.540 Sie müssen genau wissen, was der Agent ist, welche Systeme er berühren kann und wer benachrichtigt wird, wenn die Dinge aus dem Ruder laufen. 00:10:14.880 --> 00:10:16.620 Das Prinzip der geringsten Rechte muss hier die Grundlage bilden. 00:10:16.900 --> 00:10:21.000 Sie dürfen sich nicht mit Bequemlichkeit zufrieden geben oder sich einreden, dass Sie die Berechtigung später einschränken werden. 00:10:21.000 --> 00:10:27.560 Da der Wirkungsradius eines Supportagenten vollständig von seinen Berechtigungen abhängt, ist die Gestaltung dieser Berechtigung ein Kernbestandteil des Supportdesigns. 00:10:28.500 --> 00:10:34.160 Agent 365 dient in diesem Aufbau als notwendige Steuerungsebene, da es die gesamte Agentenumgebung sichtbar macht. 00:10:35.220 --> 00:10:39.540 Es bietet das Verzeichnis, die Genehmigungsworkflows und die Richtlinienvorlagen für einen sicheren Betrieb. 00:10:40.400 --> 00:10:44.280 Auch wenn diese Elemente nach Verwaltungsaufwand klingen, lösen sie ein massives, strukturelles Problem. 00:10:44.280 --> 00:10:50.860 Die meisten Unternehmen scheitern nicht an fehlenden KI-Funktionen, sondern daran, dass sie das bestehende Umfeld nicht überblicken oder steuern können. 00:10:51.460 --> 00:10:52.800 Die Forschungsergebnisse hierzu sind eine. 00:10:53.320 --> 00:10:58.280 Nur eine kleine Minderheit großer Unternehmen kann jeden aktuell laufenden Agenten im System vollständig erfassen. 00:10:59.000 --> 00:11:03.320 Bevor Führungskräfte über die Skalierung von autonomem Support sprechen, müssen sie eine einfachere Frage beantworten. 00:11:03.960 --> 00:11:06.800 Wissen wir überhaupt, welche Agenten existieren und was sie gerade tun? 00:11:07.180 --> 00:11:09.460 Die Überwachung muss zudem dem jeweiligen Risikoniveau entsprechen. 00:11:10.300 --> 00:11:12.400 Ein Produktivitätsagent für Einzelpersonen ist eine Sache. 00:11:12.400 --> 00:11:15.760 Oder ein kollaborativer Agent mit Zugriff auf geteilte Inhalte etwas völlig anderes. 00:11:16.520 --> 00:11:21.000 Dann gibt es Unternehmensagenten, die in sensiblen Workflows agieren, was eine andere Risikokategorie darstellt. 00:11:21.440 --> 00:11:25.180 Deshalb ist das Risiko-Zonen-Modell persönlich kollaborativ und unternehmensweit so wichtig. 00:11:25.560 --> 00:11:27.800 Ihr Kontrollmodell sollte mit der möglichen Tragweite wachsen. 00:11:28.720 --> 00:11:34.740 Behandelt man jeden Agenten gleich, ersticken risikoarme Aufgaben in langsamen Freigaben, während risikoreiche Aufgaben kaum geprüft durchschlüpfen. 00:11:35.440 --> 00:11:39.300 Ihr Kontrollstack in Microsoft 365 sollte für Ihr Team zumindest vertraut wirken. 00:11:39.300 --> 00:11:43.660 Sie nutzen Identitäten über Entra, Datengrenzen durch Purview und Überwachung mittels Defender. 00:11:44.240 --> 00:11:49.560 Sie wenden Zugriffsbedingungen über Conditional Access an und stellen sicher, dass Auditierbarkeit von Anfang an integriert ist. 00:11:49.920 --> 00:11:53.940 Sie müssen nach einem Vorfall exakt rekonstruieren können, was passiert ist, ohne raten zu müssen. 00:11:54.740 --> 00:11:58.520 Menschliche Aufsicht muss in die Logik integriert sein, statt sie in der Krise zu improvisieren. 00:11:58.520 --> 00:12:01.900 Aktionen mit hoher Tragweite sollten immer auf eine menschliche Freigabe warten. 00:12:02.420 --> 00:12:05.680 Die Entscheidungsfindung sollte in einer Form protokolliert werden, die für Menschen nachvollziehbar ist. 00:12:06.000 --> 00:12:09.640 Rollback-Optionen müssen vorhanden sein, bevor die erste autonome Aktion live geht, um. 00:12:10.340 --> 00:12:16.000 Wenn ein Agent den Zugriff aktualisiert oder eine Routing-Richtlinie ändert, muss dies nachverfolgbar und sauber rückgängig machbar sein. 00:12:16.560 --> 00:12:19.420 Ein weiterer Faktor wird oft übersehen, weil frühe Demos so überzeugend wirken. 00:12:20.100 --> 00:12:21.000 Die Kosten der Nacharbeit. 00:12:21.000 --> 00:12:25.640 Wenn ein Agent ihrem Team dauerhaft Aufräumarbeit beschert, schmilzt die geplante Ersparnis sofort dahin. 00:12:26.120 --> 00:12:27.060 Das ist die Steuer auf Nacharbeit. 00:12:27.340 --> 00:12:32.520 Es ist die Zeit, die man mit der Korrektur schlechter Ergebnisse, dem Widerwurf falscher Aktionen oder der Suche nach Nebeneffekten verbringt. 00:12:33.040 --> 00:12:37.020 Wenn ihr Team 10 Minuten bei der Ausführung spart, aber 8 Minuten mit Aufräumarbeiten verbringt, haben sie den Support. 00:12:37.180 --> 00:12:38.340 Nicht wirklich automatisiert. 00:12:38.820 --> 00:12:41.520 Sie haben die Reibungsverluste lediglich in einen anderen Teil des Prozesses verlagert. 00:12:41.860 --> 00:12:44.500 Vertrauen entsteht nicht durch ausgefeilte Richtlinien oder große Ankündigungen. 00:12:44.880 --> 00:12:46.200 Es entsteht durch Nachweis im laufenden Betrieb. 00:12:46.260 --> 00:12:50.080 Die Leute müssen sehen, was der Agent gesehen, was er entschieden und was er tatsächlich im System geändert hat. 00:12:50.080 --> 00:12:52.020 So bauen sie Vertrauen in autonome Support auf. 00:12:52.280 --> 00:12:55.800 Der Beweis muss im Verhalten des Tools liegen, nicht im Branding des Projekts. 00:12:56.520 --> 00:13:01.940 Sobald das Fundament der Governance steht, kann die Diskussion von Sicherheitsjargon zu einer Sprache für Führungskräfte übergehen. 00:13:02.600 --> 00:13:04.260 Was bedeutet das konkret für das Geschäftsergebnis? 00:13:04.960 --> 00:13:06.540 Der neue ROI von unsichtbarem Support. 00:13:07.080 --> 00:13:10.380 Sobald Führungskräfte das Kontrollmodell akzeptieren, ändern sich die finanziellen Fragestellungen. 00:13:10.740 --> 00:13:15.740 Im alten Modell wird der Supportwert an sichtbarer Arbeit gemessen, wie geschlossenen Tickets, bearbeiteten Anrufen und SLA-Leistungen. 00:13:16.300 --> 00:13:19.280 Diese Zahlen sind wichtig, beschreiben aber nur die Reaktionen auf ein Problem. 00:13:19.280 --> 00:13:25.260 Sie verraten nicht, wie viele Unterbrechungen die Warteschlange nie erreicht haben oder wie viel Arbeitszeit durch eine frühzeitige Problemlösung erhalten blieb. 00:13:25.560 --> 00:13:27.120 Das ist das Kernproblem der Erfolgsmessung. 00:13:27.600 --> 00:13:29.420 Unsichtbarer Support schafft Wert durch Abwesenheit. 00:13:30.000 --> 00:13:36.700 Der Wert zeigt sich, wenn kein Ticket anfällt, keine Eskalation nötig ist und kein Analyst 20 Minuten damit verbringt, ein Problem aus unvollständigen Notizen zu rekonstruieren. 00:13:37.860 --> 00:13:41.380 Wer nur den sichtbaren Aufwand des Supportteams misst, verfehlt das eigentliche Ziel. 00:13:41.600 --> 00:13:41.920 FALOI. 00:13:42.420 --> 00:13:44.500 Das Ziel war stabiles Arbeiten mit weniger Unterbrechung. 00:13:44.500 --> 00:13:47.200 Das Ticketvolumen ist für sich allein betrachtet ein schwaches Signal. 00:13:47.900 --> 00:13:52.720 Ein Rückgang der Tickets könnte bedeuten, dass die Nachfrage sank, aber auch, dass die Umgebung gesünder und die Supportebene intelligenter wurde. 00:13:53.160 --> 00:13:54.400 Das sind zwei völlig verschiedene Geschichten. 00:13:55.220 --> 00:13:58.040 Führungskräfte benötigen ein KPI-Set, das zwischen diesen unterscheiden kann. 00:13:58.680 --> 00:14:00.720 Beginnen Sie damit, die autonome Lösungsrate zu betrachten. 00:14:01.520 --> 00:14:07.120 Es geht nicht darum, wie viele Konversationen der Bot führte, sondern wie viele Supportvorgänge komplett ohne menschliches Eingreifen gelöst wurden. 00:14:07.780 --> 00:14:10.280 Sie müssen zudem die Verringerung der durchschnittlichen Lösungszeit nachverfahren. 00:14:10.280 --> 00:14:15.200 In KI-gestützten Umgebungen erreichen Diagnose-intensive Abläufe auf Verbesserungen im Bereich von 40 bis 60 Prozent. 00:14:15.660 --> 00:14:19.100 Dann können Sie die Kosten pro Lösung und die zurückgewonnene Benutzerproduktivität analysieren. 00:14:19.980 --> 00:14:23.820 Diese letzte Kennzahl wird leicht übersehen, da sie nicht in einen Standardservice-Desk-Bericht passt. 00:14:24.620 --> 00:14:26.180 Dabei liegt genau dort auf der Ware wert. 00:14:26.760 --> 00:14:31.400 Jemand, der 15 Minuten blockiert ist, bevor er überhaupt ein Ticket eröffnet, hat bereits Kosten für das Unternehmen verursacht. 00:14:32.000 --> 00:14:37.680 Multipliziert man dies mit Besprechungsunterbrechungen und Zugriffshürden in einem großen Unternehmen, ist der versteckte Verlust viel größer, als es die Warteschlange vermuten lässt. 00:14:37.680 --> 00:14:41.760 Deshalb ist das Modell der Kosten durch Nichtstun so wichtig für den Business Case. 00:14:42.080 --> 00:14:45.840 Sie berechnen die Stunden, die für manuellen Aufwand aufgewendet werden, bevor der formelle Support überhaupt beginnt. 00:14:46.040 --> 00:14:48.180 Dann addieren Sie noch die Kosten für Fehler und wiederholte Arbeit hinzu. 00:14:48.500 --> 00:14:51.280 Plötzlich klingt das Argument für Prävention nicht mehr wie eine bloße Theorie. 00:14:51.800 --> 00:14:53.800 Sie finanzieren nicht nur eine futuristische Support-Ebene. 00:14:54.240 --> 00:14:57.400 Sie schaffen eine versteckte Steuer ab, die seit Jahren Ihre tägliche Arbeit belastet. 00:14:57.760 --> 00:15:00.160 Die Wirtschaftlichkeit des spezifischen Anwendungsfalls macht dies noch deutlicher. 00:15:00.540 --> 00:15:04.980 Untersuchungen zum agentenbasierten IT-Support beziffern die manuelle Bearbeitung auf etwa 8,75 pro Fall. 00:15:04.980 --> 00:15:10.520 Im Gegensatz dazu können die Kosten bei spezialisierten Agenten auf unter 50 Cent pro Fall sinken, sobald das System entwickelt ist. 00:15:10.940 --> 00:15:13.080 Das bedeutet nicht, dass jede Support-Aktion so günstig sein wird. 00:15:13.200 --> 00:15:15.420 Führungskräfte sollten bei pauschalen Durchschnittswerten vorsichtig sein. 00:15:15.840 --> 00:15:20.800 Qualität und Steuerung der Telemetrie beeinflussen immer die Endkosten, doch die Richtung des Trends ist unverkennbar. 00:15:21.480 --> 00:15:24.600 Dies ist der Moment, in dem die IT das alte Image als reines Kostenzentrum hinter sich lässt. 00:15:24.940 --> 00:15:30.080 Nicht, weil der Support verschwindet, sondern weil er zu einer Zuverlässigkeitsebene wird, die im Hintergrund den Durchsatz der Mitarbeiter schützt. 00:15:30.080 --> 00:15:35.100 Das Unternehmen erlebt dies als flüssige Arbeitsabläufe statt als dramatische Supportereignisse. 00:15:35.580 --> 00:15:39.960 Sie erhalten weniger Unterbrechungen, schnellere Wiederherstellungen und weniger Zeitverschwendung durch Routing- und Klärungsbedarf. 00:15:40.440 --> 00:15:42.660 Dennoch können schlechte Messmethoden leicht Fortschritte vortäuschen. 00:15:43.740 --> 00:15:47.860 Wenn ihre Telemetrie schwach ist, könnte der Agent einen Fehler nur schneller zusammenfassen, statt ihn tatsächlich zu verhindern. 00:15:48.400 --> 00:15:51.500 Wenn Nachbesserungen nicht im Dashboard erscheinen, wird der ROI viel sauberer aussehen als er tatsächlich. 00:15:51.500 --> 00:15:56.560 Wenn gewonnene Zeit einfach wieder in minderwertige Tätigkeiten fließt, werden Führungskräfte den Gewinn überschätzen. 00:15:57.320 --> 00:16:01.300 Das Finanzargument muss auf harten Fakten wie verhinderten Vorfällen und weniger manuellen Eingriffen basieren. 00:16:01.980 --> 00:16:04.580 Sie müssen die Zeit messen, die tatsächlich für produktive Arbeit zurückgewonnen wird. 00:16:05.000 --> 00:16:08.960 Sobald Sie dies korrekt messen, wirkt die Supportfunktion nicht mehr wie ein Overhead, der gekürzt werden muss. 00:16:09.380 --> 00:16:12.500 Sie beginnt wie eine Betriebskapazität auszusehen, die das Unternehmen endlich zurückgebringt. 00:16:13.060 --> 00:16:14.360 Was bedeutet das für das Support? 00:16:14.360 --> 00:16:21.720 Denken Sie darüber nach, was dies wirklich für das Team vor Ort bedeutet, denn bei diesem Wandel geht es nicht um Personalabbau, sondern darum, wie Ihre Mitarbeiter ihren Tag verbringen. 00:16:22.680 --> 00:16:28.020 Im alten Setup wird ein Großteil Ihrer Supportkapazität durch Passwort-Resets-Ticket-Rotting und endlose Klärungsschleifen verschlungen. 00:16:28.600 --> 00:16:32.820 Ihre Leute jagen Updates hinterher und verschieben Daten zwischen Systemen, die nie für eine Zusammenarbeit ausgelegt waren. 00:16:33.380 --> 00:16:36.800 Nichts davon macht die Umgebung stabiler, es verhindert lediglich, dass die Warteschlange überläuft. 00:16:37.240 --> 00:16:41.940 Wenn Agenten diese vorhersehbaren Routineaufgaben übernehmen, steigt der menschliche Einsatz endlich auf eine höhere Ebene. 00:16:41.940 --> 00:16:47.500 Support-Ingenieure verbringen ihre Zeit damit, einen gesunden Systemzustand zu definieren und die Logik Hintergenehmigungen zu verfeinern. 00:16:48.080 --> 00:16:53.640 Sie konzentrieren sich darauf, Wissensquellen zu verbessern, das Verhalten von Richtlinien zu testen und sicherzustellen, dass der Agent innerhalb seiner vorgegebenen Grenzen bleibt. 00:16:54.200 --> 00:16:58.940 Da es ist ein völlig anderer Job als den ganzen Tag betrefft, seinen einzustarren und zu raten, was ein Benutzer eigentlich will. 00:16:59.740 --> 00:17:01.640 Genau hier bleiben die meisten Implementierungen stecken. 00:17:02.300 --> 00:17:07.400 Unternehmen versuchen, ihre alten, fehlerhaften Prozesse beizubehalten und einfach einen Agenten darüber zu legen, in der Hoffnung auf ein besseres Ergebnis. 00:17:07.400 --> 00:17:12.240 Doch der Prozess bleibt reaktiv, die Übergaben sind weiterhin chaotisch und das zugrunde liegende Wissen ist schwach. 00:17:12.920 --> 00:17:15.420 Der Agent ist dann nur ein weiterer Anstrich auf einer bröckelnden Wand. 00:17:15.860 --> 00:17:19.620 Er beantwortet eine Frage vielleicht schneller, kann aber kein Support-Modell reparieren, das auf Verzögerung ausgelegt. 00:17:19.860 --> 00:17:21.680 Der bessere Weg ist, die Arbeit zuerst neu zu gestalten. 00:17:22.140 --> 00:17:26.400 Sie müssen entscheiden, welche Aufgaben menschlich bleiben, weil sie Urteilsvermögen oder sensible Kommunikation erfordern. 00:17:26.900 --> 00:17:31.320 Dann entscheiden sie, welche Arbeit in autonome Abläufe übergeht, da das Ergebnis vorhersehbar und die Aktionen sicher sind. 00:17:31.320 --> 00:17:34.080 Diese Aufteilung ist wichtig, denn Support-Teams werden nicht verschwinden. 00:17:34.500 --> 00:17:37.120 Sie werden lediglich zu den Personen die Kontrollen entwerfen und Ausnahmen behandeln. 00:17:37.580 --> 00:17:39.860 Das bedeutet, dass sich auch die Art und Weise ändern muss, wie wir Mitarbeiter schulen. 00:17:40.300 --> 00:17:44.100 Teams müssen lernen, ein System zu überwachen, anstatt nur eine manuelle Aufgabe auszuführen. 00:17:44.640 --> 00:17:48.920 Sie müssen Rollback-Logik, Audit-Reviews und das Testen eines Agenten vor der Inbetriebnahme verstehen. 00:17:49.560 --> 00:17:54.720 Sie müssen auch erkennen können, wann der Modell versagt, denn ein automatisierter schlechter Workflow bleibt ein schlechter Workflow bleibt ein schlechter Workflow. 00:17:55.000 --> 00:17:56.120 Er macht die Dinge nur schneller kaputt. 00:17:56.120 --> 00:17:59.940 Wenn Sie für diese Zukunft einstellen, brauchen Sie wahrscheinlich keinen weiteren Generalisten für die Ticket-Review. 00:18:00.300 --> 00:18:05.540 Sie brauchen jemanden, der Abläufe im Microsoft 365-Stick orchestrieren und die Kontrollen definieren kann, die Agenten im Zaum halten. 00:18:05.840 --> 00:18:06.160 Halb! 00:18:06.460 --> 00:18:11.780 Sie wollen Leute, die die Umgebung verbessern können, sodass die Support-Nachfrage tatsächlich sinkt, anstatt sich nur zu staunen. 00:18:12.160 --> 00:18:15.800 Wie fangen Sie also an, ohne dass es zu einem massiven, mehrjährigen Transformationsprojekt wird? 00:18:16.340 --> 00:18:21.200 Am besten wählen Sie einen einzelnen Ablauf aus, der in Ihrer Microsoft 365-Umgebung ständig für Reibung sorgt. 00:18:22.020 --> 00:18:26.820 Zugriffsbehebungen sind meist ein guter Kandidat, aber Sie könnten sich auch Meeting-Support oder Geräte-Compliance-Übergaben ansehen. 00:18:27.200 --> 00:18:32.720 Es spielt keine Rolle, welchen Sie wählen, solange das Muster häufig auftritt und Sie genau wissen, wie ein erfolgreiches Ergebnis aussehen sollte. 00:18:33.360 --> 00:18:36.500 Sobald Sie das Ziel haben, müssen Sie die Grundlagen mit echter Disziplin definieren. 00:18:37.200 --> 00:18:41.720 Sie müssen wissen, was einen gesunden Zustand ausmacht und welche Ereignisse Ihnen signalisieren, dass etwas vom Kurs abweicht. 00:18:42.340 --> 00:18:46.240 Entscheiden Sie, welche Aktionen sicher automatisiert werden können und wo genau die menschliche Eskalation beginnen muss. 00:18:46.240 --> 00:18:52.780 Bevor Sie etwas in Betrieb nehmen, stellen Sie sicher, dass Sie eine Basislinie für Ticketsahlen, manuelle Eingriffe und die aktuelle Wartezeit der Benutzer haben. 00:18:53.280 --> 00:18:55.420 Außerdem müssen Sie Ihre Governance vom ersten Tag an etablieren. 00:18:55.800 --> 00:19:00.380 Geben Sie dem Agenten eine spezifische Identität, weisen Sie ihm einen menschlichen Besitzer zu und legen Sie klare Genehmigungsregeln. 00:19:00.760 --> 00:19:02.940 Jede einzelne Aktion, die der Agent ausführt, muss protokolliert werden. 00:19:03.460 --> 00:19:08.580 Sie sollten auch einen Plan für die Stilllegung oder Neuzuweisung des Agenten haben, damit er nicht zu einer Geisterautomatisierung wird. 00:19:09.400 --> 00:19:12.560 Sobald der erste Ablauf funktioniert, beginnt sich Ihr gesamtes Betriebsmodell zu verändern. 00:19:12.560 --> 00:19:15.840 Der Support agiert nicht mehr wie ein Empfangsschalter, der nur auf Probleme reagiert. 00:19:16.580 --> 00:19:20.640 Stattdessen beginnt er wie eine Zuverlässigkeits-Engine zu arbeiten, die direkt in das System integriert ist. 00:19:21.440 --> 00:19:24.100 Der Support wandelt sich von einer sichtbaren Reaktion hin zu eingebetteter Prävention. 00:19:24.460 --> 00:19:25.880 Das Ticket war nie die eigentliche Dienstleistung. 00:19:26.180 --> 00:19:27.740 Es war der Beweis, dass der Service zu spät kam. 00:19:28.220 --> 00:19:31.940 Wählen Sie diesen Quartal einen Supportprozess aus und gestalten Sie ihn für Vorbeugung statt für Reaktion um. 00:19:31.940 --> 00:19:39.700 Wenn Sie mehr über M365 Co-Pilot Azure Sicherheit und KI-Betriebsmodelle erfahren möchten, abonnieren Sie M365 FM und hinterlassen Sie eine Bewertung. 00:19:40.280 --> 00:19:43.480 Vernetzen Sie sich mit mir, Mirko Pieter, auf LinkedIn mit dem nächsten Thema, das Sie besprechen möchten.