Wenn 130 SaaS-Tools zum Architekturproblem werden

SaaS hat Software in Unternehmen demokratisiert.

Das war lange eine gute Nachricht. Fachbereiche mussten nicht mehr monatelang auf zentrale IT-Projekte warten. Marketing konnte Kampagnen-Tools testen. Sales konnte ein CRM erweitern. HR konnte Onboarding automatisieren. Operations konnte sich ein Dashboard bauen. Teams konnten schneller arbeiten, ohne jedes Mal ein eigenes System entwickeln zu lassen.

Aber die gleiche Bewegung hat in vielen Unternehmen eine neue Art von Komplexität erzeugt.

Auf X machte heute eine Zahl die Runde: Deutsche Unternehmen betreiben inzwischen im Durchschnitt deutlich mehr SaaS-Anwendungen als noch vor wenigen Jahren. Ob die konkrete Zahl im Einzelfall exakt passt, ist fast nebensächlich. Der Punkt trifft ein echtes Muster: Viele Mittelstandsunternehmen haben nicht mehr ein Softwareproblem. Sie haben ein Landschaftsproblem.

Nicht ein Tool ist schwierig. Die Summe der Tools ist schwierig.

Und besonders schwierig sind die unsichtbaren Verbindungen dazwischen.

SaaS-Wildwuchs beginnt selten als Fehler

Die meisten fragmentierten Softwarelandschaften entstehen nicht, weil jemand schlechte Entscheidungen treffen wollte.

Sie entstehen aus pragmatischen Gründen:

Ein Team braucht schnell eine Lösung.
Ein bestehendes System ist zu starr.
Ein Lieferant bringt sein eigenes Portal mit.
Ein Kunde verlangt ein bestimmtes Format.
Ein Prozess soll ohne großes IT-Projekt verbessert werden.
Ein Excel-Workflow wird zu riskant und braucht Ersatz.
Ein neues Tool verspricht Automatisierung in zwei Wochen statt in zwei Quartalen.

Jede einzelne Entscheidung kann sinnvoll sein.

Das Problem entsteht später, wenn niemand mehr die Gesamtkarte besitzt.

Dann gibt es Kundendaten im CRM, in der Buchhaltung, im Support-Tool, im Newsletter-System und in drei Projektmanagement-Workspaces. Produktdaten liegen im ERP, in Shop-Systemen, in PIM-Exporten und in Lieferantenportalen. Freigaben passieren halb in Slack, halb per E-Mail und halb in einer No-Code-Automation, die nur noch eine Person versteht.

Die Organisation arbeitet weiter. Aber sie arbeitet auf einem wackeligen Fundament.

Der eigentliche Schmerz liegt zwischen den Systemen

SaaS-Tools sind selten isoliert problematisch. Viele sind gut gebaut, nützlich und wirtschaftlich sinnvoll.

Der Schmerz entsteht zwischen ihnen.

Dort liegen Fragen wie:

Welches System ist führend für Kundendaten?
Wer darf Preise, Rollen oder Vertragsstatus ändern?
Was passiert, wenn eine API nicht erreichbar ist?
Welche Daten dürfen in welches externe System fließen?
Welche Automationen laufen kritisch für den Betrieb?
Wo werden Fehler protokolliert?
Wer merkt, wenn eine Synchronisation seit drei Tagen stillsteht?
Welche Tools enthalten personenbezogene oder vertrauliche Daten?
Welche Integrationen hängen an privaten Accounts einzelner Mitarbeitender?

Das sind Architekturfragen, auch wenn sie nicht immer so genannt werden.

Und genau deshalb lässt sich SaaS-Chaos nicht allein durch Lizenzmanagement lösen.

Eine Liste aller Tools ist hilfreich. Aber sie beantwortet nicht, wie das Unternehmen tatsächlich funktioniert. Entscheidend ist die Prozess- und Datenarchitektur: Welche Informationen entstehen wo, wer nutzt sie, welche Systeme verändern sie, und welche Abhängigkeiten entstehen daraus?

Schatten-IT ist oft ein Symptom, nicht der Feind

