In der heutigen digitale Wirtschaft sind kollaborative Plattformen das Rückgrat der Zusammenarbeit, sowohl intern als auch mit externen Partnern und Kunden. Als das Vorläuferprojekt ein maßgeschneidertes SharePoint‑Produkt einführte, standen wir zunächst vor einem Erfolg, der sich schnell in die nächste Entwicklungsphase übertrug: Die Plattform wurde zu einem zentralen Hub für die, teils stark regulierte, Zusammenarbeit mit externen Unternehmen. Die Anbindung an ServiceNow, die automatisierte Bereitstellung von Rollen und Rechten sowie die Einbindung mehrerer Drittanbieter‑Dienstleister machten das System zu einer hochkomplexen, aber funktionalen Lösung. Schon bald jedoch traten die Schattenseiten dieses Erfolgs in den Vordergrund: Fehler, die weder von den einzelnen Systemen noch von den beteiligten Dienstleistern eindeutig zuzuordnen waren, und ein damit verbundener, exponentiell wachsender Supportaufwand. Der äußere Eindruck war eindeutig: „Es funktioniert nicht.“ Und genau dieser Eindruck gefährdete nicht nur das Vertrauen der Nutzer, sondern auch die Reputation des Kunden als Anbieter einer professionellen Kollaborationsplattform.
Die Ausgangssituation: Mehrschichtige Prozesse, mehrfache Dienstleister
Das Projekt begann mit einem maßgeschneiderten SharePoint‑Produkt, das zunächst intern für die Zusammenarbeit eingesetzt wurde. Der Erfolg ließ das System schnell über die Unternehmensgrenzen hinaus wachsen: Externe Partner, Kunden und weitere Stakeholder bekamen Zugriff, und die Anwendungslandschaft wurde um ServiceNow‑basierte Antrags‑ und Rollenprozesse erweitert. Jede dieser Komponenten wurde von eigenständigen Dienstleistern betreut, von der SharePoint‑Konfiguration über das ServiceNow‑Ticket‑Management bis hin zu spezialisierten Datenintegrations‑ und Sicherheitsservices.
Die Integration dieser unterschiedlichen Systeme schuf jedoch ein Netz von Abhängigkeiten, das in der Praxis nur schwer zu überblicken war. Fehlermeldungen tauchten sporadisch auf, die Ursache lag oft in einer feinen Wechselwirkung zwischen einer ServiceNow‑Workflow‑Anpassung und einer SharePoint‑Berechtigungsregel. Wer war nun für die Behebung zuständig? Die internen Fachbereiche wiesen auf die ServiceNow‑Logik, während die ServiceNow‑Partner die SharePoint‑Integration kritisierten. In der Folge entstand ein klassisches „Finger‑Pointing“: keiner wollte die Verantwortung übernehmen, und der Support musste sich immer wieder mit eskalierenden Anfragen auseinandersetzen. Der Aufwand war sowohl personell als auch finanziell enorm, und die Außenwirkung litt merklich.
Das Kernproblem: Fehlende übergreifende Steuerung und Transparenz
Die zentrale Herausforderung liegt nicht in der Technologie an sich, sondern im Mangel an einer übergeordneten Steuerungsinstanz, die sowohl technische Details als auch die Kommunikationswege zwischen den Dienstleistern verstehen und koordinieren kann. In regulierten Umgebungen, in denen Compliance‑ und Sicherheitsanforderungen strikt vorgeschrieben sind, wird jede Änderung an einer Komponente sofort relevant für das gesamte Ökosystem. Das bedeutet, dass ein kleiner Eingriff in einen ServiceNow‑Workflow unvorhergesehene Konsequenzen in SharePoint hervorrufen kann und umgekehrt. Ohne einen neutralen Überblick verliert das Team die Fähigkeit, Ursachen schnell zu identifizieren, und das Fehlermanagement wird zum endlosen Ping‑Pong zwischen den Dienstleistern.
Ein weiteres Problem entsteht durch die fehlende Kategorisierung der Supportfälle. Jede neue Meldung wird ad hoc behandelt, woraufhin wiederholte Fälle immer wieder neu analysiert werden. Dies verhindert das Aufbauen von Erfahrungswissen und vergrößert den Aufwand für jede einzelne Fehlerbehebung. Zudem fehlt eine einheitliche Dokumentation, die nach offenen Standards (wie z.B. UML) strukturiert ist. Ohne ein solches Fundament wird es unmöglich, Änderungen nachzuvollziehen, Verantwortlichkeiten zuzuweisen oder automatisierte Tests zu implementieren.
Der Lösungsansatz: Technische Neutralität trifft kommunikative Durchsetzungsstärke
Um die Situation zu entwirren, brauchen wir einen Ansatz, der zwei zentrale Säulen vereint: tiefes technisches Verständnis aller beteiligten Systeme und die Fähigkeit, in einem oftmals konfliktgeladenen Umfeld als neutrale Vermittlerin zu agieren. Genau diese Kombination bildet das Herzstück der von flowciety angebotenen Dienstleistersteuerung.
Zunächst wird ein erfahrener Technikspezialist eingesetzt, der sich in die bestehenden SharePoint‑ und ServiceNow‑Implementierungen einarbeitet, die individuellen Anpassungen nachspürt und die zugrunde liegenden Datenflüsse nachzeichnet. Dieser Experte nutzt dabei UML als Referenzrahmen, um die komplexe Systemlandschaft in einer strukturierten, nachvollziehbaren Form abzubilden. Durch einheitliche Namenskonventionen, klare Schnittstellenbeschreibungen und ein zentrales Repository wird eine Plattform geschaffen, auf der alle Beteiligten dieselben Informationen vor Augen haben.
Parallel dazu entsteht ein systematisches Kategorisierungsschema für Supportfälle. Jeder Vorfall wird anhand von Ursache, betroffener Komponente und Schweregrad klassifiziert, sodass wiederkehrende Muster sofort erkennbar sind. Für die häufigsten Fehlertypen wird ein „Run‑Book“ erstellt: ein Dokumentationspaket, das sowohl technische Schritte zur Fehlerbehebung als auch klare Eskalationspfade definiert. So wird aus einem ad‑hoc‑Ticket ein standardisierter Prozess, der in Minuten statt Stunden abgewickelt werden kann.
Die eigentliche Herausforderung liegt jedoch in der zwischenmenschlichen Ebene. Der Technikspezialist übernimmt die Rolle des neutralen Moderators: Er sammelt Fakten, präsentiert die Ursachen neutral und leitet Diskussionen zwischen den Dienstleistern. Durch regelmäßige Steuerungsrunden, in denen konkrete Messgrößen (z. B. durchschnittliche Bearbeitungszeit, Wiederholungsrate von Fehlermeldungen) vorgestellt werden, entsteht ein gemeinsames Ziel: nicht die Schuldzuweisung, sondern die kontinuierliche Verbesserung der Plattform. Hierbei ist Durchsetzungsstärke gefragt: Es gilt, die Verantwortlichkeiten eindeutig zu definieren, vereinbarte Maßnahmen nachzuverfolgen und bei Bedarf nachzuhalten.
Ein weiterer Baustein ist die Einführung von Service‑Level‑Agreements (SLAs), die nicht nur Reaktionszeiten, sondern auch klare Übergabepunkte zwischen den Dienstleistern festlegen. Diese SLAs basieren auf den gewonnenen Erkenntnissen aus der Fehlerkategorisierung und werden in gemeinsamen Workshops erarbeitet, sodass jedes Team die jeweiligen Erwartungen kennt und akzeptiert.
Der erzeugte Mehrwert: Mehr Stabilität, weniger Aufwand, bessere Außenwirkung
Durch die strukturierte Analyse und Dokumentation der Systemlandschaft reduziert sich die Fehlerrate signifikant. Einmalige, wiederkehrende Probleme werden erkannt, bevor sie überhaupt zu Störungen führen. Die klare Kategorisierung und das Run‑Book ermöglichen eine Beschleunigung der Fehlersuche, weil Techniker sofort die relevanten Schritte kennen und nicht mehr jedes Mal bei Null anfangen müssen. Für den Kunden bedeutet das eine Reduktion des Supportaufwands von rund 30 %: ein Wert, der sich nicht nur in geringeren Kosten, sondern auch in mehr Freiraum für strategische Aufgaben niederschlägt.
Aus Sicht der Außenwirkung zeigt sich ein entscheidender Unterschied: Die Nutzer sehen ein System, das zuverlässig funktioniert und bei dem Fehler schnell behoben werden. Die Kommunikation nach außen wird von „Es funktioniert nicht“ zu „Wir bieten Ihnen ein stabiles, regulatorisch konformes Kollaborations-Tool“ transformiert. Das stärkt das Vertrauen sowohl in die interne IT‑Abteilung als auch in das Produkt selbst, wodurch Kunden und Partner eher bereit sind, die Plattform intensiv zu nutzen.
Schließlich profitiert das Unternehmen von einer langfristig aufrechterhaltenen Governance‑Struktur. Durch die kontinuierliche Pflege des UML‑Abbilds, die Aktualisierung der Run‑Books und die regelmäßige Abstimmung der Dienstleister bleibt die Plattform anpassungsfähig, ohne dass neue Änderungen sofort zu neuen Fehlern führen. Das Unternehmen kann so neue Funktionen schneller ausrollen, regulatorische Änderungen umsetzen und das Gesamtbild der Zusammenarbeit kontinuierlich verbessern.
Fazit: In stark regulierten, mehrfach angepassten IT‑Umgebungen ist die Schuldfrage für Fehlfunktionen zweitrangig. Die Nutzer verlangen einfach eine funktionierende Plattform. Der Schlüssel liegt daher nicht in einem starren Vorgehensmodell, sondern in der gezielten Verbindung von technischer Neutralität und durchsetzungsstarker Kommunikation. Wer die Systemlandschaft tief versteht, Supportfälle strukturiert dokumentiert und als unparteiischer Moderator zwischen den Dienstleistern vermittelt, schafft klare Verantwortlichkeiten, verkürzt die Fehlerbehebung und senkt den Supportaufwand spürbar. Das Ergebnis: stabile, automatisierte Workflows, eine positiv wahrgenommene Produktwahrnehmung und ein nachhaltiger Mehrwert für Kunden und ihre externen Partner.
Wir sind IT Partner
Unser Motto: IT im Geschäftsalltag als Lösung etablieren, nicht als Quelle von Problemen.
