BPMN 2.0 als Ihre Exit-Strategie: Wie Sie Kernprozesse modellieren, um sie jederzeit von Salesforce, SAP & Co. zu migrieren

BPMN 2.0 als Ihre Exit-Strategie: Wie Sie Kernprozesse modellieren, um sie jederzeit von Salesforce, SAP & Co. zu migrieren

Ihr Vertriebs- oder Serviceprozess steckt tief in Salesforce, SAP oder einem anderen monolithischen SaaS-System. Jede Anpassung ist teuer, jede Integration ein Kraftakt. Ein Wechsel gleicht einer Operation am offenen Herzen. Diese Abhängigkeit von proprietären Ökosystemen – der Vendor-Lock-in – ist für viele Unternehmen eine strategische Sackgasse. Die Frage ist nicht mehr ob, sondern wie Sie die Kontrolle zurückgewinnen.

Die Antwort ist kein „nächstes, besseres“ System. Sie liegt in einem fundamentalen Perspektivwechsel: Trennen Sie Ihre Geschäftsprozesse von der ausführenden Technologie. Genau hier wird der offene Standard BPMN 2.0 (Business Process Model and Notation) zu Ihrem strategischen Instrument. Ihre Blaupause für technologische Freiheit.

Dieser Leitfaden ist keine akademische Abhandlung. Er ist ein Fahrplan für Entscheider – CDOs, Heads of Business Process Management und IT-Strategen –, die eine praktikable Exit-Strategie entwickeln müssen. Wir zeigen, wie Sie Ihre in Salesforce oder SAP gefangenen Kernprozesse extrahieren, standardisieren und so gestalten, dass die Technologie darunter austauschbar wird.

Die 80.000-Euro-Frage: Was kostet Sie das Warten wirklich?

Die Angst vor den Migrationskosten lähmt. In der Praxis zeigt sich, dass eine mittelständische Salesforce-Datenmigration zwischen 25.000 und 80.000 Euro kosten und 6 bis 18 Monate dauern kann. Hinzu kommen die Kosten für den Neuaufbau von Integrationen, die sich schnell auf weitere 25.000 bis 45.000 Euro summieren können.

Diese Zahlen zeigen: Ein Systemwechsel ohne präzise Vorbereitung ist ein unkalkulierbares Risiko. Aber die Kosten des Nichtstuns sind oft höher. Steigende Lizenzgebühren, mangelnde Flexibilität und die Unfähigkeit, auf neue Marktanforderungen zu reagieren, sind versteckte Kosten, die Ihre Wettbewerbsfähigkeit untergraben. So stand in einer Umfrage unter SAP-Anwendern in der Schweiz eine große Mehrheit der Befragten der Produktstrategie von SAP „kritisch“ gegenüber. Ein klares Zeichen für Unzufriedenheit.

Der Weg aus diesem Dilemma führt über eine souveräne, plattformunabhängige Prozesslandkarte. BPMN 2.0 ist der ISO-Standard dafür.

Teil 1: Reverse-Engineering Ihres Lock-ins – Prozesse aus proprietären Systemen extrahieren

Der erste Schritt zur Freiheit ist, das Unsichtbare sichtbar zu machen. Ihre kritischen Prozesse sind oft nicht explizit dokumentiert, sondern in Konfigurationen, Workflows (z. B. Salesforce Flows) und Custom Code (z. B. Apex) „einbetoniert“. Die Aufgabe ist, diese verborgene Logik zu extrahieren und in das klare Format von BPMN 2.0 zu überführen.

Dafür hat sich eine dreistufige Methode bewährt:

Schritt 1: Entdecken (Discover)

Nutzen Sie die Prinzipien des Process Mining, auch ohne Spezial-Tool. Analysieren Sie die Event-Logs und Audit-Trails Ihres CRM-Systems. Wann ändert sich der Status eines Leads? Welche Aktion löst eine Benachrichtigung aus? Wer gibt welche Daten ein, damit eine Opportunity in die nächste Stufe wechselt? Führen Sie Workshops mit den Key-Usern durch und lassen Sie sich die Prozesse live im System zeigen. Sie wollen die tatsächlichen „As-Is“-Prozesse verstehen, nicht die, die in veralteten Handbüchern stehen.

