Ein technisches Audit von Anwendungen wird dann geschäftskritisch, wenn Kernprozesse zwar noch laufen, aber niemand mehr belastbar sagen kann, warum sie laufen, wo sie brechen und welche Änderung den nächsten Schaden auslöst. Dann geht es nicht um kosmetische Architekturdebatten, sondern um eine operative Entscheidung: stabilisieren, Integrationen neu ordnen, gezielt modernisieren oder einen klar begrenzten Neubau anstoßen.
Wann ein technisches Audit von Anwendungen geschäftlich notwendig wird
Der Auslöser ist fast nie ein einzelner Vorfall. Meist verdichten sich Symptome: Bestände stimmen nicht, Statusketten widersprechen sich, Releases werden verschoben, weil Seiteneffekte niemand sauber einschätzen kann. Oder ein ERP in Polen, ein EU-SaaS-CRM und lokale Lager- oder Buchhaltungssysteme tauschen Daten aus, ohne klare fachliche Hoheit.
In vielen Unternehmen in Polen und der EU ist genau das der Normalzustand. Gewachsene Landschaften aus ERP, E-Commerce, WMS, CRM, Buchhaltung, EDI und Dateischnittstellen funktionieren oft lange genug, bis Last, Sonderfälle oder Compliance-Anforderungen die Schwächen offenlegen. Teuer wird es an den Übergängen: unterschiedliche Steuerlogik, asynchrone Rückmeldungen, doppelte Datenhaltung und unklare Lösch- oder Aufbewahrungsregeln.
Ein Audit ist dringlich, wenn mehrere dieser Signale gleichzeitig auftreten:
- Kleine Änderungen an Kernprozessen dauern unverhältnismäßig lange und ziehen mehrere Teams oder Dienstleister in jede Freigabe.
- Manuelle Korrekturen bei Aufträgen, Beständen, Rechnungen oder Freigaben gehören zum Tagesgeschäft.
- Produktionsfehler werden vom Fachbereich entdeckt, nicht durch Monitoring oder Alarmierung.
- Backups existieren formal, aber ein vollständiger Restore wurde nie unter realistischen Bedingungen getestet.
- Verantwortung ist unklar: internes IT-Team, Fachbereich, Softwarehaus und Hosting-Partner verweisen bei Störungen aufeinander.
- DSGVO-relevante Fragen zu Löschung, Berichtigung oder Protokollierung lassen sich technisch nicht belastbar beantworten.
Die eigentliche Frage lautet nicht, ob die Anwendung alt ist. Entscheidend ist: Welche geschäftskritischen Prozesse hängen an Komponenten, deren Verhalten bei Fehlern, Last oder Änderungen nicht mehr vorhersagbar ist?
Viele Unternehmen sprechen an diesem Punkt zu früh über einen Rewrite. Das ist oft ein Einkaufsfehler. Wenn Prozessgrenzen, Datenhoheit und Ausnahmebehandlung unklar sind, baut ein Neubau dieselben Defekte nur teurer nach. Alte Technologie ist lästig. Unklare Systemlogik ist gefährlicher.
Ein weiterer Auslöser wird intern gern unterschätzt: personelle Abhängigkeit. Wenn ein einzelner Entwickler, externer Integrator oder langjähriger Administrator faktisch die einzige Quelle für Betriebswissen ist, liegt bereits ein Geschäftsrisiko vor. Kritisch ist nicht nur der Know-how-Verlust bei Urlaub oder Kündigung, sondern dass Entscheidungen auf mündlicher Überlieferung statt auf verifizierbaren Systemfakten beruhen.
In Audits taucht derselbe Musterfehler immer wieder auf: Unternehmen halten eine Anwendung für stabil, weil sie selten komplett ausfällt. Operativ ist sie aber längst instabil, weil sie nur durch stille manuelle Eingriffe, Excel-Korrekturen und informelle Workarounds funktionsfähig bleibt. Ein System, das nur mit täglicher Handarbeit korrekt wirkt, ist nicht stabil, sondern schlecht instrumentiert.
Was im Audit wirklich geprüft wird
Ein brauchbares Anwendungsaudit folgt nicht dem Organigramm, sondern den kritischen Prozesspfaden. Für Handel, Distribution, Produktion oder Service sind das meist Abläufe wie Auftrag bis Rechnung, Bestellung bis Wareneingang, Reklamation bis Gutschrift oder Lead bis Vertragsfreigabe. Dort muss sichtbar werden, welches System schreibt, welches bestätigt, welches überschreibt und wo Fehler still liegen bleiben.
Technisch laufen vier Prüffelder parallel: Architektur, Integrationen, Betrieb und Sicherheit. Wer nur Code liest, verfehlt einen großen Teil des Risikos. Die teuersten Defekte sitzen oft zwischen Systemen oder in fehlender Wiederherstellbarkeit, nicht in einer einzelnen Klasse.
Architektur und Änderbarkeit
Hier geht es um Kopplung, Verantwortlichkeiten und Eingriffstiefe. Kritisch wird es, wenn ein Modul gleichzeitig Fachlogik, Integrationslogik und Datenpersistenz steuert oder wenn kleine Änderungen mehrere Releases in verschiedenen Systemen erzwingen. Dann ist nicht nur der Code schwer lesbar, sondern die Änderungsfähigkeit geschäftlich beschädigt.
Geprüft wird unter anderem, ob fachliche Verantwortungsbereiche pro Komponente klar benannt sind, ob sich ein kritischer Prozessschritt isoliert ändern und testen lässt, ob Releases an versteckten Reihenfolgen hängen und ob Abhängigkeiten dokumentiert oder nur implizit bekannt sind. Ein alter Monolith ist dabei kein automatischer Problemfall. Viele Monolithen sind wirtschaftlich vernünftiger als ein hektisch geplanter Neubau.
Hilfreich ist eine nüchterne Zerlegung nach drei Ebenen: fachliche Domäne, technische Laufzeit und Integrationsgrenze. Wenn Preislogik im ERP gepflegt, im Shop überschrieben und im Middleware-Skript erneut transformiert wird, ist nicht nur der Code unübersichtlich. Dann ist die Fachverantwortung selbst beschädigt. Genau solche Mehrfachzuständigkeiten erzeugen spätere Eskalationen, weil jede Seite plausibel behaupten kann, der Fehler liege woanders.
Ein Audit sollte deshalb nicht nur fragen, ob Komponenten gekoppelt sind, sondern wie teuer eine Änderung an einer Stelle systemweit wird. Ein brauchbares Kriterium ist die Zahl der abhängigen Freigaben, Testumgebungen und manuellen Prüfungen, die für eine kleine fachliche Änderung nötig sind. Wenn eine Anpassung an einer Rechnungsregel vier Systeme, zwei Dienstleister und ein Wochenendfenster braucht, ist die Architektur operativ zu teuer.
Integrationen und Datenflüsse
Die meisten geschäftskritischen Fehler entstehen an Schnittstellen. Eine Integration kann technisch erfolgreich und fachlich falsch sein. Genau das macht sie gefährlich. Wenn Nachrichten ankommen, aber Dubletten, Reihenfolgefehler, stille Überschreibungen oder Teilfehler nicht sauber behandelt werden, produziert das System operative Reibung statt sichtbarer Störung.
Deshalb prüft ein Audit konkrete Kontrollpunkte: Idempotenz, also die sichere Mehrfachverarbeitung derselben Nachricht; Retry-Strategien für temporäre Fehler; Dead-Letter-Behandlung für nicht verarbeitbare Nachrichten; klare Systemhoheit für Kunden, Preise, Bestände, Dokumente und Status; sowie konsistente Behandlung von Zeitstempeln, Zeitzonen und Reihenfolgen.
Ein typischer Fall in Handels- und ERP-Landschaften: Teilstornos werden in einem System positionsbezogen, im anderen auf Belegebene verarbeitet. Die Schnittstelle meldet Erfolg, aber Bestände, Gutschriften oder Versandstatus laufen auseinander. In einem mittelständischen Handelsunternehmen mit mehreren Lagerstandorten kann schon die Bereinigung solcher Abweichungen über Wochen Rollout-Reibung erzeugen, weil Fachbereich, ERP-Partner und Shop-Verantwortliche dieselben Status unterschiedlich lesen. Die richtige Maßnahme ist dann oft keine ERP-Ablösung, sondern eine sauber definierte Integrationsschicht mit Ereignis-IDs, Konfliktregeln und fachlicher Statusabbildung.
Kurz gesagt: Schnittstellenfehler sehen harmlos aus, bis sie Geld fressen.
Ein Audit sollte hier bis auf Nachrichtenebene heruntergehen. Relevant sind nicht nur API-Verträge, sondern auch Dateiformate, Cron-Jobs, manuelle Exporte, E-Mail-basierte Freigaben und verdeckte Hilfsskripte. Gerade in gewachsenen Landschaften laufen kritische Übergaben nicht über elegante APIs, sondern über CSV-Dateien, SFTP-Verzeichnisse oder nachts gestartete Batch-Prozesse.
Ein konkretes Betriebsbeispiel: Ein Auftrag wurde im Shop angelegt, im ERP bestätigt und im WMS kommissioniert. Nach einer Adressänderung aktualisierte das CRM den Kundenstamm, nicht aber den bereits erzeugten Versandbeleg. Technisch war jede einzelne Integration erfolgreich. Operativ entstanden trotzdem Falschlieferungen. Der Fehler lag nicht in einer kaputten API, sondern in einer fehlenden Regel dafür, ab welchem Zeitpunkt eine Lieferadresse als unveränderlich gilt.
Genau deshalb müssen Ausnahmefälle explizit geprüft werden: Teilretouren, Sammelrechnungen, Währungswechsel, Steuerkorrekturen, Stornos nach Versand, doppelte Webhooks, verspätete Rückmeldungen und manuelle Nachbearbeitung. Wer nur den Happy Path bewertet, prüft die Anwendung dort, wo sie ohnehin selten Probleme macht.
Betrieb und Wiederherstellbarkeit
Ein System ist nicht beherrschbar, wenn Fehler erst über Support-Tickets sichtbar werden. Für die operative Bewertung sind die vier DORA-Metriken als Referenz nützlich: Deployment-Frequenz, Änderungsdurchlaufzeit, Fehlerrate nach Änderungen und Wiederherstellungszeit. Sie beantworten nicht jede Architekturfrage, zeigen aber schnell, ob ein Team Änderungen kontrolliert ausliefern und Störungen reproduzierbar beheben kann.
Im Audit haben einige Fragen klaren Go-oder-No-Go-Charakter: Gibt es strukturierte Logs mit Korrelation über Systemgrenzen hinweg? Werden geschäftskritische Fehler aktiv alarmiert oder nur technisch protokolliert? Ist ein Rollback reproduzierbar oder hängt er an Einzelwissen? Wurde ein Restore aus Backup praktisch nachgewiesen?
Gerade der letzte Punkt trennt belastbaren Betrieb von Beruhigungsrhetorik. Ein Backup ohne getestete Wiederherstellung ist kein Sicherheitsnetz, sondern Papierlage. Das ist kein theoretischer Mangel, sondern ein wiederkehrender Beschaffungsfehler: Viele Angebote verkaufen Monitoring, Cloud oder Modernisierung, bevor die elementare Frage beantwortet ist, ob das Unternehmen seine Kernanwendung nach einem Ausfall kontrolliert zurückholen kann.
Zur Betriebsprüfung gehört außerdem die Frage, ob Produktionszustände reproduzierbar sind. Wenn Konfigurationen manuell auf Servern geändert werden, Secrets unstrukturiert verteilt sind oder Umgebungen voneinander abweichen, wird jede Fehleranalyse unnötig teuer. Dann scheitert nicht nur die Wiederherstellung, sondern schon die saubere Ursachenanalyse.
Besonders aufschlussreich ist die Prüfung der Beobachtbarkeit. Gute Teams sehen nicht nur CPU-Last und Antwortzeiten, sondern auch fachliche Signale: blockierte Aufträge, Differenzen zwischen ERP- und Shop-Beständen, offene Dead-Letter-Nachrichten, fehlgeschlagene Rechnungsübergaben oder ungewöhnliche Stornoquoten. Ohne solche Indikatoren bleibt Monitoring technisch korrekt und geschäftlich blind.
Sicherheit und EU-Kontext
Bei Anwendungen mit personenbezogenen Daten, Vertragsdokumenten oder Mitarbeiterdaten reicht ein allgemeiner Sicherheitscheck nicht. Im EU-Kontext müssen Zugriffskontrolle, Auditierbarkeit, Löschbarkeit, Protokollierung und Datenübermittlung technisch nachvollziehbar sein. Die DSGVO verändert die Priorisierung sofort, wenn Daten in mehreren Systemen repliziert werden und unklar ist, wo Berichtigung oder Löschung tatsächlich umgesetzt wird.
Die OWASP Top 10 ist als Reality-Check sinnvoll, um offensichtliche Risiken wie fehlerhafte Zugriffskontrolle, unsichere Konfiguration oder Injection-Risiken einzuordnen. Mehr sollte man daraus nicht machen. Sie ersetzt weder die Bewertung von Integrationslogik noch die Frage, ob ein System nach einer Störung kontrolliert wieder anlaufen kann.
