Ein eigenes System statt SaaS wird sinnvoll, wenn ein Kernprozess nicht mehr im System entschieden wird, sondern in Exporten, E-Mails und manuellen Korrekturen. Dann fehlt nicht bloß eine Funktion, sondern Steuerbarkeit. Für Unternehmen in Polen und der EU kippt die Lage oft früher, als Einkaufsprozesse annehmen, weil lokale ERP-Realität, mehrere Verkaufskanäle und strengere Governance-Anforderungen Standard-SaaS schneller an Grenzen bringen.
Woran man erkennt, dass SaaS den Kernprozess nicht mehr trägt
Der Bruch zeigt sich selten in der Demo. Er zeigt sich im Betrieb: Support fragt nach, Lager stoppt Aufträge, Finance korrigiert Belege, Vertrieb verlangt Sonderregeln, und niemand kann sauber sagen, welches System gerade verbindlich ist. Wenn das regelmäßig passiert, verwaltet das SaaS den Prozess nicht mehr. Es bildet nur noch Fragmente ab.
Die entscheidende Frage ist schlicht: Wo fällt die echte Entscheidung? Wenn Preisfreigaben, Bestandsreservierungen, Retourenlogik oder Statuswechsel faktisch außerhalb des Systems gesteuert werden, reicht Standardsoftware für diesen Ablauf nicht mehr aus. Ein weiteres Add-on kaschiert das meist nur.
Drei Signale reichen oft für eine belastbare Vorentscheidung. Erstens: wiederkehrende manuelle Eingriffe in einem volumenstarken Ablauf. Zweitens: Fehler treffen direkt Marge, Lieferfähigkeit oder Abrechnung. Drittens: mehrere Systeme dürfen denselben Status oder Datensatz verändern. Genau dort entstehen die teuersten Konflikte.
Viele Unternehmen nennen das ein Integrationsproblem. Präziser ist oft fehlende Führungslogik. Daten werden zwar übertragen, aber ohne klare Reihenfolge, ohne saubere Zuständigkeit und ohne belastbare Ausnahmebehandlung. Das Ergebnis sind doppelte Kundenakten, widersprüchliche Bestände oder Freigaben per E-Mail, obwohl offiziell alles integriert ist.
Der häufigste Fehlgriff ist dann noch ein Spezial-SaaS. Das lässt sich intern leichter einkaufen als eine Architekturentscheidung. Im Betrieb wird es schnell teurer. Meine Beobachtung aus solchen Vorhaben: Der vierte Connector löst das Problem fast nie. Er verschiebt Verantwortung nur über eine weitere Systemgrenze.
Für die Erstbewertung genügt ein kompaktes Entscheidungsmodell:
- Prozesskritik: Wie oft greift ein Team manuell ein, und was kostet ein Fehler operativ?
- Systemkonflikt: Wie viele Systeme beeinflussen denselben Auftrag, Bestand, Preis oder Kundenstatus?
- Änderungsdruck: Wie häufig ändern sich Regeln, Ausnahmen oder Freigaben im realen Geschäft?
Wenn alle drei Punkte kritisch sind, sollte die Diskussion nicht mehr um Features kreisen. Dann geht es um Architektur, Betrieb und Verantwortung.
Warum die Entscheidung in Polen und der EU schneller architektonisch wird
Im Markt Polen / EU scheitert SaaS selten an einer hübschen Oberfläche oder an einer einzelnen fehlenden Funktion. Die eigentliche Reibung entsteht dort, wo internationale Standardprodukte auf regionale Betriebsrealität treffen. In Polen arbeiten viele mittelständische Unternehmen mit gewachsenen ERP- und Handelslandschaften wie Subiekt, Comarch oder enova365, ergänzt um lokale Buchhaltungslogik, Lagerprozesse und Marktplatzanbindungen.
Das verschiebt die Entscheidung spürbar. Ein globales SaaS kann im CRM, Ticketing oder in Standardkommunikation sehr gut funktionieren. Bei Belegfolgen, Reservierungen, kanalübergreifenden Preisregeln oder Retouren mit lokalen Sonderfällen ist es oft der falsche Ort für geschäftskritische Orchestrierung. Nicht weil das Produkt schlecht wäre, sondern weil es für einen anderen Standard gebaut wurde.
Deshalb ist in Polen eine eigene Prozessschicht oft vernünftiger als eine komplette Ablösung. Das ERP bleibt führend für Buchung oder Stammdaten. Das SaaS bleibt dort, wo Standardisierung wirklich trägt. Die eigene Schicht steuert Regeln, Reihenfolgen, Ausnahmen und Freigaben zwischen den Systemen.
Im EU-Kontext verschärft sich die Lage an anderer Stelle: bei Beschaffung und Governance. Größere Käufer fragen längst nicht mehr nur nach Funktionslisten. Sie wollen Rollenmodell, Audit-Trail, Exportfähigkeit, API-Grenzen, Single Sign-on und ein realistisches Exit-Szenario sehen. Das ist keine juristische Dekoration. Wenn ein Anbieter diese Punkte nur mit Roadmap oder Vertriebssprache beantwortet, ist er als Kernsystem riskant.
Bei personenbezogenen Daten zählt weniger der Hosting-Slogan als die technische Nachvollziehbarkeit von Zugriffen, Zuständigkeiten und Löschläufen. Die Leitlinien des European Data Protection Board zu Verantwortlichen und Auftragsverarbeitern sind hier relevant, weil sie die Architekturfrage praktisch verschieben: Wer Regeln und Zwecke bestimmt, muss diese Kontrolle auch technisch abbilden können.
Problematisch ist deshalb ein verbreiteter Einkaufsreflex in der EU: erst das Tool auswählen, dann Datenschutz, Betrieb und Fachlogik nachziehen. So entstehen halbe Lösungen. Das SaaS wird gekauft, die Sonderlogik landet in Tabellen, Postfächern oder bei einem Integrator, und niemand besitzt den Gesamtprozess. Auf dem Papier wirkt das schlank. Im Betrieb ist es teuer.
Wer mehrere operative Systeme zusammenführen muss, stößt oft auf dieselbe Realität wie bei ERP, WMS und Marktplatz integrieren: Nicht die einzelne Anwendung ist das Problem, sondern die fehlende Instanz, die Reihenfolge und Ausnahmen verbindlich steuert.
Wenn ein Anbieter Ihr Datenmodell kontrolliert, Ihre Ausnahmen aber nicht sauber tragen kann, besitzen Sie nicht den Prozess. Sie mieten nur seine Oberfläche.
SaaS behalten, Prozessschicht bauen oder vollständig selbst entwickeln
Die falsche Debatte lautet oft: bleiben oder alles neu bauen. In der Praxis gibt es drei saubere Optionen, aber nur eine davon passt in vielen Fällen wirklich gut. Für Unternehmen mit gewachsener Systemlandschaft ist die mittlere Option meist die wirtschaftlichste: eine eigene Prozessschicht statt kompletter Eigenplattform.
| Option | Wann sie passt | Starker Nutzen | Hauptproblem |
|---|---|---|---|
| SaaS behalten oder wechseln | Der Prozess ist weitgehend standardisierbar, Fehlerkosten bleiben begrenzt, das Problem liegt vor allem im Produktfit | Schneller Betrieb, geringere Eigenverantwortung, klarere Kostenstruktur | Abhängigkeit von Roadmap, Datenmodell und API-Grenzen |
| Eigene Prozessschicht | Mehrere Systeme müssen koordiniert werden, Ausnahmen sind häufig, bestehende Kernsysteme bleiben brauchbar | Kontrolle über Regeln, Statuslogik und Freigaben ohne Komplettablösung | Mehr Betriebsverantwortung und Bedarf an sauberer Architektur |
| Komplette Eigenentwicklung | Der Kernprozess differenziert das Geschäft stark und ändert sich schneller, als Standardsoftware folgen kann | Volle Steuerbarkeit, klare Datenhoheit, kein Produktzwang | Hoher Investitions- und Betriebsaufwand |
Ein eigenes System statt SaaS bedeutet dabei nicht automatisch ein neues Großprojekt. Oft reicht ein kleiner, harter Kern: Regelwerk, API-Schicht, Ereignisprotokoll, Rollenmodell und eine Oberfläche für Ausnahmen. Weniger spektakulär, aber oft genau die richtige Größenordnung.
