Was Sie wirklich ohne IT-Abteilung automatisieren können — und wo es kaputt geht

Was Sie wirklich ohne IT-Abteilung automatisieren können — und wo es kaputt geht

Ein Steuerberater aus meinem Netzwerk kam vor einigen Monaten mit einer Liste. Sechs Prozesse, die er automatisieren wollte. Kein IT-Budget, keine IT-Abteilung, nur er und ein Laptop.

Drei Monate später liefen drei der sechs Prozesse produktiv. Zwei weitere waren halbfertig und stagnieren seitdem. Den sechsten hatte er sich schöngeredet — er war von Anfang an zu komplex für No-Code.

Diese Geschichte wiederholt sich täglich: bei Einzelunternehmern, in kleinen Betrieben, und in Abteilungen großer Konzerne, die auf IT-Support warten, der nie kommt. No-Code-Automatisierung funktioniert. Aber die Grenze zwischen dem, was klappt, und dem, was Sie in ein zeitfressendes Projekt verwandelt, das niemand anfassen will, ist schmaler als die Anbieter zugeben.

Hier ist das ehrliche Bild.

Was No-Code eigentlich bedeutet

No-Code ist ein Marketingbegriff. Dahinter steckt etwas Echtes: visuelle Automatisierungsplattformen, die Verbindungen zwischen Softwaresystemen ermöglichen, ohne dass man in einer Programmiersprache schreiben muss. Make, n8n, Zapier, Activepieces — diese Tools haben es Tausenden von Fachleuten ermöglicht, Prozesse zu automatisieren, für die früher eine Entwicklerin nötig gewesen wäre. Das ist kein Hype, das ist der Alltag meiner Kunden.

Aber kein Code bedeutet nicht keine Komplexität. Was diese Tools verlangen, ist strukturiertes Denken: die Fähigkeit, einen Prozess in logische Schritte zu zerlegen, Daten als Objekte zu begreifen, die transformiert werden, und die Geduld, Fehler systematisch zu suchen. Das sind keine Programmierkenntnisse, aber es sind Fähigkeiten, die man unterschätzt, wenn man Demo-Videos anschaut.

Ein zweites Missverständnis: kein Code bedeutet nicht keine Abhängigkeiten. Jeder Connector in Make oder Zapier ist eine Abhängigkeit auf einen externen Dienst. Wenn dieser Dienst seine API ändert, seinen Connector aktualisiert oder seine Preise erhöht, sind Sie betroffen — ohne selbst etwas getan zu haben. Wer No-Code-Automatisierung betreibt, kauft einen anderen Typ von Aufwand, nicht weniger Aufwand.

Die drei Typen von Automatisierungsaufgaben

Bevor wir konkret werden, hilft es, Automatisierungsaufgaben in drei Kategorien einzuteilen. Die Unterscheidung ist der wichtigste Orientierungspunkt, wenn Sie entscheiden, was ohne IT realistisch ist.

Datenübertragungen und Benachrichtigungen

Wenn X passiert, tue Y. Wenn ein Lead ins CRM eingeht, schicke eine Slack-Nachricht. Wenn ein Formular ausgefüllt wird, erstelle einen Datensatz. Kein Routing, keine Transformation, keine Verzweigung.

Das sind die einfachsten Fälle. Die meisten Plattformen haben dafür fertige Templates. Aufbauzeit: ein paar Stunden. Wartungsaufwand: minimal, solange die verbundenen Dienste stabil bleiben.

Entscheidungslogik und Datentransformation

Nicht nur wenn X dann Y, sondern: Wenn X, prüfe Y, und wenn Y größer als Z ist, tue A, sonst tue B. Routing, Filterung, Datentransformation zwischen Systemen.

Das ist machbar ohne IT, aber fehleranfälliger. Fehler hier brechen den Flow oft nicht ab — sie produzieren still falsche Ergebnisse. Ein Flow, der 90% der Fälle korrekt verarbeitet und 10% falsch routet, ohne dass jemand es merkt, ist gefährlicher als ein Flow, der komplett abbricht.

Systemintegrationen mit Authentifizierung und Sicherheit

