Anfang 2026 erklärte Anthropic CEO Dario Amodei auf dem Weltwirtschaftsforum in Davos, dass KI innerhalb von sechs bis zwölf Monaten den Großteil der Aufgaben in der Softwareentwicklung übernehmen könnte [1]. Die Tech Branche reagierte prompt. Einige erklärten den Beruf bereits für überholt. Andere hielten die Aussage für einen PR-Schachzug, um die Bewertungen von KI Unternehmen in die Höhe zu treiben.

Die Marktunsicherheit ist angesichts der aktuellen Zahlen nachvollziehbar. Bis Mitte 2025 hatte GitHub Copilot 20 Millionen Abonnenten [2], und fast 46 % des gesamten Codes auf der Plattform wurden von KI generiert [3]. Europäische Untersuchungen aus dem Jahr 2025 zeigten einen Rückgang der Stellenausschreibungen für Junior Entwickler um 73 % gegenüber dem Vorjahr [4]. Diese Zahlen wirken ernüchternd. Gleichzeitig prognostiziert das US Bureau of Labor Statistics bis 2034 ein Beschäftigungswachstum von 15 % in der Softwareentwicklung [5]. Nur selten werden diese beiden Entwicklungen gegenübergestellt.
Die Geschichte folgt einem Muster
Wir waren schon einmal an diesem Punkt. Die aktuelle Diskussion geht in die falsche Richtung. Erinnern Sie sich daran, wie Geoffrey Hinton, Nobelpreisträger und einer der Pioniere neuronaler Netze, vorhersagte, dass die KI Radiologen vollständig ersetzen würde? Das Gegenteil trat ein. Die Technologie verbesserte die Diagnostik und die Nachfrage nach Radiologen stieg. Ein ähnliches Muster zeigte sich bei der Automatisierung von Produktionslinien, der breiten Einführung des Internets und dem Aufstieg des Cloud Computing.
Jede bisherige Automatisierungswelle in der IT hat die Nachfrage nach Fachkräften erhöht. IDEs und Compiler beschleunigten in den 1980er Jahren die Programmierung erheblich. Unternehmen entwickelten daraufhin mehr Systeme und stellten mehr Mitarbeiter ein. Die Zahl der Entwickler stieg. AWS und die Cloud reduzierten ab 2006 den Kapitalbedarf und den operativen Aufwand und öffneten den Markt für Tausende Start Ups, die sich zuvor keine eigene Infrastruktur leisten konnten. Wieder wurden mehr Entwickler gebraucht. Stack Overflow ermöglichte ab 2008 einen direkten Zugang zu Wissen und senkte die Einstiegshürden. Im gesamten folgenden Jahrzehnt wuchs die Beschäftigung in der IT schneller als in jedem anderen Sektor.
Vibe Coding ist längst nicht mehr nur für Start ups interessant
Wir stehen erneut an einem Wendepunkt. Vibe Coding gewinnt an Bedeutung: Anwendungen entstehen im natürlichen Dialog mit KI, statt Code auf traditionelle Weise zu schreiben. Andrej Karpathy, Mitgründer von OpenAI, beschrieb es als eine Form des Programmierens, bei der man den Code selbst ausblendet und sich nur auf das gewünschte Ergebnis konzentriert. Für kleine Projekte, junge Unternehmen und Prototyping funktioniert dieser Ansatz gut. Daten von Y Combinator zeigen, dass etwa ein Viertel der Start Ups aus jüngeren Jahrgängen ihre Produkte inzwischen überwiegend mit KI generiertem Code entwickelt.
Warum also nicht denselben Ansatz in einem großen, etablierten Unternehmen nutzen und die Entwicklung radikal beschleunigen? Genau hier liegt die Falle. Ein Start up, das Chaos in seiner Codebasis verursacht, zahlt den Preis sofort: Es entwickelt das Produkt neu oder verschwindet vom Markt. Ein Konzern bekommt dieselbe Rechnung deutlich später und mit hohen Zinsen. Die IT Architektur eines großen Unternehmens ist ein dichtes Geflecht aus Systemen, Tausenden Integrationen und über Jahre gewachsenen Geschäftsprozessen. Jede Änderung wirkt sich unmittelbar auf Betriebskontinuität, Sicherheit und regulatorische Compliance aus. In einem solchen Umfeld muss Code verständlich, überprüfbar und mit klaren Standards vereinbar sein.
Unternehmen, die Vibe Coding allzu sorglos einsetzen, riskieren eine technologische Falle: Entwicklungsdisziplin wird mit dem kurzsichtigen Argument aufgegeben, dass die generierte Anwendung schließlich funktioniert und geschäftlichen Nutzen liefert. Generative Tools sind inzwischen so beeindruckend, dass leicht der Eindruck entsteht, sie seien vollständig autonom und unfehlbar. Doch KI Modelle können architektonische Ordnung oder die Sicherheit eines gesamten Ökosystems noch nicht eigenständig gewährleisten. Menschen müssen diese Grenzen weiterhin definieren und durchsetzen. Paradoxerweise entwickelt sich Vibe Coding, das als Lösung für Technical Debt vermarktet wird, zu einem seiner größten Beschleuniger.
Konkrete Daten stützen diese Entwicklung. GitClear analysierte mehr als 211 Millionen Codezeilen in Unternehmensrepositories und stellte bei Projekten mit intensiver KI-Unterstützung eine Vervierfachung von Code Duplikaten fest. Harness kam im State of Software Delivery 2025 zu dem Ergebnis, dass 67 % der Entwickler inzwischen mehr Zeit mit dem Debugging und der Korrektur von KI generiertem Code verbringen als mit dem Schreiben traditionellen Codes [6]. Ox Security untersuchte 300 Open Source Projekte und identifizierte schwerwiegende Sicherheitslücken und strukturelle Schwächen in Code, der von LLM Modellen erzeugt wurde.
Unter diesen Bedingungen ist der Weg von der begeisterten Aussage, KI verdreifache die Entwicklungsgeschwindigkeit, hin zu einer Situation, in der kein neues Feature mehr veröffentlicht werden kann, weil niemand die internen Systeme versteht, erstaunlich kurz. Technical Debt ist zunächst kaum sichtbar. Er wächst im Hintergrund, denn generierter Code sieht korrekt aus: Er lässt sich kompilieren und besteht Tests. Die Krise beginnt, wenn niemand im Unternehmen mehr eine grundlegende Frage beantworten kann: Warum verhält sich dieses System so, wie es sich verhält?
KI braucht Strukturen, um echten Mehrwert zu schaffen
Gartner prognostiziert, dass bis Ende dieses Jahres bis zu 40 % der Unternehmensanwendungen autonome KI-Agenten enthalten könnten. Der GenAI Divide Report des MIT weist gleichzeitig auf ein konkretes Problem hin: Viele Unternehmen haben weiterhin Schwierigkeiten, mit generativen KI-Projekten messbaren geschäftlichen Mehrwert zu erzielen. Die Ausgaben steigen, während der ROI unklar bleibt.
Der Grund liegt häufig in einer unzureichenden Konzeption der Implementierung. Viele KI-Anwendungen laufen isoliert von strategischen Prozessen und dem operativen Tagesgeschäft. Unternehmen testen und betreiben Agenten in abgeschlossenen Umgebungen, weil ihnen die Werkzeuge fehlen, um diese über das gesamte Ökosystem hinweg zu orchestrieren. Es fehlen Lösungen, die Modellen vollständiges Prozesswissen, geschäftlichen Kontext und Zugriff auf historische Daten geben. Ein KI-Agent kann eine einzelne Aufgabe automatisieren oder an einem bestimmten Punkt eine Entscheidung treffen, doch ihm fehlt das Gesamtbild. Unternehmen sind komplexe Systeme, in denen die Veränderung eines Prozesses Auswirkungen auf andere hat. Wenn KI nicht im gesamten Prozesslebenszyklus des Unternehmens verankert ist, Abhängigkeiten nicht berücksichtigt und nicht skalierbar mit anderen Systemen zusammenarbeitet, entstehen operative Risiken statt Optimierung.
Dasselbe Problem betrifft KI generierten Code. GenAI Tools erzeugen Logik, ohne die übergeordnete Softwarearchitektur zu verstehen. Kurzfristige Beschleunigung kann dadurch langfristige Wartungsprobleme verursachen. Um es klar zu sagen: Ich befürworte den Einsatz von KI in der Entwicklung. Damit die KI Entwickler jedoch tatsächlich unterstützt und nicht zusätzlichen Technical Debt verursacht, braucht es klare Rahmenbedingungen, Tools und Methoden. Gleichzeitig müssen neue Kompetenzen im Software Engineering aufgebaut werden. Und damit kommen wir wieder zum Menschen.
Ein Beruf, neue Rollen
Wird die KI Entwickler also überflüssig machen? Nein. Software Engineering umfasst ein breites Spektrum. Auf der einen Seite stehen rein repetitive, ausführende Aufgaben, bei denen Geschäftsanforderungen mechanisch in Code Syntax übersetzt werden. Auf der anderen Seite stehen analytisches, architektonisches und systemisches Denken. KI übernimmt bereits zunehmend Aufgaben am ersten Ende dieses Spektrums und entwickelt sich am anderen Ende zu einem leistungsfähigen Werkzeug. Boris Cherny, Entwickler von Claude Code, geht davon aus, dass die traditionelle Rolle des „Software Engineers" zunehmend im Konzept des „Builders" aufgehen wird. Gleichzeitig betont er, dass fundiertes Engineering Wissen weiterhin die entscheidende Grundlage bleibt [7].
In Gesprächen über technologische Herausforderungen mit Führungskräften großer Unternehmen fallen immer wieder drei Begriffe: Zeit, Kompetenzen und zunehmende Komplexität. Der Druck, schnell auf Marktveränderungen reagieren zu können, ist enorm, während IT-Ökosysteme immer komplexer werden. Unternehmen brauchen Menschen, die diese Komplexität beherrschen können. KI hat die Hürde für das Schreiben von Code drastisch gesenkt. Gleichzeitig hat sie die Anforderungen an das Denken in zusammenhängenden Systemen deutlich erhöht.
Diese Verschiebung ist bereits auf dem Arbeitsmarkt sichtbar. Eine BairesDev Studie von Ende 2025 unter erfahrenen IT-Fachkräften ergab, dass 65 % davon ausgehen, dass KI ihre Rolle neu definieren wird. Von diesen erwarten 74 %, dass sich ihre Arbeit vom Schreiben von Code hin zum Design von Lösungen verlagert. 50 % gehen davon aus, dass Strategie und Architektur künftig im Mittelpunkt ihres Arbeitsalltags stehen werden. Gartner prognostiziert, dass bis 2027 80 % der Entwickler und IT-Teams ihre Arbeitsweise verändern müssen [8].
Code zu schreiben ist nicht mehr die wertvollste Fähigkeit in der IT. Entscheidend wird vielmehr, Geschäftsprozesse zu gestalten, Architekturen und Arbeitsstandards für KI Modelle zu definieren, die Code generieren, und die zunehmende technologische Komplexität zu beherrschen. KI wird die Nachfrage nach Entwicklern nicht beseitigen. Sie wird jedoch die Rolle derjenigen deutlich schwächen, die Anforderungen lediglich in Code übersetzen, anstatt Architekturentscheidungen zu treffen. Dario Amodei liegt mit der Richtung richtig. Aber er irrt sich bei der Art der Veränderung.
Dieser Artikel von Michał Potoczek, CEO von WEBCON, wurde ursprünglich am 21. Juni 2026 in Forbes Poland veröffentlicht.
Literaturverzeichnis
[1] fortune.com/2026/01/23/davos-ceo-ai-job-wipeout-projections-world-economic-forum
[2] techcrunch.com/2025/07/30/github-copilot-crosses-20-million-all-time-users
[3] quantumrun.com/consulting/github-copilot-statistics
[4] blog.asktua.ai/junior-developer-crisis
[5] https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
[6] thenewstack.io/more-ai-more-problems-for-software-developers-in-2025
[7] lennysnewsletter.com/p/head-of-claude-code-what-happens
[8] gartner.com/en/newsroom/press-releases/2024-10-03-gartner-says-generative-ai-will-require-80-percent-of-engineering-workforce-to-upskill-through-2027
In internationalen Unternehmen ist die Einführung eines Prozesses über mehrere Länder hinweg selten nur eine technische Aufgabe. Der Workflow mag fertig sein, die Freigaben sind definiert und die Governance steht. Doch in dem Moment, in dem Nutzer die Anwendung öffnen, entscheidet eine Frage über die Akzeptanz: Fühlt sich diese Anwendung so an, als wäre sie für uns gemacht?
Übersetzung bedeutet mehr als nur Wörter auszutauschen. Es geht um Kontext, Verständlichkeit und Vertrauen. Die richtige Formulierung für einen Genehmigungsschritt, eine Beschaffungsanfrage oder einen HR-Workflow kann selten die IT vorgeben. Sie liegt bei den Menschen, die den Prozess jeden Tag nutzen: den lokalen Teams, den Fachbereichen und den Muttersprachlern. Genau hier geht WEBCON beim Thema Mehrsprachigkeit einen anderen Weg.
Übersetzung ist Business-Sache, nicht IT-Sache
Bei vielen Plattformen wird Lokalisierung zu einer technischen Aufgabe. Jemand ohne Französischkenntnisse aktualisiert ein Label, ein Entwickler öffnet eine Konfigurationsdatei, ein Ticket wandert durch die IT. Wochen später erhält das lokale Team schließlich eine Benutzeroberfläche, die möglicherweise immer noch nicht widerspiegelt, wie tatsächlich gearbeitet wird. Dadurch entstehen unnötige Verzögerungen, Abhängigkeiten und Risiken.
WEBCON geht das Thema Mehrsprachigkeit für Anwendungen anders an. Übersetzungen werden im Designer Desk direkt von den Personen gepflegt, die die jeweilige Sprache am besten beherrschen.
Was Fachbereiche im Designer Desk selbst verwalten können:
- Feldnamen und Bezeichnungen
- Beschreibungen von Workflow-Schritten
- Freigabeanweisungen- und Aufgabenbeschreibungen
- Tooltips und kontextbezogene Hilfetexte
- Hinweise in Formularen und Validierungsmeldungen
- E-Mail- und Benachrichtigungsvorlagen
Für keinen dieser Punkte ist die IT erforderlich.
Ein Prozess, mehrere Länder
Stellen Sie sich vor, Ihr deutsches HR-Team hat einen Onboarding-Workflow entwickelt und Ihr Unternehmen eröffnet einen neuen Standort in Polen. Der Prozess selbst soll unverändert bleiben: dieselben Freigaben, dieselben Compliance-Vorgaben und dieselbe Governance. Nur die Sprache und der lokale Kontext müssen angepasst werden.
In einer klassischen Umgebung wird daraus ein eigenes Lokalisierungsprojekt. Mit WEBCON öffnet das polnische Team einfach die Onboarding-Anwendung, ergänzt die Übersetzungen und der Prozess ist einsatzbereit.
Die Anwendungslogik bleibt unverändert, während sich die Benutzeroberfläche an den jeweiligen Markt anpasst.
Muttersprachler sorgen für eine höhere Akzeptanz
Übersetzungen sind Fachwissen. Wer kennt die richtige Formulierung für einen Beschaffungsfreigabeschritt auf Englisch? Nicht die IT, sondern der Beschaffungsverantwortliche in Dublin. Wer weiß, wie HR-Kommunikation auf Französisch formuliert sein sollte? Kein Entwickler, sondern das lokale HR-Team.
Deshalb sollte Mehrsprachigkeit niemals ausschließlich als technisches Merkmal betrachtet werden. Wenn Muttersprachler die Benutzeroberfläche gestalten, gewinnen Nutzer schneller Vertrauen in den Prozess, machen weniger Fehler und die Akzeptanz der IT-Anwendung steigt ganz natürlich.
Dennoch benötigt das Übersetzen von Grund auf Zeit. Selbst offensichtliche Inhalte wie Namen, Feldbezeichnungen oder Schaltflächentexte müssen einzeln bearbeitet werden. Hier kommt KI ins Spiel. Mit WEBCON können Sie einen ersten Übersetzungsentwurf erstellen lassen. Die KI erstellt die erste Version, sodass sich Ihre Fachbereiche auf das konzentrieren können, was ihr Fachwissen erfordert: die prozessspezifische Sprache. Einen Entwurf zu prüfen und anzupassen ist schneller, als eine Übersetzung vollständig neu zu erstellen. So profitieren Sie von der Geschwindigkeit der KI und dem Detailwissen der Menschen, die täglich mit dem jeweiligen Prozess arbeiten.
Governance bleibt zentral, Verantwortung wird lokal
Die eigentliche Stärke von WEBCON liegt in diesem Gleichgewicht. Das Anwendungsmodell bleibt einheitlich - mit einem Satz Geschäftsregeln, einer Governance-Struktur und einer zentralen Quelle der Wahrheit. Gleichzeitig passt sich die Sprache an jeden Markt an.
Die Fachbereiche verantworten die Begriffe, die ihre Kollegen täglich lesen. Prozessverantwortliche und das Center of Excellence können sich gleichzeitig auf Prozesslogik, Architektur und die kontinuierliche Weiterentwicklung konzentrieren, statt Übersetzungstickets zu bearbeiten.
So bleibt das Center of Excellence schlank, während das Anwendungsportfolio weltweit wächst.
Entwickelt für internationale Organisationen
Für Unternehmen, die in mehreren Ländern tätig sind, ist Mehrsprachigkeit kein Nice-to-have. Sie entscheidet darüber, ob sich eine Plattform international skalieren lässt oder auf einen einzelnen Markt beschränkt bleibt.
WEBCON macht Lokalisierung zu einem Bestandteil des Geschäftsprozesses. Die richtigen Personen übernehmen die richtigen Aufgaben, die Plattform bleibt zentral gesteuert und die Benutzererfahrung passt sich dem jeweiligen Markt an.
Bereit, Ihre Prozesse global auszurollen? Erleben Sie in einer Live-Demo, wie WEBCON mehrsprachige Anwendungen umsetzt.
Bei der digitalen Transformation geht es nicht nur um Automatisierung. Es geht darum, Prozesse so gut zu verstehen, dass Sie sie gezielt verbessern können. Mit Process Mining erkennen Sie, wo Veränderungen den größten Mehrwert schaffen und wie Sie die Produktivität Ihres Unternehmens steigern können.
Wie lange dauert die Freigabe einer Rechnung in Ihrem Unternehmen? Je nachdem, wen Sie fragen, erhalten Sie wahrscheinlich unterschiedliche Antworten. Die Person, die Ausnahmen bearbeitet, sieht den Prozess anders als das Controlling. Niemand liegt falsch.
Es fehlen schlicht die Daten. Ohne Daten lassen sich Probleme weder belegen noch ihre Auswirkungen quantifizieren oder belastbare Business Cases erstellen. Genau daran scheitern viele Automatisierungsprojekte, bevor sie überhaupt beginnen. WEBCON geht einen anderen Weg: Process Mining ist standardmäßig in jeder Anwendung integriert, sodass die erforderlichen Daten von Anfang an verfügbar sind.
Was Process Mining sichtbar macht
Process Mining analysiert, wie Ihre Geschäftsprozesse tatsächlich ablaufen – auf Basis der Daten, die Ihre Systeme erzeugen. Ereignisprotokolle werden zu einem vollständigen Bild des Prozessablaufs zusammengeführt. So erkennen Sie, welche Schritte schnell funktionieren, wo Engpässe entstehen und welche Ausnahmen vom vorgesehenen Ablauf auftreten.
Die vier zentralen Process-Mining-Funktionen laut Gartner
Laut dem Gartner® Magic Quadrant™ für Process Mining Platforms gibt es vier Kernfunktionen, die jede Process-Mining-Lösung bereitstellen sollte.
| Process-Mining-Funktion | Gartner-Anforderung | So erfüllt WEBCON diese Anforderung |
| Extraktion von Ereignisdaten | Verbindung zu Quellsystemen und Extraktion der für die Analyse benötigten Ereignisdaten | ✅ Verarbeitung der Prozessdaten direkt innerhalb der Plattform |
| Prozessmodelle und -analyse | Automatische Erstellung von Prozessmodellen aus den extrahierten Daten, einschließlich Edge Cases | ✅ Automatische Erkennung von Durchlaufzeiten, Engpässen und Ausnahmen |
| Vergleichende Prozessanalyse | Vergleich zwischen tatsächlichem und geplantem Prozessablauf zur Identifikation von Abweichungen | ✅ Vergleich von Ist- und Soll-Prozessen für Prozesse, die auf der Plattform ausgeführt werden |
| Optimierung von Prozessmodellen | Nutzung realer Ausführungsdaten zur kontinuierlichen Verbesserung von Prozessen | ✅ Nutzung realer Ausführungsdaten zur schnellen Optimierung von Prozessen mit InstantChange™ |
WEBCON ist keine Process-Mining-Plattform. Und genau das ist der Vorteil.
WEBCON ist eine Workflow-Plattform, keine eigenständige Process-Mining-Plattform. Bei vielen Workflow-Plattformen erfordert Process Mining zusätzliche Konfigurationen oder separate Produkte. In WEBCON ergibt es sich aus der Architektur der Plattform. Sobald Sie einen Prozess erstellen, entstehen automatisch die Daten, die Sie für Process Mining benötigen. Durchlaufzeiten, Engpässe und Ausnahmen sind vom ersten Tag an sichtbar.
Welche Erkenntnisse Process Mining liefert
Sobald Process Mining Ihre Workflows analysiert, erhalten Sie Einblicke, die zuvor nicht verfügbar waren. Sie sehen:
- tatsächliche Durchlaufzeiten für jeden einzelnen Vorgang statt geschätzter Durchschnittswerte;
- wo Anfragen liegen bleiben und wie lange;
- welche Prozessschritte die größten Verzögerungen verursachen, welche Genehmiger Engpässe bilden und welche Prozesspfade zu Nacharbeit oder erneuten Einreichungen führen;
- seltene Ausnahmefälle, die zwar nur vereinzelt auftreten, aber unverhältnismäßig viel Zeit und Ressourcen binden.
Gerade dieser letzte Punkt wird häufig unterschätzt. Der Standardablauf funktioniert oft problemlos. Die eigentlichen Herausforderungen liegen meist in den Ausnahmen.
Die Kosten fehlender Transparenz
Vielleicht denken Sie, dass Sie dieses Problem nicht betrifft. Ihre Prozesse sind bereits digital. Aufgaben werden erledigt und Vorgänge laufen weiter. Doch digital bedeutet nicht automatisch messbar. Und Prozesse, die nicht gemessen werden, verändern sich schleichend. Die Auswirkungen werden häufig erst sichtbar, wenn bereits erhebliche Kosten entstanden sind.
Ohne Messdaten beruhen Entscheidungen auf Einschätzungen statt auf Fakten. Probleme, die sich schwer belegen lassen, erhalten oft keine Priorität, obwohl sie den größten Einfluss auf das Unternehmen haben. Automatisierungsprojekte starten ohne Ausgangsbasis, sodass sich ihr Erfolg später kaum objektiv nachweisen lässt. Jedes Projekt beginnt praktisch wieder bei null.
Process Mining in WEBCON: integriert – vom ersten Tag an
Bei vielen Plattformen ist Process Mining ein separates Produkt oder eine Funktion, die erst nach dem Go-live eingerichtet wird. In WEBCON ist Process Mining standardmäßig Bestandteil jeder Anwendung. Sobald ein Prozess ausgeführt wird, entstehen automatisch die benötigten Daten. Jede Prozessanwendung erfasst automatisch den tatsächlichen Ablauf: reale Durchlaufzeiten, Engpässe, Ausnahmen, Wartezeiten, Verzögerungen bei Freigaben, wiederholte Einreichungen und Unterbrechungen im Workflow.
Ihr erstes MVP ist damit nicht nur ein Workflow, sondern gleichzeitig ein Messinstrument.
Long Running Instances
Geschäftsprozesse sind nicht immer innerhalb weniger Stunden abgeschlossen. Vertragsprozesse, Beschaffungszyklen oder Compliance-Workflows laufen häufig über Monate oder sogar Jahre. WEBCON speichert den Status eines Prozesses über seinen gesamten Lebenszyklus hinweg. Dadurch analysiert Process Mining den vollständigen Prozess und nicht nur die schnell abgeschlossenen Vorgänge.
Mehr über Long Running Instances erfahren >
InstantChange™
Geschäftsprozesse entwickeln sich kontinuierlich weiter. Wenn Sie einen Workflow in WEBCON ändern, wird diese Änderung sofort auf alle laufenden Instanzen angewendet, ohne deren Verlauf oder Historie zu verlieren. Dadurch bleibt Ihre Process-Mining-Basis konsistent und vergleichbar. Sie können dieselbe Änderung vor und nach ihrer Einführung anhand derselben Daten messen – ohne Lücken oder Versionschaos.
Mehr über InstantChange™ erfahren >
Mit WEBCON vollständige Transparenz gewinnen und Prozesse gezielt verbessern
Process Mining in WEBCON liefert etwas, dessen Aufbau viele Unternehmen über Jahre hinweg anstreben: ein faktenbasiertes Bild ihrer tatsächlichen Abläufe – verfügbar ab der ersten produktiven Anwendung.
Daten ersetzen Vermutungen. Sie erkennen beispielsweise, dass 80 % aller Rechnungen innerhalb von zwei Tagen freigegeben werden, Verträge ab einem bestimmten Wert jedoch sechs zusätzliche Tage in einer Genehmigungsschleife verbringen. Das ist kein Bauchgefühl, sondern ein dokumentierter Engpass mit einer klaren Ursache und einem konkreten Lösungsansatz.
Ihr Center of Excellence priorisiert auf Basis von Fakten. Welche Workflows verursachen den größten Zeitverlust? Welche Prozesse wurden so weit verbessert, dass Ressourcen an anderer Stelle eingesetzt werden können? Diese Fragen beantwortet der Datenbestand in jedem Quartal – ohne politische Diskussionen.
Verbundene Prozesse schaffen zusätzliche Transparenz. Wenn Sie beispielsweise die Rechnungsfreigabe mit der Zahlungsabwicklung verbinden, können Sie den gesamten Ablauf von der Rechnungserfassung bis zur verbuchten Zahlung messen. Erst die Kombination mehrerer Prozesse liefert dieses Gesamtbild. Zwanzig Anwendungen über fünf Fachbereiche hinweg sind damit nicht länger nur ein Portfolio automatisierter Prozesse, sondern ein kontinuierliches Messsystem für die Arbeitsweise Ihres Unternehmens.
Jede weitere Investitionsentscheidung basiert auf den Erkenntnissen der vorherigen. Sie zeigen dem Management, was sich verändert hat, welche Verbesserungen erreicht wurden und welche Kennzahlen dies belegen. Ohne Schätzungen. Ohne Vermutungen.
Möchten Sie sehen, wie Process Mining in einer laufenden WEBCON-Anwendung funktioniert? Sprechen Sie mit uns!
Wenn Sie ein mittelständisches oder großes Unternehmen führen, laufen Ihre Prozesse nicht innerhalb eines einzigen Systems ab. Unterschiedliche Geschäftsbereiche arbeiten mit unterschiedlichen Anwendungen. Ein Dokument kann beispielsweise im ERP-System entstehen, einen Genehmigungsworkflow durchlaufen und anschließend in einem anderen System archiviert werden. Fehlt die Verbindung zwischen diesen Systemen, verlangsamt das Abläufe, erhöht die Fehleranfälligkeit und erschwert den Überblick über den gesamten Prozess.
Die meisten Unternehmen benötigen kein weiteres Integrationstool. Sie benötigen eine Prozessebene, die mit den vorhandenen Systemen zusammenarbeitet, Daten dort nutzt, wo sie gespeichert sind, sie im Kontext eines Geschäftsprozesses verarbeitet und sie an der nächsten Stelle wieder zur Verfügung stellt. Ein gutes Beispiel ist die ERP-Erweiterung durch Prozessanwendungen. SAP oder Microsoft Dynamics übernehmen weiterhin Transaktionen und Stammdatenverwaltung. Genehmigungen, Ausnahmen, bereichsübergreifende Workflows oder dokumentenintensive Prozesse, für die ein ERP-System ursprünglich nicht ausgelegt wurde, laufen dagegen auf einer Prozessplattform, die Daten bei Bedarf aus dem ERP liest und wieder dorthin zurückschreibt. Die Daten bleiben dort, wo sie hingehören. Der Prozess läuft dort, wo er am sinnvollsten ist.
Das funktioniert jedoch nur, wenn die Integrationsschicht von Anfang an Bestandteil der Plattform ist und nicht nachträglich ergänzt wird.
Realität in der IT: Integrationen sind aufwendig zu entwickeln und noch aufwendiger zu warten
Nicht jedes System lässt sich einfach integrieren. Manche stellen moderne APIs bereit. Andere bieten einen SOAP-Service aus dem Jahr 2009 und überlassen Ihnen den Rest. Legacy-Systeme ermöglichen unter Umständen nur den Zugriff auf Datenbankebene. Und jede neue Integration, die Sie erstellen, muss langfristig gewartet werden.
Multiplizieren Sie das mit den Dutzenden Systemen, die in einem Unternehmen im Einsatz sind. Es entsteht ein Netzwerk aus Punkt-zu-Punkt-Integrationen. Jede wurde etwas anders entwickelt, jede wird von der Person betreut, die sie ursprünglich erstellt hat, und jede ist anfälliger, als den meisten lieb ist.
IT-Teams haben bereits heute genug zu tun. Sie brauchen einen Ansatz, der Integrationen beherrschbar macht, Governance unterstützt und so viel Self-Service wie möglich bietet, ohne dabei die Kontrolle zu verlieren.
So integriert WEBCON andere Systeme
WEBCON ist eine Plattform für Business Process Automation, mit der Unternehmen Business Process Applications entwickeln und betreiben können. Da diese Anwendungen Daten aus anderen Systemen benötigen, verfügt die Plattform über eine native Integrationsschicht, die genau für diesen Zweck entwickelt wurde.
In der Praxis funktioniert das so: Power User erstellen in WEBCON Datenmodelle, die definieren, wie Informationen zwischen Prozessanwendungen und externen Systemen ausgetauscht werden. Diese Datenmodelle bilden die Verbindung. Sie entwickeln beispielsweise eine Anwendung zur Genehmigung von Bestellungen, die Lieferantendaten aus Ihrem ERP-System bezieht. Oder einen Workflow für das Vertragsmanagement, der Kundendaten aus Ihrem CRM liest. Oder einen Onboarding-Prozess, der Benutzerkonten über Active Directory bereitstellt. Die Integration ist Bestandteil der Anwendung und kein separates Projekt.
Die Plattform ermöglicht die Low-Code-Konfiguration von Verbindungen zu einer Vielzahl von Datenquellen, darunter Microsoft SQL Server, Active Directory, REST- und SOAP-Webservices sowie SharePoint, ebenso wie zu Geschäftsanwendungen wie SAP, IFS, Microsoft Dynamics, enova365, Symfonia ERP, TETA Constellation und vielen weiteren - unabhängig davon, ob es sich um Standardlösungen oder individuell entwickelte Systeme handelt.
Power User können zusätzlich eigene Datenmodelle und Integrationen erstellen, die über die standardmäßig verfügbaren Möglichkeiten hinausgehen. Wenn Ihr System seine Daten über einen gängigen Standard bereitstellt, kann WEBCON damit arbeiten.
Eine Integrationsarchitektur, die Wiederholungen vermeidet
Die erste Verbindung zu erstellen ist das eine. Sie über verschiedene Umgebungen, Mandanten und Systemaktualisierungen hinweg zuverlässig zu betreiben, das andere. Genau hier spielt die Integrationsarchitektur von WEBCON ihre Stärken aus.
Entwicklungs-, Test- und Produktivumgebungen
Wenn Sie eine Prozessanwendung entwickeln, die mit Ihrem ERP-System verbunden ist, soll Ihre Entwicklungsumgebung selbstverständlich nicht auf Produktivdaten zugreifen. WEBCON übernimmt diese Zuordnung automatisch. Wenn Sie eine Anwendung von der Entwicklungs- über die Test- bis in die Produktivumgebung übertragen, verbindet die Plattform die Datenquellen automatisch mit der jeweils passenden Umgebung. Ihre Entwicklungsanwendung greift auf die ERP-Testumgebung zu, Ihre Produktivanwendung auf das Live-System. Eine manuelle Neukonfiguration bei jeder Bereitstellung ist nicht erforderlich.
Änderungen werden in den entsprechenden Umgebungen umgesetzt

