Prozessresilienz: Drei Fähigkeiten, die Ihr Unternehmen unter Störungen handlungsfähig halten

Resilienz ist in den letzten Jahren zu einem der meistgenutzten Begriffe in der Unternehmensführung geworden. Gemeint ist oft etwas sehr Abstraktes. Im operativen Alltag entscheidet sich Resilienz aber konkret, in den Momenten, in denen etwas nicht nach Plan läuft. Eine Internetleitung fällt aus, ein Lieferant meldet sich kurzfristig ab, eine Software zickt an einem Freitagnachmittag. In diesen Situationen zeigt sich, ob ein Unternehmen handlungsfähig bleibt oder stillsteht. Dieser Artikel zeigt, aus welchen drei Fähigkeiten Prozessresilienz zusammengesetzt ist und welche Rolle das ERP-System dabei spielt.

Was bedeutet Prozessresilienz?

Prozessresilienz beschreibt die Fähigkeit von Geschäftsprozessen, auch bei Störungen weiter zu funktionieren. Der Begriff stammt ursprünglich aus der Psychologie, hat sich über Organisationslehre und Supply-Chain-Management in die IT- und ERP-Welt fortgesetzt und meint dort etwas sehr Praktisches: Ein Prozess ist resilient, wenn er nach einer Störung schneller wieder arbeitet, als dass die Störung sich ausbreiten kann.

Wichtig ist die Abgrenzung zu zwei verwandten Begriffen. Robustheit meint, dass ein System Störungen möglichst gut aushält, ohne umzufallen. Redundanz meint, dass Systeme doppelt vorhanden sind, damit eines übernehmen kann, wenn das andere versagt. Resilienz schließt beides ein, geht aber weiter: Sie beschreibt, wie gut ein Prozess sich an veränderte Bedingungen anpasst, weiterarbeitet und schnell wieder zum Normalzustand zurückkehrt. Resilienz ist deshalb nicht nur eine Eigenschaft von Servern oder Netzwerken, sondern immer eine Kombination aus Technik, Prozessen und Menschen. Sobald einer der drei Bausteine fehlt, bricht die Kette.

Warum Prozessresilienz heute wichtiger ist als noch vor fünf Jahren

Die Zahl der externen Störquellen ist spürbar gewachsen. Angespannte Lieferketten sind zum Dauerthema geworden, Cyberangriffe auf mittelständische Unternehmen haben sich in den vergangenen Jahren vervielfacht, und auch die vermeintlich selbstverständliche Infrastruktur wie Internetleitungen, Energie und Erreichbarkeit von Cloud-Diensten zeigt an einzelnen Tagen, dass sie eben doch nicht immer da ist.

Gleichzeitig hat der Automatisierungsgrad in den meisten Unternehmen deutlich zugenommen. Prozesse, die früher notfalls per Hand, per Telefon oder per Papierbeleg ausgeführt werden konnten, sind heute vollständig in Software abgebildet. Das ist ein Produktivitätsgewinn, aber es erhöht die Abhängigkeit von den beteiligten Systemen. Wenn ein einzelner Baustein ausfällt, fällt oft der ganze Prozess aus.

Dazu kommt der Fachkräftemangel, der in vielen Betrieben keine Reserven mehr lässt, um manuell einzuspringen. Eine fünfköpfige Buchhaltung, in der eine Person spontan die Arbeit einer anderen übernehmen konnte, ist in vielen Mittelständlern zu einer zwei- oder dreiköpfigen Abteilung geschrumpft, in der es keinen Puffer mehr gibt. Wer hier ausfällt, hinterlässt eine Lücke, die unmittelbar Wirkung entfaltet.

Aus diesen drei Entwicklungen zusammen ergibt sich eine neue Lage. Resilienz ist kein Nice-to-have mehr, über das man nach erfolgreichem Geschäftsjahr philosophiert. Sie ist zu einer operativen Voraussetzung geworden, ohne die die Abhängigkeit von Systemen und Partnern zum Risiko wird.

Fähigkeit 1: Business Continuity - weiterarbeiten, auch wenn die Leitung steht

Die erste und spürbarste Dimension von Prozessresilienz ist die schlichte Frage, ob gearbeitet werden kann, wenn etwas Technisches ausfällt. Und in der Praxis ist das häufigste "etwas" die Internetverbindung.

Das unterschätzte Risiko Internetausfall