Der Begriff Schatten-IT klingt nach Regelbruch.

Manchmal stimmt das. Ungeprüfte Tools können Sicherheitsrisiken erzeugen, Datenschutz verletzen oder kritische Unternehmensdaten in Systeme bringen, die niemand kontrolliert.

Aber in vielen Fällen ist Schatten-IT auch ein Signal.

Sie sagt: Ein Team hatte ein reales Problem und der offizielle Weg war zu langsam, zu teuer oder zu unflexibel.

Wenn Unternehmen nur reagieren, indem sie Tools verbieten, verschwindet das Bedürfnis nicht. Es verlagert sich. Menschen gehen zurück zu Excel, privaten Accounts, manuellen Workarounds oder informellen Prozessen.

Besser ist eine nüchterne Frage:

Welche produktive Energie steckt hinter dieser Schatten-IT — und wie kann man sie sicher, wartbar und skalierbar machen?

Das ist besonders für den Mittelstand wichtig. Viele Unternehmen haben gewachsene Prozesse, erfahrene Fachabteilungen und begrenzte IT-Kapazität. Sie brauchen keine Konzernbürokratie. Aber sie brauchen klare Leitplanken, damit lokale Verbesserungen nicht zur langfristigen Systemlast werden.

Warum KI das Thema dringender macht

KI-Tools beschleunigen diese Entwicklung.

Nicht nur, weil neue SaaS-Produkte mit KI-Funktionen entstehen. Sondern weil Teams heute schneller kleine interne Anwendungen, Automationen und Integrationen bauen können.

Ein Fachbereich kann mit No-Code-Tools, KI-Assistenten oder Agenten in kurzer Zeit ein internes Portal erstellen. Ein Entwickler kann mit KI-Unterstützung mehrere Integrationen in Tagen statt Wochen bauen. Ein Produktteam kann Prototypen testen, bevor klassische Roadmap-Prozesse überhaupt starten.

Das ist gut.

Aber es erhöht den Bedarf an Architektur.

Wenn Umsetzungskosten sinken, werden mehr Dinge umgesetzt. Wenn mehr Dinge umgesetzt werden, entstehen mehr Schnittstellen. Wenn mehr Schnittstellen entstehen, steigt der Bedarf an Datenhoheit, Zugriffskontrolle, Monitoring und Verantwortlichkeit.

KI macht gute Softwarelandschaften nicht automatisch. Sie macht die vorhandene Landschaft schneller.

Wenn die Struktur stimmt, ist das ein Vorteil. Wenn sie fehlt, entsteht schneller ein schwer wartbares Geflecht aus Tools, Skripten, Workflows und halbdokumentierten Annahmen.

Was Unternehmen wirklich brauchen: eine Integrationslandkarte

Der erste praktische Schritt ist keine große Transformation.

Es ist eine Integrationslandkarte.

Nicht als PowerPoint-Friedhof, sondern als arbeitsfähige Übersicht, die Teams regelmäßig nutzen. Sie sollte mindestens beantworten:

Welche SaaS-Tools sind im Einsatz?
Welche davon sind kritisch für Vertrieb, Betrieb, Finanzen, Produkt oder Kundenservice?
Welche Datenobjekte bewegen sich zwischen ihnen?
Welches System ist jeweils führend?
Welche Integrationen sind offiziell, welche informell?
Welche laufen über API, CSV, E-Mail, Zapier/Make, Webhooks oder manuelle Exporte?
Welche Accounts, Tokens und Berechtigungen werden verwendet?
Wo gibt es Monitoring, Logs und Fehlerbenachrichtigungen?
Wer ist fachlich und technisch verantwortlich?

Diese Karte muss nicht perfekt starten. Sie muss ehrlich starten.

Schon nach wenigen Stunden werden oft Muster sichtbar: doppelte Datenerfassung, gefährliche Abhängigkeiten von Einzelpersonen, nicht dokumentierte Automationen, unnötige Tools, fehlende Eigentümer oder kritische Prozesse ohne Monitoring.

Drei Kategorien helfen beim Aufräumen

