Ihr Unternehmen braucht nicht mehr Software. Es braucht weniger Chaos.

Der Vertrieb verliert den Überblick über Anfragen, also wird ein CRM gekauft. Projekte verzögern sich, ein Tool für Aufgaben kommt dazu. Die Rechnungsstellung stockt, eine weitere Anwendung wird ergänzt. Jede dieser Entscheidungen war für sich genommen vernünftig.

Ein Jahr später fragen Sie, wie viele offene Aufträge das Unternehmen hat und welche Marge auf ihnen liegt. Die Antwort kommt nicht in einer Minute, sondern in zwei Tagen. Die Daten existieren, sie liegen nur in fünf Systemen, die einander nicht sehen, und jemand muss sie von Hand zusammensetzen.

Das ist kein Problem der Software, sondern eines der Unternehmensstruktur. Gleich vorweg: Dieser Text behauptet nicht, dass die Lösung ein eigenes System ist. In den meisten Fällen ist sie es nicht. Das Ziel sind nicht weniger Anwendungen um jeden Preis, sondern niedrigere Total Cost of Ownership, also geringere Gesamtbetriebskosten.

Der typische Stack, den niemand entworfen hat

Versuchen Sie, die Software aufzuzählen, die Ihr Unternehmen einsetzt. Die meisten Inhaber kommen auf sechs bis zehn: CRM, Buchhaltung oder ERP, E-Mail, Excel, WhatsApp, Notion, Rechnungsstellung, Zeiterfassung.

Die tatsächliche Zahl liegt höher. Laut dem Zylo 2025 SaaS Management Index setzen Unternehmen mit 1 bis 500 Beschäftigten im Schnitt 152 Anwendungen ein. Ein durchschnittliches Unternehmen verwaltet laut Zylo 305, und der MuleSoft Connectivity Benchmark Report 2025 nennt für große Organisationen 897. Die Zahlen widersprechen einander nicht, sie messen nur andere Stichproben. Eines gilt in jedem Fall: Die Zahl der Tools, für die ein Unternehmen tatsächlich bezahlt, ist höher als jene, an die sich die Geschäftsführung erinnert.

Jedes einzelne System kann gut sein. Das Problem entsteht dazwischen.

Das CRM erledigt seine Arbeit gut, das Buchhaltungssystem ebenso. Das Problem beginnt, wenn derselbe Auftrag in beiden liegen muss und niemand festgelegt hat, welches von beiden die Quelle der Wahrheit ist.

Single Source of Truth bedeutet, dass es für jede wichtige Information einen einzigen Ort mit der offiziellen Version gibt und alle anderen nur darauf schauen. Ohne das hat ein Kunde drei Adressen, ein Auftrag zwei Status und ein Report eine dritte Zahl. Niemand lügt, jeder hat in seinem System recht.

Laut MuleSoft sind von durchschnittlich 897 Anwendungen nur 29 % miteinander verbunden, und 90 % der IT-Verantwortlichen sagen, dass Datensilos geschäftliche Probleme verursachen. Dieselben 29 % nannte MuleSoft bereits im Jahrgang 2023. In zwei Jahren hat sich dieser Anteil nicht bewegt.

SaaS-Wildwuchs und Schatten-IT

SaaS-Wildwuchs ist das unkontrollierte Wachstum der Zahl abonnierter Cloud-Tools, bei dem niemand eine vollständige Liste dessen hat, was bezahlt wird, wer es nutzt und welche Daten darin liegen. Schatten-IT ist der nahe Verwandte davon: Tools, die sich Teams ohne Wissen der Verantwortlichen für Technologie und Daten beschaffen. Eine Tabelle in einem privaten Account, ein Chat-Tool, das der Vertrieb eingeführt hat, oder ein KI-Assistent mit Kundendaten.

Laut Gartner werden 74 % der Technologieeinkäufe zumindest teilweise außerhalb der IT finanziert, und 41 % der Beschäftigten sind Business Technologists, also Menschen, die technologische Kapazitäten außerhalb der IT schaffen. Auf dem Summit in London im September 2025 prognostizierte Gartner, dass „75 % der Beschäftigten Technologie außerhalb der Sichtbarkeit der IT beschaffen, anpassen oder erstellen werden“. Das ist eine Prognose, kein gemessener Zustand. Zylo sieht es an den Ausgaben: Laut dem Index für 2026 kontrollieren die Fachbereiche 81 % der SaaS-Ausgaben und die IT nur 15 %. Und 77 % der IT-Verantwortlichen haben im eigenen Unternehmen KI-Anwendungen entdeckt, von denen sie nichts wussten.

