Digitale Prozesse: Warum jeder Systemwechsel Sie zweimal bezahlen lässt

Die Welle ist keine Prognose mehr

Lünendonk hat für die Studie „IT-Modernisierung zwischen Legacy, Cloud und KI“ Verantwortliche zum Zustand ihrer Anwendungslandschaft befragt. 62% geben an, Teile ihrer geschäftskritischen Anwendungen seien bereits so veraltet, dass sie den heutigen Anforderungen nicht mehr genügen. In jedem zweiten Unternehmen ist der Betrieb dieser Altsysteme mittel- bis langfristig nicht mehr sichergestellt.

Entsprechend planen 83%, ihr Modernisierungsbudget zu erhöhen. Die Frage ist also nicht, ob ausgetauscht wird. Die Frage ist, was dabei verloren geht.

Was ins System gehört, bleibt im System

Eine Klarstellung vorweg, weil dieser Gedanke gern missverstanden wird: Es geht nicht darum, Logik aus Ihren Fachanwendungen herauszuziehen. Was innerhalb einer Anwendung sinnvoll aufgehoben ist, gehört dorthin und bleibt dort. Dafür wurde das System gekauft, dafür ist es gebaut, und niemand sollte es herausoperieren. Ob eine Anwendung abgelöst werden sollte, ist eine ganz eigene Betrachtung und nicht das Thema dieses Textes.

Der Ort ohne Eigentümer ist ein anderer: der leere Raum zwischen den Anwendungen.

Was in diesem leeren Raum liegt

Denken Sie an das, was Ihre Abläufe tatsächlich ausmacht. Nicht die Software — es sind die Regeln, die oft keine Software für sich beansprucht.

Ab welchem Betrag braucht eine Freigabe eine zweite Unterschrift, und wer erteilt sie, wenn der Zuständige im Urlaub ist. Welcher Kunde bekommt abweichende Konditionen und warum. Welche Prüfung entfällt bei Bestandslieferanten. Was passiert, wenn eine Auskunft von außen nicht rechtzeitig eintrifft. Welche drei Sonderfälle es in der Reklamationsbearbeitung gibt, die man nur kennt, wenn man dabei war, als sie entstanden sind.

Diese Logik ist über Jahre gewachsen. Sie ist das Ergebnis von Fehlern, die man einmal gemacht hat, von Kundenwünschen, die sich durchgesetzt haben, und von Entscheidungen, die jemand gut begründet getroffen hat. Sie ist, ökonomisch betrachtet, das Wertvollste an Ihrer Verwaltung.

Und sie liegt nirgends dort, wo man sie wiederfinden würde. Sie steckt in einer Formularvalidierung. In einem Skript, das nachts läuft. In einer Zwischentabelle, die seit sieben Jahren im gleichen Verzeichnis liegt. In Mailverläufen. Und zu einem erheblichen Teil in den Köpfen von drei Personen.

Warum ausgerechnet die gelebte Praxis verlorengeht

Hier ist eine Präzisierung fällig, denn die verbreitete Behauptung, beim Systemwechsel gehe alles verloren, stimmt so nicht. Hersteller liefern Migrationswerkzeuge für das, was in ihrem eigenen Standard vorgesehen ist. Konfigurationen, Stammdaten, Formulare — vieles davon wird übernommen oder maschinell überführt. Wer etwas anderes behauptet, war nie in einem solchen Projekt.

Was diese Werkzeuge nicht mitnehmen können, ist alles, was zwischen zwei Systemen liegt. Der Grund ist einfach: Dieser Teil hat keinen Hersteller, der sich um seine Migration kümmert. Er gehört keinem Produkt an, steht in keiner Systemdokumentation und taucht in keinem Migrationsleitfaden auf. Er existiert als gelebte Praxis — und gelebte Praxis lässt sich nicht exportieren.

Warum diese Kosten nie jemand sieht

Der entscheidende Punkt ist nicht, dass diese Logik neu gebaut werden muss. Der entscheidende Punkt ist, dass niemand es als eigene Position wahrnimmt.

Im Projekt heißt es „Konzeption“, „Fachkonzept“, „Anpassungen“. Es taucht nie auf als das, was es ist: der Wiederkauf einer Sache, die Sie bereits besessen haben. Ihre Geschäftslogik hat keinen Posten in der Bilanz, keinen Abschreibungszeitraum und meistens auch keinen Verantwortlichen. Sie ist ein Nebenprodukt von Projekten — und Nebenprodukte werden nicht inventarisiert.

Dazu kommt ein zweiter Effekt. Bei der Neuimplementierung sitzen Berater am Tisch, die den Ablauf nicht kennen, und Mitarbeiter, die ihn kennen, aber gerade wenig Zeit haben. Was dabei herauskommt, ist selten die alte Logik. Es ist eine Näherung — meistens die Standardvorlage des neuen Systems, ergänzt um das, was in den Workshops zufällig zur Sprache kam. Die drei Sonderfälle in der Reklamationsbearbeitung fallen dabei regelmäßig hinten runter und werden anschließend zwei Jahre lang als „Kinderkrankheiten“ nachgezogen.