Verbindungen zu internen Systemen hinter Firewalls, OAuth-Konfigurationen, Datenbankzugriffe, sensible Daten. Technisch möglich in No-Code-Plattformen. Ob es klug ist, einen Make-Flow mit Zugriff auf die Kundendatenbank zu bauen, ohne jemanden mit Sicherheitshintergrund einzubeziehen, ist eine andere Frage.

Was sich tatsächlich ohne IT-Abteilung umsetzen lässt

Formular-zu-CRM-Flows

Jede neue Anfrage über Ihr Kontaktformular landet automatisch im CRM, löst eine Slack-Benachrichtigung aus, und der Interessent bekommt eine Bestätigungsmail. Klassischer Typ-1-Fall. In Make oder n8n ist das ein 20-Minuten-Aufbau für jemanden, der das kennt, und zwei Stunden für jemanden, der neu dabei ist.

Ich habe genau das mit einem Handwerksbetrieb ohne jeden Technologiehintergrund umgesetzt. Der Inhaber folgte einer Schritt-für-Schritt-Anleitung, machte drei Fehler, fand sie beim Testen. Nach zwei Stunden lief der Flow. Dieser Flow läuft seit über einem Jahr, ohne dass jemand ihn angefasst hat.

Reporting und Zusammenfassungen

Wöchentliche Reports aus Google Sheets oder einem CRM, automatisch per E-Mail verschickt. Zusammenfassungen, die morgens im Postfach sind. Gut machbar.

Der häufige Stolperstein: Datenvolumen. Was für 100 Datensätze schnell geht, kann für 10.000 auf Plattform-Limits stoßen. Das passiert nicht am ersten Tag, sondern nach sechs Monaten, wenn das Volumen gewachsen ist und niemand daran gearbeitet hat.

KI-Schritte in Workflows

E-Mail-Zusammenfassungen, Klassifizierung von Supportanfragen, Extraktion von Daten aus unstrukturierten Dokumenten — KI-Schritte in No-Code-Flows sind heute Standard. Diese Flows bauen sich schnell und liefern oft sofortigen Mehrwert.

Was man dabei im Kopf behalten muss: Jede KI-Verarbeitung kostet Token. Was bei 20 Anfragen täglich günstig ist, wird bei 500 teuer. Wer keine Kostenkontrolle einbaut, erlebt Überraschungen in der Monatsabrechnung.

Onboarding-Sequenzen

Automatische Willkommens-E-Mails, zeitgesteuerte Follow-ups, Erinnerungen nach definierten Intervallen. Sowohl spezialisierte E-Mail-Tools als auch Custom-Flows in Make oder n8n decken das ab. Der Vorteil der eigenen Plattform: mehr Flexibilität bei der Logik. Dafür mehr Aufbauaufwand.

Dokumentengenerierung

Angebote oder einfache Verträge aus Vorlagen generieren — Daten aus einem Formular oder CRM in ein strukturiertes Dokument übertragen. Für unkomplizierte Vorlagen funktioniert das zuverlässig.

Die Grenze liegt bei Vorlagen mit bedingten Abschnitten. Wenn Ihr Vertrag je nach Auftragstyp andere Abschnitte enthalten soll, wird die Logik komplex. Lösbar, aber langwieriger als erwartet.

Was nach außen einfach aussieht, aber IT braucht

Make hat über 1.000 Connectoren, Zapier ähnlich viele. Das klingt nach grenzloser Konnektivität. In der Praxis gibt es eine wichtige Unterscheidung: Cloud-zu-Cloud-Integrationen funktionieren meistens gut. Integrationen mit On-Premise-Systemen — Software, die auf Ihrer eigenen Infrastruktur läuft — sind eine andere Welt.

Wenn Sie SAP, DATEV oder ein älteres ERP betreiben, das hinter Ihrer Firewall läuft, kommen Sie mit einem Cloud-Automatisierungstool allein nicht weiter. Sie brauchen jemanden, der die Netzwerkinfrastruktur kennt und API-Zugänge einrichten kann. Das ist IT-Arbeit, und keine, die sich mit Tutorial-Videos lösen lässt.

Ich erwähne das explizit, weil ich regelmäßig Kunden sehe, die vier bis sechs Wochen in einen Flow investieren, nur um dann festzustellen, dass die Verbindung zum entscheidenden System ohne IT-Beteiligung nicht möglich ist.