Schritt 2: Dokumentieren (Document)

Übersetzen Sie die Erkenntnisse in BPMN-2.0-Modelle. Visualisieren Sie mit einem BPMN-Tool die Sequenz von Aufgaben, Entscheidungen (Gateways), Ereignissen und beteiligten Rollen (Pools/Lanes). Der entscheidende Punkt: Sie modellieren die fachliche Logik, losgelöst von der technischen Implementierung. Eine Aufgabe heißt „Bonität des Kunden prüfen“, nicht „Apex-Klasse ‚CreditCheck‘ aufrufen“. Diese Abstraktion ist der Schlüssel.

Schritt 3: Validieren (Validate)

Legen Sie die BPMN-Diagramme den Fachexperten und Stakeholdern vor. Die visuelle Natur von BPMN 2.0 erlaubt es auch Nicht-Technikern, die Modelle zu prüfen. Ist das wirklich unser Weg, einen Neukunden anzulegen? Fehlt ein Genehmigungsschritt? Dieser Zyklus stellt sicher, dass Ihr BPMN-Modell zur „Single Source of Truth“ für Ihre Geschäftsprozesse wird.

Danach besitzen Sie das wertvollste Gut für jede zukünftige IT-Entscheidung: eine präzise, plattformunabhängige Dokumentation Ihrer Abläufe.

Teil 2: Die Architektur der Freiheit – ‚Was‘ von ‚Wie‘ trennen

Ein BPMN-Diagramm ist mehr als ein Bild. Es ist das Herzstück einer entkoppelten Systemarchitektur, die Ihre Prozesslogik (das „Was“) von der ausführenden Technologie (das „Wie“) trennt. Ein bewährtes Muster dafür ist die Hexagonale Architektur, auch bekannt als „Ports and Adapters“.

Stellen Sie sich Ihr BPMN-Modell als den stabilen Kern im Zentrum vor. Dieser Kern definiert die Geschäftslogik: „Nach Eingang einer Bestellung muss eine Bonitätsprüfung erfolgen.“

• Ports sind die Schnittstellen des Kerns zur Außenwelt (z. B. „starteBonitätsprüfung“).
• Adapter sind die austauschbaren technologischen Komponenten, die an diese Ports „andocken“.

In Ihrem aktuellen Setup ist Salesforce der Adapter. Der Aufruf zur Bonitätsprüfung ist durch einen Salesforce-Flow oder Apex-Code implementiert. In einer hexagonalen Architektur würde der BPMN-Prozess über einen definierten Port einen Adapter aufrufen. Dieser Adapter könnte heute Salesforce sein, morgen eine Open-Source-Lösung, übermorgen ein Microservice oder eine RPA-Lösung für einen Legacy-Prozess.

Die Vorteile dieser Entkopplung sind pragmatisch:

1. Austauschbarkeit: Sie können die Technologie hinter einem Prozessschritt wechseln, ohne den Kernprozess selbst anzufassen.
2. Testbarkeit: Der Prozesskern lässt sich isoliert von externen Systemen testen. Das erhöht Qualität und Stabilität.
3. Technologische Souveränität: Ihre Prozesse gehören wieder Ihnen. Sie entscheiden, welche Technologie am besten passt, nicht der Vendor.

Teil 3: Vom Blueprint zur Realität – BPMN als lebendiges Gut verankern

Die größte Gefahr bei Dokumentationsprojekten sind „Friedhofsdokumente“, die in der Schublade veralten. Um das zu verhindern, muss Prozessmodellierung ein lebendiger, kontinuierlicher Prozess im Unternehmen werden.

Drei Strategien haben sich bewährt: Erstens, gründen Sie ein Center of Excellence (CoE) für Prozessmanagement. Ein kleines Team aus Fach- und IT-Experten übernimmt die Verantwortung für die Prozesslandkarte, agiert als Hüter der Standards und schult Mitarbeiter. Zweitens, machen Sie BPMN zur Grundlage für alle Anforderungsanalysen. Jede Anforderung für neue Software muss zuerst im BPMN-Modell abgebildet werden. So wird verhindert, dass die IT am Geschäftsprozess vorbeiplant. Das Diagramm wird zur gemeinsamen Sprache. Drittens, integrieren Sie die Modelle in Ihre Ausführungsumgebung. Moderne Prozess-Engines können BPMN-2.0-Modelle direkt ausführen und so Konfigurationen in anderen Systemen (z.B. einem neuen CRM) steuern und validieren.

