WEBCON: Warum Integrationen über den Erfolg der Prozessautomatisierung entscheiden

Prozessautomatisierung findet in Unternehmen selten innerhalb eines einzigen Systems statt. ERP, CRM, DMS, Collaboration-Plattformen, Fachanwendungen, Datenbanken und individuell entwickelte Lösungen bilden gemeinsam die IT-Landschaft, in der Geschäftsprozesse tatsächlich ablaufen.

Eine Prozessanwendung kann deshalb noch so gut gestaltet sein: Wenn sie nicht zuverlässig auf die benötigten Informationen zugreifen und Ergebnisse an andere Systeme zurückgeben kann, entstehen Medienbrüche, manuelle Übertragungen und zusätzliche Fehlerquellen.

Integrationen sind damit keine technische Ergänzung der Prozessautomatisierung. Sie sind eine ihrer grundlegenden Voraussetzungen.

Entscheidend ist allerdings nicht nur, ob Systeme miteinander verbunden werden können. Mindestens genauso wichtig ist die Frage, wie diese Verbindungen aufgebaut, betrieben, wiederverwendet und langfristig gewartet werden.

Prozesse verlaufen über Systemgrenzen hinweg

Die meisten Unternehmenssysteme erfüllen klar definierte Aufgaben.

Ein ERP-System verwaltet beispielsweise Transaktionen und Stammdaten. Ein CRM-System bündelt Kundeninformationen. Ein Dokumentenmanagementsystem sorgt für die strukturierte Ablage von Dokumenten. Weitere Fachsysteme unterstützen spezialisierte betriebliche Aufgaben.

Geschäftsprozesse halten sich jedoch nicht an diese Systemgrenzen.

Informationen müssen abgerufen, ergänzt, geprüft, freigegeben, weitergegeben und anschließend wieder in führende Systeme zurückgeschrieben werden. Dabei entstehen Abhängigkeiten zwischen Anwendungen, Organisationseinheiten und Datenquellen.

Aus Sicht der Prozessautomatisierung entsteht deshalb eine zentrale Anforderung:

Der Prozess muss unterschiedliche Systeme miteinander verbinden können, ohne deren jeweilige Aufgaben unnötig zu übernehmen.

Das bedeutet auch, dass Daten nicht zwangsläufig in eine Prozessplattform kopiert und dort dauerhaft gespeichert werden müssen. Häufig ist es sinnvoller, Informationen dort zu belassen, wo sie fachlich geführt werden, und sie im jeweiligen Prozesskontext bereitzustellen.

Eine moderne Prozessplattform wird damit zu einer verbindenden Ebene innerhalb der bestehenden IT-Architektur.

Warum Integrationen schnell komplex werden

Auf den ersten Blick klingt eine Systemintegration einfach: Daten werden aus System A gelesen und an System B übergeben.

In der Realität gibt es jedoch kaum zwei identische Integrationsszenarien.

Moderne Anwendungen stellen REST-APIs zur Verfügung. Andere Systeme verwenden SOAP-Webservices. Bei älteren Anwendungen erfolgt der Zugriff möglicherweise über Datenbanken oder andere proprietäre Schnittstellen.

Hinzu kommen unterschiedliche Authentifizierungsverfahren, Datenmodelle, Berechtigungen, Versionen und Betriebsumgebungen.

Die eigentliche Herausforderung entsteht deshalb häufig nicht bei der ersten technischen Verbindung, sondern während ihres gesamten Lebenszyklus.

Eine Integration muss:

• sicher konfiguriert werden,
• unterschiedliche Umgebungen berücksichtigen,
• Änderungen an Quellsystemen verkraften,
• nachvollziehbar dokumentiert sein,
• zentral administriert werden können,
• wiederverwendbar sein,
• und langfristig wartbar bleiben.

Werden Integrationen für jede Prozessanwendung individuell entwickelt, entsteht mit der Zeit ein kaum überschaubares Netz aus Punkt-zu-Punkt-Verbindungen.