Internetausfälle sind selten katastrophal lang, aber häufig genug und lang genug, um einen Arbeitstag zu ruinieren. Baustellen, bei denen ein Glasfaserkabel versehentlich gekappt wird. Provider-Störungen, die regionale Ausfälle verursachen. Lokale Stromausfälle, die einzelne Verteiler betreffen. Routerprobleme im eigenen Gebäude. In der Summe erlebt jedes Unternehmen solche Situationen ein- bis mehrmals pro Jahr. Wenn in diesen Stunden nichts geht, summiert sich das über die Jahre zu erheblichen Produktivitätsverlusten.

Was Cloud-only-Systeme in diesem Moment können - und was nicht

Ein ERP-System, das ausschließlich in der Cloud betrieben wird, ist untrennbar mit der Internetverbindung verknüpft. Fällt die Leitung aus, steht das System still. Unabhängig davon, wie leistungsfähig der Cloud-Anbieter ist, unabhängig davon, wie zuverlässig sein Rechenzentrum läuft: Ohne Verbindung hin zum Kunden gibt es keine Nutzung. In den meisten Fällen bedeutet das, dass Aufträge nicht erfasst, Rechnungen nicht gestellt und Bestellungen nicht ausgelöst werden können, bis die Leitung wieder steht.

Mobile Hotspots oder LTE-Backup-Leitungen mildern das Risiko, lösen es aber nicht vollständig. Sobald mehrere Personen gleichzeitig arbeiten, stößt ein Hotspot schnell an seine Grenzen. Und in ländlichen Gegenden ist auch der Mobilfunk keine Garantie.

On-Premises-Betrieb im lokalen Netzwerk als funktionierende Rückfallebene

Hier liegt eine der konkreten Stärken einer On-Premises-Betriebsvariante. Läuft das ERP-System auf einem Server im eigenen Büro, und sind die Arbeitsplätze über das lokale Netzwerk mit diesem Server verbunden, ist die Internetverbindung für die interne Arbeit nicht erforderlich. Der Vertrieb kann Angebote schreiben, die Buchhaltung kann Rechnungen erfassen, das Lager kann Buchungen durchführen. Was nicht geht, sind Versand von E-Mails, Zahlungsverkehr und externe Abfragen. Aber der Kern der Arbeit läuft weiter.

Das klingt nach einer Selbstverständlichkeit, wird aber in Cloud-first-Strategien oft übersehen. Wer Ausfallsicherheit ernst meint, sollte sich vor einer Entscheidung bewusst machen, wie lange das eigene Unternehmen ohne Internetzugang handlungsfähig bleibt.

Fähigkeit 2: Anpassungsfähigkeit - Prozesse müssen sich biegen können

Die zweite Dimension betrifft die Prozesse selbst. Ein Unternehmen, das seine Abläufe zu eng ausformuliert hat, ist bei jeder Änderung auf tiefe Eingriffe in das System angewiesen. Ein Unternehmen, das seine Abläufe flexibel abbilden kann, reagiert auf neue Bedingungen ohne großen Aufwand.

Der Unterschied zwischen starrer Automatisierung und flexibler Prozessführung zeigt sich im Alltag in vielen kleinen Situationen. Ein zusätzlicher Freigabeschritt wird eingeführt, weil das Controlling ihn fordert. Eine Abrechnungsart ändert sich, weil ein Kunde einen anderen Turnus verlangt. Ein Bestellprozess muss temporär umgestellt werden, weil der Hauptlieferant kurzfristig ausfällt. Diese Situationen haben alle etwas gemeinsam: Sie sind im Voraus nicht vollständig planbar, und sie müssen schnell umgesetzt werden können.

Eine ERP-Software, die solche Anpassungen über Konfiguration, Rollen und Workflows zulässt, gibt ihrem Nutzer die Möglichkeit, ohne Entwicklungsprojekt auf Veränderungen zu reagieren. Im Idealfall geschieht eine solche Anpassung innerhalb von Stunden, nicht innerhalb von Wochen. Wenn stattdessen jede Änderung zu einem IT-Projekt wird, ist die Prozessresilienz unabhängig von der technischen Verfügbarkeit bereits eingeschränkt.

Als Voraussetzung dafür wirkt das, was wir im Rahmen des Clean-Core-Prinzips bereits ausführlicher betrachtet haben: eine klare Trennung zwischen Standardsystem und Anpassungsebene, die es möglich macht, Änderungen schnell und gefahrlos vorzunehmen. Prozessresilienz ist ohne diese architektonische Disziplin kaum dauerhaft herstellbar.

Fähigkeit 3: Schutzfunktion - Servicequalität, wenn es gerade akut brennt

Die dritte Dimension ist die, die in Hochglanz-Broschüren am seltensten auftaucht und im Ernstfall am meisten zählt: Wer hilft, wenn etwas nicht funktioniert und die Uhr läuft?