Indem Sie die Prozesshoheit zurück ins Unternehmen holen, schaffen Sie eine nachhaltige Basis für Agilität. Sie verhindern, das Lock-in-Problem mit dem nächsten Anbieter einfach zu wiederholen.

Teil 4: Fallstudie – Der CRM-Migrations-Playbook

Spielen wir die Migration eines zentralen „Lead-to-Opportunity“-Prozesses von einem proprietären SaaS-CRM zu einer souveränen Lösung durch.

Das Ziel: Den Prozess nahtlos umziehen, ohne den Vertrieb lahmzulegen.

Die Methode: Das Strangler Fig Pattern. Statt eines „Big Bang“-Go-Live „erdrosseln“ wir das Altsystem schrittweise. Funktionalität wird Stück für Stück in die neue Lösung überführt, der Datenverkehr langsam umgeleitet.

Der Migrationsfahrplan

1. Phase 1: Modellierung & Zielarchitektur (Woche 1-4)

   Kontakt aufnehmen
   • Aktion: Der bestehende Lead-to-Opportunity-Prozess wird per Reverse-Engineering in BPMN 2.0 überführt und validiert.
   • Ergebnis: Ein klares, von allen abgenommenes Prozessmodell. Die Blaupause für die Implementierung.

2. Phase 2: Parallele Implementierung (Woche 5-12)

   • Aktion: Das neue System wird auf Basis des BPMN-Modells konfiguriert. Gleichzeitig wird eine Synchronisationsschicht (z. B. über APIs) aufgebaut, die Daten zwischen altem und neuem System abgleicht.
   • Ergebnis: Beide Systeme laufen parallel. Eine kleine Pilotgruppe beginnt, im neuen System zu arbeiten.

3. Phase 3: Schrittweise Umleitung (Woche 13-16)

   • Aktion: Neue Leads werden nur noch im neuen System angelegt. Bestehende Leads laufen im Altsystem weiter, aber alle relevanten Daten werden synchronisiert. Die „Strangler Fig“ umschließt das Altsystem.
   • Ergebnis: Der operative Druck auf das Altsystem nimmt ab. Die Anwender gewinnen Vertrauen.

4. Phase 4: Go-Live & Abschaltung (Woche 17)

   • Aktion: An einem Stichtag erfolgt die finale Migration der verbleibenden aktiven Datensätze. Der Zugriff auf das Altsystem wird auf „read-only“ gesetzt und später komplett abgeschaltet.
   • Ergebnis: Der Prozess läuft vollständig auf der neuen, souveränen Plattform. Die Fesseln des Vendor-Lock-ins sind gelöst.

Dieser methodische, risikominimierte Ansatz ist nur möglich, weil Sie zu Beginn eine klare, technologieunabhängige Prozesslandkarte mit BPMN 2.0 erstellt haben.

Ihr nächster Zug: Technologische Souveränität zurückerlangen

Der Ausstieg aus einem tief integrierten System wie Salesforce oder SAP ist keine rein technische, sondern eine strategische Herausforderung. Wenn Sie BPMN 2.0 nicht als Dokumentationswerkzeug, sondern als Fundament Ihrer Exit-Strategie begreifen, wird ein unlösbares Problem zu einem planbaren Projekt.

Sie hören auf, Opfer der Produkt-Roadmaps von Vendoren zu sein. Sie werden wieder zum Architekten Ihrer eigenen Prozesslandschaft. Sie investieren nicht mehr nur in Lizenzen, sondern in ein nachhaltiges, souveränes Asset: Ihre modellierten Kernprozesse.

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Wo stehen Sie? Wie stark sind Ihre Abhängigkeiten? Nutzen Sie unseren Readiness-Check für eine fundierte Einschätzung.

Beginnen Sie noch heute damit, Ihre Fesseln zu kartieren. Denn nur was Sie kennen, können Sie auch verlassen.