Nicht jede Integration verdient die gleiche Aufmerksamkeit.

Eine sinnvolle Einteilung ist:

1. Kritische Betriebsintegrationen

Das sind Verbindungen, die Umsatz, Lieferung, Support, Abrechnung oder rechtliche Pflichten betreffen.

Beispiele: CRM zu ERP, Shop zu Warenwirtschaft, Support zu Kundendaten, Abrechnung zu Finanzbuchhaltung, Identitätsmanagement zu internen Tools.

Hier braucht es robuste Architektur: klare Datenhoheit, Fehlermeldungen, Wiederholbarkeit, Zugriffskontrolle, Tests, Dokumentation und Rollback-Strategien.

2. Produktivitätsintegrationen

Das sind Workflows, die Teams schneller machen, aber nicht sofort den Betrieb gefährden.

Beispiele: Benachrichtigungen, interne Dashboards, einfache Automationen, Reporting-Flows, Übergaben zwischen Projektmanagement-Tools.

Hier darf man pragmatischer sein. Aber auch diese Integrationen brauchen Eigentümer, sichtbare Fehler und regelmäßige Prüfung. Sonst werden sie später unbemerkt kritisch.

3. Experimente und Prototypen

Das sind neue Tools, KI-Workflows oder Automationen, die bewusst getestet werden.

Hier sollte Geschwindigkeit möglich sein. Aber Experimente brauchen Grenzen: keine produktiven Daten ohne Prüfung, keine dauerhaften Schattenprozesse, klare Laufzeit, klare Entscheidung nach dem Test.

Diese Unterscheidung verhindert zwei schlechte Extreme: alles blockieren oder alles erlauben.

API-Management ist mehr als Technik

Wenn viele Systeme miteinander sprechen, klingt API-Management nach einem rein technischen Thema.

In Wahrheit ist es auch Governance.

Gutes API- und Integrationsmanagement klärt:

Welche Schnittstellen offiziell unterstützt werden;
welche Datenformate stabil sind;
wie Authentifizierung und Berechtigungen funktionieren;
wie Änderungen angekündigt werden;
wie Fehler behandelt werden;
wie Systeme versioniert werden;
welche externen Anbieter Zugriff auf Unternehmensdaten haben;
welche Integrationen aus Compliance-Sicht relevant sind.

Das muss nicht sofort eine große Plattform bedeuten. Für viele mittelständische Unternehmen reicht am Anfang eine saubere Architekturentscheidung: Welche Systeme sind Kernsysteme, welche sind Satelliten, welche Datenflüsse sind erlaubt, und welche Integrationen gehören in eine kontrollierte technische Schicht statt in einzelne Tool-Accounts?

Diese technische Schicht kann später ein internes API-Gateway, eine Integrationsplattform, ein kleines Backend, ein Event-System oder eine Kombination sein. Wichtig ist nicht das Schlagwort. Wichtig ist, dass kritische Verbindungen nicht zufällig entstehen.

Wann individuelle Software sinnvoller ist als noch ein SaaS-Tool

SaaS ist oft die richtige Wahl. Aber nicht immer.

Ein weiteres Tool lohnt sich, wenn es ein klar abgegrenztes Problem löst, wenig kritische Daten hält und gut in die bestehende Landschaft passt.

Individuelle Software oder ein internes Tool wird sinnvoll, wenn:

mehrere SaaS-Systeme nur durch manuelle Arbeit zusammengehalten werden;
ein Kernprozess nicht sauber in Standardsoftware passt;
Teams denselben Datensatz in vielen Tools pflegen;
Compliance oder Datenschutz eine kontrollierte Lösung verlangen;
ein Workflow strategisch wichtig ist und nicht vom Produktplan eines Anbieters abhängen sollte;
die Kosten vieler Lizenzen und Workarounds höher werden als eine gezielte Lösung.

Der Punkt ist nicht, alles selbst zu bauen.

Der Punkt ist, bewusst zu entscheiden, was gekauft, verbunden und selbst entwickelt wird.