Schatten-IT ist keine Disziplinlosigkeit, sondern ein Symptom. Menschen umgehen den offiziellen Weg, wenn er langsam ist. Wenn die Freigabe eines Tools für dreißig Euro sechs Wochen dauert, kaufen sie es selbst. Die Lösung ist kein Verbot, sondern eine schnellere Freigabe.

Versteckte Kosten, die im Abopreis nicht auftauchen

Die Methodik der Total Cost of Ownership hat die Gartner Group im Jahr 1987 bekannt gemacht. CIPS definiert sie als Schätzung der End-to-End-Kosten einschließlich jener Prozesse, die keinen Wert schaffen. Bei Software geht es um fünf Positionen, von denen Sie im Budget nur die erste sehen.

• Ungenutzte Abonnements. Laut dem Zylo 2026 SaaS Management Index bleiben im Schnitt 36 % der Lizenzen ungenutzt. Der Median der SaaS-Ausgaben pro Beschäftigtem liegt dabei bei 9.455 US-Dollar pro Jahr.
• Integration Overhead, also der Aufwand für das Verbinden. Laut MuleSoft entfallen 39 % der Zeit von IT-Teams auf den Bau eigener Integrationen. Im Jahrgang 2023 gaben Unternehmen dafür im Schnitt 4,7 Millionen US-Dollar pro Jahr aus.
• Einarbeitung, Administration und doppelte Daten. Jedes Tool hat eigene Zugänge, Rollen und ein eigenes Onboarding. Derselbe Kunde in drei Systemen bedeutet drei Stellen, an denen ein Fehler entstehen kann.
• Switching Cost. Die Kosten für den Ausstieg bei einem Anbieter: Export, Migration, Nachschulung, Neuschreiben der Integrationen. Sie steigen mit der Dauer der Nutzung, deshalb hält sich auch ein schwaches Tool über Jahre.
• Verlust des Überblicks. Laut dem Flexera 2025 State of ITAM Report ist der Anteil der Organisationen mit vollständigem Überblick über den eigenen Technologie-Stack von 47 % auf 43 % gesunken.

Die Zahlen stammen aus internationalen Erhebungen, überwiegend aus größeren Unternehmen. Nehmen Sie sie nicht als Prognose, sondern als Richtungsangabe: Der Betrag auf der Abo-Rechnung ist meist die kleinste Position dieser Liste.

Warum in Ihrem Unternehmen ein Mensch die Rolle einer API übernimmt

Eine API ist eine Schnittstelle, über die zwei Programme automatisch Daten in einem vereinbarten Format austauschen. Fehlt eine solche Schnittstelle, baut sich ein Unternehmen unbemerkt eine aus einem Menschen. Der Auftrag kommt per E-Mail, jemand überträgt ihn ins CRM, von dort trägt ihn eine andere Person in die Planungstabelle, aus der Tabelle geht der Termin per WhatsApp an den Techniker, der Techniker meldet die Fertigstellung, jemand schreibt sie zurück und stellt die Rechnung aus. Vier dieser sieben Schritte sind keine Arbeit, sondern nur die Weitergabe derselben Information.

Dieser Mensch ist die Integration. Nur ist er langsamer, macht Fehler, hinterlässt kein Log und lässt sich nicht skalieren. Und anders als eine Lizenz taucht sein Preis nicht im Budget auf, obwohl er sich berechnen lässt.

Das Modell Cost of Friction, das ich in jenem Text ausgeführt habe, wann sich ein gutes internes System früher rechnet als ein neuer Mitarbeiter, ist bewusst einfach: Zeit × Häufigkeit × Anzahl der Beteiligten × Kosten.

Eine Modellrechnung, setzen Sie Ihre eigenen Werte ein. Die Übertragung eines Auftrags dauert 4 Minuten, sie geschieht 40-mal pro Woche, und 3 Personen sind daran beteiligt. Das sind 8 Stunden pro Woche, bei 45 Arbeitswochen 360 Stunden pro Jahr. Neun Arbeitswochen einer Person, verbracht mit dem Abtippen von Daten von einem Fenster ins andere. Multiplizieren Sie das mit Ihrem internen Stundensatz und Sie haben die erste Zahl.

