Warum modernes ITSM in Microsoft 365 lebt

"Modernes ITSM" wird oft verwendet, meist um genau das zu verkaufen, was der Anbieter gerade baut. Deshalb lohnt es sich, präzise zu sein, was sich wirklich geändert hat. Die Frameworks nicht. Incident, Change, Problem und Request Management funktionieren noch so, wie ITIL es beschrieben hat. Geändert hat sich, wo Service Management läuft und wie nah es an der täglichen Arbeit der Menschen sitzt.

Zwei Jahrzehnte lang war die Antwort einfach: Service Management lief auf einer eigenen Plattform, neben allem anderen. Das ergab Sinn, als die Alternative Papier und E-Mail war. Es ergibt deutlich weniger Sinn, jetzt, da die tägliche Arbeit einer Organisation ohnehin in einer einzigen Umgebung stattfindet.

Das alte Modell: Service Management neben der Arbeit

Gehen wir eine normale Support-Anfrage in einem klassischen Setup durch. Ein Problem entsteht in Teams. Die Anfrage wird in Outlook formuliert. Die relevanten Informationen liegen in SharePoint. Eine Genehmigung passiert irgendwo in einem Chat. Und danach muss der formale Vorgang in ein separates Service-Management-System übertragen werden, damit er sauber nachverfolgt werden kann.

Es funktioniert. Menschen machen es jeden Tag. Aber jede dieser Übergaben kostet etwas. Zeit, Aufmerksamkeit und ein bisschen Genauigkeit, jedes Mal, wenn der Kontext von einem Ort zum nächsten wandert. Nicht das Werkzeug ist das Problem. Die Distanz ist es.

Adoption als stilles Scheitern

Das ist auch der Grund, warum Adoption immer das stille Scheitern des klassischen ITSM war. Man kann eine starke Plattform kaufen und trotzdem zusehen, wie die halbe Organisation einen Bogen darum macht, weil noch ein weiteres Portal zu öffnen, nur um ein Ticket zu erfassen, eine Reibung ist, die niemand will. Geringe Adoption untergräbt dann die Daten, und schwache Daten untergraben alles, wofür man die Plattform überhaupt angeschafft hat.

Modernes ITSM geht dorthin, wo die Menschen schon arbeiten

Die Verschiebung, die modernes ITSM ausmacht, ist kein neues Feature. Es ist ein Ortswechsel. Service Management zieht in die Umgebung, in der die Menschen ohnehin sind.

Für einen großen Teil der Organisationen ist diese Umgebung Microsoft 365. Teams ist der Ort der Gespräche. Outlook gibt den Takt des Tages vor. SharePoint hält die Dokumente und das Wissen. Entra ID regelt, wer was sehen und tun darf. Power Platform und Copilot liegen über all dem. Läuft Service Management darin, verschwinden die Übergaben. Man erstellt eine Anfrage dort, wo das Problem entstanden ist. Historie, Identität und Berechtigungen sind bereits vorhanden.

Die praktische Definition

Das ist die praktische Definition von modernem ITSM: nicht Service Management mit einer schöneren Oberfläche, sondern Service Management, das aufhört, ein separates Ziel zu sein.

AI ist die eigentliche Trennlinie, und sie ist eine Architekturentscheidung

Der ehrliche Grund, warum das 2026 mehr zählt als 2022, ist AI. Fast jeder ITSM-Anbieter sagt inzwischen, er habe AI. Diese Aussage allein bedeutet wenig. Jedes System kann ein Ticket zusammenfassen oder eine Antwort entwerfen.

Die eigentliche Frage ist, was die AI tun darf, und das hängt vollständig davon ab, wo sie läuft. AI, die auf einer externen Plattform sitzt, sieht nur, was die Integrationen dieser Plattform ihr zuführen. Sie kann unterstützen. Sie kann vorschlagen. Aber sie arbeitet auf Distanz zu den Systemen, die Probleme tatsächlich lösen: Identität, Geräte, Sicherheitssignale, der breitere Betrieb.

Zwei unterschiedliche Positionen für AI

AI, die im eigenen Microsoft-Tenant läuft, arbeitet aus einer anderen Position. Sie hat den Kontext bereits, weil die Daten ihn nie verlassen haben. Sie kann über dieselben Copilot-, Governance- und Identity-Kontrollen handeln, die der Rest der Umgebung nutzt. Das ist der Unterschied zwischen einem Assistenten, der über die Arbeit spricht, und einem, der sie erledigt.

