Was ein ESM-Framework ist, und warum es stockt

Enterprise Service Management ist einer dieser Begriffe, die nach einer größeren Version von ITSM klingen, und oft so verkauft werden. Die Idee dahinter ist wirklich gut. Warum so viele ESM-Vorhaben steckenbleiben, bevor sie sie einlösen, lohnt sich zu verstehen, denn es liegt fast nie am Framework selbst.

ESM in einem Satz

Enterprise Service Management heißt, die Disziplinen, die IT Service Management funktionieren ließen, strukturierte Anfrageannahme, einen Servicekatalog, definierte Workflows, Wissen und klare Verantwortung, auf jede Abteilung anzuwenden, die intern Services liefert. HR, Facility, Finanzen, Recht, Einkauf. Überall, wo Menschen etwas von einem Team anfordern und auf die Erledigung warten.

Das Versprechen ist, dass ein Mitarbeiter einen neuen Laptop, eine Vertragsprüfung, einen Schreibtischumzug oder ein Arbeitszeugnis über eine konsistente Erfahrung anfragen kann, statt für jede Abteilung einen anderen Prozess und einen anderen Posteingang zu lernen.

Das Framework

Ein ESM-Framework ist im Prinzip nicht kompliziert. Es verallgemeinert die ITSM-Bausteine, sodass sie nicht IT-spezifisch sind:

• Eine einzige Annahme, über die jede Anfrage an jede Abteilung gleich gestellt werden kann.
• Ein Servicekatalog, der auflistet, was jede Abteilung anbietet, sodass Anfragen strukturiert sind statt Freitext-Vermutungen.
• Workflows und Genehmigungen, pro Service definiert, sodass jede Anfrage einem bekannten Pfad folgt.
• Wissen, sodass häufige Fragen ganz ohne Anfrage beantwortet werden.
• Verantwortung und Reporting, sodass jedes Team seine eigene Warteschlange, Last und Leistung sehen kann.

Auf dem Papier ist das geradlinig, und die meisten ESM-Frameworks beschreiben ungefähr das. Der schwierige Teil ist nicht das Design.

Warum ESM meist bei der IT steckenbleibt

Hier das Muster. Die IT macht Service Management gut, beschließt, es auf den Rest des Unternehmens auszuweiten, und stößt auf eine Wand, vor der das Framework nicht warnte: Jede andere Abteilung hat bereits eigene Tools und eine eigene Arbeitsweise. HR ist in einem System, Facility in einem anderen, Recht in einem geteilten Postfach.

ESM auszuweiten heißt also entweder, jede Abteilung auf die IT-Service-Plattform zu zwingen, was sie ablehnt, weil sie für die IT gebaut wurde und sich so anfühlt, oder ein Dutzend separater Tools zu integrieren, was teuer und fragil ist. Beide Wege sind schwer genug, dass die meisten Organisationen still bei "die IT hat gutes Service Management, und alle anderen machen ihr eigenes Ding" stehenbleiben. Das Framework war in Ordnung. Der Rollout starb an den Kosten, Abteilungs-Toolgrenzen zu überqueren.

Was ESM tatsächlich verbreitet

ESM verbreitet sich, wenn seine Einführung nicht verlangt, dass jede Abteilung auf eine neue, fremde Plattform umzieht. Die Frameworks übersehen das, weil sie eine Service-Plattform voraussetzen und behandeln, wo sie läuft, als Detail. Bei ESM ist, wo sie läuft, das ganze Spiel. Eine Service-Erfahrung wird nur geteilt, wenn sie irgendwo lebt, wo jede Abteilung ohnehin ist.

ESM in Microsoft 365

Hier verändert es die Rechnung, Service Management nativ in Microsoft 365 zu betreiben. Jede Abteilung, ob IT oder nicht, lebt bereits in Teams, Outlook und SharePoint. Läuft das Service-Framework dort, ist seine Ausweitung auf HR oder Facility keine Migration zu einem IT-Tool. Es ist das Einschalten von strukturierter Annahme, Katalog und Workflow in einer Umgebung, die diese Teams ohnehin täglich nutzen.

Warum das die Hürde beseitigt

Die Annahme ist in Teams, wo die Menschen ohnehin sind. Die Daten bleiben im eigenen Tenant der Organisation, unter einem Satz von Governance- und Identity-Kontrollen, was zählt, sobald HR- und Rechtsdaten im Spiel sind. Keine Abteilung wird gebeten, eine Plattform zu übernehmen, die offensichtlich für jemand anderen gebaut wurde.

Deshalb bleibt ESM in einem klassischen Setup so oft bei der IT stecken, und deshalb bleibt es in einem Microsoft-nativen meist in Bewegung. Das Framework war nie das Hindernis. Das Hindernis war, jede Abteilung zu bitten, ihren Arbeitsort zu verlassen. Entfernen Sie das, und Enterprise Service Management kann endlich unternehmensweit sein.

Das Fazit

ESM-Frameworks scheitern seltener am Design als an der Verbreitung. Jede Abteilung zu bitten, eine fremde, IT-gebaute Plattform zu übernehmen, ist meist der Punkt, an dem Vorhaben still stehenbleiben.

Service Management innerhalb von Microsoft 365 zu betreiben, umgeht diese Kosten. Jede Abteilung ist bereits dort, sodass die Ausweitung von strukturierter Annahme, Katalog und Workflows ein Konfigurationsschritt ist, keine Migration.