Die zweite Zahl ist die Fehlerquote. Laut einer Asana-Umfrage aus dem Jahr 2021, über die das Portal CIO Dive berichtete, wechseln Beschäftigte 30-mal täglich zwischen 13 Anwendungen, und mehr als ein Viertel gibt an, dass ihnen dabei Vorgänge und Nachrichten entgehen. Das ist eine ältere Sekundärquelle, also ein Indiz und kein Beweis.

Die Entscheidungsmatrix: wann was

Für jeden Reibungspunkt kommen vier Antworten infrage. Am häufigsten richtig ist die erste.

1. Standardsoftware

Ist der Prozess ein Standardprozess und nicht die Quelle Ihres Wettbewerbsvorteils, kaufen Sie ein fertiges Tool. Rechnungsstellung, Löhne, Buchhaltung, Helpdesk. Deckt es achtzig Prozent des Bedarfs ab und ist der Rest nicht das, wofür Ihr Kunde Sie bezahlt, passen Sie den Prozess an das Tool an. Unternehmen tun das viel zu selten.

2. Integration

Funktionieren zwei Systeme gut und sprechen nur nicht miteinander, ist die Lösung eine Verbindung und kein drittes System. Suchen Sie zuerst nach einem nativen Konnektor des Herstellers, erst danach nach einer Integrationsplattform. Achten Sie auf den Integration Overhead: Jede Integration kann bei einem Update brechen, verbinden Sie deshalb wenige Dinge, diese aber sauber.

3. Automatisierung

Ist ein Prozess stabil, wiederholt er sich und lässt sich seine Logik in Regeln fassen, dann automatisieren Sie ihn. Aber erst dann, wenn Sie ihn vereinfacht haben. Sonst gilt, was ich in jenem Text geschrieben habe, dass KI keinen schlechten Prozess rettet: Sie machen die falsche Sache nur billiger und schneller.

4. Eigenes System

Eigene Software ist in einer engen Menge von Fällen sinnvoll: wenn der Prozess die Quelle des Wettbewerbsvorteils ist und kein fertiges Tool ihn abdeckt, ohne ihn zu verbiegen; wenn die Lizenzkosten mit der Zahl der Personen schneller steigen als die Kosten einer eigenen Lösung; oder wenn Sie einen einzigen Ort der Wahrheit für einen Bereich brauchen, für den am Markt kein Tool passt.

Genauso wichtig ist es zu wissen, wann sie nicht sinnvoll ist. Auch ein eigenes System hat seine TCO: Die Entwicklung ist nur der Anfang, danach kommen Wartung, Sicherheit und die Abhängigkeit von denen, die es ändern können. Wenn Sie nicht sicher sind, dass Sie es fünf Jahre lang betreiben werden, bauen Sie es nicht. Das beste Ergebnis eines Audits ist häufig, dass gar nichts gebaut wird, drei Tools abgeschaltet werden und eines endlich sauber konfiguriert wird.

So führen Sie ein Technologie- und Prozessaudit durch

In einem kleineren Unternehmen ist das kein Projekt über sechs Monate, sondern zwei bis vier Wochen Gespräche und eine Tabelle.

1. Die Liste der Tools aus den Zahlungen, nicht aus dem Gedächtnis. Gehen Sie die Abrechnungen der Firmenkarten und die erstatteten Ausgaben der letzten zwölf Monate durch. Zylo gibt an, dass die Ausgaben über Spesenabrechnungen im Jahresvergleich um 267 % gestiegen sind. Wer nur auf zentrale Rechnungen schaut, sieht einen Teil der Wahrheit.
2. Kartieren Sie fünf bis acht Kernprozesse. Vom ersten Kontakt bis zur bezahlten Rechnung. Halten Sie bei jedem Schritt fest, wer ihn ausführt und in welchem System.
3. Markieren Sie die Übertragungsstellen. Überall dort, wo ein Mensch Daten zwischen Systemen weitergibt. Das sind Ihre menschlichen APIs, schicken Sie sie durch die Cost of Friction.
4. Legen Sie die Single Source of Truth fest. Bestimmen Sie für Kunde, Auftrag, Projekt und Rechnung jeweils ein führendes System, alle anderen dürfen nur darauf schauen. Die meisten Streitigkeiten über Zahlen drehen sich nämlich nicht um Fakten, sondern darum, welcher Export gilt.
5. Finden Sie Dopplungen. Laut Zylo ist generative KI erstmals unter den redundantesten Funktionen gelandet: Unternehmen halten davon im Schnitt sieben Anwendungen parallel.
6. Halten Sie die Reihenfolge Remove, Simplify, Automate, Augment ein. Entfernen Sie zuerst die Schritte, die nicht existieren müssen, vereinfachen Sie dann die verbliebenen, automatisieren Sie erst danach und ergänzen Sie zuletzt um KI. Wer am Ende beginnt, zementiert das Chaos.
7. Führen Sie eine Regel für neue Tools ein. Eine Seite: Wer ist der Eigentümer, welche Daten liegen darin, wie wird es angebunden und wie kommt man wieder heraus.