Mehrere Geschäftseinheiten
Wenn Ihr Unternehmen in mehreren Ländern oder Tochtergesellschaften tätig ist, arbeiten Sie wahrscheinlich mit mehreren Active Directory-Domänen und mehreren ERP-Instanzen. Die deutsche Niederlassung nutzt SAP, die Unternehmenszentrale Microsoft Dynamics und die britische Niederlassung ein anderes System. WEBCON unterstützt Active Directory-Forests und föderierte Domänen mit intelligentem Caching für schnelle Antwortzeiten. Noch wichtiger ist, dass Integrationsaufrufe anhand des Geschäftseinheitenkontexts des angemeldeten Benutzers weitergeleitet werden. Ruft ein Benutzer in der Unternehmenszentrale beispielsweise eine Lieferantenliste ab, greift WEBCON auf einen SAP-Webservice zu. Stammt dieselbe Anfrage aus einer Niederlassung, werden die Daten aus einer SQL-View von Dynamics AX abgerufen. Dieselbe Prozessanwendung, dieselbe Benutzererfahrung, unterschiedliche Backend-Systeme. Einmal konfiguriert, zentral verwaltet.
Die Plattform für externe Systeme öffnen
Mit Version 25 wurde die User Defined API (UDA) eingeführt. Sie ermöglicht es WEBCON-Beratern und Power Usern, Integrationsendpunkte direkt im Designer Studio zu erstellen. Keine komplexen JSON-Strukturen, keine OAuth-Herausforderungen und kein Engpass durch Entwickler. Sie vergeben einen Namen für den Endpunkt, definieren die eingehenden und ausgehenden Daten, und die Plattform erstellt die OpenAPI-Dokumentation automatisch. Externe Systeme nutzen den Endpunkt wie jede andere standardisierte REST-API. UDA unterstützt drei Betriebsarten: das Auslösen von Automatisierungen, die Arbeit mit Workflow-Instanzen und die Bereitstellung von Datenquellen.
Unternehmen mit erfolgreichen Prozessen haben zuerst ihre Integrationen richtig umgesetzt
GTX Service, ein Unternehmen, das Reparaturservices in acht Märkten verwaltet, stieß mit SAP an seine Grenzen. Jede Prozessänderung erforderte monatelange Dokumentation, brachte ein hohes Fehlerrisiko bei Aktualisierungen mit sich und verursachte Kosten, die das Unternehmen nicht mehr rechtfertigen konnte. Digitalisierungsinitiativen wurden immer wieder abgelehnt, weil das ERP-System mit den Anforderungen nicht Schritt halten konnte.
Das Unternehmen führte WEBCON als Prozessebene über dem bestehenden ERP-System ein. Heute verarbeitet GTX Service jährlich 100.000 Serviceaufträge über WEBCON. Prozessänderungen werden innerhalb weniger Tage statt erst nach Monaten bereitgestellt. Das ERP übernimmt weiterhin die Aufgaben, für die es ausgelegt ist: Transaktionen. WEBCON übernimmt alles andere - sämtliche Prozesse rund um diese Transaktionen - und verbindet die einzelnen Systeme miteinander.
Dieses Muster wiederholt sich immer wieder. Kunden beginnen mit einem Prozess, der an ein System angebunden ist. Anschließend verbinden sie einen zweiten Prozess mit demselben System und einen dritten mit einem weiteren. Da jede Anwendung auf WEBCON auf derselben modellgetriebenen Grundlage basiert, lässt sich jede neue Integration schneller umsetzen als die vorherige.
Eine Forrester Total Economic Impact-Studie ermittelte über einen Zeitraum von drei Jahren einen ROI von 113 % sowie eine Verbesserung der Prozessbearbeitungszeit um 87 % für Unternehmen, die diesen Ansatz nutzen. Diese Ergebnisse entstehen durch den kumulativen Effekt: Jede neue Anwendung und jede neue Integration macht die nächste schneller und kostengünstiger.
Schaffen Sie ein vernetztes IT-Ökosystem statt einer Sammlung einzelner Integrationen
Mehr als 1.000 Unternehmen in über 70 Ländern steuern ihre Prozesse mit WEBCON. Sie nutzen die Integrationsfunktionen der Plattform, um ihre bestehenden Systeme zu einem konsistenten, zentral gesteuerten Ökosystem zu verbinden, in dem Daten im Kontext realer Geschäftsprozesse fließen.
Wenn Sie vor Integrationsherausforderungen stehen, Ihr ERP erweitern, Legacy-Systeme anbinden oder Ihre Prozessanwendungen mit Ihrer übrigen IT-Landschaft verbinden möchten, sprechen Sie mit uns. Kontaktieren Sie uns, um Ihre individuelle Situation zu besprechen.
Dokumentation ist keine Aufgabe, die man erledigt, nachdem die eigentliche Arbeit getan ist. Sie ist etwas, das die Plattform kontinuierlich erzeugt – für jede Anwendung, automatisch.
Was „immer aktuell" tatsächlich bedeutet
Die modellgesteuerte Entwicklungsumgebung von WEBCON erstellt automatisch eine umfassende, strukturierte Word-Dokumentation für jede Anwendung und jeden Prototyp - von dem Moment an, in dem sie erstellt werden. Es gibt keine separate Dokumentationsaufgabe im Projektplan. Keinen Dokumentations-Sprint am Ende eines Releases. Keine verantwortliche Person, die die Dokumentation aktuell halten muss. Jeder Workflow, jedes Formular, jede Geschäftsregel, jede Routing-Bedingung und jeder Genehmigungsschritt wird automatisch dokumentiert, ist jederzeit aktuell und kommt ganz ohne manuellen Aufwand aus.
Das ist kein Reporting-Tool, das man konfiguriert. Es ist eine Konsequenz daraus, wie die Plattform Anwendungsdefinitionen speichert und verwaltet.
Das Problem der Dokumentationsschuld
Auf den meisten Workflow- und Low-Code-Plattformen ist Dokumentation stets eine nachgelagerte Aktivität. Teams bauen die Anwendung und entwickeln sie weiter, während die Dokumentation zusätzliche Arbeit bedeutet – etwas, das manuell erstellt, gepflegt und mit den Änderungen der Anwendung synchron gehalten werden muss.
Wenn das Team unter Zeitdruck steht, bleibt die Dokumentation liegen. Wenn sich das Team ändert, wird die Dokumentation zur Aufgabe von Personen, die das System nicht selbst gebaut haben. Wenn sich die Anwendung häufig ändert, gerät die Dokumentation schneller in Rückstand, als jemand mithalten kann.
Das Ergebnis ist eine Dokumentationsschuld: eine wachsende Lücke zwischen dem, was die Dokumentation aussagt, und dem, was das System tatsächlich tut. In regulierten Branchen ist diese Lücke ein Audit-Risiko. In operativen Umgebungen ist sie ein Wartungsrisiko. In jeder Umgebung ist sie ein Wissensrisiko – das organisatorische Verständnis dafür, wie ein Prozess funktioniert, wird brüchig, weil es in den Köpfen der Mitarbeitenden liegt statt in einem Dokument.
Die Plattform weiß, was sie gebaut hat
WEBCON speichert jede Anwendung als strukturiertes Modell – eine Definition, die die Plattform zu jedem Zeitpunkt vollständig versteht.
Wenn Sie einen Workflow in Designer Studio bauen, bildet die Plattform jeden Status, jeden Übergang, jede Geschäftsregel, jedes Formularfeld und jede Weiterleitungsbedingung ab. Ändern Sie die Anwendung, aktualisiert sich die Dokumentation entsprechend. Das Modell hat sich geändert – also hat sich auch die Dokumentation geändert.
Die Dokumentation ist immer aktuell. Nicht als Ziel, das man anstrebt, sondern als strukturelle Eigenschaft der Funktionsweise der Plattform.
Das ist deshalb relevant, weil Governance in der Plattformarchitektur verankert ist, nicht prozedural. Die Plattform setzt sie durch Design durch - nicht in der Hoffnung, dass Ihr Team die Richtlinien befolgt. Ihr erstes MVP, in einer einzigen Sitzung gebaut, verfügt bereits über vollständige Dokumentation. Wenn Sie eine Weiterleitungsregel ändern oder einen Freigabeschritt hinzufügen, wendet InstantChange™ diese Änderung sofort auf alle laufenden Instanzen an – und die Dokumentation spiegelt diese Änderung im selben Moment wider.
5 Wege, wie Auto-Dokumentation die Arbeit Ihres Teams verändert
- Dokumentationsschuld entsteht gar nicht erst
Jede Änderung wird sofort abgebildet. Die Lücke zwischen dem, was die Dokumentation aussagt, und dem, was das System tut, ist strukturell unmöglich. - Das Center of Excellence (CoE) bleibt klein
Auf den meisten Plattformen ist Dokumentation ein eigener Job – jemand schreibt sie, prüft sie und pflegt sie. Bei WEBCON gibt es diese Kategorie von Arbeit nicht. Ein Team von zwei bis fünf Personen kann Dutzende Unternehmensanwendungen betreiben, weil die Plattform ganze Kategorien von Wartungsaufwand eliminiert – Dokumentation eingeschlossen. - Governance wird durchgesetzt, nicht nur angestrebt
Der MVP, der in einer einzigen Session als Prototyp erstellt wurde, verfügt bereits über eine vollständige Dokumentation. Die Einhaltung von Governance-Vorgaben wird nicht erst am Ende eines Projekts sichergestellt. Sie ist von Anfang an gegeben - vom ersten Tag an, für jede Anwendung, unabhängig davon, wie schnell sie entwickelt wurde. - Wissen überlebt Personalwechsel
Verlässt ein Process Champion das Unternehmen, bleibt die Dokumentation aller von ihm entwickelten Anwendungen vollständig, aktuell und wird weiterhin automatisch von der Plattform erstellt. Neue Teammitglieder können jede Anwendung im Portfolio verstehen, weil die Dokumentation sie präzise beschreibt. Organisatorisches Wissen verlässt das Unternehmen nicht mit der Person, die es trägt. - Audits werden unkompliziert
Wenn eine Aufsichtsbehörde nach der Dokumentation eines Geschäftsprozesses fragt, liegt die Antwort sofort vor. Die Dokumentation existiert, ist aktuell und spiegelt genau das wider, was das System tut.
Sehen Sie es in der Praxis
Buchen Sie eine Demo und erleben Sie, wie WEBCON in einer Live-Umgebung automatisch eine vollständige Anwendungsdokumentation erstellt - von der ersten Prototyping-Session bis hin zu Änderungen an einem produktiven Workflow.
Designer Studio dient zur Entwicklung von Business-Anwendungen über eine visuelle Oberfläche – ganz ohne Programmierkenntnisse. Nach einer kurzen Einarbeitung kann jedes Teammitglied Designer Studio nutzen und leistungsstarke, individuell zugeschnittene Business-Anwendungen entwickeln.
Mehr Anwendungen, weniger Abhängigkeit von der IT
Der Bedarf an Business-Anwendungen wächst kontinuierlich. Laut Gartner wird der Anteil der Citizen Developer, die zu Digitalisierungsinitiativen beitragen, von 10 % im Jahr 2025 auf 70 % im Jahr 2029 steigen. Unternehmen aller Branchen entwickeln immer mehr Anwendungen – schneller und zunehmend ohne klassische Softwareentwickler.
WEBCON beantwortet diese Entwicklung mit Citizen-Assisted Development. Fachbereiche bringen ihr Prozesswissen ein und erstellen Prototypen im Designer Desk. Process Champions übernehmen diese anschließend und entwickeln daraus im Designer Studio produktionsreife Anwendungen. So entsteht keine Lücke zwischen den Anforderungen des Fachbereichs und der späteren Umsetzung.
„Die Zeit zur Entwicklung neuer Lösungen verkürzt sich von Monaten auf wenige Tage.“
Marek Witkowski
IT Director, Südzucker Poland, [Quelle]
Was ist Designer Studio?
Designer Studio ist die Low-Code-Konfigurationsumgebung innerhalb von WEBCON. Process Champions entwickeln damit über eine visuelle Oberfläche produktionsreife Business-Anwendungen.
Die modellgetriebene Plattform übernimmt Architektur, Governance, Dokumentation, Auditierbarkeit und Compliance automatisch. Process Champions können sich dadurch auf das konzentrieren, was wirklich zählt: die fachlichen Anforderungen zu verstehen und in funktionierende Anwendungen umzusetzen.
Designer Desk definiert die Anforderungen. Designer Studio setzt sie um
Fachbereiche erstellen im Designer Desk Prototypen. Sie modellieren den Prozess, entwerfen Formulare und definieren die fachlichen Anforderungen.
Process Champions übernehmen den Prototyp anschließend im Designer Studio. Workflows, Formularstrukturen und Felddefinitionen sind bereits vorhanden. Sie ergänzen Integrationen, Geschäftsregeln, Sicherheitskonfigurationen und Automatisierungen und stellen die Anwendung anschließend bereit.