Das technische Problem wächst dann mit jeder weiteren automatisierten Anwendung.

Von einzelnen Schnittstellen zu einer Integrationsarchitektur

Nachhaltige Prozessautomatisierung benötigt deshalb mehr als die Fähigkeit, eine API aufzurufen.

Sie benötigt eine Integrationsarchitektur.

Der Unterschied liegt vor allem in der Wiederverwendbarkeit.

Wenn dieselbe Verbindung zu einem ERP-System für mehrere Prozessanwendungen benötigt wird, sollte sie nicht jedes Mal neu entwickelt werden. Datenquellen, Authentifizierung und technische Konfiguration sollten zentral definiert und anschließend innerhalb unterschiedlicher Anwendungen verwendet werden können.

Dadurch verändert sich die Skalierung grundlegend.

Statt:

Anwendung → individuelle Integration → System

entsteht eine gemeinsame Integrationsschicht, über die mehrere Prozessanwendungen mit den vorhandenen Unternehmenssystemen kommunizieren können.

Damit werden Integrationen nicht nur schneller umsetzbar. Sie lassen sich auch wesentlich besser verwalten.

Integration als Bestandteil der Prozessplattform

WEBCON verfolgt diesen Ansatz über eine native Integrationsschicht innerhalb der Plattform.

Die Verbindung externer Systeme wird damit nicht als vollständig getrenntes Integrationsprojekt betrachtet, sondern als Bestandteil einer Prozessanwendung.

Innerhalb von WEBCON können Datenquellen und Verbindungen zentral konfiguriert und anschließend innerhalb unterschiedlicher Workflows genutzt werden.

Unterstützt werden unter anderem klassische Datenbankverbindungen sowie REST- und SOAP-Webservices, Active Directory, SharePoint und verschiedene Geschäftssysteme.

Entscheidend ist dabei weniger die Anzahl einzelner Konnektoren als das zugrunde liegende Prinzip:

Prozesslogik und Integrationslogik bleiben miteinander verbunden, ohne dass jede Schnittstelle individuell programmiert werden muss.

Dadurch können auch Power User und Prozessentwickler Integrationen innerhalb eines kontrollierten Rahmens konfigurieren, während die IT weiterhin Standards für Sicherheit, Governance und Architektur vorgeben kann.

Low-Code bedeutet nicht No-Governance

Gerade bei Integrationen ist Self-Service ein sensibles Thema.

Auf der einen Seite sollen Fachbereiche und Process Owner nicht für jede kleinere Anpassung auf klassische Entwicklungsprojekte angewiesen sein.

Auf der anderen Seite kann ein unkontrollierter Zugriff auf produktive Systeme schnell zu Sicherheits-, Datenqualitäts- oder Wartungsproblemen führen.

Eine geeignete Low-Code-Plattform muss deshalb beide Anforderungen miteinander verbinden:

mehr Eigenständigkeit bei der Prozessentwicklung und gleichzeitig zentrale Kontrolle über die technische Infrastruktur.

Das ist insbesondere bei größeren Automatisierungsinitiativen entscheidend.

Wenn zehn, fünfzig oder hundert Anwendungen entstehen, reicht es nicht mehr aus, jede Integration individuell abzustimmen. Schnittstellen müssen standardisiert, dokumentiert und wiederverwendbar sein.

Low-Code reduziert damit nicht die Bedeutung von IT-Governance. Im Gegenteil: Je einfacher Anwendungen erstellt werden können, desto wichtiger wird eine gemeinsame technische Grundlage.

Entwicklungs-, Test- und Produktivumgebungen richtig trennen

Ein häufig unterschätzter Bestandteil der Integrationsarchitektur ist das Environment Management.

Prozessanwendungen werden normalerweise nicht direkt in der Produktivumgebung entwickelt. Sie durchlaufen Entwicklungs-, Test- und anschließend Produktivsysteme.

Für Integrationen bedeutet das:

Eine Anwendung in der Entwicklungsumgebung sollte mit Testsystemen kommunizieren. Erst nach dem Deployment in die Produktivumgebung darf sie auf produktive Datenquellen zugreifen.

Werden diese Zuordnungen manuell verwaltet, entstehen zusätzliche Arbeitsschritte und Fehlerquellen.

WEBCON ermöglicht es, Datenquellen den jeweiligen Umgebungen zuzuordnen. Beim Transport einer Anwendung zwischen Entwicklungs-, Test- und Produktivumgebung können dadurch die passenden Verbindungen verwendet werden, ohne dass die Integrationslogik jedes Mal neu aufgebaut werden muss.

Das klingt zunächst nach einem technischen Detail.

Bei einer wachsenden Anzahl von Anwendungen ist es jedoch eine wichtige Voraussetzung für stabile Deployments und reproduzierbare Prozesse.

Unterschiedliche Backend-Systeme, einheitliche Prozesse

Noch komplexer wird die Situation bei international tätigen Unternehmen oder Organisationen mit mehreren Tochtergesellschaften.

Nicht jede Geschäftseinheit verwendet zwangsläufig dieselben Systeme.

Während ein Standort mit SAP arbeitet, nutzt ein anderer möglicherweise Microsoft Dynamics oder ein individuell entwickeltes ERP-System.

Trotzdem soll derselbe Geschäftsprozess möglicherweise unternehmensweit eingesetzt werden.

Eine skalierbare Prozessarchitektur sollte deshalb nicht voraussetzen, dass alle Organisationseinheiten dieselbe IT-Landschaft besitzen.

Stattdessen kann dieselbe Prozesslogik abhängig vom organisatorischen Kontext mit unterschiedlichen Backend-Systemen kommunizieren.

Für Anwender bleibt die Prozessanwendung dadurch weitgehend einheitlich, während die Integrationsschicht im Hintergrund berücksichtigt, welches System für die jeweilige Organisationseinheit relevant ist.

Gerade für international standardisierte Prozesse ist diese Trennung zwischen Prozesslogik und Systemlandschaft von großer Bedeutung.

Integrationen müssen in beide Richtungen funktionieren

Bei Integrationen wird häufig zunächst daran gedacht, dass eine Prozessanwendung Daten aus bestehenden Systemen abruft.

In modernen Architekturen ist jedoch auch die Gegenrichtung wichtig.

Externe Anwendungen müssen Prozesse starten, Informationen aktualisieren oder auf Prozessdaten zugreifen können.

Eine Prozessplattform sollte deshalb nicht nur fremde APIs konsumieren können, sondern auch standardisierte Schnittstellen nach außen bereitstellen.

In WEBCON steht dafür unter anderem die User Defined API zur Verfügung. Damit können eigene API-Endpunkte innerhalb der Plattform definiert werden, über die externe Systeme mit Prozessanwendungen interagieren können.

Dadurch wird die Prozessplattform nicht nur zum Verbraucher von Unternehmensdaten, sondern selbst zu einem Bestandteil der API-Landschaft.

Das ist besonders relevant, wenn Prozesse zukünftig stärker ereignisgesteuert oder systemübergreifend orchestriert werden sollen.

Die Rolle einer Prozessplattform zwischen bestehenden Systemen

Eine Prozessplattform sollte bestehende Kernsysteme nicht ersetzen, nur um Prozesse automatisieren zu können.

ERP-, CRM- oder Fachsysteme erfüllen weiterhin die Aufgaben, für die sie entwickelt wurden.

Eine Prozessplattform kann stattdessen die Abläufe organisieren, die zwischen diesen Systemen entstehen:

• Genehmigungen,
• Ausnahmebehandlungen,
• bereichsübergreifende Workflows,
• dokumentenintensive Abläufe,
• Koordination verschiedener Beteiligter,
• Aufgaben und Eskalationen,
• sowie die Weitergabe von Informationen zwischen Systemen.

Damit entsteht eine klare Aufgabenverteilung.