Bei McDougall Digital betrachten wir solche Entscheidungen gerne aus Architektur- und Produktsicht zusammen: Welche Software sollte Standard bleiben? Wo braucht es eine schlanke Integration? Wo lohnt sich ein internes Produkt, weil es den operativen Kern besser abbildet als ein weiterer SaaS-Baustein?

Ein pragmatischer 30-Tage-Plan

Für Unternehmen, die SaaS-Wildwuchs spüren, aber kein großes Transformationsprojekt starten wollen, hilft ein kurzer, fokussierter Einstieg.

Woche 1: Sichtbarkeit schaffen

Sammeln Sie die wichtigsten Tools, Integrationen, Datenflüsse und Eigentümer. Nicht jedes Nebenwerkzeug muss sofort erfasst werden. Starten Sie mit Vertrieb, Betrieb, Finanzen, Support und produktkritischen Prozessen.

Woche 2: Risiken priorisieren

Markieren Sie Integrationen mit produktiven Daten, personenbezogenen Daten, Umsatzbezug, manuellen Exports, privaten Accounts, fehlendem Monitoring oder unklarer Verantwortung.

Woche 3: Leitplanken definieren

Legen Sie einfache Regeln fest: Wer darf neue Tools einführen? Welche Daten dürfen wohin? Welche Integrationen brauchen Review? Wo werden API-Tokens verwaltet? Welche Automationen müssen dokumentiert werden?

Woche 4: Die ersten drei Knoten lösen

Wählen Sie nicht zwanzig Probleme. Wählen Sie drei.

Zum Beispiel: eine kritische CSV-Synchronisation ersetzen, einen privaten Automations-Account ablösen, einen führenden Datensatz definieren, eine fehleranfällige Integration stabilisieren oder ein internes Dashboard aus mehreren manuellen Reports bauen.

So entsteht Vertrauen. Und Vertrauen ist wichtiger als ein perfektes Architekturprogramm.

Das Ziel ist nicht weniger Software. Das Ziel ist mehr Kontrolle.

Moderne Unternehmen werden nicht wieder zu monolithischen Ein-System-Landschaften zurückkehren. Das wäre auch nicht wünschenswert.

SaaS bleibt wertvoll. KI-gestützte Tools werden wichtiger. Fachbereiche werden weiter schnelle Lösungen brauchen. Die Frage ist nicht, wie man diese Entwicklung stoppt.

Die Frage ist, wie man sie beherrschbar macht.

Eine gute Softwarelandschaft erlaubt lokale Geschwindigkeit, ohne zentrale Kontrolle zu verlieren. Sie gibt Teams Werkzeuge, ohne Unternehmensdaten zu verstreuen. Sie nutzt Standardsoftware, ohne Kernprozesse beliebig abhängig zu machen. Sie lässt Experimente zu, ohne sie unbemerkt in kritische Infrastruktur verwandeln zu lassen.

Das ist Architekturarbeit.

Nicht als Selbstzweck, sondern als Voraussetzung dafür, dass Digitalisierung im Mittelstand dauerhaft funktioniert.

Wie McDougall Digital helfen kann

Wenn Ihre SaaS-Landschaft gewachsen ist und niemand mehr sicher sagen kann, welche Tools, Datenflüsse und Automationen wirklich kritisch sind, ist das lösbar.

McDougall Digital unterstützt Unternehmen dabei, Softwarelandschaften sichtbar, wartbar und sicherer zu machen — von der Integrationslandkarte über API- und Datenarchitektur bis zur Entwicklung schlanker interner Tools.

Wir helfen besonders dort, wo technische Entscheidungen und Produktrealität zusammenkommen: Welche Systeme bleiben? Welche Schnittstellen müssen stabilisiert werden? Welche Workflows verdienen eigene Software? Und wo kann KI-gestützte Entwicklung sicher beschleunigen, ohne neue Schatten-IT zu erzeugen?

Der beste Zeitpunkt, SaaS-Chaos zu ordnen, ist nicht erst nach dem nächsten Ausfall.

Er ist dann, wenn die Organisation noch schnell genug ist, um aus Kontrolle wieder Geschwindigkeit zu machen.