Die AI-Frage dreht sich also nicht wirklich um Features. Es geht um Architektur. Proaktive, agentische AI ist nichts, was man auf einen Service Desk aufsetzt. Es ist etwas, das verlangt, dass der Service Desk dort lebt, wo Daten und Kontrollen bereits sind.

Wie das in der Praxis aussieht

Modernes ITSM in einem Microsoft-nativen Setup ist im Gebrauch ziemlich unspektakulär, und genau das ist der Punkt:

• Tickets, Anfragen und Genehmigungen passieren in Microsoft Teams, nicht in einem separaten Portal.
• CMDB und Wissensdatenbank liegen in SharePoint, es gibt also keinen zusätzlichen Datenspeicher zu synchronisieren oder abzusichern.
• Workflows und Automatisierung laufen auf Power Automate, mit Konnektoren, die die Organisation schon hat.
• Reporting kommt über Power BI oder Copilot, auf denselben Daten, ohne Export-Schritt.
• Copilot unterstützt innerhalb des Tenants, unter dessen eigenen Regeln.

Niemand muss einen neuen Arbeitsort lernen. Die Service-Management-Erfahrung wird Teil des digitalen Arbeitsplatzes, statt eine Station außerhalb davon zu sein.

Was das alte Modell kostet

Es gibt eine finanzielle Seite, die oft übersprungen wird. Organisationen, die klassisches ITSM neben Microsoft betreiben, zahlen faktisch dreimal. Einmal für Microsoft 365, das sie ohnehin haben. Einmal für die separate Service-Plattform. Und ein drittes Mal, weniger sichtbar, für die Reibung dazwischen: die zu pflegenden Integrationen, die duplizierten Daten, die in Übergaben verlorene Zeit, die Adoption, die nie ganz gelingt.

Modernes ITSM entfernt die zweite und dritte Kosten, statt eine vierte hinzuzufügen. Die Daten liegen bereits im Tenant. Es gibt keine externe Plattform, die pro Agent für Fähigkeiten lizenziert werden muss, die Microsoft schon bereitstellt. Die Total Cost of Ownership sinkt nicht, weil die Software billiger ist, sondern weil die Architektur aufhört, Arbeit zu erzeugen.

Compliance gehört jetzt zur Definition

Vor einigen Jahren konnte man Compliance als separaten Arbeitsbereich behandeln. Unter NIS2, DORA und GDPR ist das nicht mehr realistisch, besonders in regulierten Branchen. Wo die Service-Daten liegen, ist heute eine Compliance-Frage, nicht nur eine IT-Frage.

Hier zahlt sich der Ortswechsel erneut aus. Läuft das Service Management im Microsoft-Tenant, bleiben die Daten unter den eigenen Governance-, Identity- und Audit-Kontrollen der Organisation. Mit „Back-end in a box“ gibt es keine Kopie sensibler Service-Daten in einer Drittanbieter-Cloud, die man verantworten muss.

Wo man anfängt

Man modernisiert ITSM nicht, indem man eine größere Plattform kauft. Man tut es, indem man die Distanz zwischen Service Management und der Arbeit verkürzt. In der Praxis heißt das ein paar ehrliche Fragen:

• Wie viele separate Orte durchläuft eine einzelne Anfrage, bevor sie gelöst ist?
• Wie viel Ihrer Service-Daten liegt außerhalb der Umgebung, der Sie ohnehin vertrauen?
• Und wenn Sie sagen, Sie "haben AI", handelt sie auf Ihrem echten Betrieb, oder spricht sie nur darüber?

Wenn die Antworten auf Distanz, Duplizierung und auf Distanz gehaltene AI hindeuten, ist das genau die Lücke, die modernes ITSM schließen soll. Die Frameworks waren nie das Problem. Der Ort war es.

Das Fazit

Modernes ITSM ist kein neues Framework und keine größere Plattform. Es ist Service Management, das in die Umgebung zieht, in der die Arbeit ohnehin stattfindet, Microsoft 365, sodass Anfragen, Daten und AI auf demselben Kontext handeln statt über eine Lücke hinweg.

Dieser Wechsel klärt auch die Kosten- und Compliance-Fragen gleich mit. Hört Service Management auf, ein separates Ziel zu sein, verschwinden die doppelte Lizenzierung, der Integrationsaufwand und die Audit-Lücken rund um eine Kopie der Daten bei einem Drittanbieter mit.