Integrierte Funktionen in Designer Studio
Die meisten Low-Code-Plattformen bieten eine Entwicklungsoberfläche. Designer Studio bietet eine Entwicklungsoberfläche und alles, was dazugehört: Logikkonfiguration, Änderungen an laufenden Prozessen, wiederverwendbare Komponenten und automatische Governance – alles integriert und von der ersten Anwendung an verfügbar.
Die Business Rules Engine ermöglicht es, auch komplexe Logik per Drag-and-Drop zu konfigurieren. Bedingungen werden definiert, Aktionen festgelegt und Regeln visuell miteinander verknüpft. So lässt sich Logik umsetzen, deren Programmierung von Grund auf Wochen dauern würde.
Mit InstantChange™ können laufende Prozesse geändert werden, ohne sie anzuhalten oder neu aufzusetzen. Sie folgen Ihrem Dev-Test-Prod-Prozess, stellen die Änderungen bereit und sind fertig. Bereits laufende Prozessinstanzen werden aktualisiert und bleiben dabei an ihrer aktuellen Stelle im Prozess.
Die modellgetriebene Architektur sorgt dafür, dass jede Anwendung von Beginn an automatisch Governance, Auditierbarkeit, KI-Funktionen und automatisch erzeugte Dokumentation erhält. Dafür ist keine zusätzliche Konfiguration erforderlich. Jede Anwendung verfügt von Anfang an über diese Funktionen – auch der erste MVP, den Sie in einer einzigen Session erstellen.
Ein Werkzeug, das Ihr Team selbst beherrschen kann
Process Champions werden nicht auf dem Entwicklerarbeitsmarkt gesucht. Sie finden sie bereits in Ihrem Unternehmen – in den Bereichen Operations, IT oder Fachbereich. Designer Studio ist ein Werkzeug, das sie in kurzer Zeit erlernen können.
Ein Team aus drei bis fünf Process Champions kann 100 oder mehr produktive Anwendungen betreuen. Der Grund dafür ist einfach: Jede Anwendung in WEBCON funktioniert nach denselben Prinzipien. Wer eine Anwendung versteht, versteht auch alle anderen. Das Team, das Sie dafür benötigen, arbeitet wahrscheinlich bereits in Ihrem Unternehmen. Vereinbaren Sie hier Ihre Demo!
FAQ
Häufig gestellte
Fragen

