Letzte Woche bei einem Kunden ist uns nachts um 02:13 Uhr ein „Roboter“ umgekippt, weil ein Login-Button im Portal plötzlich nicht mehr „Anmelden“ hieß, sondern „Weiter“. Klingt banal. War’s auch. Aber das Ding hing halt an fünf Folgeprozessen, und plötzlich standen Rechnungen, Tickets und ein halbes Reporting still. Genau da merkst du: Klassische RPA ist manchmal wie Tape auf einem Wasserrohr – hält, bis jemand niest.

Wenn du gerade nach einer RPA alternative suchst, meinst du meistens nicht „noch ein anderes Tool“, sondern: weniger fragil, besser wartbar, mehr observability, und bitte nicht jedes Mal „UI changed, bot dead“. Ich bin nicht 100% sicher, ob es die perfekte Alternative gibt, aber wir haben ein paar Muster, die sich in Projekten immer wieder als robuster rausstellen.

What You’ll Build

Die häufigsten Fehler entstehen bei der Webhook-Retry-Logik

Beispiel: Enterprise E-Commerce Platform

Fehlerrate von 2.5% auf 0.3% gesenkt

Implementation Checklist

✓ Requirements definiert
✓ Architektur geplant
✓ Tests geschrieben
✓ Dokumentation erstellt

```typescript // Configuration Example export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, retries: 3 }; ```

Wir bauen eine kleine, realistische Automatisierung ohne „klassische“ RPA:

Ein Workflow, der Daten zieht (API), transformiert und irgendwo ablegt
Ein optionaler Browser-Step (wenn’s wirklich nicht anders geht), aber stabiler als RPA-Klickorgien
Ein Mini-Healthcheck, damit du merkst, bevor der Prozess brennt

Und nebenbei: Ich liste dir die Alternativen, die ich in DACH-Projekten tatsächlich schon gesehen habe – mit Pros/Cons aus Entwickler-Sicht.

Prerequisites

Node.js (aktuell, LTS reicht)
TypeScript (ts-node oder build über tsc)
Wenn du Browser-Automation willst: Playwright
Wenn du Workflows willst: n8n (self-hosted) oder Make / Zapier (SaaS)

Übrigens: Wenn du im Unternehmen eh schon Kafka/Queues und ein bisschen Plattform-Engineering hast, dann ist „RPA ersetzen“ oft eher eine Architektur- als eine Toolfrage.

Step-by-Step Guide

Ich geh das mal so an, wie wir’s bei Kunden meistens machen: erst API-first, dann Workflow/Orchestrierung, und nur wenn’s wirklich gar nicht anders geht, ein Browser-Step.

1) RPA ersetzen durch API-Integration (wenn möglich)

Ein Fehler, den ich oft sehe: Man automatisiert eine Weboberfläche, obwohl es eine halbwegs brauchbare API gibt (oder man sie sich „bauen“ kann, z.B. über DB-Views, Export-Endpunkte, SFTP-drop). UI-Automation ist halt das wackeligste Glied.

Hier ein simples TypeScript-Beispiel: Daten von einer API ziehen, transformieren, in ein Zielsystem posten. Das klingt langweilig – ist aber genau der Punkt: langweilig ist stabil.

import fetch from "node-fetch";

type Order = {
  id: string;
  totalCents: number;
  customerEmail: string;
  status: "OPEN" | "PAID" | "CANCELLED";
};

type InvoicePayload = {
  orderId: string;
  amountEuro: number;
  recipient: string;
};

function toInvoicePayload(order: Order): InvoicePayload {
  return {
    orderId: order.id,
    amountEuro: Math.round(order.totalCents) / 100,
    recipient: order.customerEmail,
  };
}

export async function syncPaidOrders(): Promise<{ synced: number }> {
  const apiBase = process.env.SOURCE_API_BASE!;
  const targetBase = process.env.TARGET_API_BASE!;
  const token = process.env.SOURCE_TOKEN!;

  // TODO: später optimieren (pagination, retries, backoff)
  const res = await fetch(`${apiBase}/orders?status=PAID`, {
    headers: { Authorization: `Bearer ${token}` },
  });

  if (!res.ok) {
    throw new Error(`SOURCE API error: ${res.status} ${await res.text()}`);
  }

  const orders = (await res.json()) as Order[];

  let synced = 0;
  for (const order of orders) {
    const payload = toInvoicePayload(order);

    const post = await fetch(`${targetBase}/invoices`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });

    if (!post.ok) {
      // hier nicht sofort alles killen, sonst hast du bei einem Ausreißer einen kompletten Stopp
      console.warn(`Failed to sync order ${order.id}: ${post.status} ${await post.text()}`);
      continue;
    }

    synced++;
  }

  return { synced };
}

Das ist natürlich „nur“ Code. Die Alternative zur RPA ist hier aber das Pattern: Integration statt UI-Klicken. In der Praxis hängt man das dann an einen Scheduler (Cron, GitHub Actions, Cloud Scheduler) oder in einen Workflow-Runner.

2) Workflow-Automation statt Bot: n8n / Make / Zapier

