Hier liegt der Fehler, den Teams am häufigsten machen: Sie behandeln Geschäftsprozessautomatisierung und Geschäftsprozessmanagement als zwei Bezeichnungen für dieselbe Kaufentscheidung. Also kaufen sie ein BPA-Tool und nennen es BPM, oder sie investieren in eine BPM-Plattform und nehmen an, die Ausführung werde sich von selbst regeln. Beides funktioniert nicht. Was ist der Unterschied zwischen den beiden? Größer, als die meisten erwarten, und genau in dieser Lücke geraten Programme zur Prozessverbesserung ins Stocken.
Was Teams erst spät lernen
- BPM ist eine Disziplin, keine Software – wer es mit seinen Tools verwechselt, verliert die Governance aus dem Blick.
- Automatisierung ohne BPM-Grundlage spart keine Zeit – sie führt fehlerhafte Prozesse nur schneller aus.
- BPA vs. BPM ist keine Wahl zwischen zwei Optionen; es ist eine Hierarchie, in der eines die Richtung vorgibt und das andere sie umsetzt.
Was Business Process Management tatsächlich umfasst
Business Process Management ist eine Managementdisziplin, keine Produktkategorie. Die von Gartner stammende Definition umfasst Entdeckung, Modellierung, Analyse, Messung, Verbesserung und Optimierung – alles zur Unterstützung der Geschäftsstrategie. Das ist ein Governance-Zyklus, keine Softwareinstallation. BPM ist fortlaufend, iterativ und organisatorisch. Es stellt die Frage: Wie sollten diese Prozesse aussehen, und woran erkennen wir, dass sie gesund sind?
In der Praxis sieht der Lebenszyklus so aus: entwerfen, modellieren, implementieren, überwachen, iterieren. Dann wiederholen. BPM endet nicht, wenn ein Prozess dokumentiert ist. Es endet, wenn der Prozess dauerhaft die Zielvorgaben erfüllt – was meist nie der Fall ist, weil sich Ziele ändern. Genau darum geht es. Prozessmodellierung und Prozessverbesserung sind keine Liefergegenstände. Sie sind Gewohnheiten.
Der Fehler, den ich immer wieder sehe – in Support-Tickets, in Onboarding-Gesprächen, in Gesprächen mit Operations-Verantwortlichen, die sechs Monate in der Einführung einer Plattform stecken –, ist die Annahme, BPM sei gleichbedeutend mit der Software, die das Team im letzten Quartal gekauft hat. Das ist es nicht. Eine BPM-Plattform ist ein Tool, das Sie innerhalb einer BPM-Disziplin einsetzen können. Managementprozesse erfordern per Definition, dass jemand sie verantwortet, misst und verändert, wenn sie vom Kurs abweichen. Den entsprechenden Teil kann die Software nicht übernehmen.
Was Business Process Automation tatsächlich leistet
Business Process Automation ist die technologische Ausführungsebene. Die von Gartner stammende und von Bizagi wiederholte Definition beschreibt BPA als die Automatisierung komplexer Geschäftsprozesse über herkömmliche Datenmanipulation hinaus mithilfe fortschrittlicher Technologien. Das ist ein weiter gefasster Umfang, als die meisten Teams annehmen, wenn sie ihr erstes Workflow-Tool einführen.
BPA steht für einen ganzheitlichen Ansatz, nicht für den Kauf eines einzelnen Tools. Laut Appian kann moderne BPA RPA, Workflow-Automatisierungsplattformen, KI und Datenmanagement kombinieren, die gemeinsam als Teil einer Ausführungsstrategie arbeiten. Das ist wichtig, denn dem Missverständnis, dem ich am häufigsten begegne, liegt die Annahme zugrunde, dass jemand nach der Einführung eines Automatisierungstools bereits „BPA betreibt“. Vielleicht tun Sie das. Aber wenn dieses Tool einen einzelnen Schritt in einem Prozess abwickelt, haben Sie eine Aufgabe automatisiert, keinen Geschäftsprozess.
Die Automatisierungstechnologien in echten BPA-Implementierungen reichen von regelbasierter Workflow-Automatisierung für Genehmigungsweiterleitung und Dateneingabe über RPA-Bots für die Interaktion mit Altsystemen bis hin zu KI-Ebenen für Klassifizierung und unstrukturierte Eingaben. BPA ist der architektonische Rahmen. Jedes einzelne Tool, das Sie kaufen, ist eine Komponente darin.
Unterschiede zwischen BPA und BPM: Strategie vs. Taktik
Die Einordnung von ProcessMaker ist hier hilfreich: BPM ist Strategie, BPA ist Taktik. SAP Signavio ergänzt dies um eine Hierarchie, in der BPM das gesamte Programm steuert und BPA innerhalb dieses Rahmens ausführt. Die folgende Tabelle ordnet die Dimensionen zu, die für ein Team tatsächlich relevant sind, wenn es herausfinden will, über welches Thema es gerade spricht.
| Dimension | BPM | BPA |
|---|---|---|
| Wesen | Managementdisziplin | Technologieansatz |
| Umfang | End-to-End-Governance in der gesamten Organisation | Ausführung eines spezifischen Workflows oder Prozesses |
| Zentrale beantwortete Frage | Wie sollte dieser Prozess funktionieren? | Wie führen wir ihn schneller und mit weniger manuellem Aufwand aus? |
| Verantwortlich dafür | Prozessexzellenz, Operations-Verantwortliche, Prozessverantwortliche | IT, Automatisierungsteam sowie Fachbereichs- und IT-Teams gemeinsam |
| Ergebnis | Prozessmodell, Governance-Richtlinie, KPI-Basiswert | Automatisierter Workflow, reduzierter manueller Aufwand, Ausführungsprotokolle |
| Zeithorizont | Kontinuierlicher Verbesserungszyklus | Projekt- oder Implementierungszyklus |
| Rolle in der Automatisierungsstrategie | Definiert, welche Geschäftsprozesse verbessert werden sollten und warum | Setzt die Automatisierungsstrategie auf Ausführungsebene um |
Die Designdimension ist in der Praxis am wichtigsten. BPM fragt „Sollte dieser Prozess in seiner aktuellen Form überhaupt existieren?“, bevor BPA fragt „Wie führen wir ihn automatisch aus?“. Wer die erste Frage überspringt, erzeugt mit Automatisierungsprogrammen oft messbare Ergebnisse, die jedoch das Falsche messen.
Warum BPA und BPM keine konkurrierenden Disziplinen sind
Das ist die falsche Dichotomie, die ich am häufigsten bei der Einordnung von Tooling-Entscheidungen durch Teams sehe: Sie behandeln BPM und BPA als zwei konkurrierende Optionen, wählen eine davon und ignorieren die andere. Das Ergebnis ist vorhersehbar und tritt in zwei Varianten auf.
Variante eins: BPA ohne BPM. Das Team führt Automatisierungstools ein, erstellt Workflows und berichtet über Effizienzgewinne. Sechs Monate später laufen die Workflows schnell und erzeugen falsche Ergebnisse, weil niemand das zugrunde liegende Prozessdesign gesteuert hat. Die Automatisierung wird ausgeführt, aber das, was sie ausführt, wurde nie als richtiges Verhalten validiert. Das ist der Fall, der im Support auftaucht: Der Workflow läuft, das Dashboard ist grün, aber das Geschäftsergebnis entspricht nicht den Erwartungen.
Variante zwei: BPM ohne BPA. Das Team erstellt umfassende Prozessdokumentationen, bildet jeden Schritt ab und führt Governance-Reviews durch. An der Ausführungsgeschwindigkeit ändert sich jedoch nichts, weil keine Automatisierungsebene das modellierte Verhalten durchsetzt. Die Prozesskarten liegen irgendwo in einem gemeinsamen Laufwerk.
Die Hierarchie von SAP Signavio macht die richtige Beziehung klar: BPM gibt die strategische Richtung vor, die Prozessanalyse identifiziert Verbesserungsziele, und anschließend setzen BPA oder andere Automatisierungstools diese Verbesserungen im großen Maßstab um. BPA und RPA arbeiten beide innerhalb des umfassenderen BPM-Programms. Sie sind keine Alternativen dazu. Ein Team, das RPA-Bots ohne BPM-Framework einführt, verfügt über schnelle Ausführung, aber keine Governance. Die Bots laufen. Niemand hat definiert, wie „korrekt“ aussieht – deshalb laufen die Bots korrekt in die falsche Richtung.
Die Verbesserung von Geschäftsprozessen erfordert beide Ebenen. Die Disziplin setzt die Geschäftsziele. Die Technologie setzt sie um. Keine Ebene macht die andere überflüssig, und die Reihenfolge ist entscheidend: zuerst Governance, dann Automatisierung.
Wie BPM die Voraussetzungen schafft, damit sich Automatisierung lohnt
Einen fehlerhaften Prozess zu automatisieren, behebt ihn nicht. Es skaliert ihn. Ich habe das in so vielen Onboarding-Gesprächen gesagt, dass es reflexartig kommt, doch genau diese Abhängigkeitslogik überspringen die meisten Teams. Wenn der bestehende Prozess eine fehlerhafte Weiterleitungsregel, eine falsche Feldzuordnung oder einen Engpass enthält, der nicht strukturell, sondern verhaltensbedingt ist, wird eine BPA-Implementierung diesen Fehler bei jeder Ausführung schnell durchsetzen.
Das BPM-Framework existiert, um die Frage zu beantworten, die Automatisierung allein nicht beantworten kann: Wie sieht „korrekt“ aus? Ohne diese Basis arbeiten automatisierte Prozesse gegen imaginäre Kriterien. Sie erhalten Kennzahlen zur Prozessleistung, die Ausführungsvolumen statt Geschäftsergebnisse messen. Der Engpass verschiebt sich oder bleibt verborgen. Das Dashboard sieht gesund aus.
BPM legt die Grundlage fest. Es definiert, was der Prozess tun soll, wer jeden Schritt verantwortet, wie Ausnahmen behandelt werden und wie die Leistung gemessen wird. BPA führt dann gegen diese definierte Grundlage aus. Teams, die diese Grundlage überspringen, sparen nicht die Zeit, die BPM benötigt. Sie investieren sie später in Incident-Reviews, um herauszufinden, warum die Automatisierung schnellere Ergebnisse erzeugt hat, die niemand wollte.
Wo Workflow-Automatisierung in ein BPM-Framework passt
Workflow-Automatisierung ist ein Mechanismus innerhalb der BPA-Ebene, die wiederum innerhalb eines BPM-Frameworks arbeitet. Diese Einordnung ist wichtig, weil Workflow-Automatisierung häufig als Synonym für BPA oder – noch verwirrender – für BPM selbst verwendet wird. Beides trifft nicht zu.
Workflow-Automatisierung verarbeitet bestimmte Aufgabenfolgen: eine Genehmigungsanfrage weiterleiten, bei einer Statusänderung eine Benachrichtigung auslösen oder Daten nach einem definierten Zeitplan zwischen zwei Systemen verschieben. Dies sind Automatisierungsarten, die Ausführungsprobleme innerhalb eines definierten Prozesses lösen. Robotic Process Automation übernimmt einen anderen Bereich, typischerweise Interaktionen auf der Benutzeroberfläche mit Systemen ohne APIs. Aufgabenautomatisierung löst einzelne, wiederkehrende Schritte. All das sind Mechanismen, die BPA einsetzen kann, sobald BPM die Zielprozessstruktur definiert hat. Keiner davon ersetzt die Governance-Ebene, die Ihnen sagt, ob der Prozess überhaupt korrekt ist.
Geschäftsprozessanalyse: Die Ebene, die die meisten Teams überspringen
Die Geschäftsprozessanalyse ist die diagnostische Brücke zwischen BPM-Strategie und BPA-Ausführung. Hier untersuchen Sie, was Prozesse tatsächlich tun, messen ihre Leistung und identifizieren, welche davon für Automatisierung, Neugestaltung oder Abschaffung infrage kommen. SAP Signavio beschreibt dies als dreiteilige Hierarchie: BPM steuert das Programm, die Prozessanalyse identifiziert den Änderungsbedarf und die Automatisierung setzt die Änderungen im großen Maßstab um.
Der Fehlermodus, den ich am regelmäßigsten sehe, besteht darin, dass Teams von „Wir müssen automatisieren“ direkt zur Toolauswahl springen und den Analyseschritt vollständig überspringen. Sie wissen, dass sie manuelle Arbeit haben. Sie kaufen ein Automatisierungstool. Sie automatisieren die manuelle Arbeit. Drei Monate später haben sie schnellere manuelle Arbeit, in einem Workflow kodiert, für den niemand verantwortlich ist und dessen Ergebnisse niemand validiert hat.
Was die Prozessanalyse tatsächlich beantwortet, bevor Sie irgendetwas entwickeln:
Welche Prozesse tatsächlich für Automatisierung infrage kommen
Automatisierungskandidaten sind Prozesse mit hohem Volumen, klaren Regeln, hoher Stabilität und eindeutiger Definition. Die Leistungsanalyse zeigt, welche Prozesse diese Kriterien erfüllen und welche zu variabel sind oder zu stark von Ermessensentscheidungen abhängen, um zuverlässig automatisiert zu werden.
Was der Prozess tatsächlich tut im Vergleich zu dem, was Menschen glauben, dass er tut
Process Mining auf Basis von Systemprotokollen zeigt häufig, dass der dokumentierte Prozess und der tatsächlich ausgeführte Prozess unterschiedliche Dinge sind. Die dokumentierte Version zu automatisieren, ignoriert, wie die Arbeit wirklich fließt.
Wo die tatsächlichen Engpässe liegen
Teams identifizieren Automatisierungsmöglichkeiten häufig danach, wo die Arbeit am sichtbarsten ist, nicht danach, wo die tatsächliche Einschränkung liegt. Die Analyse trennt Symptom und Ursache, bevor Ausführungstools ins Spiel kommen.
Wie der Ausgangswert vor der Automatisierung aussieht
Ohne einen Ausgangswert vor der Automatisierung können Sie nicht messen, ob Automatisierungsinitiativen eine echte Verbesserung erzielt oder die Arbeit nur verschoben haben. BPM benötigt diesen Ausgangswert. BPA braucht ihn, um den ROI nachzuweisen.
Die Teams, die am eifrigsten das richtige Automatisierungstool auswählen wollen, überspringen diese Ebene meist am schnellsten. Sie wollen mit der Entwicklung beginnen. Die Kosten werden Monate später sichtbar – in Form von Workflows, die korrekt laufen und falsche Ergebnisse produzieren, weil niemand gefragt hat, ob es überhaupt sinnvoll war, den Prozess korrekt auszuführen.
🤔 Moment mal.
Die Teams, die BPA am schnellsten einführen, sind oft diejenigen, die am wenigsten Zeit für Prozessanalyse aufgewendet haben. Das bedeutet: Der Geschwindigkeitsvorteil moderner Automatisierungstools kann die Produktion falscher Ergebnisse beschleunigen. Automatisierungsbereitschaft hängt nicht vom Zugang zu Tools ab. Sie hängt davon ab, vor der Automatisierung zu wissen, wie „korrekt“ aussieht.
Vorteile der Geschäftsprozessautomatisierung, wenn BPM bereits etabliert ist
Die Vorteile der Geschäftsprozessautomatisierung sind real. Sie sind jedoch an Bedingungen geknüpft. Jeder davon erfordert eine BPM-Voraussetzung, um in dem Umfang wirksam zu werden, den Teams tatsächlich erwarten. So sieht die Liste aus, wenn sie ehrlich ist:
Schnellere Durchlaufzeiten bei klar definierten Prozessen
Wenn BPM einen Prozess eindeutig dokumentiert hat – mit definierten Eingaben, Ausgaben, Regeln und Ausnahmewegen –, kann BPA ihn ohne die Verzögerungen ausführen, die durch manuelle Übergaben und Weiterleitungsentscheidungen entstehen. Der Geschwindigkeitsgewinn ist real. Er setzt voraus, dass der Prozess so gut definiert ist, dass die Automatisierung ihm folgen kann, ohne bei jedem Schritt menschliche Interpretation zu benötigen.
Weniger manueller Aufwand bei regelbasierter Backoffice-Arbeit
Shared-Services-Teams in HR, Finanzwesen und Kundenservice, die Genehmigungen, Fallweiterleitung und Dateneingabe bearbeiten, sind der klassische BPA-Anwendungsfall. Die wiederkehrenden Aufgaben in diesen Funktionen eignen sich gerade deshalb gut für Automatisierung, weil sie regelbasiert, volumenstark und nach der BPM-Definition der Regeln nicht entscheidungsintensiv sind. Ohne diese Definition bedeutet „manuellen Aufwand automatisieren“, einfach zu kodieren, was jemand letzten Dienstag zufällig getan hat.
Höherer Durchsatz bei Onboarding- und Order-to-Cash-Workflows
Die Kategorien Onboarding- und Genehmigungsprozesse reagieren gut auf BPA, weil sie sequenziell ablaufen, mehrere Systeme einbeziehen und klare Abschlusskriterien haben. BPM setzt diese Kriterien. BPA setzt sie anschließend im großen Maßstab durch – mit einer konsistenten Ausführung, die nicht davon abhängt, wer gerade im Büro ist.
Messbarer ROI, den Teams für digitale Transformation nachweisen können
Teams, die nach einer BPA-Einführung eine Kennzahl vorlegen können, sind jene, die ihren Ausgangspunkt gemessen haben. BPM liefert diesen Ausgangswert. Ohne ihn läuft die ROI-Behauptung auf „Wir haben einige Dinge automatisiert und es fühlt sich schneller an“ hinaus – und das reicht einem CFO nicht, um die nächste Initiative zu genehmigen. Geschäftsprozesse auf einer BPM-Grundlage zu automatisieren bedeutet, dass Sie wissen, was sich verändert hat, weil Sie vorher und nachher gemessen haben.
Bessere Geschäftsergebnisse, die sich mit der Zeit verstärken
BPA innerhalb einer BPM-Governance erzeugt Feedbackschleifen: Die Monitoringdaten automatisierter Prozesse fließen zurück in den BPM-Zyklus, dieser identifiziert das nächste Verbesserungsziel, das BPA dann umsetzt. Die gesamte Geschäftsleistung verbessert sich nicht aufgrund einer einzelnen Automatisierungseinführung, sondern weil die Disziplin die Ausführungsebene an der aktuellen Strategie ausrichtet. Optimieren Sie Geschäftsabläufe einmal, haben Sie ein Projekt umgesetzt. Bauen Sie den Zyklus auf, haben Sie verändert, wie sich die Organisation verbessert.
Wer BPM und BPA nutzt – und für welche Geschäftsprozesse
Die Zielgruppen unterscheiden sich. Wenn sie innerhalb derselben Organisation nicht aufeinander abgestimmt sind, laufen BPM und BPA als getrennte Programme, die doppelte Arbeit und konkurrierende Governance-Modelle erzeugen.
Operations- und Prozessexzellenz-Verantwortliche nutzen BPM, um funktionsübergreifende Geschäftsprozesse zu standardisieren, Verantwortlichkeiten festzulegen und die Governance aufrechtzuerhalten, die Prozessabweichungen verhindert. Ihr Blickwinkel ist organisatorisch: Sie denken darüber nach, wie Arbeit durch die gesamte Organisation fließt, nicht nur innerhalb eines Teams.
CIOs und IT-Automatisierungsverantwortliche sind in der Regel diejenigen, die BPA für komplexe Workflows einsetzen – insbesondere dort, wo mehrere Systeme, Datenquellen und Ausführungspfade koordiniert werden müssen. Ihre Agenda zur Transformation von Geschäftsprozessen ist meist technisch geprägt, weshalb sie manchmal ohne ausreichende Prozess-Governance von Operations-Seite umgesetzt wird.
Shared-Services-Manager in HR, Finanzwesen und Kundenservice nutzen BPA innerhalb eines BPM-Frameworks für Backoffice-Anwendungsfälle: Mitarbeiter-Onboarding, Spesengenehmigung, Aktualisierungen im Customer Relationship Management und Abstimmungen im Bestandsmanagement. In diesen Funktionen ist das Volumen hoch genug, damit Automatisierung klaren Mehrwert liefert, und die Prozesse sind stabil genug, damit BPM-Governance trägt.
Teams für digitale Transformation nutzen BPM, um die Wertschöpfungskette abzubilden und festzulegen, wohin Automatisierungsinvestitionen fließen sollten. Anschließend nutzen sie BPA, um spezifische Problempunkte innerhalb dieser Karte anzugehen. Das Risiko entsteht, wenn die Transformationsinitiative und die BPA-Einführung in unterschiedlichen Budgetzyklen mit unterschiedlichen Sponsoren stattfinden. Ich habe erlebt, wie dieses Muster einen detailliert per BPM abgebildeten Geschäftsprozess erzeugt, den niemand automatisiert hat, neben einer BPA-Einführung, die einen Prozess automatisiert hat, den niemand gesteuert hat. Dasselbe Unternehmen. Unterschiedliche Verantwortliche für die Initiativen. Keine Zusammenarbeit zwischen Fachbereichs- und IT-Teams.
Diese letzte Konstellation erzeugt normalerweise kein Ticket. Sie führt zu einem Quartalsreview, in dem alle positive Kennzahlen berichten, während das tatsächliche Ergebnis der kombinierten Initiative unklar bleibt.
Ein praktisches Beispiel dafür, wie Abstimmung in einer Automatisierungsplattform aussieht: Wenn Latenode als BPA-Ausführungsebene neben einer bestehenden Prozess-Governance-Struktur eingesetzt wird, wird die Workflow-Canvas zur sichtbaren Dokumentation dessen, wie der Prozess tatsächlich läuft – nicht nur dazu, wie er modelliert wurde. Ein Operations-Manager eines SaaS-Unternehmens mit 40 Mitarbeitenden kann sein CRM, Abrechnungs- und Supportsystem über integrierte OAuth-Integrationen verbinden, Verzweigungsregeln direkt in einem JavaScript-Node kodieren und Sonderfälle an eine Warteschlange für menschliche Prüfung weiterleiten – alles innerhalb eines einzigen Ablaufs. Die BPM-Ebene definiert, was der Ablauf tun soll. Der Latenode Workflow führt ihn aus. Wenn sich der Prozess ändert, wird der Workflow an einer Stelle aktualisiert statt in verstreuten Skripten. So funktioniert die Übergabe korrekt: BPM gibt die Richtung vor, BPA nutzt Software, um deren Ausführung zu automatisieren.
Intelligente Automatisierung und BPM-Tools: Wohin sich der Stack entwickelt
Die Konvergenz ist real und beeinflusst bereits Kaufentscheidungen. BPM-Plattformen ergänzen Automatisierungsfunktionen. BPA-Tools ergänzen Funktionen für Prozess-Governance. KI taucht gleichzeitig in beiden Ebenen auf. Harvard Business Review stellte fest, dass Prozessmanagement eine Renaissance erlebt – insbesondere, weil Organisationen, die KI als isoliertes Experiment behandeln, schlechtere Ergebnisse erzielen als jene, die KI in eine gesteuerte Prozessstruktur einbetten. Die Governance-Ebene macht KI-gestützte Automatisierung vorhersehbar statt experimentell.
Für Teams, die derzeit entscheiden, ob sie ein BPM-Tool, ein BPA-Tool oder eine kombinierte Plattform kaufen sollen, bedeutet diese Konvergenz, dass Kategorien als Auswahlkriterien zunehmend unzuverlässig werden. Eine als BPA-Software vermarktete Plattform kann Funktionen zur Prozessmodellierung enthalten. Eine BPM-Suite kann Automatisierungsfunktionen enthalten, die BPA-Tools für bestimmte Anwendungsfälle überflüssig machen. Der richtige Automatisierungsansatz lässt sich nicht allein anhand von Kategorienamen erkennen.
Was nicht konvergiert ist: Die Unterscheidung zwischen Strategie und Taktik gilt weiterhin. BPM-Tools sind selbst mit zusätzlichen Automatisierungsfunktionen auf Governance und Modellierung ausgerichtet. BPA-Lösungen und Automatisierungssoftware sind selbst mit zusätzlichen Governance-Funktionen auf Ausführung und Durchsatz ausgerichtet. Intelligente Automatisierung entwickelt sich hin zu Plattformen, die beide Ebenen abdecken. Doch die Disziplin, vor der Automatisierung zu fragen „Sollte dieser Prozess so funktionieren?“, kann Ihnen keine Plattform abnehmen.
📊 In der Praxis:
Appian beschreibt moderne BPA als ganzheitlichen Ansatz, der RPA, BPM-Plattformen, Workflow-Automatisierung, KI und Datenmanagement kombiniert – nicht als Kauf eines einzelnen Tools. Das bedeutet: Eine „Automatisierungsplattform“ zu kaufen und zu erwarten, dass sie die Lücke zwischen Strategie und Taktik schließt, ist eine falsche Beschaffungsannahme. Die Lücke ist organisatorisch. Kein Stack-Kauf schließt sie.
