Die wahren Kosten von Software-Sprawl in Mid-Market-Unternehmen

Das durchschnittliche Mid-Market-Unternehmen betreibt über 130 SaaS-Anwendungen. Die IT kennt vielleicht 60 davon. Finance bezahlt alle. Der SaaS-Intelligence-Report von Productiv zeigt, dass große Unternehmen im Schnitt über 300 Apps im gesamten Unternehmen nutzen, wobei die Auslastung dazu führt, dass ein Drittel dieser Ausgaben faktisch verschwendet ist.

Die sichtbaren Kosten sind leicht zu finden: Kreditkartenabrechnung des Unternehmens öffnen und zusammenzählen. Doch CFOs, die Sprawl als Übung zur Lizenzkonsolidierung angehen, lösen das falsche Problem. Die Lizenzkosten sind oft der kleinste Teil. Die wahren Kosten entstehen dadurch, was diese 130 Tools mit der Aufmerksamkeit, der Security-Lage und der operativen Effizienz Ihrer Organisation anrichten. Diese Zahlen tauchen in keiner Budgetzeile auf.

Die drei Kosten, die die meisten Sprawl-Analysen übersehen

Standardmäßige Software-Audits betrachten Lizenzgebühren, Nutzungsraten und Redundanz. Das ist wichtig. Doch drei Kostenkategorien fallen fast immer aus der Rechnung.

Kosten für die Pflege von Integrationen. Jedes Tool, das mit einem anderen verbunden ist, braucht eine gewartete Integration. APIs ändern sich, Authentifizierung bricht, Datenformate driften auseinander. In einem Unternehmen mit 130 Anwendungen liegt die Zahl aktiver Integrationen oft bei 40–80, je nachdem, wie die Tools verdrahtet sind. Jede dieser Integrationen verursacht Wartungsaufwand: Jemand überwacht sie, jemand repariert sie, wenn sie ausfällt, jemand managt die Vendor-Beziehung, wenn sich die API mit 30 Tagen Vorlauf ändert.

Eine Rework-Analyse von Mid-Market-IT-Teams legt nahe, dass die Pflege von Integrationen in Unternehmen, die ihren Tool-Stack nicht aktiv steuern, 20–30 % der IT-Kapazität verschlingt. Das ist kein Budgetposten. Es ist Kapazität, die nicht in Produktinfrastruktur, Security-Verbesserungen oder irgendetwas anderes fließt, das das Geschäft voranbringt. Teams, die eine Konsolidierung erwägen, beginnen oft damit, Daten vor einer Migration vorzubereiten, um den tatsächlichen Umfang dessen zu verstehen, womit sie es zu tun haben.

Doppelte Dateneingabe und Abgleich. Betreibt ein Unternehmen getrennte Tools für CRM, Rechnungsstellung, Projektmanagement und Customer Success ohne saubere Integrationen, überträgt jemand (meist mehrere) Daten manuell zwischen den Systemen. Ein Deal wird im CRM abgeschlossen. Jemand legt manuell ein Projekt im PM-Tool an. Jemand erstellt manuell die Rechnung im Billing-System. Jemand aktualisiert manuell die Customer-Success-Plattform.

Die Arbeitskosten sind real. In einem Unternehmen mit 500 Mitarbeitenden ergeben sich bei 50 Personen, die durchschnittlich 2 Stunden pro Woche mit manuellem Datenabgleich verbringen, 5.200 Arbeitsstunden pro Jahr. Bei durchschnittlichen Vollkosten von 75 US-Dollar pro Stunde für Wissensarbeiter im Mid-Market sind das 390.000 US-Dollar jährlich allein für manuellen Abgleich. Die meisten Unternehmen ahnen nicht, dass diese Kosten existieren, weil sie unsichtbar auf alle Teams verteilt sind.

Die Fokuskosten durch Tool-Wechsel. Kognitives Umschalten ist teuer. Jedes Mal, wenn ein Mitarbeiter von einem Tool zum nächsten wechselt (eine Nachricht in Slack prüfen, eine Aufgabe in Asana aktualisieren, einen Call in Salesforce protokollieren, einen Zeitplan in Notion anpassen), entsteht ein Kontextwechsel-Aufschlag, der laut kognitionswissenschaftlicher Forschung der American Psychological Association bei komplexer Wissensarbeit spürbare Kosten verursacht, einschließlich der Erholungszeit nach jedem Wechsel. In Unternehmen, in denen Mitarbeitende an einem einzigen Vormittag routinemäßig über sechs bis acht Anwendungen hinweg arbeiten, ist der Produktivitätsverlust in Summe erheblich und nicht gemessen.