Authentifizierung und Benutzerberechtigungen

OAuth konfigurieren klingt nach einer 10-Minuten-Aufgabe. Für jemanden ohne Erfahrung kann das ein Abend werden. Für jemanden, der es kennt: 20 Minuten. Das ist eine Zeitrechnung, keine Kritik. Wenn Sie bereit sind, sich das anzueignen, machen Sie es selbst. Wenn nicht, holen Sie sich für diesen Schritt jemanden dazu.

Fehlerbehandlung in geschäftskritischen Prozessen

Kein Flow läuft ewig fehlerfrei. Die Frage ist: Was passiert, wenn er ausfällt?

Für einen Report-Flow, der einmal wöchentlich läuft, ist ein stiller Ausfall tragbar. Für einen Flow, der Auftragsbestätigungen verschickt oder Daten in ein Kernsystem bucht, nicht.

Fehlerbehandlung ist in No-Code-Plattformen technisch möglich. Aber sie erfordert, dass man Fehlerfälle antizipiert, bevor man live geht. Das ist nicht intuitiv, und die meisten Flows, die ich sehe, überspringen diesen Schritt.

Bei einem Kunden hatte ein Flow die Aufgabe, eingehende Bestellungen ins ERP zu buchen. Er funktionierte — bis ein Sonderzeichen in einem Kundennamen den Parsing-Schritt zerstörte. Der Flow brach still ab. Niemand wusste es. Drei Bestellungen wurden nicht gebucht. Ein Kunde beschwerte sich, weil seine Bestellung nicht ankam. Das Problem wäre mit einem einfachen Ausfall-Alert vermeidbar gewesen. Fünf Minuten Konfiguration.

DSGVO und Datensicherheit

Das meiste wird übersprungen. Nicht aus Böswilligkeit, sondern weil die Plattformen diese Fragen nicht prominent stellen.

Wo Ihre Daten verarbeitet werden

Wenn Sie einen Flow bauen, der Kundendaten verarbeitet, werden diese durch die Server des Anbieters geleitet. Zapier hat Server primär in den USA. Make bietet europäische Serverstandorte an, aber Sie müssen sie explizit auswählen.

Das ist kein automatisches Compliance-Problem. Aber Sie müssen wissen, wo Ihre Daten landen. Wenn personenbezogene Kundendaten durch Zapier fließen und Zapier nicht in Ihrer Datenschutzerklärung als Auftragsverarbeiter genannt ist, handeln Sie nicht DSGVO-konform. Lösbar — aber nur wenn jemand darüber nachdenkt.

Zugangsdaten und API-Schlüssel

In No-Code-Plattformen werden Verbindungen mit API-Schlüsseln oder OAuth-Tokens gespeichert. Diese Tokens haben Zugriff auf Ihre Systeme. Wenn jemand Zugriff auf Ihren Make-Account erhält, hat er möglicherweise Zugriff auf alles, was damit verbunden ist.

Einfache Fragen mit ernsthaften Konsequenzen: Wer hat Zugriff auf Ihren Automatisierungs-Account? Ist Zwei-Faktor-Authentifizierung aktiv? Werden Zugänge entfernt, wenn Mitarbeiter das Unternehmen verlassen?

In Audits habe ich Accounts gesehen, die ohne 2FA betrieben wurden, mit API-Schlüsseln von sechs Produktivsystemen, von Mitarbeitern, die das Unternehmen vor Monaten verlassen hatten.

Shadow IT durch Erfolg

Hier ist ein Muster, das kaum besprochen wird: Jemand baut einen cleveren Zapier-Flow, der täglich zwei Stunden einspart. Alle sind begeistert. Er zeigt es dem Kollegen. Der baut einen ähnlichen. Sechs Monate später hat die Abteilung achtzehn Flows, die niemand in der IT kennt, kein Mensch vollständig überblickt, und die still Kundendaten verarbeiten, die nirgendwo dokumentiert sind.

Das entsteht nicht aus Fahrlässigkeit, sondern aus Erfolg. Automatisierung funktioniert, also verbreitet sie sich. Der richtige Zeitpunkt für Governance ist vor dem Problem, nicht danach.