Wenn du sowas wie RPA genutzt hast, weil Fachbereiche selbst Flows zusammenklicken wollen, dann sind Workflow-Tools oft die bessere Alternative. n8n ist bei uns ziemlich beliebt, weil self-hosting und „du kannst notfalls JavaScript reinschreiben“.

Was ich mag: Du bekommst Retries, Logs, Webhooks, und die Sachen sind irgendwie sichtbarer als „Bot läuft auf irgendeinem Windows-VM-Desktop“.

Was ich nicht mag: Wenn man anfängt, komplexe Geschäftslogik in 40 Nodes zu modellieren, wird’s wieder unwartbar – dann lieber ab in Services (TypeScript), und n8n orchestriert nur.

3) BPMN/Process Engines statt RPA: Camunda / Zeebe

Wenn du echte Prozesse orchestrieren willst (Wartezustände, Human Tasks, Eskalationen, saubere Zustände), dann ist eine Process Engine oft näher an dem, was das Business eigentlich braucht. Bei einem Projekt letzten Monat hatten wir einen RPA-Flow für „Kündigungen verarbeiten“. Der war ein Monster. Mit BPMN war das plötzlich… nachvollziehbar. Nicht perfekt, aber wesentlich sauberer.

Camunda/Zeebe ist nicht „mal eben“, klar. Aber wenn du langfristig wartbare Prozesse willst, ist das eine der besten RPA-Alternativen, die nicht nach zwei UI-Updates auseinanderfällt.

4) Browser Automation als letzte Meile: Playwright statt klassischem RPA

Manchmal gibt’s halt keine API. Dann musst du ins UI. Aber statt klassischer RPA-Recorder setze ich lieber auf Playwright (oder Puppeteer/Selenium). Das ist immer noch UI-Automation, aber du hast Code-Reviews, Selektor-Strategien, CI, Screenshots, Traces – das fühlt sich wie Engineering an und nicht wie Magie.

import { chromium } from "playwright";

export async function downloadReport(): Promise<string> {
  const browser = await chromium.launch({ headless: true });
  const page = await browser.newPage();

  try {
    await page.goto(process.env.PORTAL_URL!, { waitUntil: "domcontentloaded" });

    // Ich nehme gern data-testid, wenn verfügbar. Sonst wird's halt schnell brittle.
    await page.locator("[data-testid='email']").fill(process.env.PORTAL_USER!);
    await page.locator("[data-testid='password']").fill(process.env.PORTAL_PASS!);
    await page.locator("[data-testid='login']").click();

    await page.waitForURL("**/dashboard", { timeout: 30_000 });

    // TODO: später optimieren: Download-Event statt fixed wait
    await page.locator("text=Reports").click();

    const [download] = await Promise.all([
      page.waitForEvent("download"),
      page.locator("text=Export CSV").click(),
    ]);

    const filePath = await download.path();
    if (!filePath) throw new Error("No download path available");

    return filePath;
  } finally {
    await browser.close();
  }
}

Der Unterschied zu RPA ist hier nicht „kann auch klicken“, sondern: du kannst’s testen, versionieren, in Pipelines laufen lassen und vernünftig debuggen. Und du kannst Selektoren stabil halten (data-testid), was bei RPA-Recordern halt oft „Pixel-Positionen“ sind… naja.

Testing & Verification

Was ich bei RPA echt vermisse: schnelle, verlässliche Checks. Darum bau ich fast immer wenigstens diese drei Dinge ein:

Dry-Run: Daten holen, transformieren, aber nicht schreiben
Health Endpoint oder ein Ping, der Credentials/Reachability prüft
Alerting: Wenn synced=0 obwohl sonst immer >0, dann stimmt was

Ganz pragmatisch: Lass den Job nach dem Lauf eine Metrik oder eine Nachricht posten (Slack/Teams). Klingt oldschool, rettet aber Nerven.

Für Playwright: Lass bei Failure einen Screenshot + Trace speichern. Das ist Gold, wenn morgens jemand sagt „läuft nicht“. Und du willst nicht erstmal remote in eine VM und zuschauen, wie ein Bot irgendwo rumklickt.

Next Steps

Wenn du gerade evaluierst, welche RPA alternative passt, dann geh ich meistens so vor:

API vorhanden? Dann Integration/Service + Scheduler/Workflow.
Prozess mit Zuständen/Human-in-the-loop? Dann BPMN/Process Engine.
Nur „wenn X dann Y“ mit vielen SaaS-Tools? Dann n8n/Make/Zapier.
Keine API, UI muss? Dann Playwright + gute Selektoren + CI + Observability.

Wenn du willst, schreib mir (bzw. sag mir hier), was dein aktueller RPA-Use-Case ist: welche Systeme, wie oft läuft’s, und ob’s eher „Backoffice klicken“ oder „echter End-to-End Prozess“ ist. Dann kann ich dir ziemlich konkret sagen, welchen Stack ich heute dafür bauen würde – oder wo ich noch unsicher wäre, weil’s von Randbedingungen abhängt.

Cloudox Blog

RPA-Alternativen, die in der Praxis weniger weh tun: n8n, Camunda, Playwright & Co.