Für wen ist Designer Studio gedacht?
Designer Studio ist für Menschen aus Ihrem Team gedacht – ganz ohne Programmierkenntnisse. Ihr Process Champion kann aus den Bereichen Operations, IT oder direkt aus dem Fachbereich kommen. Die Entwicklung von Anwendungen in Designer Studio lässt sich erlernen.
Benötige ich Programmierkenntnisse, um Designer Studio zu nutzen?
Nein. Designer Studio ist eine Low-Code-Umgebung. Workflows, Formulare, Geschäftsregeln und Integrationen werden über eine visuelle Oberfläche konfiguriert. Die Business Rules Engine bildet auch komplexe Logik per Drag-and-Drop ab.
Wie werde ich in Designer Studio geschult?
Die WEBCON Academy deckt alles ab – von der ersten Anwendung bis zur fortgeschrittenen Konfiguration – in praxisnahen Workshops mit WEBCON-Experten. Am Ende erhalten Sie ein anerkanntes Zertifikat.
Das Community-Forum bietet eine zusätzliche Ebene: echte Fragen und Antworten von Champions, die bereits Anwendungen produktiv betreiben.
Was ist der Unterschied zwischen Designer Desk und Designer Studio?
Designer Desk ist für Fachbereiche gedacht. Sie erstellen damit Prototypen von Prozessen, entwerfen Formulare und beschreiben Geschäftsregeln in natürlicher Sprache – ganz ohne technisches Wissen.
Designer Studio ist für Process Champions gedacht. Sie übernehmen den Prototyp und entwickeln daraus die produktionsreife Anwendung.
Kann ich eine Anwendung ändern, die bereits produktiv läuft?
Ja. Mit InstantChange™ können Sie einen laufenden Prozess ändern, ohne ihn anzuhalten oder neu aufzusetzen. Sie nehmen die Änderung in Designer Studio vor, und neue Instanzen übernehmen sofort die aktualisierte Definition. Nutzer, die sich bereits mitten im Prozess befinden, bleiben genau dort, wo sie sind.
Wie viele Anwendungen kann ein Process Champion betreuen?
Ein Team aus drei bis fünf Champions betreut in der Regel 100 oder mehr produktive Anwendungen. Das ist möglich, weil jede WEBCON-Anwendung auf derselben architektonischen Grundlage basiert. Wer eine Anwendung versteht, versteht alle. Es gibt kein anwendungsspezifisches Wissen, das beim Einstieg oder beim Wachstum des Portfolios erworben werden muss.
Welche Governance stellt Designer Studio automatisch sicher?
Jede in Designer Studio erstellte Anwendung erhält automatisch Governance, Auditierbarkeit, Process Mining, KI-Funktionen und automatisch erzeugte Dokumentation. Nichts davon muss separat konfiguriert werden. Die Plattform stattet jede Anwendung standardmäßig damit aus – auch den ersten MVP, den Sie in einer einzigen Session erstellen.
Unterstützt Designer Studio KI-Funktionen?
Ja. Da Designer Studio auf einer modellgetriebenen Architektur basiert, stehen KI-Funktionen standardmäßig in jeder Anwendung zur Verfügung. Die KI arbeitet innerhalb des Workflow-Frameworks mit strukturierten Anwendungsdaten und ist damit von Anfang an kontextbewusst. Unternehmensdaten bleiben in der zentral gesteuerten Umgebung – das verhindert das Schatten-KI-Problem, bei dem Mitarbeiter sensible Informationen in unkontrollierte Tools kopieren.
Wo finde ich weitere Ressourcen und Unterstützung?
WEBCON stellt Dokumentation unter docs.webcon.com bereit, eine Wissensdatenbank unter kb.webcon.pl sowie ein aktives Community-Forum unter community.webcon.com, in dem Champions und Administratoren Praxisbeispiele, Anleitungen und Antworten auf konkrete Konfigurationsfragen teilen.
Bieten Sie Unterstützung bei der Implementierung an?
WEBCONs Netzwerk zertifizierter Implementierungspartner ist in Europa und Nordamerika aktiv. Die Partner kennen die Plattform, kennen die Branchen und begleiten Ihr Team vom ersten Prototyp bis zum vollständigen Produktivbetrieb.
Darüber hinaus haben Sie jederzeit direkten Zugang zur Unterstützung durch die internen Berater von WEBCON. In beiden Fällen ist das Ziel dasselbe: Ihr Team beherrscht die Plattform selbst, wenn das Projekt abgeschlossen ist.
Jede Plattform verspricht Governance. Die meisten stellen jedoch lediglich Werkzeuge bereit, die Teams nutzen können oder eben nicht: Richtlinien, Leitplanken, Code Reviews oder Dokumentationsvorlagen. Das Problem dabei: Governance, die von konsequentem menschlichem Handeln abhängt, lässt sich nicht beliebig skalieren. Es gibt einen anderen Ansatz: Die Plattform setzt Governance architektonisch durch. So können Anwendungen, die nicht den definierten Standards entsprechen, gar nicht erst entstehen.
Viele Unternehmen kennen diese Situation. Unter Zeitdruck wird eine Anwendung entwickelt. Die Dokumentation bleibt auf der Strecke, weil der Termin drängt. Die Sicherheitsprüfung erfolgt erst nach dem Go-live oder gar nicht. Benennungskonventionen unterscheiden sich von Abteilung zu Abteilung. Ein geschäftskritischer Workflow wird ohne ausreichende Fehlerbehandlung umgesetzt. Einige Monate später tritt ein Problem im Produktivbetrieb auf und niemand weiß mehr genau, wie die Anwendung funktioniert, weil der ursprüngliche Entwickler inzwischen eine andere Rolle übernommen hat.
Das liegt nicht daran, dass Mitarbeitende nachlässig arbeiten. Es liegt daran, dass Governance, die auf Disziplin basiert, unter realen Bedingungen an ihre Grenzen stößt. Bei fünf Anwendungen funktioniert sie meist noch. Vielleicht auch bei zehn. Bei fünfzig entstehen erste Lücken. Bei hundert werden daraus ernsthafte Risiken.
Prozessbasierte oder architektonische Governance?
Grundsätzlich gibt es zwei unterschiedliche Ansätze, Governance auf einer Plattform für Business Process Automation umzusetzen.
Prozessbasierte Governance stößt mit zunehmender Skalierung an ihre Grenzen
Unternehmen definieren Standards, schulen Mitarbeitende, etablieren Review-Prozesse und hoffen, dass diese dauerhaft eingehalten werden. Das funktioniert, solange ausreichend Zeit, Aufmerksamkeit und Ressourcen vorhanden sind. Mit jeder neuen Anwendung, jedem neuen Teammitglied und jedem engen Zeitplan wächst jedoch der Abstand zwischen Richtlinie und Realität. Nicht, weil bewusst Abkürzungen genommen werden, sondern weil prozessbasierte Governance kontinuierlichen manuellen Aufwand erfordert.
Architektonische Governance funktioniert automatisch
Bei diesem Ansatz gibt die Plattform eine verbindliche Struktur vor, der jede Anwendung folgen muss. Entwickler müssen Standards nicht aktiv einhalten, weil die Plattform gar keine Möglichkeit bietet, diese zu umgehen. Dokumentation entsteht automatisch aus dem Anwendungsmodell, nicht als separate Aufgabe. Sicherheitsmechanismen müssen nicht für jede Anwendung separat eingerichtet werden, da alle Anwendungen dasselbe Sicherheitsmodell der Plattform übernehmen.
WEBCON verfolgt genau diesen Ansatz. Governance ist keine zusätzliche Ebene über der Plattform, sondern Bestandteil ihrer Architektur. Anwendungen ohne Governance können in WEBCON nicht entstehen, weil die Plattform sie technisch ausschließt.
Wie integrierte Governance in der Praxis aussieht
Der Unterschied zeigt sich in konkreten Funktionen, die unabhängig davon gleich arbeiten, ob Sie fünf oder fünfhundert Anwendungen betreiben.
Dokumentation, die automatisch entsteht
Die modellgetriebene Architektur von WEBCON erstellt automatisch eine vollständige Dokumentation für jede Anwendung und jeden Prototypen. Sie entspricht jederzeit dem aktuellen Stand und wird bei jeder Änderung automatisch aktualisiert. Dadurch entsteht keine Dokumentationslücke, bei der die Dokumentation noch Version 1.0 beschreibt, während die Anwendung längst bei Version 4.7 angekommen ist.
Audit-Trail und Compliance ab dem ersten Tag
Jede Anwendung verfügt automatisch über vollständige Nachvollziehbarkeit, unabhängig davon, ob diese explizit eingeplant wurde oder nicht. Jede Änderung wird protokolliert. Sie sehen jederzeit, wer was wann und in welchem Prozess geändert hat.
Der MVP, den Ihr Team innerhalb einer gemeinsamen Session erstellt hat, verfügt über denselben Audit-Trail wie ein geschäftskritischer Prozess, der seit mehreren Jahren produktiv im Einsatz ist. Gerade in regulierten Branchen ist diese Nachvollziehbarkeit unverzichtbar. In WEBCON ist sie kein zusätzlicher Aufwand, sondern fester Bestandteil der Plattform.
Ein Sicherheitsmodell für alle Anwendungen
Die Sicherheit wird nicht für jede Anwendung einzeln konfiguriert. Stattdessen stellt die Plattform ein einheitliches Sicherheitsmodell bereit, das automatisch von jeder Anwendung übernommen wird. Dadurch entfällt ein häufiges Risiko: Anwendungen, die versehentlich mit unvollständigen Berechtigungen oder Standardkonfigurationen produktiv gehen.
Laufzeitdiagnosen und SIEM-Integration
WEBCON bietet umfassende Einblicke in das Verhalten Ihrer Anwendungen während des Betriebs. Probleme können erkannt werden, bevor Anwender sie melden. Kommt es dennoch zu einer Störung, müssen Teams keine undokumentierten Anwendungen analysieren. Die Plattform zeigt nachvollziehbar, was passiert ist und an welcher Stelle das Problem entstanden ist.
Warum integrierte Governance bei wachsender Skalierung entscheidend ist
Prozessbasierte Governance verursacht mit jeder zusätzlichen Anwendung mehr Aufwand. Jede neue Anwendung benötigt eigene Dokumentationsprüfungen, Sicherheitskontrollen und Compliance-Freigaben. Governance-Teams werden zum Engpass. Entweder verzögert sich die Entwicklung oder Qualitätsstandards werden schrittweise aufgeweicht.
Architektonische Governance funktioniert dagegen unabhängig von der Anzahl der Anwendungen. Ob Anwendung Nummer eins oder Nummer hundert:
Dokumentation, Sicherheit, Auditierbarkeit und Compliance entstehen automatisch für jede Anwendung. Dadurch kann sich Ihr Team auf Aufgaben konzentrieren, die menschliche Entscheidungen erfordern, statt Zeit in wiederkehrende Governance-Aufgaben zu investieren.
Und wenn aus einer kleinen Fachbereichsanwendung später ein geschäftskritischer Prozess wird – was in der Praxis häufig geschieht – ist keine nachträgliche Anpassung an Unternehmensstandards erforderlich. Governance war von Anfang an Bestandteil der Anwendung. Die Dokumentation ist aktuell. Der Audit-Trail vollständig. Das Sicherheitsmodell war nie optional. Es gibt nichts nachzubessern, weil von Beginn an die richtigen Grundlagen geschaffen wurden.
Das große Ganze
Integrierte Governance ist eine der wichtigsten Folgen einer modellgetriebenen Architektur: alle Anwendungen basieren auf derselben technischen Grundlage, denselben Regeln und denselben Plattformfunktionen.
Wenn Sie verstehen möchten, wie diese Architektur gleichzeitig Konsistenz, eine nahtlose Vernetzung zwischen Anwendungen und eine skalierbare Plattform ohne wachsende Komplexität ermöglicht, sprechen Sie mit uns!
Alle Workflow-Apps auf eine Plattform zu bringen, klingt nach einer Konsolidierungsstrategie. Aber wenn diese Plattform jedem Team erlaubt, auf seine eigene Art zu bauen, organisiert man das Chaos nur neu. Eine modellgetriebene Architektur löst genau das: Sie erzwingt eine gemeinsame Struktur für jede Anwendung, sodass Governance, Konsistenz und Vernetzung aus der Plattform selbst kommen — nicht daraus, dass sich Menschen an Regeln halten. Hier ist, warum dieser Unterschied darüber entscheidet, ob Ihr App-Portfolio bei 10 Anwendungen noch überschaubar ist oder auch bei 100 noch funktioniert.
Sie kennen das: Finance kauft ein Tool für Rechnungsfreigaben. HR entscheidet sich für etwas anderes fürs Onboarding. Operations findet eine weitere vielversprechende Workflow-App. Zwei Jahre später gibt es 15 unverbundene Workflow-Anwendungen in der Organisation, jede mit eigener Logik und eigenem Wartungsaufwand.
Und jedes Mal, wenn eine neue Abteilung ein neues Tool anfragt, wird das Problem größer. Nicht linear, sondern exponentiell — denn jede neue Anwendung bringt eine weitere Schicht Uneinheitlichkeit, eine weitere Integration, um die man sich kümmern muss, eine weitere Sache, die das IT-Team lernen und unterstützen muss. Ihr IT-Team verwaltet an diesem Punkt kein Portfolio mehr. Es löscht Brände.
Warum Konsolidierungsprojekte scheitern
Die naheliegende Lösung: alles auf eine Plattform bringen. Anbieter auswählen, Workflows migrieren, fertig.
Aber das passiert tatsächlich: Wenn Ihre Plattform es Menschen erlaubt, Anwendungen so zu bauen, wie sie wollen, beseitigen Sie die Zersplitterung nicht — Sie verschieben sie nur unter ein Dach. Statt 15 verschiedener Tools haben Sie jetzt 15 verschiedene Anwendungen, die auf 15 verschiedene Arten auf derselben Plattform gebaut wurden. Ein Team nutzt Namenskonventionen, ein anderes nicht. Eine Anwendung hat sauberes Error-Handling, die nächste wurde in Eile gebaut, und niemand hat etwas dokumentiert.
Governance hängt in dieser Welt von der Disziplin der Entwickler:innen ab, davon, ob Code-Reviews konsequent stattfinden, davon, ob sich Menschen an Richtlinien halten, die irgendjemand mal in einem Wiki festgehalten hat. Wir alle wissen, wie das ausgeht: Die Plattform wird zum Gefäß für das Chaos statt zu seiner Lösung.
Was "modellgetrieben" bedeutet
Die meisten Plattformen geben Ihnen einen Werkzeugkasten: Hier sind die Bausteine, hier ist eine Leinwand, bauen Sie, was Sie wollen. Das Ergebnis hängt vollständig davon ab, wer baut und wie viel Sorgfalt darauf verwendet wird, es richtig zu machen.
Eine modellgetriebene Plattform funktioniert anders, weil sie die Struktur festlegt, der jede Anwendung folgen muss — nicht als Richtlinie, sondern als architektonische Vorgabe. Bei WEBCON teilt sich jede Anwendung dieselbe zugrunde liegende Struktur, unabhängig davon, wer sie gebaut hat, welche Abteilung sie nutzt oder welches Problem sie löst. Dieselbe Formular-Architektur, dieselbe Workflow-Engine, dasselbe Business-Rules-Framework, dasselbe Sicherheitsmodell, derselbe Umgang mit Dokumenten, Reporting und Integrationen.
Das ist keine Best Practice, von der man hofft, dass Entwickler:innen sie befolgen. Die Plattform erzwingt es. Man kann auf WEBCON keine ungovernte Anwendung bauen, weil die Architektur es schlicht nicht zulässt.
Dieser Unterschied ist wichtiger als alles andere, wenn es um App-Konsolidierung geht. Die Frage ist nicht, ob man alle Apps auf eine Plattform bringen kann. Die Frage ist, ob diese Apps noch überschaubar sind, wenn man 50 oder 100 davon hat.
Was eine modellgetriebene Architektur in der Praxis bringt
Governance per Voreinstellung, nicht per Disziplin
Jede WEBCON-Anwendung erhält Auditierbarkeit, Sicherheit, Compliance und automatisch generierte Dokumentation, direkt im Modell verankert. Das gilt für jede Anwendung gleichermaßen — die schnelle MVP, die Ihr Team in einer einzigen Session gebaut hat, hat dieselbe Governance wie der geschäftskritische Prozess, der seit drei Jahren läuft.
Wenn sich diese kleine Anwendung als geschäftskritisch herausstellt, brauchen Sie kein Nachbesserungsprojekt, um Sicherheit und Compliance auf Standard zu bringen. Sie sind bereits da. Zum Vergleich: Bei zusammengesetzten Plattformen hängt Governance von Entwicklungspraktiken, Leitplanken und Code-Reviews ab — Kontrollen, die eigentlich stattfinden sollten, es in der Praxis aber oft nicht tun.
Jeder kann alles unterstützen
Wenn jede Anwendung dieselbe Architektur teilt, ist ein neues Teammitglied sofort produktiv, weil es nichts Unbekanntes zu lernen gibt. Ein Prozess-Champion aus dem Finance-Bereich kann eine von HR gebaute Anwendung unterstützen, weil die Struktur darunter identisch ist. So schaffen es Organisationen, 100+ Anwendungen mit einem Team von 3 bis 5 Personen zu betreiben — nicht weil diese Menschen übermenschlich wären, sondern weil die Architektur die Lernkurve pro Anwendung eliminiert, die klassische Portfolios so teuer in der Wartung macht.
Native Vernetzung statt Integrationsprojekte
Wenn Ihre Anwendungen dieselbe architektonische Grundlage teilen, ist das Verbinden eine Standard-Plattformfunktion, kein Projekt. Rechnungsfreigabe verbindet sich mit der Zahlungsabwicklung, Zahlungsabwicklung verbindet sich mit dem Einkauf — und plötzlich haben Sie Einblick in durchgängige Durchlaufzeiten, die Sie nie hatten, als das getrennte Systeme waren.
Onboarding von Business-Usern, das sich nicht aufsummiert
Stellen Sie sich vor, was eine neue Mitarbeiterin am ersten Tag erwartet: HR-Anträge, Einkaufs-Workflows, Reisefreigaben, Spesenabrechnungen. In einem typischen Unternehmen ist jedes davon ein eigenes Tool mit eigener Navigation und eigener Logik — und jede zusätzliche Prozess-Anwendung erhöht den Onboarding-Aufwand.
In einer modellgetriebenen Umgebung bedeutet, eine Anwendung zu lernen, alle zu lernen. Sie sehen gleich aus, verhalten sich gleich, funktionieren gleich. Die Onboarding-Kosten, die normalerweise mit jeder neuen App wachsen, gibt es hier schlicht nicht.
Das System, das niemand entwerfen musste
Hier fügt sich alles zusammen. Niemand hat ein großes System geplant. Menschen haben konkrete Probleme gelöst, eines nach dem anderen, in welcher Reihenfolge auch immer sinnvoll war. Aber weil alles auf derselben Grundlage sitzt und sich nativ verbindet, blickt man eines Tages auf die Sammlung von Anwendungen in der Organisation und erkennt: Das hier ist das System.
Das System, das sich in einem zweijährigen Anforderungsprojekt nicht hätte spezifizieren lassen, existiert jetzt — Bereich für Bereich gebaut von Menschen, die jeden Bereich genau verstanden haben, zugeschnitten darauf, wie die Organisation tatsächlich arbeitet.
Das ist der eigentliche Gewinn einer modellgetriebenen Architektur. Nicht nur Konsistenz um ihrer selbst willen, nicht nur Governance als Häkchen auf einer Liste. Es ist die Tatsache, dass Dutzende unabhängiger Entscheidungen, getroffen von unterschiedlichen Teams zu unterschiedlichen Zeiten, sich zu etwas Kohärentem summieren. Weil die Architektur es garantiert.
Wie es weitergeht
Eine modellgetriebene Architektur liefert das Fundament: Konsistenz, Governance und die Fähigkeit zu wachsen, ohne im Chaos zu enden. Es gibt noch eine andere Seite dieser Geschichte. Wenn Ihre Plattform eine gemeinsame Struktur für jede Anwendung erzwingt, passiert etwas mit der Geschwindigkeit, in der neue Anwendungen entstehen: Jede wird schneller gebaut als die vorherige, weil Muster wiederverwendet werden, Teams routinierter werden und sich organisatorische Stärke aufbaut. Wir nennen das den Application-Factory-Effekt — und er verändert die Rechnung bei der Konsolidierung komplett.
Wie Organisationen davon kommen, eine Anwendung zu bauen, zu Dutzenden — in Monaten statt Jahren — ist ein eigenes Gespräch wert. Mehr über den ApplicatioODn-Factory-Ansatz.
Die meisten Workflow-Plattformen basieren auf einer einfachen Annahme: Sobald ein Prozess läuft, lässt man ihn in Ruhe. Verbesserungen kommen in die nächste Version. Instanzen migriert man, wenn man bereit ist. Aber solange der Prozess live ist, mit Hunderten laufenden Fällen, fasst man ihn nicht an.
WEBCON wurde auf der gegenteiligen Annahme aufgebaut.
Was ist InstantChange™
InstantChange™ ist die Technologie, mit der Sie einen laufenden Workflow während des Betriebs ändern können. Fügen Sie einen Freigabeschritt hinzu, ändern Sie eine Geschäftsregel, strukturieren Sie um, wie Arbeit zwischen Personen und Teams weitergeleitet wird − und jede aktive Prozessinstanz übernimmt die Änderung sofort. Kein Neustart. Kein Datenverlust. Keine manuelle Migration. Die Änderung wird auf alle aktiven Instanzen an ihrer aktuellen Position im Workflow angewendet, und ein lückenloser Audit-Trail bleibt dabei durchgängig erhalten.
Was Sie mit InstantChange™ live ändern können
Seien wir konkret, denn „einen laufenden Workflow ändern" kann auf verschiedenen Plattformen ganz Unterschiedliches bedeuten. Bei WEBCON kann ein Process Champion (jemand aus Ihrem Team, geschult im Aufbau und in der Pflege von Workflows – oft aus der IT oder der Business-Analyse) jede der folgenden Änderungen an einem Workflow vornehmen, und zwar sofort, mit aktiven Instanzen in Bearbeitung:
- Einen Freigabeschritt hinzufügen oder entfernen. Die 300 Fälle, die aktuell auf eine Freigabe warten, starten nicht neu. Sie laufen von ihrer jeweiligen Position aus weiter, jetzt nach der aktualisierten Definition.
- Eine Geschäftsregel ändern – die Bedingungen, die Weiterleitung bestimmen, Schwellenwerte, die eine Eskalation auslösen, die Logik, die entscheidet, wer was bearbeitet. Jeder aktive Fall folgt ab dem Moment des Speicherns den neuen Regeln.
- Formularfelder hinzufügen oder bestehende anpassen. Laufende Fälle übernehmen die neuen Felder an ihrer aktuellen Position. Es gehen keine Daten verloren.
- Die Weiterleitungslogik vollständig umstrukturieren – wie Arbeit zwischen Personen, Teams, Abteilungen wandert. Alles läuft weiter.
InstantChange™ hält jede Instanz auf demselben Stand
In jedem Fall wird die Änderung an der aktuellen Position jeder aktiven Instanz angewendet. Die vollständige Kontinuität des Audit-Trails bleibt erhalten. Es gibt eine Version des Prozesses, nicht zwei parallel laufende, während Sie darauf warten, dass alte Instanzen auslaufen. Das ist kein erweitertes Feature, das man in den Einstellungen aktiviert. So funktioniert die Architektur.
Warum die meisten Workflow- und Low-Code-Plattformen das nicht können
Um zu verstehen, was InstantChange™ ungewöhnlich macht, hilft es zu verstehen, warum andere Plattformen mit Änderungen im laufenden Betrieb kämpfen.
Auf den meisten Workflow-Plattformen ist eine Prozessinstanz im Grunde an die Version der Prozessdefinition gebunden, die bei ihrer Erstellung aktiv war. Die Instanz trägt einen Verweis auf diese Version. Wenn Sie den Prozess ändern, wissen bestehende Instanzen nichts davon – sie laufen weiterhin nach den alten Regeln. Um sie zu überführen, brauchen Sie eine Form der Migration, und Migration bedeutet Risiko.
Die meisten Plattformen bieten drei Möglichkeiten: Sie lassen bestehende Instanzen unter der alten Definition weiterlaufen (Monate paralleler Versionsstände und zunehmende Komplexität), migrieren sie manuell (risikoreich, zeitaufwendig und häufig unvollständig) oder beenden sie und starten sie unter der neuen Definition neu (wodurch Fortschritt, Kontext und Audit-Historie verloren gehen). Jede dieser Optionen verursacht erhebliche betriebliche Kosten. Keine davon ist wirklich gut.
WEBCON funktioniert anders
Workflow-Instanzen sind Datenbankeinträge, keine Laufzeitobjekte, die an eine bestimmte Version gebunden sind. Wenn sich eine Prozessdefinition ändert, übernimmt jede aktive Instanz die Änderung an ihrer aktuellen Position. Keine Migration. Keine parallelen Versionen. Kein Datenverlust. Es gibt kein architektonisches Zeitlimit dafür, wie lange eine Instanz laufen darf − die Plattform behandelt einen seit drei Stunden laufenden Workflow genauso wie einen, der seit drei Jahren läuft.
| ✅ WEBCON InstantChange™ | Der Standardansatz | |
| Was mit laufenden Instanzen passiert | Übernehmen die Änderung sofort, an ihrer aktuellen Position | Laufen unter der alten Version weiter, bis der Fall abgeschlossen ist |
| Versionen in Produktion | Immer eine | Alt und neu laufen parallel |
| Migration erforderlich | Nein – die Architektur übernimmt das | Ja, oder Sie warten – Migration birgt Datenverlustrisiko |
| Audit-Trail | Sauber und durchgängig – eine Version, eine Zeitlinie | Über Versionen verteilt – Audit wird zum Ratespiel |
| Ergebnis über die Zeit | Prozess bleibt aktuell – keine aufgeschobenen Verbesserungen | Rückstand wächst – niemand fasst laufende Prozesse an |
Was InstantChange™ in der Praxis verändert
Die meisten Prozessanwendungen beginnen mit einem Rückstandsproblem, das niemand kommen sieht. Teams sammeln Verbesserungen an, die sie gerne umsetzen würden, es aber nicht tun, weil das Anfassen eines laufenden Prozesses mit Hunderten aktiven Instanzen zu viel operatives Risiko birgt. Die Änderung wird verschoben. Dann noch eine. Die Lücke zwischen dem, wie der Prozess funktioniert, und dem, wie er funktionieren sollte, wird größer, und niemand möchte eine Migration auslösen.
InstantChange™ beseitigt diese Kosten vollständig. In der Praxis verändert das vier Dinge:
- Sie gehen live, bevor Ihre Anforderungen vollständig sind. Prototyp in 60 Minuten, Bereitstellung am nächsten Tag, Verbesserung basierend auf echter Nutzung. Die erste Version muss nicht perfekt sein.
- Ihr Portfolio skaliert, ohne dass das Team wächst. Drei bis fünf Personen können hundert Anwendungen betreiben, weil die Architektur die Arbeit nicht mit jedem Release schwieriger macht.
- Ihr Audit-Trail bleibt sauber. Immer eine Version des Prozesses. Keine parallelen Versionen, keine Governance-Unklarheit, keine schwierigen Fragen, wenn ein Regulator wissen will, welche Regeln an einem bestimmten Tag für einen bestimmten Fall galten.
Warum InstantChange™ wichtig ist – und für wen
Dieselbe Technologie wirkt unterschiedlich, je nachdem, wo Sie im Unternehmen stehen.
Wenn Sie Process Champion sind, ist die Änderung in dem Moment live, in dem sie die Tests besteht – keine Migration, kein Deployment-Fenster, keine IT-Warteschlange. Jede aktive Instanz übernimmt sie sofort.
Wenn Sie CIO sind, liegt der Kern in der Architektur. Ihr Portfolio skaliert, ohne die Governance-Risiken, die sonst mit Geschwindigkeit einhergehen. Keine parallelen Versionen, keine Schatten-Prozesse, die auf veralteter Logik laufen. Ihr Team bleibt klein. Ihre Kontrolle bleibt erhalten.
Wenn Sie in Compliance oder Recht arbeiten, liegt der Kern im Audit-Trail. Immer eine Version des Prozesses. Wenn ein Regulator fragt, welche Regeln an welchem Tag für welchen Fall galten, ist die Antwort eindeutig.
Wenn Sie Fachbereichsleiter oder Prozessverantwortlicher sind, liegt der Kern in der Reaktionsfähigkeit. Eine Richtlinie ändert sich heute, Ihr Prozess spiegelt das heute wider. Kein Change Request. Keine Warteschlange. Kein veralteter Prozess, während die IT hinterherarbeitet.
Die meisten Plattformen versprechen No-Code. Sobald Sie jedoch eine Anwendung entwickeln möchten, die wirklich zu Ihren Geschäftsprozessen passt, landen Sie oft in einem Skript-Editor. WEBCON geht einen anderen Weg. Mit der Business Rules Engine konfigurieren Sie Bedingungen, Verzweigungen, Weiterleitungen und Eskalationen über einen visuellen Drag-and-Drop-Editor.
Lesbar und anpassbar für alle - genau darum geht es
Befindet sich die Logik in einem Skript, benötigen Sie einen Entwickler, der den Code lesen, verstehen und sicher ändern kann. Ist diese Person im Urlaub, ausgelastet oder nicht mehr im Projekt, bleibt oft nur ein Ticket und Wartezeit.
Mit visuellen Regeln kann jeder, der den Prozess kennt, genau nachvollziehen, was eine Regel bewirkt. Fachbereiche erkennen Probleme schneller und können gezieltes Feedback geben. Der Process Champion nimmt die Änderung vor, InstantChange™ übernimmt den Rest. Alle laufenden Prozessinstanzen werden sofort aktualisiert.
Was ist die Business Rules Engine?
Die Business Rules Engine ist Bestandteil des Designer Studio. Mit ihr definieren Sie die Orchestrierungslogik Ihrer Prozesse: Wer genehmigt was, unter welchen Bedingungen, wann Eskalationen ausgelöst werden und welchen Pfad ein Workflow nimmt.
Regeln lassen sich auf zwei Arten erstellen:
- Per Drag-and-Drop: Ziehen Sie Elemente aus dem Wörterbuchbereich in den Arbeitsbereich und verbinden Sie sie visuell.
- Direkt im Editor: Klicken Sie in den Editor und beginnen Sie zu schreiben. Die Plattform vervollständigt Funktionsnamen automatisch und schlägt passende Operatoren vor.
Regeln geben je nach Anwendungsfall unterschiedliche Datentypen zurück: einen Wert (Text, Dezimalzahl oder Datum), um ein Standardfeld zu setzen, eine Ausführungsbedingung (wahr oder falsch), um zu steuern, ob eine Aktion ausgeführt wird oder welchen Pfad ein Workflow nimmt, oder eine Benutzerliste für die Aufgabenzuweisung.
Regeln können andere Regeln aufrufen. Dadurch erstellen Sie modulare Logik einmal und verwenden sie in verschiedenen Prozessen wieder. Die Plattform verfolgt, wo jede Regel eingesetzt wird, sodass Sie die Auswirkungen einer Änderung kennen, bevor Sie sie vornehmen. Jede Regel wird außerdem automatisch in der generierten Dokumentation erfasst. So bleiben Ihre Prozessspezifikationen ohne zusätzlichen Aufwand aktuell.
Formularregeln funktionieren nach demselben Prinzip
Während die Business Rules Engine die Prozesslogik steuert, übernimmt die Form Rule Engine das Verhalten von Formularen: Sie legt fest, welche Felder angezeigt werden, welche Pflichtfelder sind und welche Werte automatisch berechnet werden, abhängig von den Eingaben der Benutzer. Beide Werkzeuge arbeiten mit einer visuellen Oberfläche.
Die Form Rule Engine erzeugt den benötigten JavaScript-Code automatisch und berücksichtigt dabei die Kompatibilität mit verschiedenen Browsern und Endgeräten. Benötigen Sie Logik, die über das Formular hinausgeht, beispielsweise die Prüfung einer Active Directory-Mitgliedschaft, Daten aus einem externen System oder eine Datenbankabfrage, können Sie eine Business Rule innerhalb einer Formularregel aufrufen. So greifen beide Komponenten nahtlos ineinander.
Praxisbeispiele für Business Rules
So sieht die Erstellung einer Business Rule im Designer Studio aus:
Es gibt nicht den einen richtigen Weg, eine Regel zu erstellen. Der visuelle Editor unterstützt verschiedene Ansätze für dieselbe Aufgabenstellung, sodass jeder Designer seinen eigenen Arbeitsstil entwickeln kann. Da alle Regeln automatisch in der generierten Dokumentation erfasst werden, bleiben sie auch sechs Monate später noch nachvollziehbar, wenn Sie wieder darauf zurückkommen.
Genehmigungen nach Bestellwert und Standort
Ein Einkaufsprozess benötigt abhängig vom Bestellwert und der zuständigen Organisationseinheit unterschiedliche Genehmiger. Bestellungen oberhalb eines definierten Schwellenwerts werden an die Geschäftsleitung weitergeleitet. Liegt der Bestellwert darunter, erfolgt die Genehmigung durch den regionalen Abteilungsleiter. Die Business Rule prüft beide Bedingungen und steuert den Workflow entsprechend. Eine Regel, kein Code.
Dynamische Währungsumrechnung
Eine globale Business Rule ruft den aktuellen Wechselkurs für die ausgewählte Währung zum gewählten Datum ab. Eine Formularregel nutzt diesen Wert, um Rechnungsbeträge automatisch neu zu berechnen, sobald der Benutzer die Währung oder das Datum ändert. Eine Regel, mehrfach in verschiedenen Finanzprozessen wiederverwendbar.
Rollenbasierte Sichtbarkeit von Formularfeldern
Eine Business Rule prüft, ob der angemeldete Benutzer Mitglied einer bestimmten Active Directory-Gruppe ist. Sie gibt das Ergebnis wahr oder falsch zurück. Eine Formularregel verwendet dieses Ergebnis, um Felder ein- oder auszublenden. Die Logik ist für jeden nachvollziehbar, der den Prozess kennt, und kann von jedem Mitglied des Teams angepasst werden.
FAQ
Häufig gestellte
Fragen

