Der Begriff, der die Kategorie am besten beschreibt, lautet Process Orchestration. Frei übersetzt: das Dirigieren eines Prozesses. Camunda übernimmt die Rolle des Dirigenten, der weiß, welcher Schritt als Nächstes kommt, wer oder welches System ihn ausführt, was bei einem Fehler passiert und wie der Gesamtstatus aussieht. Die einzelnen Aufgaben werden weiterhin von Fachsystemen, Microservices, Menschen oder KI-Diensten erledigt – Camunda sorgt dafür, dass sie in der richtigen Reihenfolge, zuverlässig und nachvollziehbar zusammenspielen.
Das gedankliche Fundament dafür sind zwei offene Standards. BPMN (Business Process Model and Notation) ist eine standardisierte Bildsprache für Prozessdiagramme, die Fachbereich und IT gleichermaßen lesen können. DMN (Decision Model and Notation) ist das passende Gegenstück für Entscheidungslogik – etwa Regeln in Form von Entscheidungstabellen. Weil beide Standards herstellerunabhängig sind, sind in Camunda modellierte Prozesse keine Blackbox, sondern dokumentierte, prüfbare Diagramme.
Camunda richtet sich an Organisationen, die geschäftskritische, langlaufende und mehrstufige Prozesse verlässlich steuern müssen – Prozesse, bei denen es auf Nachvollziehbarkeit, Fehlerresistenz und Auditierbarkeit ankommt. Typische Felder sind Antrags- und Genehmigungsstrecken, das Onboarding von Kunden oder Mitarbeitenden, die Auftrags- und Bestellabwicklung, die Schadensbearbeitung oder komplexe Integrationsprozesse zwischen mehreren Fachsystemen.
Weniger passend ist Camunda, wenn nur zwei Cloud-Apps über einen simplen Auslöser verbunden werden sollen. Für diese leichtgewichtigen Verknüpfungen sind No-Code-Werkzeuge schneller und günstiger. Camunda entfaltet seinen Wert erst dort, wo aus vielen Einzelschritten ein zusammenhängender, kontrollierter Prozess werden soll – und wo dieser Prozess das Unternehmen im Kern trägt. Diese Abgrenzung schärfen wir in Kapitel 06.
Der vielleicht wichtigste Gedanke hinter Camunda ist die konsequente Ausrichtung an BPMN. In vielen Automatisierungswerkzeugen ist der Ablauf in einer proprietären, nur im jeweiligen Tool lesbaren Darstellung gespeichert. Wechselt das Unternehmen das Werkzeug, muss alles neu gebaut werden. Ein BPMN-Diagramm hingegen folgt einer offen dokumentierten Norm und ist damit zugleich verständliche Dokumentation für den Fachbereich und präzise Ausführungsanweisung für die Engine.
Dieser Ansatz löst ein altes Problem der Prozessdigitalisierung: die Kluft zwischen dem, was der Fachbereich beschreibt, und dem, was die IT tatsächlich baut. Wenn beide auf dasselbe Diagramm schauen, sinkt das Risiko von Missverständnissen, und Änderungen lassen sich gemeinsam diskutieren. Aus unserer Projektpraxis ist das ein unterschätzter, aber sehr realer Vorteil – gerade in Organisationen, in denen Prozesse über Jahre gewachsen und in vielen Köpfen unterschiedlich abgespeichert sind.
Gleichzeitig ist Camunda kein Werkzeug, das eine Fachabteilung mal eben am Nachmittag einführt. Die Plattform belohnt eine saubere Prozessanalyse und ein Grundverständnis von Softwarearchitektur. Wer diese Investition scheut, wird ihren Wert nicht heben. Camunda ist ein strategisches Werkzeug für Prozesse, die zählen – nicht ein schneller Klick-Automat für Randaufgaben.
Historisch war Camunda vor allem als einbettbare Prozess-Engine bekannt, die Entwickler direkt in ihre Java-Anwendung integrierten. Diese klassische Generation wird weiterhin in vielen Bestandssystemen betrieben und geschätzt. Die aktuelle Generation, häufig als Camunda 8 bezeichnet, verfolgt einen anderen Architekturansatz: eine cloud-native, horizontal skalierbare Plattform, die als eigenständiger Dienst betrieben wird und über Netzwerkschnittstellen mit der Umgebung kommuniziert.
Das für Entscheider wichtigste Unterscheidungsmerkmal ist das Betriebsmodell. Camunda bietet die aktuelle Plattform in zwei grundsätzlichen Varianten an, die sich funktional ähneln, aber in Verantwortung und Kontrolle deutlich unterscheiden.
Camunda hat starke Wurzeln in der Open-Source-Welt. Teile der Technologie sind quelloffen verfügbar, was die Prüfbarkeit erhöht und den Einstieg für technische Teams erleichtert. Gleichzeitig ist Camunda ein kommerzielles Unternehmen, das seine Plattform in kostenpflichtigen Ausbaustufen mit erweiterten Funktionen, Support und Betriebswerkzeugen anbietet. Für Entscheider heißt das: Ein Ausprobieren ohne große Hürden ist möglich, für den produktiven, unterstützten Betrieb ist jedoch in der Regel eine kommerzielle Lizenz vorgesehen. Welche Komponenten in welcher Stufe enthalten sind, ändert sich über die Zeit und sollte direkt beim Anbieter geprüft werden.
Camunda positioniert sich bewusst als Orchestrierungsschicht für die gesamte Prozesslandschaft und nicht als weiteres Fachsystem. Der Anspruch lautet, dort zu sitzen, wo bislang keine zentrale Steuerung existierte: über den vielen Systemen, die einzeln gut funktionieren, aber gemeinsam einen durchgängigen Prozess ergeben sollen. Diese Positionierung erklärt, warum Camunda in mittleren bis großen Organisationen mit heterogener IT-Landschaft besonders präsent ist – und warum es dort seltener eingesetzt wird, wo die Prozesswelt schlank und die Anforderungen an Nachvollziehbarkeit gering sind.
Der typische Lebenszyklus verdeutlicht das Zusammenspiel: Im Modeler entsteht das BPMN-Diagramm des Prozesses, gemeinsam abgestimmt zwischen Fachbereich und Entwicklung. Dieses Modell wird an die Zeebe-Engine übergeben, die es ausführt und für jede einzelne Instanz den Zustand vorhält. Verlangt ein Schritt menschliches Zutun, erscheint er in der Tasklist; verlangt er einen Systemaufruf, übernimmt ein Connector oder ein angebundener Dienst. In Operate behält der Betrieb den Überblick über alle laufenden Vorgänge und greift bei Störungen ein. Und Optimize liefert langfristig die Kennzahlen, um den Prozess weiter zu verbessern.
Was Camunda von leichtgewichtigen Automatisierern unterscheidet, ist der Umgang mit dem, was schiefgehen kann. Langlaufende Prozesse müssen Ausfälle überstehen: Ein System ist kurz nicht erreichbar, eine Aufgabe bleibt tagelang liegen, ein Schritt schlägt fehl und muss wiederholt werden. Die Engine hält den Zustand jedes Vorgangs sicher fest, kann Schritte gezielt wiederholen und macht sichtbar, wo ein Prozess klemmt. Genau diese Zuverlässigkeit bei komplexen, verteilten und langlaufenden Abläufen ist der eigentliche Grund, warum Organisationen zu einer Orchestrierungsplattform greifen – und nicht zu einer einfachen Wenn-Dann-Automatisierung.
Die zentrale Idee ist die eines Orchestrators für heterogene Akteure: In einem modernen Prozess arbeiten Menschen, klassische Systeme, RPA-Roboter und KI-Modelle zusammen. Camunda versteht sich als die Instanz, die diese unterschiedlichen Akteure koordiniert – und dabei jederzeit weiß, wer welchen Schritt erledigt hat und was bei einem Fehler zu tun ist.
RPA (Robotic Process Automation) automatisiert Aufgaben, indem Software die Bedienung anderer Programme über deren Oberfläche nachahmt – etwa das Abtippen von Daten aus einem Altsystem, das keine Schnittstelle bietet. RPA ist stark bei genau dieser Brücke zu Alt- und Fremdsystemen, aber schwach bei der Steuerung des Gesamtprozesses und bei der Fehlerbehandlung. Camunda schließt hier eine Lücke: Der RPA-Roboter wird zu einem einzelnen, klar umrissenen Schritt innerhalb eines BPMN-Prozesses, während die Orchestrierung – Reihenfolge, Wiederholung, Eskalation, Übergabe an Menschen – bei Camunda liegt. Diese Kombination gilt als deutlich robuster als reine RPA-Ketten, die bei einer Störung oft still stehenbleiben.
Über Connectoren lassen sich KI-Dienste als Schritt in einen Prozess einbinden – etwa um ein eingehendes Dokument zu klassifizieren, einen Freitext in strukturierte Felder zu überführen oder einen Sachverhalt einzuordnen. Der entscheidende Unterschied zur reinen KI-Automatisierung liegt im Kontext: Der KI-Aufruf ist eingebettet in einen Prozess, der genau definiert, was vor und nach dem Modellaufruf passiert. So lässt sich zum Beispiel festlegen, dass ein KI-Ergebnis unterhalb einer bestimmten Sicherheit automatisch einem Menschen zur Prüfung vorgelegt wird. KI liefert die Einschätzung, der Prozess behält die Kontrolle.
Die jüngste Entwicklungsstufe ist die Orchestrierung von KI-Agenten: Akteure, die nicht starr einem festen Pfad folgen, sondern eigenständig entscheiden, welche Schritte zur Erfüllung einer Aufgabe nötig sind. Camunda positioniert sich hier mit einem charakteristischen Anspruch – Agenten sollen nicht unkontrolliert agieren, sondern innerhalb der Leitplanken eines definierten Prozesses. Der BPMN-Prozess gibt den Rahmen vor, in dem ein Agent flexibel handeln darf, und stellt sicher, dass jeder Schritt nachvollziehbar bleibt und ein Mensch an den richtigen Stellen eingreifen kann.
Dieser Ansatz ist bemerkenswert, weil er die größte Schwäche autonomer Agenten adressiert: ihre schwer vorhersehbare, schwer prüfbare Natur. Ein Agent, der frei im Unternehmen agiert, ist ein Risiko; ein Agent, der innerhalb eines definierten, überwachten Prozesses agiert, wird beherrschbar. Für geschäftskritische Abläufe ist das ein wichtiger Unterschied. Gleichzeitig gilt auch hier: Die Technologie ist jung, und wir empfehlen einen schrittweisen, gut überwachten Einsatz, bei dem der Mensch die Kontrolle über wirksame Entscheidungen behält.
Wie bei jeder Plattform raten wir zu einem nüchternen Blick. KI und Agenten entfalten ihren Wert dort, wo ein Prozessschritt echtes Sprach- oder Kontextverständnis erfordert – das Einordnen unstrukturierter Eingaben, das Verdichten von Dokumenten, das Vorbereiten einer menschlichen Entscheidung. Für strukturierte, regelbasierte Schritte bleibt die klassische, deterministische Modellierung überlegen: nachvollziehbar, testbar, günstig. Die Kunst der Orchestrierung besteht gerade darin, jeden Schritt dem passenden Akteur zuzuweisen – Mensch, System, Roboter oder KI – und nicht KI aus Prinzip überall einzusetzen.
Das ist ein wichtiger konzeptioneller Unterschied zu No-Code-iPaaS-Werkzeugen: Deren Stärke ist eine riesige Bibliothek vorkonfigurierter App-Verbindungen. Camundas Stärke ist die tiefe, flexible Integration in gewachsene, oft individuelle Systemlandschaften – dort, wo es keine fertige Verbindung gibt und wo der Prozess das eigentlich Komplexe ist.
Connectors sind vorgefertigte Bausteine, die einen Prozessschritt mit einem externen System verbinden, ohne dass für jeden Fall eigener Code geschrieben werden muss. Es gibt allgemeine Connectors – etwa für HTTP- und REST-Aufrufe, mit denen sich beliebige moderne Schnittstellen ansprechen lassen – sowie spezifischere Bausteine für gängige Dienste. Ergänzend lassen sich eigene Connectors erstellen und im Modeler wie fertige Bausteine nutzen. Damit sinkt der Aufwand für wiederkehrende Anbindungen erheblich, während für Sonderfälle die volle Flexibilität erhalten bleibt.
Der eigentliche Integrationsansatz von Camunda ist das Worker-Prinzip: Ein Prozessschritt wird als Aufgabe veröffentlicht, und ein externer Dienst – ein Microservice – meldet sich, holt die Aufgabe ab, erledigt sie und meldet das Ergebnis zurück. Dieses Muster entkoppelt die Orchestrierung sauber von der Ausführung. Die Engine muss nicht wissen, wie ein Schritt technisch umgesetzt wird; sie muss nur wissen, dass er erledigt wurde. Für Organisationen mit einer Microservice-Architektur ist das ein natürliches, sehr tragfähiges Muster – Camunda wird zur Klammer, die viele kleine, unabhängige Dienste zu einem Geschäftsprozess zusammenfügt.
Weil die Kommunikation über offene Schnittstellen und gängige Programmiersprachen erfolgt, ist Camunda weitgehend technologieneutral. Die einzelnen Dienste können in unterschiedlichen Sprachen und auf unterschiedlichen Plattformen laufen – sie müssen sich nur an das vereinbarte Muster halten. Diese Offenheit ist ein wesentlicher Grund, warum sich Camunda gut in bestehende, heterogene Landschaften einfügt, statt eine Neuentwicklung von Grund auf zu erzwingen.
Für Systeme, die keine moderne Schnittstelle bieten – häufig ältere Fachanwendungen –, kommt die bereits beschriebene RPA-Brücke ins Spiel. Ein RPA-Roboter bedient das Altsystem stellvertretend über dessen Oberfläche und wird als Prozessschritt orchestriert. So lassen sich auch Systeme einbinden, die technisch eigentlich nicht dafür vorgesehen sind. Wir betrachten das in Projekten als pragmatische Übergangslösung: nützlich, um schnell Wert zu schaffen, aber nach Möglichkeit mittelfristig durch eine echte Schnittstelle abzulösen, weil oberflächenbasierte Automatisierung anfälliger für Änderungen ist.
Klassische BPM-Suiten hatten oft den Anspruch, einen Prozess ganzheitlich abzubilden – inklusive eigener Oberflächen, eigener Datenhaltung und einer meist proprietären, schwergewichtigen Plattform. Camunda verfolgt einen schlankeren, entwicklerfreundlicheren Ansatz: Es konzentriert sich auf die Orchestrierung und überlässt die Fachlogik den bestehenden Systemen. Der Vorteil ist eine geringere Bindung an eine Monolith-Plattform und eine bessere Einbettung in moderne Architekturen. Der Preis ist, dass Camunda für sich genommen weniger fertige Bausteine für Oberflächen und Datenhaltung mitbringt – vieles wird bewusst dem umgebenden System überlassen.
iPaaS-Werkzeuge und No-Code-Automatisierer beantworten eine andere Frage: Sie verbinden Systeme oder Apps schnell und mit geringem technischem Aufwand. Ihre Stärke ist die Breite fertiger Verbindungen und die niedrige Einstiegshürde. Ihre Grenze ist die Orchestrierung langlaufender, geschäftskritischer Prozesse mit vielen Beteiligten, komplexer Fehlerbehandlung und hohem Anspruch an Nachvollziehbarkeit. Genau dort beginnt Camundas Domäne. Vereinfacht: No-Code und iPaaS verbinden, Camunda orchestriert.
In der Praxis schließen sich diese Werkzeuge nicht aus – im Gegenteil. Wir sehen häufig sinnvolle Kombinationen: leichtgewichtige Automatisierung für Randprozesse und schnelle Verknüpfungen, Camunda für die geschäftskritischen Kernprozesse, die das Unternehmen tragen. Die Kunst besteht darin, für jeden Prozess das angemessene Werkzeug zu wählen, statt aus einem einzigen Werkzeug alles herauspressen zu wollen.
Beim SaaS-Modell betreibt der Anbieter die Plattform. Das Unternehmen erhält einen betriebsbereiten Dienst und konzentriert sich auf die Modellierung und Anbindung seiner Prozesse. Der Vorteil ist ein schneller Start und ein geringer Betriebsaufwand; die Kehrseite ist, dass Daten durch die Infrastruktur des Anbieters fließen und der Serverstandort sowie die Verarbeitungsbedingungen gesondert zu prüfen sind.
Beim Self-Managed-Modell läuft Camunda in der eigenen Umgebung – im eigenen Rechenzentrum oder in einer selbst gewählten Cloud. Das Unternehmen hat volle Kontrolle über Daten, Standort und Konfiguration, trägt dafür aber die Verantwortung für Installation, Betrieb, Aktualisierung und Skalierung. Für Organisationen mit hohen Souveränitätsanforderungen oder strengen regulatorischen Vorgaben ist dies häufig der einzig gangbare Weg – und zugleich einer der stärksten Gründe, sich überhaupt für Camunda zu entscheiden.
Die aktuelle, cloud-native Generation von Camunda ist auf den Betrieb mit Kubernetes ausgelegt – einer Standardtechnologie zum Betrieb containerisierter Anwendungen. Das ist Fluch und Segen zugleich. Der Segen: Kubernetes ist ein weit verbreiteter Industriestandard, der Skalierung, Ausfallsicherheit und reproduzierbaren Betrieb ermöglicht. Der Fluch: Kubernetes selbst ist anspruchsvoll und verlangt spezialisiertes Betriebs-Know-how. Ein Unternehmen, das Self-Managed betreibt, muss diese Kompetenz entweder im Haus haben oder einkaufen. Diese Anforderung sollte niemand unterschätzen – sie ist einer der häufigsten Stolpersteine bei der Einführung.
Aus unserer Projektpraxis hat sich ein schrittweises Vorgehen bewährt, das den Reifegrad kontrolliert erhöht, statt zu früh zu breit zu starten.
Auffällig ist ein klares Muster: Camunda glänzt bei langlaufenden, mehrstufigen Prozessen, die über Systemgrenzen und Abteilungen hinweg koordiniert werden müssen und bei denen Nachvollziehbarkeit zählt. Der Wert entsteht nicht durch das Wegautomatisieren einer einzelnen Handbewegung, sondern durch die verlässliche Steuerung eines ganzen Ablaufs – inklusive der Fälle, in denen etwas schiefgeht und ein Mensch eingreifen muss.
Wichtig für die Erwartungshaltung im Mittelstand: Camunda lohnt sich nicht für jede Automatisierung. Ein Unternehmen sollte mit dem einen Prozess beginnen, der wirklich zählt und heute Schmerzen bereitet – nicht mit einer Randaufgabe. Der Nutzen wird dort am schnellsten sichtbar, wo ein kritischer Prozess bislang unübersichtlich, fehleranfällig oder intransparent war. Wir raten deshalb, den ersten Camunda-Prozess mit Bedacht auszuwählen: sichtbar genug, um zu überzeugen, aber überschaubar genug, um beherrschbar zu bleiben.
Ein realistischer Punkt, den wir offen ansprechen: Camunda verlangt technische Kompetenz. Anders als ein No-Code-Werkzeug, das eine Fachabteilung allein bedienen kann, braucht eine Orchestrierungsplattform das Zusammenspiel aus Fachbereich und Entwicklung. Für den Mittelstand bedeutet das, entweder internes Know-how aufzubauen oder einen Partner an der Seite zu haben. Der Vorteil des BPMN-Standards hilft hier: Weil die Modelle offen und lesbar sind, lässt sich Wissen besser teilen und die Abhängigkeit von einzelnen Köpfen verringern. Dennoch bleibt der Aufbau von Kompetenz eine bewusste Investition, die eingeplant werden muss.
Konkrete Preise nennen wir hier bewusst nicht, weil Camunda seine Lizenzmodelle und Konditionen anpasst und jede Zahl schnell veralten würde. Prüfen Sie die aktuellen Konditionen stets direkt beim Anbieter. Wichtiger ist das Verständnis der Kostenstruktur, und die unterscheidet sich grundlegend von der task- oder operationsbasierten Abrechnung vieler No-Code-Tools.
Die Gesamtkosten einer Camunda-Lösung setzen sich aus mehreren Bausteinen zusammen, die je nach Betriebsmodell unterschiedlich gewichtet sind:
Anders als volumenbasierte Modelle skaliert Camunda nicht zwangsläufig mit der Zahl der Durchläufe teurer – gerade beim Self-Hosting verursacht ein zusätzlicher Prozessdurchlauf keine direkte Zusatzgebühr. Der wirtschaftliche Kern liegt eher in Lizenz, Betrieb und Kompetenz. Das macht Camunda bei hohem Prozessvolumen potenziell attraktiv, während der Einstieg wegen des Kompetenzbedarfs schwerer wiegt als bei No-Code-Tools.
Hier liegt eines der stärksten Argumente für Camunda im DACH-Raum. Camunda ist ein deutscher Anbieter mit Sitz in Berlin und unterliegt damit europäischem Recht. Vor allem aber erlaubt das Self-Managed-Modell, die gesamte Plattform in der eigenen Infrastruktur zu betreiben. In dieser Konstellation verlassen die verarbeiteten Prozessdaten die eigene Umgebung nicht – ein struktureller Vorteil für Datenhoheit und EU-Souveränität, den rein cloud-basierte US-Anbieter so nicht bieten können.
Für Unternehmen mit sensiblen Daten, für regulierte Branchen oder für Organisationen mit hohen Souveränitätsanforderungen ist dies oft der ausschlaggebende Grund, sich für Camunda zu entscheiden. Die datenschutzrechtliche Bewertung wird erheblich einfacher, wenn Daten die eigene Infrastruktur nicht verlassen und kein Transfer in ein Drittland stattfindet. Das ganze Themenfeld eines Drittlandtransfers und seiner rechtlichen Grundlagen entfällt in einem sauber aufgesetzten Self-Managed-Szenario weitgehend. Bei der Cloud-Variante hingegen sollten Serverstandort und Verarbeitungsbedingungen konkret beim Anbieter geprüft werden.
Bei aller Stärke gehört zur ehrlichen Einordnung auch die Kehrseite: Der Souveränitätsvorteil des Self-Hostings erkauft sich durch Betriebsaufwand und Kompetenzbedarf. Wer die volle Datenhoheit will, muss die Plattform selbst zuverlässig betreiben – mit allem, was dazugehört. Für viele Mittelständler ist das ein lohnender Tausch, weil Datenhoheit ein echtes Geschäftsargument ist. Für andere ist der Aufwand höher als der Nutzen, und das SaaS-Modell mit sorgfältiger Prüfung des Serverstandorts ist der pragmatischere Weg. Diese Abwägung ist individuell und sollte bewusst getroffen werden – wir begleiten Kunden dabei mit einer nüchternen Gegenüberstellung von Aufwand und Nutzen.