Wann Sie IT einbeziehen sollten

Meine Faustregel-Kriterien:

Wenn der Flow geschäftskritisch ist — Bestellungen nicht verarbeitet werden, Kunden keine Bestätigungen erhalten, Daten verloren gehen, wenn er ausfällt. Für diese Flows brauchen Sie Monitoring, Alerting und getestete Fehlerbehandlung. Das ist technisch ohne IT machbar, aber jemand mit technischem Hintergrund richtet es in einem Bruchteil der Zeit ein.

Wenn On-Premise-Systeme beteiligt sind. Interne Software hinter einer Firewall braucht Netzwerk- und Authentifizierungsarbeit, unabhängig davon, wie die Plattform vermarktet wird.

Wenn sensible Daten verarbeitet werden. Personenbezogene Daten, Zahlungsdaten — die regulatorischen Anforderungen sind klar, und das Risiko eines Fehlers ist real.

Wenn die Komplexität einen Punkt überschreitet, an dem Sie mehr Zeit mit Debuggen verbringen als mit Aufbauen. Spätestens dann ist externe Hilfe effizienter als weiteres Alleinarbeiten.

Wenn der Flow mehr als drei externe Systeme verbindet. Eine grobe Faustformel: Ab dieser Schwelle steigen Komplexität und Abhängigkeitsrisiken so stark, dass ein technisches Review fast immer lohnt.

Wie Sie intern Automatisierungs-Kompetenz aufbauen

Den richtigen Citizen Developer finden

Nicht jeder wird gut darin sein. Das hat nichts mit Intelligenz zu tun, sondern mit einer bestimmten Denkweise: Komfort mit abstraktem Prozessdenken, Bereitschaft, Wenn-Dann-Logik konsequent durchzudenken, und Geduld beim systematischen Debuggen.

In meiner Erfahrung sind das oft Menschen, die Excel-Formeln lieben, die irgendwo Coding-Berührungspunkte hatten, oder die schon mit Datenbanken experimentiert haben. Die Plattform-Skills sind schnell lernbar. Die Denkweise ist schwerer zu entwickeln.

Der häufige Fehler: Man fragt, wer das machen will, statt wer die passende Denkweise mitbringt.

Realistische Zeitrechnung

Jemanden von null auf produktiv in Zapier für einfache Flows zu bringen dauert einen Tag. Für n8n oder Make, die mehr Kontrolle und mehr Komplexität bieten: ein bis zwei Wochen fokussiertes Lernen. Bis zu dem Punkt, wo jemand komplexe Workflows mit ordentlicher Fehlerbehandlung und Dokumentation baut, vergehen Monate — erst recht, wenn er das neben seinem eigentlichen Job macht.

Das ist kein Argument gegen interne Kompetenz. Es ist ein Argument gegen unrealistische Zeitpläne.

Eines gut, nicht drei mittelmäßig

No-Code-Plattformen sind nicht austauschbar. Jede hat ihr eigenes Modell, ihre eigenen Eigenheiten, ihre eigenen nativen Stärken. Tiefe Kompetenz in einer Plattform schlägt oberflächliche Kenntnisse in drei.

Wählen Sie eine Plattform für Ihr Unternehmen. Make, n8n, Activepieces, Zapier — alle funktionieren für gängige Anwendungsfälle. Die Konsistenz ist wichtiger als die spezifische Wahl.

Eine einfache Governance-Struktur

Was darf jemand allein umsetzen? Was braucht ein Review? Was muss durch IT?

Drei Sätze auf einer internen Wiki-Seite reichen. Was zählt, ist dass diese Aufteilung existiert und kommuniziert wird, damit gut gemeinte Initiative nicht versehentlich Sicherheitslücken öffnet.

Ein praktisches Drei-Stufen-Modell:

Stufe 1 — allein umsetzbar: interne Benachrichtigungen, Reporting ohne sensible Daten, einfache Datentransfers.

Stufe 2 — Review durch erfahrenen Kollegen: Kundenkommunikation, CRM-Flows, KI-gestützte Verarbeitung.

Stufe 3 — IT-Review nötig: Systemintegrationen, sensible Daten, geschäftskritische Flows.