Was ist der Unterschied zwischen einer Business Rule und einer Formularregel?
Business Rules steuern das Prozessverhalten: Weiterleitungen, Genehmigungen, Eskalationen und Aufgabenzuweisungen. Formularregeln steuern das Formularverhalten: Sichtbarkeit von Feldern, Berechnungen und Validierungen. Beide arbeiten zusammen, und Formularregeln können Business Rules einbinden, wenn sie Daten von außerhalb des Formulars benötigen.
Können Business Rules einander aufrufen?
Ja. Regeln lassen sich in andere Regeln einbetten, um modulare Logik aufzubauen. Definieren Sie eine Regel einmal und verwenden Sie sie überall dort wieder, wo sie benötigt wird. Die Plattform verfolgt jeden Ort, an dem eine Regel eingesetzt wird.
Kann ich weiterhin SQL nutzen, wenn ich es benötige?
Ja. Die Business Rules Engine unterstützt SQL-Abfragen über die Funktion SQL COMMAND sowie .NET-Code für Fälle, in denen die visuelle Konfiguration nicht ausreicht. Die meisten Prozesse benötigen das nicht, aber die Möglichkeit besteht.
Wer kann Business Rules erstellen und bearbeiten?
Process Champions, die im Designer Studio arbeiten. Fachbereiche erstellen Regeln nicht direkt, können sie aber im visuellen Editor lesen und im Designer Desk gezieltes Feedback geben, weil die Logik sichtbar ist und nicht im Code verborgen liegt.
Was passiert mit laufenden Prozessinstanzen, wenn ich eine Regel ändere?
Aktive Instanzen übernehmen die Änderung sofort. Das ist InstantChange™. Sie ändern eine Regel in einem laufenden Prozess und jede laufende Instanz übernimmt die Änderung in Echtzeit – mit vollständiger Integrität des Audit-Trails.
Werden Regeln in der automatisch generierten Dokumentation erfasst?
Ja. Jede Business Rule erscheint in der Word-Dokumentation, die die Plattform automatisch erstellt. Die Dokumentation bleibt ohne separaten Pflegeaufwand aktuell.
Wo befinden sich globale Regeln und wo prozessspezifische Regeln?
Globale Regeln liegen in den Systemeinstellungen und stehen in allen Prozessen zur Verfügung. Prozessspezifische Regeln werden innerhalb der Konfiguration einzelner Prozesse definiert und sind nur in diesem Prozess verfügbar.

