Wenn Aufträge aus dem Shop per Excel ins ERP wandern, Artikelpreise an drei Stellen gepflegt werden und niemand sicher sagen kann, welches System die Kundendaten führt, ist das kein einzelnes IT-Problem. Es ist ein Architekturproblem. Systemarchitektur planen bedeutet, solche Brüche vor der Entwicklung sichtbar zu machen und ein System zu schaffen, das reale Geschäftsabläufe unterstützt - statt neue Umwege zu erzeugen.
Für mittelständische Unternehmen geht es dabei selten um einen kompletten Neubau auf der grünen Wiese. Meist gibt es bereits einen Shop, ein ERP, vielleicht ein CRM, eine Lagerlösung, Zahlungsanbieter und individuelle Prozesse, die über Jahre entstanden sind. Eine gute Planung nimmt diese Realität ernst. Sie trennt, was erhalten werden sollte, von dem, was unnötig kompliziert geworden ist.
Systemarchitektur planen beginnt bei den Abläufen
Die falsche erste Frage lautet: Welches System brauchen wir? Die richtige lautet: Wie läuft ein Auftrag heute tatsächlich durch das Unternehmen - vom ersten Kontakt bis zur Rechnung, Lieferung, Retoure und Auswertung?
In vielen Projekten zeigt sich schnell, dass die technische Landschaft nur die sichtbare Seite ist. Dahinter stehen unklare Verantwortlichkeiten, Sonderfälle im Vertrieb, manuelle Freigaben oder Daten, die in mehreren Abteilungen unterschiedlich gepflegt werden. Ein neuer Shop oder ein neues ERP löst das nicht automatisch. Ohne klare Zielprozesse digitalisiert man im schlimmsten Fall nur bestehendes Excel-Chaos.
Darum gehört an den Anfang eine Bestandsaufnahme: Welche Systeme sind beteiligt? Welche Daten werden wo angelegt, verändert und benötigt? Wo entstehen Wartezeiten, Fehler oder Doppelpflege? Und welche Abläufe sind für Umsatz, Kundenservice oder Produktion besonders kritisch?
Diese Arbeit wirkt zunächst weniger spektakulär als ein klickbarer Prototyp. Sie verhindert aber, dass ein Projekt später an einer scheinbar kleinen Frage hängen bleibt, etwa daran, wer eine Preisänderung freigibt oder welches System den verfügbaren Lagerbestand bestimmt.
Das Zielbild muss fachlich verständlich sein
Eine Systemarchitektur ist nicht nur ein Diagramm für Entwickler. Geschäftsführung, Operations, Vertrieb und Marketing müssen nachvollziehen können, wie die künftige Lösung arbeitet. Gute Planung beschreibt deshalb nicht nur Schnittstellen und Datenbanken, sondern auch konkrete Situationen.
Ein B2B-Kunde meldet sich im Shop an, sieht seine individuellen Konditionen, bestellt aus dem vereinbarten Sortiment und erhält Informationen zum Lieferstatus. Die Bestellung wird ohne manuelle Übertragung im ERP angelegt. Der Lagerbestand wird verlässlich zurückgemeldet. Der Kundenservice sieht denselben Vorgang, ohne in mehreren Anwendungen suchen zu müssen.
Solche Szenarien machen sichtbar, ob die Architektur den Alltag erleichtert. Sie zeigen auch, wo bewusst mit Ausnahmen gerechnet werden muss. Nicht jeder Prozess muss vollständig automatisiert sein. Bei komplexen Angeboten, Freigabestufen oder regulierten Gesundheitsanwendungen kann eine gezielte manuelle Prüfung sinnvoller sein als eine aufwendig automatisierte Sonderlösung.
Die sechs Entscheidungen, die Architektur tragfähig machen
1. Das führende System für jede Datenart festlegen
Der wichtigste Grundsatz lautet: Eine Information braucht eine fachlich führende Quelle. Artikelstammdaten liegen beispielsweise häufig im ERP oder PIM, Bestellungen im ERP, Inhalte und Kampagnen im Shop oder CMS, Kundeneinwilligungen in einem dafür geeigneten System. Entscheidend ist nicht das Lehrbuchmodell, sondern eine eindeutige Regelung.
Wenn Preis, Adresse oder Verfügbarkeit gleichzeitig in mehreren Systemen gepflegt werden, sind Abweichungen vorprogrammiert. Dann wird die Technik zum Schiedsrichter zwischen widersprüchlichen Daten. Klare Datenhoheit reduziert Rückfragen, Korrekturen und den Aufwand bei Updates erheblich.
2. Schnittstellen nach Geschäftskritikalität priorisieren
Nicht jede Verbindung muss zum Go-Live perfekt sein. Bestellübertragung, Bestandsabgleich und Zahlungsstatus sind für einen Onlineshop in der Regel geschäftskritisch. Eine automatisierte Übergabe spezieller Marketingsegmente kann dagegen in einer späteren Ausbaustufe sinnvoll sein.
Diese Priorisierung schafft ein planbares Budget und verhindert, dass ein Projekt unter der Last sämtlicher Wünsche stehen bleibt. Sie ist kein Verzicht auf Qualität. Sie sorgt dafür, dass zuerst die Prozesse stabil laufen, von denen Kunden und Mitarbeitende unmittelbar abhängig sind.
Auch die Art der Schnittstelle ist eine Abwägung. Echtzeit ist nicht immer besser. Für Bestände mit hoher Umschlagshäufigkeit kann sie notwendig sein. Für Produkttexte oder Auswertungen reicht oft ein zeitgesteuerter Abgleich. Echtzeit-Integrationen erhöhen Komplexität, Überwachungsbedarf und Kosten. Ihr Nutzen muss diese Investition rechtfertigen.
3. Standards nutzen, Sonderlogik bewusst begrenzen
Shopware, Odoo, WordPress oder mobile Anwendungen bringen bereits viele bewährte Funktionen mit. Wer jeden internen Sonderfall sofort als individuelle Erweiterung baut, schafft schnell eine Lösung, die bei jedem Update teuer wird.
Das heißt nicht, Geschäftsprozesse blind an eine Standardsoftware anzupassen. Manche Besonderheiten sind ein echter Wettbewerbsvorteil oder regulatorisch erforderlich. Die Frage ist: Ist diese Logik strategisch wichtig, oder wurde sie nur aus Gewohnheit beibehalten? Individuelle Entwicklung sollte dort eingesetzt werden, wo sie messbaren Nutzen bringt - nicht als technische Übersetzung historisch gewachsener Ausnahmen.
4. Sicherheit und Datenschutz früh einbauen
Datenschutz und Informationssicherheit sind keine Abnahmeprüfung am Projektende. Sie beeinflussen Rollen, Berechtigungen, Datenflüsse, Protokollierung, Hosting und Aufbewahrungsfristen von Beginn an.
Das gilt besonders für Gesundheitsapps und digitale Versorgungsangebote, aber ebenso für Kundenportale und B2B-Shops. Wer darf welche Daten sehen? Werden sensible Daten wirklich benötigt? Wie werden Zugriffe nachvollzogen? Was passiert bei einem Ausfall oder einem fehlerhaften Import?
Eine Architektur, die diese Fragen erst nach der Entwicklung beantwortet, produziert teure Nacharbeiten. Früh definierte Anforderungen führen dagegen zu klaren Zuständigkeiten und einem System, das im Betrieb besser beherrschbar bleibt.
5. Fehlerfälle und Betrieb mitplanen
Eine Schnittstelle ist nicht deshalb zuverlässig, weil sie in einer Demo funktioniert. Entscheidend ist, was passiert, wenn das ERP vorübergehend nicht erreichbar ist, ein Datensatz unvollständig übertragen wird oder ein Zahlungsanbieter eine Rückmeldung verzögert sendet.
Zur Planung gehören deshalb Wiederholungsmechanismen, verständliche Fehlermeldungen, Protokolle und ein klarer Prozess für die Bearbeitung von Ausnahmen. Mitarbeitende brauchen keine technische Diagnosekonsole. Sie brauchen die Information, welcher Auftrag betroffen ist, was fehlt und wer handeln muss.
Ebenso wichtig sind Backups, Monitoring, Update-Fenster und Ansprechpartner. Ein System, das nach dem Launch nicht beobachtet und gepflegt wird, wird mit der Zeit zum Risiko. Langfristige Wartbarkeit ist kein Zusatzpaket, sondern Teil der Architekturentscheidung.
6. Verantwortlichkeiten verbindlich regeln
Komplexe Systemlandschaften scheitern selten nur an Code. Häufig bleibt offen, wer Entscheidungen trifft, Stammdaten freigibt, Fehler priorisiert oder Änderungen beauftragt. Gerade bei mehreren Dienstleistern führt das zu langen Abstimmungen und unklaren Zuständigkeiten.
Ein Architekturkonzept sollte daher auch ein Betriebsmodell enthalten. Dazu gehören feste fachliche und technische Ansprechpartner, dokumentierte Freigabewege sowie Regeln für Änderungen. So bleibt aus einer anfänglichen Projektlösung ein steuerbares digitales Produkt.
Migration und Go-Live ohne Schweißperlen
Bei der Ablösung bestehender Systeme ist die Datenmigration oft der kritische Teil. Alte Artikelnummern, Dubletten bei Kunden, unvollständige Adressen oder uneinheitliche Preislogiken verschwinden nicht dadurch, dass sie in ein neues System importiert werden. Vor der Migration braucht es klare Bereinigungsregeln und Testdaten, die die schwierigen Fälle abbilden.
Ein belastbarer Go-Live wird schrittweise vorbereitet: mit Testumgebungen, festgelegten Abnahmekriterien, einem Plan für Datenstände und einer Unterstützung für die ersten Betriebstage. Je nach Risiko kann ein gestaffelter Start sinnvoll sein. Ein internationaler Shop mit mehreren Preislogiken erfordert eine andere Einführung als ein internes Portal für einen begrenzten Nutzerkreis.
Wichtig ist Ehrlichkeit bei Abhängigkeiten. Wenn ein externes ERP-Team, ein Zahlungsdienstleister oder interne Freigaben beteiligt sind, gehört das in den Zeitplan. Ein Termin ist nur dann belastbar, wenn diese Voraussetzungen sichtbar gemacht und aktiv gesteuert werden.
Architektur bleibt eine laufende Aufgabe
Nach dem Go-Live beginnt der Teil, der oft unterschätzt wird: Das Unternehmen verändert sich. Neue Vertriebskanäle kommen hinzu, Sortimente wachsen, gesetzliche Anforderungen ändern sich und Mitarbeitende entwickeln neue Arbeitsweisen. Eine gute Architektur lässt Raum für diese Entwicklung, ohne jeden Ausbau zum Neuaufbau zu machen.
Dafür helfen dokumentierte Schnittstellen, nachvollziehbare Entscheidungen und regelmäßige technische Prüfungen. Nicht jede Optimierung muss sofort umgesetzt werden. Aber offene Risiken, veraltete Abhängigkeiten und wiederkehrende manuelle Umwege sollten sichtbar bleiben, damit sie nicht erneut zu Insellösungen werden.
Wer seine Systemarchitektur sauber plant, entscheidet nicht nur über Software. Er entscheidet darüber, wie verlässlich das Unternehmen arbeiten kann, wenn Auftragsvolumen, Anforderungen und Erwartungen wachsen. Der beste nächste Schritt ist deshalb oft kein Toolvergleich, sondern ein gemeinsamer Blick auf den Prozess, der heute am meisten Zeit, Nerven und Vertrauen kostet.