Die Kernsysteme verwalten die fachlich führenden Daten. Die Prozessplattform steuert den Ablauf zwischen Menschen, Daten und Systemen.

Diese Architektur reduziert den Druck, für jede neue Prozessanforderung umfangreiche Anpassungen am ERP- oder Kernsystem vornehmen zu müssen.

Wiederverwendbarkeit entscheidet über die Skalierbarkeit

Die erste Prozessautomatisierung funktioniert häufig auch mit individuell entwickelten Schnittstellen.

Die wirkliche Architekturqualität zeigt sich erst später.

Was passiert beim zehnten Prozess?

Oder beim fünfzigsten?

Müssen Datenquellen, Authentifizierungen und Schnittstellen erneut eingerichtet werden, wächst der Aufwand nahezu proportional mit jeder neuen Anwendung.

Können bestehende Integrationen dagegen wiederverwendet werden, entsteht ein anderer Effekt: Jede bereits geschaffene Verbindung erweitert die technische Grundlage für zukünftige Prozesse.

Aus einer Sammlung einzelner Anwendungen entwickelt sich schrittweise eine gemeinsame Prozessarchitektur.

Dieser Unterschied ist entscheidend, wenn Prozessautomatisierung nicht als Einzelprojekt, sondern als langfristige Unternehmensstrategie verstanden wird.

Integration ist auch ein Governance-Thema

Technische Konnektivität allein reicht nicht aus.

Mit zunehmender Anzahl von Systemen und Prozessanwendungen stellen sich weitere Fragen:

Wer darf neue Datenquellen konfigurieren?

Welche Anwendungen greifen auf welche Systeme zu?

Wie werden Änderungen an Schnittstellen dokumentiert?

Welche Integrationen sind unternehmenskritisch?

Wie werden Authentifizierungen und Zugriffsrechte verwaltet?

Und wie lässt sich verhindern, dass verschiedene Teams dieselbe Verbindung mehrfach und unterschiedlich implementieren?

Integrationsarchitektur und Governance gehören deshalb unmittelbar zusammen.

Eine zentrale Plattform kann dabei helfen, wiederkehrende technische Aufgaben zu standardisieren und gleichzeitig klare Verantwortlichkeiten festzulegen.

Das Ziel sollte nicht sein, jede Integration zentral durch die IT entwickeln zu lassen.

Ebenso wenig sollte jeder Fachbereich beliebige Schnittstellen unabhängig aufbauen.

Die sinnvollste Architektur liegt häufig dazwischen: zentrale Standards und Governance, kombiniert mit kontrolliertem Self-Service.

Von Punkt-zu-Punkt-Verbindungen zum vernetzten IT-Ökosystem

Je mehr Prozesse digitalisiert werden, desto deutlicher zeigt sich, dass Integrationen keine Nebensache der Prozessautomatisierung sind.

Eine einzelne Schnittstelle kann kurzfristig ein konkretes Problem lösen. Eine gute Integrationsarchitektur schafft dagegen eine Grundlage, auf der viele weitere Prozessanwendungen aufgebaut werden können.

Dabei geht es nicht darum, sämtliche Unternehmenssysteme in einer einzigen Plattform zusammenzuführen.

Es geht darum, ihre jeweiligen Stärken zu nutzen und die notwendigen Informationen im richtigen Prozesskontext verfügbar zu machen.

Eine nachhaltige Architektur trennt deshalb bewusst:

Wo werden Daten fachlich geführt?

Wo werden Transaktionen verarbeitet?

Wo wird der Geschäftsprozess gesteuert?

Und wie kommunizieren diese Ebenen miteinander?

Wenn diese Fragen frühzeitig beantwortet werden, entsteht Prozessautomatisierung nicht als Sammlung isolierter Anwendungen, sondern als Teil eines vernetzten IT-Ökosystems.

Genau darin liegt die strategische Bedeutung von Integrationen: Sie verbinden nicht nur Systeme. Sie bestimmen, wie gut Prozessautomatisierung langfristig wachsen und sich weiterentwickeln kann.