Der Klebstoff braucht einen eigenen Ort

Ein systemübergreifender Ablauf ist ein eigenständiger Gegenstand. Er gehört in keine der beteiligten Anwendungen, sondern über sie — als Klebstoff, der die Systeme verbindet, ohne ihnen ihre Aufgabe wegzunehmen.

Konkret: Der Ablauf wird in BPMN modelliert, die Entscheidungsregeln in DMN — beides offene, dokumentierte Standards. Die Fachanwendungen werden über Adapter angebunden und tun weiterhin genau das, wofür sie gebaut wurden. Der Prozess entscheidet nur, in welcher Reihenfolge welches System gefragt wird, wer was freigeben muss und was im Ausnahmefall geschieht.

Die Fähigkeit zu orchestrieren ist damit keine Option unter mehreren. Sie ist die Voraussetzung dafür, dass eine gemischte Landschaft überhaupt beherrschbar bleibt.

Für die Verantwortlichen der einzelnen Systeme bedeutet das keine Konkurrenz, sondern Entlastung: Was heute als Eigenentwicklung oder Zwischenlösung neben dem Standard mitgeschleppt wird, wandert an einen Ort, an dem es sichtbar, dokumentiert und wartbar ist — und muss beim nächsten Release nicht mehr angefasst werden.

Wie portabel offene Standards wirklich sind

An dieser Stelle wird häufig zu viel versprochen, deshalb die ehrliche Fassung:

Portabel ist die Fachlichkeit. Ein BPMN-Modell und eine DMN-Entscheidungstabelle sind lesbare, dokumentierte Artefakte. Wer sie öffnet, sieht die Reihenfolge der Schritte, die Verzweigungen, die Schwellenwerte und die Zuständigkeiten — unabhängig davon, wer die Engine gebaut hat. Das ist die Substanz Ihrer Abläufe, und sie gehört Ihnen in einer Form, die man mitnehmen kann.

Die Verkabelung kann Anpassung brauchen. Wer bei den Standards bleibt, nimmt auch sie zu großen Teilen mit. Wo das Zielsystem anders aussieht — eine Schnittstelle erwartet andere Felder, ein Dienst antwortet anders —, wird nachgezogen. Das ist ehrlicherweise Arbeit, und wir nennen sie lieber hier als im dritten Projektmonat.

Entscheidend ist aber die Art dieser Arbeit. Ein Adapter hat ein Parameter-Set und eine Funktion. Er lässt sich isoliert entwickeln, isoliert testen und einzeln austauschen, ohne dass jemand den Ablauf anfasst. Das ist eine überschaubare, abgrenzbare Aufgabe für die IT — und eine, die sie hundertmal gemacht hat.

Genau darin liegt der Unterschied zu Logik, die in einer Anwendung vergraben ist. Dort ist die Fachlichkeit an eine Technik gebunden und ohne sie nicht lesbar. Um sie wiederherzustellen, müssen Fachbereich und IT gemeinsam rekonstruieren, was niemand mehr vollständig weiß — ein Aufwand, den man vorher nicht beziffern kann und der nie ganz fertig wird.

Im Prozessmodell steht die Fachlichkeit fest. Was bleibt, ist Technik: bekannt, planbar, testbar. Das ist nicht „kein Aufwand“. Es ist die Sorte Aufwand, die man kalkulieren kann.

Fünf Anforderungen an eine Plattform, die das leisten soll

Diese fünf Punkte sind aus unserer Sicht nicht verhandelbar. Sie taugen gleichzeitig als Prüfliste für jedes Angebot, das Ihnen vorgelegt wird.

1. Vollständige Protokollierung auf Prozessebene. Welcher Schritt lief wann, mit welchem Ergebnis, aufgrund welcher Regel. Das ist die Grundlage für Nachvollziehbarkeit im Betrieb — und beim Systemwechsel die einzige verlässliche Beschreibung dessen, was Ihr Ablauf tatsächlich tut.
2. Ablauf und Regel müssen getrennt sein. Der Prozess beschreibt die Reihenfolge, die Entscheidungstabelle die Bedingungen. Nur so lässt sich eine Freigabegrenze von 5.000 auf 7.500 Euro ändern, ohne dass jemand Software anfasst und ein Release plant.
3. Systemübergreifende Abläufe gehören in kein einzelnes Fachsystem. Was innerhalb einer Anwendung bleibt, ist dort richtig. Sobald ein Ablauf aber mehrere Systeme berührt und trotzdem in einem davon abgelegt wird, ist er beim nächsten Wechsel gebunden — und die anderen Beteiligten sehen ihn ohnehin nicht.
4. Offene Standards, keine proprietäre Notation. BPMN und DMN sind lesbar, dokumentiert und werkzeugübergreifend. Ein Modell in einem herstellereigenen Format ist eine neue Abhängigkeit, nur eine Etage höher.
5. Versionierung mit parallelem Betrieb. Ändert sich eine Regel, müssen laufende Vorgänge nach der alten Fassung zu Ende gehen und neue nach der neuen starten. Ohne das ist jede Änderung ein Risiko, und deshalb wird sie nicht gemacht.

