Die teure Entscheidung lautet selten „SaaS oder nicht“. Sie lautet: noch ein SaaS — in eine Landschaft, die bereits mehrere gemietete Produkte enthält. Das erste Werkzeug kürzt einen sichtbaren Umweg. Das fünfte erzeugt einen zweiten: dieselbe Information liegt dann an mehreren Stellen, und niemand kann mehr sagen, welche davon gilt.
Genau an diesem Punkt wird aus einer Beschaffungsfrage eine Architekturfrage. Nicht, weil Software mieten grundsätzlich falsch wäre. Sondern weil jedes zusätzliche Produkt vier Dinge mitbringt, die selten in der Lizenzrechnung stehen: eine eigene Nutzerverwaltung, eine eigene Datenhaltung, eine eigene Preisstruktur und eine eigene Vorstellung davon, wie der Ablauf auszusehen hat. Die ersten drei kosten Geld und Verwaltungsaufwand. Das vierte kostet mehr: Der Ablauf wird dem Werkzeug angepasst, weil das im Moment billiger wirkt, als das Werkzeug anzupassen.
Was „noch ein SaaS“ technisch bedeutet
Das National Institute of Standards and Technology definiert Software as a Service so, dass die Kundin die Anwendung des Anbieters nutzt — und die zugrunde liegende Infrastruktur nicht steuert, „or even individual application capabilities, with the possible exception of limited user-specific application configuration settings“ (NIST SP 800-145). Das ist keine Warnung, sondern die Beschreibung des Geschäfts: Sie mieten ein fertiges Verhalten und dürfen es in den vorgesehenen Grenzen konfigurieren. Alles, was außerhalb dieser Grenzen liegt, ist entweder ein Workaround oder ein zweites Produkt.
Für Buchhaltung, Lohnabrechnung oder E-Mail ist das der richtige Handel. Der Prozess läuft bei Ihnen im Wesentlichen so wie bei allen anderen; die laufende Pflege regulatorischer Änderungen wollen Sie nicht selbst tragen. Für einen Ablauf, der mehrere vorhandene Systeme berührt und der genau deshalb bei Ihnen so aussieht, wie er aussieht, ist derselbe Handel ein Tausch: Sie geben die Prozesslogik ab und behalten die Integrationsarbeit.
Das Bundesamt für Sicherheit in der Informationstechnik macht sichtbar, warum sich diese Arbeit vervielfacht. Der IT-Grundschutz-Baustein OPS.2.2 Cloud-Nutzung ist „immer auf eine konkrete Cloud-Dienstleistung anzuwenden“. Nutzen Sie mehrere Anbieter, gilt er für jeden — und „die Schnittstelle zwischen den Cloud-Diensteanbietenden ist ebenfalls Gegenstand des Bausteins“. Jedes weitere SaaS ist damit nicht nur eine Lizenz, sondern ein eigener Governance-Gegenstand: Strategie, Service-Definition, Verantwortungsabgrenzung, Einbindung, Nachweis der Sicherheit. Wer das nicht mitrechnet, unterschätzt den n-ten Dienst systematisch.
Hinzu kommt die Gefährdung, die das BSI unter „fehlende oder unzureichende Strategie“ fasst: Ohne vorher festgelegte Kriterien entstehen ungeeignete Dienste, die mit der eigenen IT, den internen Prozessen oder dem Schutzbedarf nicht zusammenpassen — organisatorisch, technisch oder finanziell. In der Praxis heißt das oft: Ein Bereich kauft, weil der Anbieter die Demo in zwanzig Minuten zeigt. Die Integration, die Rechte, der Abgleich und die zweite Wahrheit in einem weiteren System kommen danach und gehören niemandem.
Wann die Entscheidung überhaupt ansteht
Beim ersten Werkzeug steht sie meistens nicht an. Zwei Systeme mit dokumentierter Schnittstelle und überschaubarem Volumen verbindet eine fertige Plattform schneller und günstiger als ein Eigenbau. Die Grenze liegt dort, wo die Logik verzweigt, wo Fehlerbehandlung und Wiederanlauf verlässlich sein müssen oder wo die Kosten mit der Zahl der Vorgänge oder Nutzer steigen, ohne dass der Nutzen mitwächst.
Vier Lagen machen internes Tooling zur besseren Wahl — oft treten sie gemeinsam auf.
Der Ablauf ist ein Grund, warum Kunden bei Ihnen kaufen. Was Sie unterscheidet, sollten Sie nicht mieten. Eine Agentur, die für jedes Kundenprojekt eine eigene Anbindung an dasselbe Sprachmodell baut, zahlt die Integrationsarbeit mehrfach und kann den Anbieter nicht wechseln, ohne jedes Projekt anzufassen. Eine gemeinsame, eigene Schicht macht denselben Wechsel zur Konfiguration. Das Muster gilt unabhängig von KI: Die Differenzierungsleistung gehört Ihnen, das Standardstück darf ein Produkt sein.
Es sind mehrere Systeme beteiligt, und kein Standardprodukt kennt alle. Shop, Warenwirtschaft, PIM, CRM, ein branchenspezifisches Fachverfahren. Jedes einzelne hat ein Ökosystem. Die Strecke dazwischen hat keins. Wer dafür ein weiteres SaaS kauft, kauft ein fünftes Datenmodell und die Pflicht, es mit den anderen vier in Übereinstimmung zu halten.
Die Lizenz skaliert mit Köpfen oder Vorgängen, der Nutzen nicht. Ein Werkzeug, das zehn Personen brauchen, um einen Abgleich anzustoßen, den anschließend niemand mehr anfasst, wird mit jeder Einstellung teurer. Internes Tooling hat Baukosten und Betriebskosten. Es hat keine Sitzplatzlogik für eine Tätigkeit, die kein Mensch ausführen sollte.
Sie müssten den Ablauf verbiegen, damit er ins Produkt passt. Das ist der Punkt, an dem „schnell eingeführt“ teuer wird. Ein verbogener Prozess erzeugt Umgehungen. Umgehungen erzeugen Schattendaten. Schattendaten sind der Rohstoff für den nächsten manuellen Schritt — genau den, den das neue Werkzeug abschaffen sollte.
Der Moment, in dem SaaS-Wildwuchs wirklich kostet, ist deshalb selten die Summe der Rechnungen. Es ist der Moment, in dem ein wachsender Teil der Organisation Systeme miteinander in Übereinstimmung hält. Für diese Tätigkeit bezahlt kein Kunde.
Was internes Tooling in der Praxis ist
Interne Werkzeuge sind fast nie große Software. Häufig sind es ein paar hundert Zeilen, die zwei Systeme verbinden; ein schlichtes Formular mit einer Datenbank dahinter; ein nächtlicher Lauf, der Bestände abgleicht; eine Warteschlange für Fälle, die die Automatik nicht abdeckt. Der entscheidende Unterschied ist nicht die Größe, sondern wem die Logik gehört — und ob sie in Ihren Konten liegt, mit Protokollierung, definiertem Fehlerweg und einer Person, die Änderungen freigibt.
Das ist etwas anderes als „noch ein Skript auf dem Rechner der zuständigen Kollegin“. Ein Skript, das niemand benennen, niemand überwachen und niemand übergeben kann, ist kein internes Tooling. Es ist eine geduldete Ausnahme, die im Urlaub oder beim nächsten Systemwechsel ausfällt. Wer SaaS-Wildwuchs gegen einen Bestand ungewarteter Skripte tauscht, hat das schlechtere Ende: Gekündigt werden kann das nicht.
Deshalb gehören Betrieb, Protokollierung und Dokumentation von Anfang an zum Umfang. Eine Strecke ohne Überwachung ist keine Entlastung, sondern eine verschobene Störung. Das gilt für gemietete Plattformen genauso wie für eigenen Code; der Unterschied ist, dass Sie beim eigenen Code die Lücke selbst schließen können — und sie deshalb auch selbst schließen müssen.
Wem die Logik nicht gehört, der verhandelt über Ausnahmen. Wem sie gehört, der ändert eine Regel.
Die ehrliche Kehrseite bleibt: Eigenbau erzeugt Wartungspflicht. Abhängigkeiten müssen aktuell bleiben, Schnittstellen der Gegenseite ändern sich, Fachregeln werden nachgezogen. Wer das nicht einplant — intern oder über einen benannten Betrieb —, sollte beim SaaS bleiben, auch wenn die Lizenz ärgert. Eine unbeaufsichtigte Eigenentwicklung ist kein Souveränitätsgewinn.
Für wen SaaS die richtige Wahl bleibt
Internes Tooling ist keine Haltung gegen Standardsoftware. Es ist die Ausnahme für Abläufe, die kein Produkt kennen darf, weil sie Ihres sind. In den übrigen Fällen ist Mieten die richtige Entscheidung — und zwar dauerhaft, nicht nur „bis wir größer sind“.
Der Prozess läuft bei Ihnen wie bei allen anderen. Buchhaltung, Lohnabrechnung, Zeiterfassung, E-Mail, Videokonferenz. Eigenbau ist hier reine Verschwendung. Sie kaufen nicht nur Software, Sie kaufen die laufende Abbildung gesetzlicher und marktüblicher Änderungen.
Es bestehen regulatorische Anforderungen, deren Pflege Sie nicht selbst übernehmen wollen. Wo der Nachweis gegenüber Prüfern, Aufsicht oder Kunden zum Produkt gehört, ist ein etabliertes SaaS oft der kürzere Weg — vorausgesetzt, der Anbieter legt offen, wo Daten liegen, wer sie verarbeitet und was im Auftragsverarbeitungsvertrag steht. Das BSI verlangt für jeden Cloud-Dienst eine Service-Definition und eine klare Abgrenzung der Verantwortlichkeiten. Wer das beim Anbieter bekommt, muss es nicht selbst bauen.
Das Produkt hat eine dokumentierte, stabile Schnittstelle, und Sie kommen jederzeit vollständig an Ihre Daten. Ohne beides kaufen Sie eine Blackbox. Mit beidem bleibt das SaaS ein Baustein, den Sie ersetzen können, ohne den Prozess neu zu erfinden. Fehlt die Schnittstelle, ist das kein Argument für noch ein SaaS daneben, sondern für eine eigene Entscheidung: Zugangsweg bauen oder das System mittelfristig ablösen.
Das Volumen ist überschaubar, die beteiligten Systeme sind wenige, die Regel ist stabil. Dann ist eine fertige Automatisierungsplattform das richtige Werkzeug. Sie wird zum Kostentreiber erst, wenn Verzweigungen, Wiederanlauf und Fehlerbehandlung ernst genommen werden müssen — oder wenn die Preisstruktur mitwächst, der Nutzen aber nicht.
Niemand im Haus kann den Betrieb eines eigenen Werkzeugs tragen, und niemand soll es. Das ist eine legitime Lage, keine Schwäche. Internes Tooling ohne Zuständigkeit veraltet und wird umgangen. In dieser Lage ist das kleinere Übel ein gemietetes Produkt mit klarem Vertrag — plus die Disziplin, nicht jedes Jahr ein weiteres dazuzulegen.
Was SaaS nicht heilt: einen ungeklärten Ablauf. Wer einen solchen Ablauf in ein Werkzeug gießt, bekommt denselben Ablauf, nur schneller, mit Fehlern, die sich entsprechend schneller vervielfachen. Die Reihenfolge bleibt: zuerst streichen und schneiden, dann entscheiden, ob gemietet oder gebaut wird.
Vier Fragen vor der nächsten Lizenz
Bevor ein weiteres Produkt ins Haus kommt, reichen vier schriftliche Antworten. Wenn eine davon unsicher bleibt, ist das der Befund — nicht ein Grund, die Demo zu verlängern.
- Welche Information ist nach der Einführung die führende, und in welchem System liegt sie? Gibt es darauf keine eindeutige Antwort, erzeugen Sie eine weitere Kopie, keine Lösung.
- Welchen Schritt müssten Sie an das Produkt anpassen — und warum existiert dieser Schritt? Ist die Antwort „weil das Produkt das so verlangt“, automatisieren Sie eine fremde Vorgabe. Ist die Antwort „weil Kunden das so von uns erwarten“, gehört die Logik Ihnen.
- Was kostet der Dienst in drei Jahren, wenn Nutzerzahl oder Vorgangsvolumen wachsen, der fachliche Nutzen aber nicht? Sitzplatz- und Transaktionspreise wirken in der ersten Rechnung klein. Sie werden groß, sobald das Werkzeug zur Pflichtlizenz für Tätigkeiten wird, die niemand mehr ausführen sollte.
- Wer betreibt die Strecke, wenn sie steht — und was passiert, wenn sie ausbleibt? Fehlt die zuständige Person, fehlt auch das Recht, intern zu bauen. Fehlt die Überwachung, fehlt sie bei beiden Varianten; intern können Sie sie wenigstens einbauen.
Die Abhängigkeit vom Anbieter — Vertragsende, Preisänderung, Wegfall eines Dienstes — gehört in diese Überlegung, aber sie entscheidet sie nicht allein. Sie ist ein eigenes Thema. Hier genügt der Hinweis aus demselben BSI-Baustein: Wer Cloud-Dienste nutzt, gibt Kontrolle ab und muss den Ausstieg vorher regeln, nicht wenn der Vertrag endet. Wer das nicht tun will, sollte die Logik nicht vermieten.
Wie eine Strecke von der Aufnahme bis zum Betrieb geschnitten wird, steht unter Prozessautomatisierung. Ob die vorhandene Landschaft das überhaupt hergibt — Schnittstellen, Datensätze, die zweite und dritte Wahrheit —, klärt ein System-Audit.
Quellen