Eine Rolle, sechs Jobs

Sie haben einen Platform Owner eingestellt. Oder intern befördert.

Klug, kompetent, kennt ServiceNow. Wahrscheinlich aus dem ITSM oder der Entwicklung kommend. Hat die Plattform besser verstanden als jeder andere im Raum.

Sechs Monate später geht diese Person unter.

Sie priorisiert Anforderungen aus fünf Geschäftsbereichen. Sie steuert einen externen Partner. Sie bereitet das nächste Upgrade vor. Sie bearbeitet CMDB-Beschwerden. Sie sitzt in Architecture Review Boards. Sie schreibt Business Cases für neue Module.

Sie erledigt die Arbeit von sechs Personen. Und Sie haben ihr ein Team von zwei Leuten gegeben.

Die unmögliche Stellenbeschreibung

Schauen Sie sich die meisten Stellenbeschreibungen für Platform Owner an. Wirklich genau.

Gesucht wird ein Architekt, der gleichzeitig die Anforderungsaufnahme steuert. Ein Product Manager, der auch Eskalationen mit Dienstleistern übernimmt. Ein Demand Manager, der gleichzeitig die Upgrade-Roadmap verantwortet. Eine technische Führungskraft, die auch vierteljährlich vor dem CIO präsentiert.

Niemand formuliert das absichtlich so. Es wächst einfach. Jedes Mal, wenn etwas keinen klaren Verantwortlichen hat, landet es beim Platform Owner.

Weil er ja „die Plattform verantwortet.”

Was das Organigramm sagt vs. was tatsächlich passiert

Auf dem Papier berichtet der Platform Owner an einen VP oder Director. Es gibt eine gestrichelte Linie zum Architektur-Team. Es gibt ein Governance Board, an das eskaliert werden kann.

In der Praxis tagt das Governance Board einmal im Quartal und winkt durch, was ohnehin schon läuft. Das Architektur-Team konzentriert sich auf Infrastruktur, nicht auf Now Platform Design Patterns. Der VP jongliert zwölf andere Prioritäten.

Der Platform Owner ist allein. Trifft in Echtzeit Abwägungsentscheidungen, die das gesamte Unternehmen betreffen. Ohne Rückendeckung.

Warum das immer wieder passiert

Niemand verantwortet das Operating Model

Die meisten Organisationen haben ServiceNow gekauft, um ein konkretes Problem zu lösen. ITSM-Ticketing. Vielleicht ITOM Discovery. Vielleicht HR Case Management über HRSD.

Dann ist die Plattform gewachsen. CSM kam dazu. SPM wurde für die Projektaufnahme eingeführt. SecOps tauchte auf. Jemand kaufte ITAM.

Aber niemand hat sich hingesetzt und ein Operating Model für eine unternehmensweite Multi-Modul-Plattform entworfen. Die Governance, der Demand-Management-Prozess, die Architekturstandards, die Teamstruktur: nichts davon ist mit der Plattform skaliert worden.

Der Platform Owner hat all diese fehlende Struktur geerbt. Als persönliche Verantwortung.

Die Plattform ist gewachsen. Das Team nicht.

Dieses Muster sehe ich ständig.

Eine Organisation gibt jährlich einen siebenstelligen Betrag für ServiceNow-Lizenzen aus. Fünfzehn oder zwanzig Module sind aktiv. Hunderte individueller Workflows in Flow Designer. Tausende Nutzer.

Und das interne Plattform-Team besteht aus drei Personen. Vielleicht vier.

Der Rest ist an einen Managed-Services-Partner ausgelagert, der Tickets bearbeitet, aber keine Strategie verantwortet. Der Platform Owner ist also die einzige Person, die den strategischen Faden hält. Für eine Plattform, die jede Abteilung berührt.

Das ist keine Rolle. Das ist ein Single Point of Failure.

Befugnis ohne Rückendeckung ist keine Befugnis

Manche Organisationen geben dem Platform Owner tatsächlich einen Titel und ein Mandat. „Sie verantworten die Plattform. Treffen Sie die Entscheidungen.”

Und beim ersten Mal, wenn der Platform Owner das Lieblingsprojekt eines VP ablehnt, weil es unkontrollierten Scope oder Technical Debt erzeugen würde, wird die Entscheidung überstimmt.

Kein Executive greift ein. Kein Governance Board stützt die Entscheidung. Das Projekt wird durchgewunken. Der Platform Owner lernt die Lektion: Die Befugnis war rein theoretisch.

Nachdem das zweimal passiert ist, hört er auf, Widerstand zu leisten. Er absorbiert einfach alles. Und die Plattform leidet.

Was zuerst kaputtgeht

Upgrades verzögern sich. Anforderungen stauen sich. Technical Debt wächst.

Wenn der Platform Owner über seine Kapazitätsgrenze hinaus belastet wird, priorisiert er nach Dringlichkeit. Und das bedeutet, dass immer etwas zurückgestellt wird.

Meistens sind es Upgrades. Denn Upgrades haben keinen Business Sponsor, der lautstark darauf drängt. Sie fallen einfach leise zurück. Dann sind Sie zwei Releases im Rückstand. Dann stehen die Features, für die Sie mit Ihrem Pro SKU bezahlen, nicht zur Verfügung. Dann kann Ihr Partner Ihre Version nicht mehr unterstützen.