Das ist kein Plädoyer, alles in einem Tool abzuwickeln. Es ist ein Plädoyer dafür, bewusst zu entscheiden, wie viele Kontextwechsel Sie Ihren Leuten zumuten. An jedem Tool, das Sie dem Stack hinzufügen, hängt eine kognitive Steuer, die täglich jeder zahlt, der es nutzt.

Wie Sprawl sich beschleunigt

Wer die Kosten von Sprawl verstehen will, muss den Mechanismus verstehen, der ihn erzeugt. Software-Sprawl entsteht nicht, weil die IT aufgehört hat zu steuern. Er entsteht, weil das Kaufverhalten der Organisation strukturell verteilt ist und einzelne Kaufentscheidungen, die für sich genommen vernünftig wirken, in der Summe unvernünftig werden.

Das Muster sieht so aus: Ein Sales-Team braucht ein besseres Prospecting-Tool. Der Sales-Leiter findet eines für 3.000 US-Dollar pro Jahr und holt die Freigabe seines Vorgesetzten ein, der bis 5.000 US-Dollar entscheiden darf. Das Tool wird ausgerollt. Ein Jahr später braucht das Customer-Success-Team ein Tool für Health Scoring. Gleicher Ablauf, 4.000 US-Dollar pro Jahr, auf Managerebene freigegeben. Marketing braucht ein neues SEO-Tool. Freigegeben. RevOps braucht ein Enrichment-Tool. Freigegeben.

Keine dieser Entscheidungen ist für sich genommen falsch. Doch kein einzelner Entscheider hat Einblick in die Gesamtsumme. Der CFO hat ein Budget genehmigt. Jedes Team gibt innerhalb dieses Budgets aus. Niemand hat den vollständigen Überblick über den gesamten Stack, und niemand hat die Befugnis, über Teamgrenzen hinweg zu konsolidieren, ohne dass eine von der Führung getragene Initiative dahintersteht.

Die IT kann dieses Muster nicht stoppen, weil die Käufe stattfinden, bevor sie davon erfährt, oft über Kreditkarten der Fachbereiche. Finance sieht es nicht klar, weil die Kosten auf Dutzende Kostenstellen verteilt sind. Das Ergebnis ist organischer Sprawl, der sich jedes Quartal weiter aufschaukelt.

Die Dynamik von Shadow IT

Shadow IT, also Tools, die Mitarbeitende ohne Wissen der IT kaufen, beschleunigt dieses Muster. Doch die typische Reaktion auf Shadow IT stellt die falsche Diagnose.

Wenn Mitarbeitende die IT umgehen, um Tools zu kaufen, sagen sie Ihnen meist etwas über unerfüllte Bedürfnisse. Das Design-Team nutzt ein kostenpflichtiges Figma-Plugin, von dem die IT nichts weiß, weil die freigegebenen Design-Tools den benötigten Workflow nicht unterstützen. Das Sales-Team nutzt ein privates KI-Schreibtool, weil der freigegebene Sales-Stack diese Fähigkeit nicht hat. Shadow IT ist kein Wildwuchs aus Trotz. Sie ist ein Signal.

Die richtige Reaktion ist nicht, hart gegen nicht genehmigte Käufe vorzugehen. Sie besteht darin, Shadow IT auf Muster zu prüfen, die Lücken im freigegebenen Stack offenlegen. Haben 15 Personen einzeln dieselbe Tool-Kategorie bezahlt, ist das ein berechtigter Bedarf, den Ihr offizieller Stack nicht deckt.

Shadow IT spielt auch beim Experimentieren eine wichtige Rolle. Kleine Teams, die neue Tools vor dem unternehmensweiten Rollout ausprobieren, sind gesund. Das Problem entsteht, wenn diese Experimente nie in geordnete Bahnen gelenkt werden. Wird aus dem Experiment ein Dauerzustand, ohne formale Evaluation, Governance oder Integrationsplan, haben Sie kurzfristige Flexibilität gegen langfristige technische Schulden getauscht. Das ist derselbe Fehlermodus, der einen späteren Wechsel der CRM-Plattform teurer macht als nötig: angehäufte technische Schulden aus ungesteuerten Experimenten.

Die Software-Sprawl-Audit-Matrix

Um zu priorisieren, welche Tools Sie behalten, konsolidieren oder abschaffen, bewerten Sie jede Anwendung anhand von vier Dimensionen:

Nutzungstiefe: Wie tief ist dieses Tool in den Arbeitsalltag eingebettet? Ein Tool, das 80 % der Nutzer täglich öffnen, ist etwas anderes als eines, das 20 % der Nutzer monatlich öffnen. Vergeben Sie 1–5 Punkte anhand aktiver Nutzer, Häufigkeit und der Frage, ob Workflows zusammenbrechen, wenn es wegfällt.