Support unter Stressbedingungen ist eine eigene Disziplin

Support im Normalbetrieb ist eine Sache, Support im Ausnahmezustand eine andere. Ein Monatsabschluss läuft, der Steuerberater wartet auf Zahlen, eine Lagerumbuchung verursacht eine Inkonsistenz, und in anderthalb Stunden soll die erste Rechnungslieferung raus. In solchen Situationen reicht es nicht, ein Ticket aufzumachen und auf die Rückmeldung in drei Werktagen zu warten. Es braucht jemanden, der schnell dran ist, der das System kennt und der die richtigen Fragen stellt, statt sich durch einen Skript-Katalog zu arbeiten.

Ticket-System versus direkter Herstellerkontakt

Der Unterschied zwischen beiden Ansätzen wird im Ernstfall unmittelbar sichtbar. Ein mehrstufiger Support-Prozess, in dem zuerst ein externes Helpdesk, dann ein Dienstleister und erst am Schluss der Hersteller einbezogen werden, ist im Normalbetrieb günstig. In der akuten Situation kostet jede Stufe Zeit. Ein direkter Draht zum Hersteller ist teurer in der Bereitstellung, zahlt sich aber in genau den Stunden aus, in denen es drauf ankommt.

Unsere Erfahrung aus vielen Jahren Kundenbetreuung zeigt ein wiederkehrendes Muster. Wenn Kunden anrufen und erkennbar Druck haben, geht es selten um die schöne, methodisch saubere Lösung. Es geht darum, dass die nächsten zwei Stunden funktionieren. Genau darin liegt die Qualität eines guten Supports: zu erkennen, ob ein Fall eine gründliche Ursachenanalyse braucht oder eine schnelle Überbrückungshilfe, und in beiden Modi souverän zu arbeiten.

Warum Herstellersupport an dieser Stelle unersetzbar ist

Ein externes Helpdesk kann Prozessfragen beantworten und bekannte Problemmuster lösen. Sobald jedoch der Kern des Systems betroffen ist, fehlt ihm die Tiefe. Herstellersupport kennt nicht nur das Symptom, sondern das System dahinter. Er kann Wechselwirkungen abschätzen, auf Code-Ebene prüfen und im Zweifel Anpassungen vornehmen, ohne dass ein Eskalationsweg mit drei Ansprechpartnern eröffnet werden muss. Das ist die Schutzfunktion, die unter Stressbedingungen greift.

Was Prozessresilienz NICHT ist

Um Missverständnissen vorzubeugen, lohnt es sich, ein paar Abgrenzungen zu benennen.

Prozessresilienz ist keine Versicherung, die man einmal abschließt und dann vergisst. Sie ist eine Eigenschaft, die fortlaufend gepflegt werden muss, weil sich Prozesse, Risiken und Rahmenbedingungen ändern. Was heute resilient ist, kann nach einem Technologiewechsel oder einer Umstrukturierung wieder verletzlich sein.

Prozessresilienz ist kein rein technisches Thema. Die beste Technik wird durch undokumentierte Prozesse entwertet, und ein guter Support wird durch chaotische Zuständigkeiten ausgebremst. Resilienz entsteht immer im Dreiklang von Technik, Organisation und Menschen.

Prozessresilienz ist nicht dasselbe wie Ausfallsicherheit. Ausfallsicherheit beschreibt, wie selten ein System ausfällt. Resilienz beschreibt, wie gut der Geschäftsbetrieb weiterläuft, wenn es trotzdem passiert. Beides ist wichtig, aber beides löst unterschiedliche Probleme.

Und schließlich ist Prozessresilienz kein Ersatz für klare Prozesse und Dokumentation. Wer im Normalbetrieb nicht weiß, wie seine Prozesse aussehen, wird sie im Störfall erst recht nicht stabil halten können.

Wie Sie Prozessresilienz im eigenen Unternehmen prüfen

Eine Prüfung der eigenen Resilienz muss nicht aufwendig sein. Die folgenden vier Fragen reichen als Einstieg:

• Erstens: Wie lange kann Ihr Unternehmen ohne Internetverbindung produktiv weiterarbeiten, bevor die wichtigsten Prozesse zum Erliegen kommen? Wenn die Antwort "gar nicht" lautet, ist das ein Hinweis auf die technische Dimension.
• Zweitens: Wie schnell lässt sich in Ihrem ERP-System ein neuer Freigabeschritt, eine geänderte Berechnungslogik oder eine zusätzliche Rolle einrichten? Wenn die Antwort "nur mit Entwickler und Projektplan" lautet, spricht das für eine eingeschränkte Anpassungsfähigkeit.
• Drittens: Wen rufen Ihre Key-User an, wenn an einem Freitagnachmittag etwas klemmt, und wie lange dauert die erste fachliche Rückmeldung? Wenn die Antwort unklar oder "kommt drauf an" lautet, ist das ein Warnsignal für die Supportdimension.
• Viertens: Wann haben Sie zuletzt einen ernsthaften Störfall erlebt, und wie ist Ihr Unternehmen damit umgegangen? Nach einer Störung lässt sich Resilienz deutlich besser einschätzen als davor. Wer aus einem Vorfall nichts gelernt hat, verschenkt die wichtigste Chance auf Verbesserung.

Wer auf diese vier Fragen klare Antworten hat, kennt seine Stärken und Schwächen. Wer nicht antworten kann, hat einen guten Anhaltspunkt, wo der nächste Schritt ansetzen sollte.

Fazit: Resilienz entscheidet sich im Störfall, nicht im Normalbetrieb

Prozessresilienz ist kein einzelnes Feature und kein Produkt, das man kauft. Sie ist das Ergebnis aus einer bewussten technischen Aufstellung, einer flexiblen Prozesslogik und einem belastbaren Supportmodell. Kommt eine dieser drei Dimensionen zu kurz, wird die Resilienz im Ernstfall nicht tragen.

TOPIX ist an den drei Punkten anschlussfähig, die diesen Artikel strukturiert haben: mit einem On-Premises-Betrieb, der bei Internetstörungen im Haus weiterarbeitet, mit einer Softwarearchitektur, die schnelle Prozessanpassungen zulässt, und mit einem direkten Herstellersupport, der in akuten Fällen nicht im Ticketsystem verschwindet. Wenn Sie überprüfen möchten, wie stabil Ihre Prozesse heute wirklich aufgestellt sind, kommen wir gerne mit Ihnen ins Gespräch.

FAQ: Antworten auf häufige Fragen zur Prozessresilienz

Was unterscheidet Prozessresilienz von Business Continuity?

Business Continuity ist in der Regel enger gefasst und beschreibt Maßnahmen, die den Geschäftsbetrieb bei konkreten Störfällen aufrechterhalten. Prozessresilienz ist der übergeordnete Begriff und schließt auch die Anpassungsfähigkeit der Prozesse und die menschliche Unterstützungskomponente mit ein. Business Continuity ist damit Teil der Resilienz, aber nicht ihr gesamtes Spektrum.

Ist ein On-Premises-Betrieb bei Internetausfall wirklich autark?

Innerhalb des lokalen Netzwerks ja, solange Server und Arbeitsplätze mit Strom versorgt sind und die interne Infrastruktur läuft. Externe Kommunikation, Zahlungsverkehr und Cloud-basierte Dienste stehen dann zwar still, die eigentliche Arbeit an Aufträgen, Buchungen und Stammdaten läuft aber weiter. Diese innere Autarkie ist der entscheidende Vorteil gegenüber einer reinen Cloud-Lösung.

Wie lässt sich Prozessresilienz messen?

Ein sinnvoller Ansatz sind drei Kennzahlen:

• die maximal tolerierbare Ausfallzeit pro Prozess,
• die tatsächliche Wiederherstellungszeit bei realen Störungen und
• die Anzahl manuell kompensierter Arbeitsschritte pro Monat.

Ergänzend helfen qualitative Fragen zur Anpassungsgeschwindigkeit und zur Supportqualität. Eine einzige Kennzahl bildet Resilienz nicht ab.

Welche Rolle spielen Mitarbeitende für die Resilienz?

Eine entscheidende. Technik kann Prozesse stützen, aber sie entscheidet nicht. Im Störfall sind es Menschen, die die Lage einschätzen, Prioritäten setzen und die richtigen Entscheidungen treffen. Unternehmen, die ihre Mitarbeitenden gut schulen und Verantwortung klar verteilen, sind deutlich resilienter als solche, bei denen im Zweifel alles auf eine Person zurückfällt.

Muss Resilienz immer teuer sein?

Nein. Viele Resilienzgewinne entstehen durch klügere Entscheidungen, nicht durch größere Investitionen. Eine On-Premises-Option wählen, statt den Cloud-Zwang zu akzeptieren, Prozessanpassungen über Konfiguration statt Programmierung ermöglichen, direkten Herstellersupport statt vielstufiger Ticketwege wählen: Jede dieser Entscheidungen kostet nicht zwingend mehr, sie zahlt sich aber im Ernstfall aus.