Wann fertiges SaaS nicht mehr reicht und ein eigenes System sinnvoll wird
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.
Ein konkretes Muster aus dem polnischen Handel zeigt das besser als jede abstrakte Matrix. Ein Unternehmen mit eigenem Shop, Subiekt, WMS und zwei Marktplätzen verarbeitete pro Woche grob 1.500 bis 2.000 Aufträge. Das Problem war nicht nur das Volumen, sondern die Häufung wiederkehrender Sonderfälle: Teillieferungen, Reservierungen, B2B-Sonderpreise und kanalabhängige Statuswechsel. Mehrfach am Tag mussten Operations, Lager und Kundenservice Aufträge per Export und E-Mail nachsteuern. Genau diese Reibung sprach gegen ein neues Order-Management-SaaS, weil die wirtschaftlich relevanten Ausnahmen weiterhin außerhalb des Systems gelandet wären.
Im SaaS bleiben sollte meist das Unspektakuläre: Standardkommunikation, Kalender, generisches Ticketing oder CRM ohne tiefe Prozesslogik. In eine eigene Schicht gehören eher Freigaben, Preisregeln, Auftragsrouting, kanalübergreifende Statuslogik und wiederkehrende Ausnahmen.
Kurz gesagt: Nicht alles neu bauen.
Wer sofort CRM, ERP, Support und Reporting neu entwickeln will, verwechselt Frust mit Priorisierung. Das endet oft in einer teuren Modernisierung ohne klaren operativen Gewinn.
Gerade bei regional geprägten ERP-Setups liegt der Engpass häufig nicht im ERP selbst, sondern in der Verbindung zum Onlinegeschäft. In solchen Fällen ist Subiekt mit E-Commerce integrieren oft sinnvoller als ein kompletter Systemwechsel.
Wie man die Entscheidung belastbar vorbereitet
Für diese Entscheidung braucht es kein langes Transformationsprogramm. Nötig ist eine kurze, harte Diagnose mit realen Prozessdaten. Ziel ist nicht Vollständigkeit, sondern eine belastbare Wahl zwischen SaaS, Prozessschicht und Eigenentwicklung.
Der erste Schritt ist immer derselbe: einen kritischen Ablauf isolieren. Nicht die gesamte Systemlandschaft, sondern genau einen Prozess mit spürbarem Schaden. Typische Kandidaten sind Auftragserfüllung, Preisfreigaben, Serviceannahme oder kanalübergreifende Bestandssteuerung. Danach muss klar sein, welche Systeme denselben Datensatz verändern, wo außerhalb des Systems entschieden wird, welche Ausnahmen regelmäßig auftreten und welches System je Objekt führend ist.
Wenn diese Fragen nach kurzer Analyse nicht beantwortbar sind, ist ein Neubau zu früh. Dann fehlt nicht Software, sondern Diagnose. Viele Unternehmen überspringen genau diesen Punkt und kaufen aus Ungeduld ein weiteres Tool. Das ist selten mutig. Es ist meist nur aufgeschobene Architekturarbeit.
Im zweiten Schritt wird der erste Scope hart geschnitten. Nicht die längste Wunschliste gewinnt, sondern der Entscheidungsschritt mit dem höchsten operativen Schaden. Gute erste Umfänge sind automatische Reservierungslogik, ein Freigabeworkflow für Sonderpreise, ein zentrales Ausnahme-Cockpit oder eine saubere Status-Synchronisation zwischen ERP und Shop.
Hier entscheidet sich auch, ob ein Anbieter oder Umsetzungspartner wirklich passt. Technologie allein ist kein brauchbares Auswahlkriterium. Wichtiger sind vier Fragen: Kann der Partner den Prozess sauber zerlegen? Begrenzt er den ersten Scope diszipliniert? Regelt er Betrieb und Monitoring realistisch? Und verhindert der Vertrag einen neuen Lock-in bei Deployment, Dokumentation und Exit?
API-Limits, Exportqualität, Rollenmodell und Supportzugriffe gehören zwingend in diese Prüfung. Wer diese Punkte erst nach Vertragsabschluss testet, kauft blind. Gerade im EU-Umfeld ist das fahrlässig, weil Governance-Anforderungen später nicht billiger werden.
Technisch reicht für den Start oft eine schlanke Zielarchitektur. Eine API-Anbindung an die Bestandssysteme, ein Regelkern, ein Ereignisprotokoll und eine kleine Arbeitsoberfläche für operative Teams sind häufig genug. Mehr Komplexität am Anfang ist selten ein Zeichen von Reife. Oft ist sie nur schlecht kaschierte Unsicherheit.
Ein weiterer Fehler ist die Vermischung mit allgemeiner Legacy-Modernisierung. Dann wird aus einem lösbaren Prozessengpass ein jahrelanges Programm. Erst den Engpass produktiv stabilisieren. Danach kann man größere Modernisierung sinnvoll priorisieren.
Kosten, Beschaffung und die eigentliche Marktwarnung
Wer nur Lizenzkosten mit Projektkosten vergleicht, rechnet zu flach. Die relevante Frage lautet: Was kostet der heutige Kontrollverlust? Dazu gehören manuelle Nacharbeit, Eskalationen, verspätete Faktura, Fehlbestände, Sonderfreigaben, Schattenlisten und die Zeit von Führungskräften, die operative Widersprüche auflösen müssen.
Für eine brauchbare Wirtschaftlichkeitsprüfung reichen drei Blöcke: laufende SaaS-Kosten inklusive Add-ons und API-Mehrkosten, verdeckte Prozesskosten durch Workarounds und Fehler sowie Umsetzungs- und Betriebskosten einer eigenen Lösung. Entscheidend ist, ob der betroffene Ablauf volumenstark ist und Fehler direkt Marge, Lieferfähigkeit oder Compliance treffen.
Wenn das der Fall ist, kann eine kleine eigene Prozessschicht wirtschaftlicher sein als ein weiteres Spezial-SaaS. Wenn der Ablauf selten vorkommt, geringe Fehlerkosten hat und kaum Änderungen braucht, bleibt SaaS fast immer die bessere Wahl. Diese Unterscheidung ist wichtiger als jede Grundsatzdebatte über Standardsoftware oder Individualentwicklung.
Ein SaaS-Wechsel ist sinnvoll, wenn der Prozess an sich standardisierbar ist und das Hauptproblem im Anbieter liegt: schwache APIs, schlechte Exporte, unklare Rollen oder unbrauchbare Basisfunktionen. Dann sollte zuerst der Markt neu geprüft werden, statt vorschnell zu bauen.
Die eigentliche Marktwarnung ist unbequemer: Viele Unternehmen in Polen und der EU bauen nicht zu früh selbst, sondern zu spät. Sie kaufen noch ein Tool, dann ein Add-on, dann einen Integrator und nennen das Risikominimierung. Tatsächlich verteilen sie Verantwortung über mehrere Anbietergrenzen und verlieren genau die Steuerbarkeit, die sie eigentlich einkaufen wollten. Darüber kann man streiten. Im Betrieb zeigt sich dieser Fehler erstaunlich oft.
Warnsignale in der Voranalyse sind klar. Das Team kann reale Ausnahmen nicht sauber benennen. Niemand übernimmt fachliche Verantwortung für Regeln und Prioritäten. Der gewünschte Scope besteht überwiegend aus Oberflächenwünschen. API- und Exportprüfung wurden nicht gemacht. Und für Betrieb, Monitoring und Änderungsfreigaben gibt es keinen belastbaren Plan.
Die teuerste Fehlentscheidung ist am Ende nicht der Eigenbau. Es ist die Teilablösung ohne klare Führungslogik. Dann bleibt das alte SaaS bestehen, ein neues Modul kommt dazu, und beide Systeme dürfen denselben Status verändern. Genau dort entstehen die Konflikte, die später niemand mehr sauber entwirrt.
Eigenes System statt SaaS ist deshalb keine ideologische Frage. Bleiben Sie bei SaaS, wenn der Prozess standardisierbar ist und Abweichungen wirtschaftlich klein bleiben. Bauen Sie eine eigene Prozessschicht, wenn mehrere Systeme koordiniert werden müssen und Ausnahmen den Kernprozess dominieren. Entwickeln Sie umfassender selbst, wenn Ihr Geschäft von Regeln lebt, die der Standardmarkt nicht sauber abbildet.