Die häufigsten Fehler

Den falschen Prozess als erstes automatisieren

Der erste Automatisierungsversuch prägt, wie No-Code in Ihrem Unternehmen wahrgenommen wird. Wählen Sie etwas, das täglich oder wöchentlich wiederkehrt, keine sensiblen Daten verarbeitet, und bisher wirklich manuell erledigt wurde — nicht nur theoretisch automatisierbar wäre.

Ein guter Kandidat: die manuelle Weiterleitung von Formulareinreichungen. Jemand empfängt ein Formular, kopiert die Daten ins CRM, schickt eine Bestätigung. Wiederkehrend, strukturiert, kein großes Risiko.

Kein Monitoring einrichten

Wer einen Flow baut und nie wieder hinschaut, baut eine Blackbox. Flows scheitern. APIs ändern sich. Ohne Monitoring erfahren Sie das erst, wenn ein Kunde anruft oder ein Kollege fragt, wo der wöchentliche Report geblieben ist.

Minimum: eine E-Mail, wenn ein Flow scheitert. Die meisten Plattformen bieten das nativ an. Zwei Minuten Konfiguration.

Nicht testen vor dem Launch

Was passiert, wenn ein Pflichtfeld leer ist? Was passiert, wenn der API-Call zeitlich ausläuft? Was passiert, wenn ein Datum ein unerwartetes Format hat?

Diese Fragen vor dem Launch zu beantworten rettet vor den typischen Produktionsproblemen in der ersten Woche.

Dokumentation ignorieren

Sie bauen heute einen Flow. In fünf Monaten gibt es ein Problem und Sie erinnern sich nicht mehr an die Logik. Für jeden Flow drei Sätze: Was macht er, wann läuft er, wer ist zuständig. Fünf Minuten pro Flow.

Zu viele Plattformen auf einmal

Der No-Code-Markt hat dutzende Tools, viele davon gut. Die Versuchung ist groß, für jeden Anwendungsfall das vermeintlich beste zu testen. Tiefe Kompetenz baut man auf Fokus auf, nicht auf Breite. Starten Sie mit einer Plattform, bauen Sie zwanzig Flows damit, bevor Sie das nächste Tool anfassen.

Das gilt auch für Teams: Wenn drei Abteilungen drei verschiedene Tools nutzen, kann niemand dem anderen helfen, und bei einem Problem muss jeder allein debuggen.

Was in 90 Tagen realistisch möglich ist

Mit vier bis acht Stunden pro Woche:

Monat 1: Sie lernen die Plattform. Zwei bis vier einfache Flows laufen produktiv. Sie richten Monitoring ein und testen systematisch. Mindestens ein Problem dauert länger als erwartet.

Monat 2: Flows mit Entscheidungslogik. Erste Dokumentation entsteht. Erste Fragen tauchen auf, bei denen Sie merken, dass IT-Kenntnisse weiterhelfen würden — und Sie entscheiden bewusst, was Sie selbst lösen und was nicht.

Monat 3: Ein kleines Portfolio von acht bis zwölf Flows läuft. Die wichtigsten haben Alerting. Sie wissen, welche Grenzen Sie solo haben, und Sie haben einen klaren Plan, wer für welchen Flow verantwortlich ist.

Acht bis zwölf gut betriebene Automatisierungen sind kein Transformationsprojekt. Aber sie können mehrere Stunden pro Woche einsparen und echte Prozesse entlasten.

Wo die Grenze liegt

No-Code-Automatisierung ohne IT-Abteilung funktioniert für einen erheblichen Teil dessen, was die meisten Unternehmen automatisieren wollen. Die Grenze setzt nicht die Plattform, sondern die Systeme, zu denen Sie sich verbinden, die Sensibilität der verarbeiteten Daten, und die Verlässlichkeitsanforderungen.

Die meisten Unternehmen können ohne technische Hilfe anfangen. Was sie brauchen, ist ein realistisches Bild — nicht die Demo-Version, sondern die Version, die in sechs Monaten noch läuft.

Wenn Sie wissen möchten, welche Ihrer Prozesse dafür geeignet sind und welche nicht, beantwortet der kostenlose Automations-Check diese Frage in 30 Minuten.