Modellbeispiel: 28 Personen, sieben Systeme

Vorher. Ein hypothetisches Serviceunternehmen, kein konkreter Kunde. Es hat 28 Beschäftigte, davon 12 Techniker im Außendienst. Anfragen kommen per E-Mail, Angebote ins CRM, die Planung in eine geteilte Tabelle, die Techniker laufen über WhatsApp, die Dokumentation liegt in Notion, die Rechnungen in der Buchhaltung, die Zeiterfassung in einem eigenen Tool. Ein Auftrag existiert an vier Stellen in vier Versionen, der Abschluss dauert zwei Tage, und die Marge eines Auftrags ist erst nach sechs Wochen bekannt, wenn sich daran nichts mehr ändern lässt.

Audit. Drei Tools bezahlt das Unternehmen, obwohl sie niemand nutzt, zwei weitere leisten dasselbe. Die teuerste Stelle ist jedoch keines davon, sondern das Übertragen eines Auftrags zwischen CRM, Tabelle und Buchhaltung.

Nachher. Der Auftrag bekommt einen einzigen Eigentümer, das vorhandene CRM. Die Planungstabelle entfällt, weil dieselbe Funktion ein Modul beherrscht, das das Unternehmen seit Jahren bezahlt und nicht nutzt. Die Buchhaltung wird über einen fertigen Konnektor angebunden. WhatsApp bleibt, hört aber auf, der Ort zu sein, an dem der offizielle Status eines Auftrags entsteht. Gebaut wird eine einzige eigene Sache: eine mobile Anwendung für die Techniker, die den Leistungsnachweis direkt ins CRM schreibt, weil kein fertiges Tool zur Arbeit im Außendienst passte.

Vier der fünf Änderungen erforderten keine einzige Zeile Code: die Abschaltung der Tabelle, die Konfiguration des bereits bezahlten Moduls, ein fertiger Konnektor und eine Regel. Die Entwicklung kam erst an fünfter Stelle und war der kleinste Teil. Darum geht es bei Konsolidierung: nicht um ein großes eigenes System, sondern um die Fähigkeit zu erkennen, welches einzelne Stück sich zu bauen lohnt. Dieselbe Logik habe ich in jenem Text ausgeführt, wie Sie ein Unternehmen ohne Verwaltungsarmee aufbauen.

Die Frage lautet also nicht, ob Sie ein weiteres Tool oder ein eigenes System brauchen. Sie lautet, wo in Ihrem Prozess Reibung entsteht und was sie kostet. Das lässt sich nicht vom Schreibtisch aus schätzen, es lässt sich nur messen.

Was Sie mitnehmen

• Zählen Sie Ihre Software anhand von Kontoauszügen und erstatteten Ausgaben zusammen, nicht aus dem Gedächtnis.
• Finden Sie die Stellen, an denen ein Mensch Daten zwischen Systemen weitergibt, und schicken Sie sie durch die Cost of Friction: Zeit × Häufigkeit × Anzahl der Beteiligten × Kosten. Diese Zahl bestimmt die Reihenfolge der Änderungen.
• Bestimmen Sie für jedes zentrale Objekt ein System, das die Quelle der Wahrheit ist. Das kostet weder eine Lizenz noch eine Zeile Code, sondern nur eine Entscheidung.
• Halten Sie die Reihenfolge Remove, Simplify, Automate, Augment ein. Die Automatisierung eines unbereinigten Prozesses ist nur schnelleres Chaos.
• Optimieren Sie die Total Cost of Ownership, nicht die Zahl der Anwendungen. Standardsoftware ist am häufigsten die richtige Antwort. Eine eigene Lösung bauen Sie nur dort, wo der Prozess Ihr Wettbewerbsvorteil ist und Sie sie über Jahre betreiben werden.