Integrationswert: Wie viel trägt dieses Tool zu Ihren Datenflüssen bei? Ein Tool mit sauberen bidirektionalen Integrationen zu Ihren Kernsystemen (CRM, ERP, Data Warehouse) hat über seine direkten Funktionen hinaus strukturellen Wert. Ein eigenständiges Tool, das im Grunde eine Insel ist, erzeugt Integrationsschulden, sobald es irgendwann angebunden werden muss. Vergeben Sie 1–5 Punkte anhand von Integrationsqualität und Kritikalität.

Redundanzrisiko: Deckt ein Tool, das Sie bereits besitzen, mehr als 80 % desselben Use Cases ab? Wenn ja, haben Sie einen Konsolidierungskandidaten. Vergeben Sie 1–5 Punkte invertiert: Eine 5 bedeutet hohe Redundanz mit vorhandenen Tools, eine 1 bedeutet, dass es eine wirklich einzigartige Funktion erfüllt.

Vendor-Stabilität: Wird es diesen Vendor in drei Jahren noch geben? Seed-Stage-Startups in Ihrem Stack sind ein Risiko. Tools, die in 18 Monaten drei Entlassungsrunden hatten, sind ein Risiko. Vergeben Sie 1–5 Punkte anhand von Finanzierungsstatus, Umsatzgröße und strategischer Bedeutung für die eigene Roadmap des Vendors.

Das Ergebnis ist ein Raster. Jedes Tool mit niedrigen Werten bei Nutzungstiefe und Integrationswert und hohem Wert beim Redundanzrisiko ist ein Kandidat zur Abschaffung. Jedes Tool mit hoher Nutzungstiefe, aber ebenfalls hohem Redundanzrisiko ist eine Konsolidierungsentscheidung. Jemand verliert den Zugang zu einem Tool, das er mag, und genau hier kommt es auf Change Management an.

Konsolidierung ohne Aufstand

Die meisten Bemühungen zur Software-Rationalisierung scheitern nicht beim Audit, sondern beim Rollout. Die Tools, die gestrichen werden, sind Tools, die Menschen tatsächlich nutzen. Die Teams, die den Zugang verlieren, sind selten die, die die Konsolidierungsinitiative vorangetrieben haben. Und die politische Dynamik in Mid-Market-Organisationen führt dazu, dass Fachbereichsleiter ihre bevorzugten Tools oft schützen können, selbst wenn das Büro des CFO eine Reduktion trägt. Der Leitfaden zu CRM-Rollout und Adoption behandelt dieselbe Stakeholder-Dynamik für die häufigste Konsolidierungskategorie: Sales- und Revenue-Tooling.

Die Konsolidierungsfehler, die sich am häufigsten wiederholen, folgen einem Muster: IT oder Finance identifiziert die redundanten Tools, legt eine Liste dessen vor, was gestrichen wird, und bittet die Teams, auf das Konsolidierungsziel zu migrieren. Die Teams wehren sich. Der Zeitplan rutscht. Drei Monate später laufen die Hälfte der "abgeschafften" Tools weiter, weil bei jemandem ein Workflow davon abhängt und die Migration nie vollständig abgeschlossen wurde.

Was stattdessen funktioniert:

Mit Daten beginnen, nicht mit Entscheidungen. Führen Sie die Audit-Matrix durch, bevor ein Tool zur Abschaffung benannt wird. Zeigen Sie die Analyse vor der Empfehlung. Teams, die die Kriterien verstehen, deuten das Ergebnis seltener als willkürlich.

Das Konsolidierungsziel sich bewähren lassen. Wenn Sie vier Projektmanagement-Tools auf eines konsolidieren, führen Sie eine 30-tägige Evaluation mit echten Nutzern aus jedem betroffenen Team durch. Lassen Sie sie die Use Cases einreichen, die ihr aktuelles Tool abdeckt und das Konsolidierungsziel nicht. Geben Sie dem Konsolidierungs-Vendor die Chance zu antworten. Das ist kein Vertriebsprozess. Es ist ein Legitimationsprozess. Teams, die an der Evaluation beteiligt waren, akzeptieren das Ergebnis besser als Teams, denen eine Entscheidung übergestülpt wurde.

Migrieren statt abschalten. Der typische Fehler ist, das alte Tool abzuschaffen, bevor der neue Workflow stabil läuft. Setzen Sie eine Überlappungsphase von 60 Tagen an, in der beide Tools parallel laufen, mit aktiver Migrationsunterstützung. Schalten Sie das alte Tool erst ab, wenn die Nutzungsdaten zeigen, dass das Team tatsächlich umgezogen ist.