Die Anforderungsaufnahme wird zum Engpass. Geschäftsbereiche umgehen den Platform Owner, beauftragen den Partner direkt oder, schlimmer noch, bauen Schattenlösungen außerhalb der Plattform.

Technical Debt häuft sich unsichtbar an. Anpassungen stapeln sich. Namenskonventionen verwässern. Die CMDB wird verunreinigt, weil niemand Zeit hatte, Data Governance durchzusetzen.

Bis das Leadership es bemerkt, ist der kumulierte Schaden erheblich.

Der Platform Owner wird genau der Engpass, den er verhindern sollte

Das ist die bittere Ironie.

Sie haben die Rolle geschaffen, um Ordnung zu schaffen. Um die Strategie zu zentralisieren. Um einen einzigen Verantwortlichen zu haben.

Aber ohne die richtige Struktur bedeutet „einziger Verantwortlicher” einfach nur „Single Point of Failure.”

Und wenn sich alles verlangsamt, wer bekommt die Schuld? Der Platform Owner. Nicht das Operating Model. Nicht die mangelnde Investition. Nicht die fehlende Governance.

Die Person.

Das Minimum Viable Operating Model

Sie lösen dieses Problem nicht, indem Sie einen besseren Platform Owner einstellen. Sie lösen es, indem Sie die Struktur um die Rolle herum aufbauen, die Erfolg überhaupt erst möglich macht.

Trennen Sie die Rollen. Wirklich.

Der Platform Owner sollte Plattformstrategie, Roadmap und Standards verantworten. Punkt.

Demand Management ist eine eigenständige Funktion. Partner Management ist eine eigenständige Funktion. Architecture Governance ist eine eigenständige Funktion.

Wenn Sie nicht für jede Funktion eine eigene Person einstellen können, dann benennen und zuweisen Sie sie zumindest explizit. Auch wenn manche geteilt oder in Teilzeit besetzt sind. Der entscheidende Punkt ist, dass „das macht der Platform Owner” nicht mehr die Standardantwort für jede Lücke sein darf.

Geben Sie dem Platform Owner Entscheidungsrechte. Schriftlich.

Nicht in einer Stellenbeschreibung. In einem RACI oder einer Governance-Charta, die das Leadership unterzeichnet hat.

Der Platform Owner sollte eine dokumentierte Befugnis haben, Plattformänderungen auf Basis von Architekturstandards zu genehmigen oder abzulehnen. Das Backlog nach vereinbarten Kriterien zu priorisieren. Nein zu sagen zu Anforderungen, die die Intake-Kriterien nicht erfüllen.

Wenn diese Entscheidungen von jedem VP mit ausreichend Dringlichkeit überstimmt werden können, existiert die Befugnis nicht. Die Governance-Charta muss den Eskalationsweg definieren, und die Führungsebene muss sich tatsächlich daran halten.

Finanzieren Sie ein Plattform-Team, nicht eine Plattform-Person

Ein einzelner Platform Owner kann eine unternehmensweite Now Platform nicht allein betreiben.

Sie brauchen mindestens einen Plattformarchitekten (oder einen Senior Developer mit Architekturverantwortung), einen Demand- oder Intake-Koordinator und dedizierte Admin-Kapazität, die nicht mit fünf anderen Systemen geteilt wird.

Wenn Ihre ServiceNow-Ausgaben jährlich über einer Million liegen und Ihr internes Team weniger als fünf Personen umfasst, besteht ein strukturelles Missverhältnis zwischen Ihrer Investition und Ihrer Fähigkeit, diese zu schützen.

Schaffen Sie einen Executive Governance Sponsor

Der Platform Owner braucht jemanden auf VP- oder CIO-Ebene, der seine Entscheidungen öffentlich stützt.

Keinen passiven Sponsor, der bei den Quarterly Reviews auftaucht. Einen aktiven. Jemanden, der das Governance-Modell verteidigt, wenn es auf die Probe gestellt wird. Jemanden, der in einem Raum voller Peers sagt: „Wenn der Intake-Prozess des Platform Owner das abgelehnt hat, bringen Sie es zum Governance Board. Umgehen Sie nicht einfach den Prozess.”

Ohne das ist der Platform Owner ein Torwächter ohne Schloss am Tor.

Die Lösung ist nicht eine bessere Besetzung

Wenn Ihr Platform Owner Schwierigkeiten hat, sollte die erste Frage nicht lauten: „Haben wir die richtige Person?”

Sie sollte lauten: „Haben wir dieser Person überhaupt eine Chance auf Erfolg gegeben?”

Schauen Sie auf die Struktur. Schauen Sie auf die Teamgröße. Schauen Sie auf das Governance-Modell. Schauen Sie, ob die Person echte Befugnis hat oder nur einen Titel.

In neun von zehn Fällen liegt das Problem im Operating Model. Nicht beim Operator.

Beheben Sie das Modell. Dann werden Sie erleben, wie dieselbe Person, die Sie gerade ersetzen wollten, anfängt zu liefern.

Wenn Ihre ServiceNow-Plattform über die Struktur hinausgewachsen ist, die sie umgibt, kann ich Ihnen helfen, das Operating Model zu entwerfen, das tatsächlich funktioniert. Schreiben Sie mir eine Nachricht oder besuchen Sie michael-moch-consulting.com

Oder buchen Sie ein 30-minütiges Platform Review. Kein Verkaufsgespräch. Nur Klarheit.