Der Selbsttest: Könnten Sie Ihren wichtigsten systemübergreifenden Ablauf auf einer frischen Installation in Betrieb nehmen, ohne dass jemand aus dem Gedächtnis nacharbeiten müsste?

Wenn die Antwort nein lautet, gehört Ihnen Ihre Geschäftslogik derzeit nur eingeschränkt. Sie besitzen dann nicht das Verfahren, sondern nur dessen aktuelle Ausprägung in Systemen, die irgendwann abgelöst werden.

Wer darf Regeln ändern, und wer merkt es

Punkt eins der Liste klingt nach Freiheit für den Fachbereich, und genau deshalb gehört die Kehrseite dazu.

Wenn eine Freigabegrenze ohne Release änderbar ist, muss geregelt sein, wer sie ändern darf. In der Praxis bedeutet das: Entscheidungstabellen bekommen dieselbe Behandlung wie andere kritische Stammdaten. Änderungen sind an Rollen gebunden, sie werden versioniert, und jede Änderung ist im Protokoll sichtbar — mit Zeitpunkt, altem und neuem Wert.

Das ist mehr Kontrolle als heute, nicht weniger. Denn wenn dieselbe Grenze in einer Formularvalidierung steckt, ändert sie jemand aus der IT im Rahmen eines Tickets, und in der Fachabteilung merkt es niemand. Sichtbarkeit entsteht erst dadurch, dass die Regel an einem benannten Ort steht.

Wenn die Prozessebene ausfällt

Ein berechtigter Einwand aus dem IT-Betrieb: Wenn diese Ebene über allem liegt, ist sie ein kritisches System. Fällt sie aus, steht nicht ein Ablauf, sondern jeder, der über sie läuft.

Das stimmt, und man sollte es nicht kleinreden. Zwei Dinge relativieren es.

Erstens läuft eine Prozess-Engine technisch unspektakulär: Sie braucht keine Container-Plattform, keinen Cluster und kein eigenes Betriebsteam. Auf einer ordentlich gesicherten virtuellen Maschine mit Ihren üblichen Verfahren für Sicherung und Wiederanlauf ist sie kein Sonderfall in Ihrer Landschaft.

Zweitens sind laufende Vorgänge persistiert. Ein Ausfall bedeutet Stillstand, keinen Datenverlust — nach dem Wiederanlauf setzen die Vorgänge dort fort, wo sie standen. Das ist ein anderes Risiko als bei einem verteilten Geflecht aus Mails und Tabellen, bei dem im Zweifel niemand sagen kann, wo etwas stand. Wer diese Verantwortung nicht ins eigene Haus nehmen will, betreibt die Ebene bei uns oder bei einem Dienstleister seiner Wahl. Auch das ist eine Entscheidung, keine Vorgabe.

Was das beim nächsten Systemwechsel bedeutet

Der Unterschied zeigt sich beim übernächsten Projekt, nicht beim ersten. Liegt die Logik im Prozessmodell, schrumpft eine Ablösung von einer Neuimplementierung auf einen Anbindungsvorgang. Der Adapter zur alten Anwendung wird durch den zur neuen ersetzt. Das Modell bleibt, die Regeln bleiben, die Sonderfälle bleiben. Beide Systeme lassen sich sogar eine Zeit lang parallel betreiben, weil der Prozess weiß, welchen Vorgang er wohin schickt — was Umstellungen erheblich entspannt.

Bemerkenswert ist, was die befragten Unternehmen selbst von einer vollständigen Neuentwicklung halten: Nur 47% sehen darin überhaupt einen gangbaren Weg. Die große Mehrheit setzt auf modulare Architekturen und darauf, Bestehendes weiterzuverwenden. Das funktioniert aber nur, wenn es eine Ebene gibt, die über den Modulen liegt und sie zusammenhält.

Der beste Einstiegspunkt ist ein System, das ohnehin geht

Wir haben die Technik dafür im Haus — Prozess- und Regel-Engines auf offenen Standards, die Anbindung an Ihre Bestandssysteme, Betrieb wahlweise bei uns oder in Ihrem Rechenzentrum und den fachlichen Support, der einen Ablauf über Jahre stabil hält.

Der pragmatische Anfang ist kein großes Vorhaben, sondern eine Terminfrage: Nehmen Sie einen Ablauf, der über eine Anwendung läuft, die Sie in den nächsten drei Jahren ohnehin ablösen werden. Dort ist die Rechnung am einfachsten, weil die Alternative — dieselbe Logik ein weiteres Mal implementieren zu lassen — bereits in Ihrer Planung steht.

Und falls die Ablösung verschoben wird oder ausfällt: Der Ablauf läuft trotzdem, ist trotzdem messbar und trotzdem ohne Release änderbar. Sie haben dann kein Argument weniger, sondern nur einen Anlass weniger.

Ein Gespräch reicht, um diesen Ablauf zu identifizieren. Danach wissen Sie, was Ihre Geschäftslogik wert ist. Und Sie besitzen sie zum ersten Mal wirklich.