Migrationsverantwortliche benennen, nicht nur IT-Tickets anlegen. Migrationen scheitern, wenn sie als IT-Projekte behandelt werden. Sie gelingen, wenn in jedem betroffenen Team ein Verantwortlicher aus dem Fachbereich dafür einsteht, dass die Migration seines Teams abgeschlossen wird. Diese Person hat das organisatorische Vertrauen, ihre Kollegen durch den Wandel zu begleiten, wie es ein IT-Ticket nicht kann.

Das 30-Tage-Sprawl-Audit

Hier ein praktischer Einstieg, den jeder COO oder IT-Leiter ohne externe Berater umsetzen kann.

Woche 1: Discovery. Ziehen Sie alle SaaS-Abbuchungen von Firmenkreditkarten und aus Spesenabrechnungen der letzten 12 Monate. Gleichen Sie sie mit dem bekannten Anwendungsinventar der IT ab. Die Lücke zwischen beiden Listen ist Ihre Shadow-IT-Karte.

Woche 2: Klassifizierung. Ordnen Sie jedes Tool einer von vier Kategorien zu: Core (unverzichtbar im Tagesgeschäft), Departmental (kritisch für ein Team, nicht funktionsübergreifend), Experimental (in Erprobung oder begrenzter Nutzung), Orphaned (niemand besitzt es oder nutzt es aktiv).

Woche 3: Bewertung mit der Matrix. Wenden Sie die Software-Sprawl-Audit-Matrix auf jedes Core- und Departmental-Tool an. Markieren Sie jedes Tool mit hohem Redundanzrisiko für die Konsolidierungsprüfung. Jedes Orphaned-Tool wird zur Kündigung vorgemerkt.

Woche 4: Priorisierte Empfehlungen. Erstellen Sie eine Rangliste der zehn wichtigsten Kandidaten für Konsolidierung oder Abschaffung, mit geschätzten Kosteneinsparungen, geschätzter Migrationskomplexität und empfohlener Verantwortung für die Entscheidung. Präsentieren Sie sie dem Führungsteam mit sichtbaren Kriterien, nicht nur mit den Schlussfolgerungen.

Dieser Prozess identifiziert regelmäßig 15–25 % der SaaS-Ausgaben als redundant oder verwaist. Bei einem Mid-Market-Unternehmen mit 500 Mitarbeitenden und 2 Mio. US-Dollar jährlichen Softwareausgaben sind das 300.000 bis 500.000 US-Dollar an einsparbaren Ausgaben. Gartners Leitlinien zum Software Asset Management beziffern das durchschnittliche SaaS-Optimierungspotenzial im Enterprise-Bereich auf 20–30 % der aktuellen Ausgaben, wenn Organisationen strukturierte Audits statt reaktiver Lizenzprüfungen durchführen. Doch der eigentliche Wert liegt in den abgebauten Integrationsschulden und der zurückgewonnenen IT-Kapazität.

Was sich ändert, wenn Sie es richtig machen

Unternehmen, die alle 12 bis 18 Monate strukturierte Sprawl-Audits durchführen, entwickeln eine organisatorische Disziplin, die über die Lizenzeinsparungen hinausgeht. Sie bauen sauberere Datenarchitekturen auf, weil weniger unverbundene Tools weniger Integrationsnähte bedeuten. Sie senken die Security-Exposure, weil jedes Tool im Stack eine potenzielle Angriffsfläche ist. Und sie senken die organisatorische Aufmerksamkeitssteuer, die verteiltes Tooling erzeugt.

Auch das Procurement-Modell reift. Statt Käufen auf Abteilungsebene ohne Überblick entwickeln CFO und CIO einen gemeinsamen Freigabeprozess für jedes neue SaaS oberhalb einer Schwelle, typischerweise 5.000 bis 10.000 US-Dollar jährlich. Diese Schwelle ist niedrig genug, um die meisten relevanten Käufe zu erfassen, und lässt Teams zugleich Spielraum für kleine Experimente. Zu verstehen, wie CAC-Payback und SaaS-Unit-Economics funktionieren, gehört zu dieser Reifung: Procurement-Entscheidungen beginnen, Investitionsentscheidungen zu ähneln.

Das Ziel ist nicht, das gesamte Unternehmen auf fünf Tools zu betreiben. Es geht darum, bei jedem neuen Tool bewusst zu entscheiden, die Gesamtkosten des Stacks zu verstehen und Tools abzuschaffen, die ihren Komplexitätsaufwand nicht verdienen.

Weiterführende Inhalte

• Das neue B2B-Buying-Committee: Wer wirklich im Raum ist, die Governance-Struktur, die Sprawl schon beim Kauf verhindert
• Seat-Based Pricing stirbt. Was es ersetzt, wie sich wandelnde Pricing-Modelle darauf auswirken, was Softwarekonsolidierung tatsächlich kostet