Sieben Tage Audit in einem alten Make-Konto: was wirklich darin lag

Was nach zwei Jahren in einem ungepflegten Make-Konto wirklich passiert

Im Januar bekam ich einen Anruf von einem alten Kunden, mittelgroßes B2B-Software-Unternehmen, 180 Mitarbeitende. Vor zwei Jahren hatte ich dort einen Workshop gehalten und ein paar erste Workflows aufgesetzt. Seitdem hatte ich nichts mehr gehört. Der Anruf war kurz: "Max, wir haben hier einen Make-Account. Wir wissen nicht mehr genau, was darin läuft. Kannst du das mal anschauen?"

Eine Woche später saß ich vor dem Laptop, loggte mich in das Konto ein und begann zu graben. Was ich in den nächsten sieben Tagen fand, ist der Inhalt dieses Artikels. Nicht weil dieser Kunde besonders schlampig gewesen wäre. Im Gegenteil. Sondern weil das, was darin lag, in fast jedem produktiven Make-, n8n- oder Zapier-Konto vorkommt, das nicht systematisch gepflegt wird. Das Muster ist konsistent. Die Beträge variieren.

Dieser Artikel ist mein forensisches Tagebuch dieser Woche. Was ich gefunden habe, was es konkret gekostet hat, was ich daraus für andere Unternehmen mitnehme.

Tag eins: die Inventur, die niemand gemacht hatte

Ich beginne jedes Audit mit derselben simplen Frage. Wie viele Szenarien existieren in diesem Konto, wie viele laufen aktiv, wie viele sind seit Wochen inaktiv?

Im Konto dieses Kunden lagen 47 Szenarien. Davon waren 23 aktiv geschaltet, 11 manuell deaktiviert, 13 so alt, dass ihre Verbindungen nicht mehr funktionierten. Diese 13 hatten in den letzten 90 Tagen keine einzige Ausführung mehr gehabt. Sie standen aber noch im Konto. Manche mit Webhook-URLs, die theoretisch jederzeit getriggert werden konnten.

Erste Beobachtung an Tag eins: ein Szenario, das auf "inaktiv" steht, kostet nichts in Operations. Es kostet aber sehr viel in kognitiver Last. Jemand muss bei jedem zukünftigen Audit jedes dieser Szenarien öffnen, lesen, verstehen, einordnen. Bei 13 Szenarien sind das mindestens 13 mal 20 Minuten, also über vier Stunden. Wer Audits regelmäßig macht, summiert das.

Was tut man mit alten Szenarien? Die ehrliche Antwort lautet: löschen. Wenn ein Szenario seit 90 Tagen nicht aktiv war und nicht aus einem konkreten Grund geparkt wurde, gehört es weg. Aufheben mit dem Argument "vielleicht möchte ich noch einmal hineinschauen" ist eine Lüge. Niemand schaut nochmal hinein. Was unverzichtbar war, taucht innerhalb von 30 Tagen wieder auf, weil sich dann jemand meldet. Was niemand vermisst, kann weg.

Konkret habe ich an Tag eins angefangen, eine Tabelle anzulegen. Pro Szenario eine Zeile mit Spalten für Name, Status, letzter Run, Modulanzahl, vermutete Funktion, vermuteter Eigentümer, Empfehlung. Diese Tabelle wurde später das zentrale Arbeitsdokument der Woche. Ohne sie ist eine Audit-Woche nicht zu leisten.

Ein Satz dazu, der mir wichtig ist. Ein Audit ohne Inventur ist keine Audit. Eines, das nur in einzelne Szenarien hineinschaut, ohne das Gesamtbild zu bauen, übersieht systematische Probleme. Erst die Inventur zeigt, wie viel Müll, wie viele Dubletten und wie viel Schatten in einem Konto liegen.

Tag zwei: die ersten Überraschungen in den aktiven Szenarien

Am zweiten Tag öffnete ich die 23 aktiven Szenarien systematisch. Mit der Inventur-Tabelle als Leitfaden. Pro Szenario maximal 30 Minuten, schauen, was es tut, dokumentieren, was ich finde. Was ich fand, war eine Mischung aus solide, fragwürdig und besorgniserregend.

Drei konkrete Beispiele.

Szenario "Lead Routing zu Pipedrive". 18 Module. Lief seit 14 Monaten. Auf den ersten Blick sauber aufgebaut, klare Struktur, sinnvolle Verzweigungen für verschiedene Lead-Quellen aus Webformularen, Drittanbieter-Plattformen, Messen. Beim genaueren Hinsehen entdeckte ich einen "Filter", der seit acht Monaten alle Leads aus Österreich blockierte. Niemand wusste, warum. Vermutlich hatte jemand vor langer Zeit testen wollen, ob österreichische Leads anders qualifiziert werden müssten, und den Filter danach vergessen. Acht Monate lang verschwanden österreichische Leads. Niemandem aufgefallen, bei einem Sales-Team, das aktiv im DACH-Raum verkauft.

Szenario "Stripe-Webhooks zur Buchhaltung". Sollte jede Stripe-Zahlung in eine interne Buchhaltungs-API weitergeben. Bei näherem Hinsehen: das Szenario lief jeden Tag, das Stripe-Modul lieferte Daten, der HTTP-Request zur Buchhaltungs-API antwortete jedoch seit fünf Monaten mit 401 Unauthorized. Das Token war abgelaufen. Niemand hatte es bemerkt, weil das Szenario keinen expliziten Fehler-Handler hatte. In Make wird ein Modul mit 4xx-Antwort als "ausgeführt" gewertet, der Workflow läuft weiter. Die Operationsstatistik sah gut aus. Die Buchhaltungsdaten für fünf Monate fehlten teilweise in der Hauptdatenbank und mussten später manuell rekonstruiert werden. Aufwand der Nacharbeit: zwei Wochen Buchhaltung.

Szenario "Customer Success E-Mail-Sequenz". Sollte neuen Kunden über fünf Wochen automatisierte Onboarding-Mails schicken. Hatte einen Bug, der bewirkte, dass jeder neue Kunde nicht nur seine eigene Mails bekam, sondern alle Mails, die jemals an irgendeinen Kunden geschickt worden waren. Der Trigger las nicht den einzelnen neuen Kunden, sondern die gesamte Kundenliste. Das Resultat: jeder neue Kunde bekam in den ersten 24 Stunden zwischen 60 und 80 Onboarding-Mails. Das Customer-Success-Team hatte den Bug seit drei Monaten gemeldet, niemand hatte ihn angefasst, weil niemand das Szenario in seiner Zuständigkeit sah.

Zweite Lektion. Ein Szenario, das in Make "läuft", ist nicht dasselbe wie ein Szenario, das funktioniert. Make zeigt grüne Häkchen für ausgeführte Module, nicht für ausgeführte Geschäftslogik. Wenn ein HTTP-Modul eine 401 zurückbekommt und es im Szenario keinen expliziten Fehler-Handler gibt, läuft das Szenario weiter, als wäre nichts passiert. Wenn ein Trigger die falschen Daten zieht, sieht der Operations-Report sauber aus, während im Hintergrund die Geschäftslogik kollabiert.

Was ich daraus mitnehme. Jeder produktive Workflow braucht einen Fehler-Handler, der nicht nur loggt, sondern aktiv jemanden alarmiert. Slack, E-Mail, Pager, egal. Aber nicht stumm. Make hat seit 2023 eine eingebaute Auto-Recovery-Funktion für gescheiterte Runs, sie ist nicht standardmäßig aktiv. In drei von vier Audits finde ich, dass sie nicht eingeschaltet ist.

Tag drei: die Datenflüsse, die niemand mehr versteht

Tag drei verbrachte ich damit, die wichtigsten Datenflüsse zu rekonstruieren. Welche Daten fließen in welchen Volumina von wo nach wo, mit welcher Frequenz, mit welchen Transformationen?

Bei einem Workflow zur Synchronisation von HubSpot-Kontakten zu Mailchimp entdeckte ich ein Problem, das ich oft sehe. Der Sync lief alle 15 Minuten, jedes Mal mit "Search Contacts" als Trigger, statt mit einem delta-basierten "Watch Updated Contacts". Bedeutet: bei jeder Ausführung wurden alle 12.000 Kontakte verglichen und gegebenenfalls aktualisiert. Pro Ausführung gut 12.000 Operations, die in Make zur Operations-Quote zählen. 96 Ausführungen pro Tag mal 12.000 Operations ergeben 1.152.000 Operations täglich, also rund 35 Millionen Operations im Monat.

Make rechnet im Stammtarif mit 10.000 Operations pro Monat ab. Das Konto lag chronisch auf dem teuersten Tarif, weil die Operations-Zahl im Vorjahr immer wieder gerissen war und automatische Upgrades ausgelöst hatte. Resultat: ein Make-Tarif mit 1.500 Euro pro Monat, der durch eine schlechte Trigger-Wahl entstanden war. Tatsächlich relevante Updates an Mailchimp passierten gut 30 Mal pro Tag.

Die simple Reparatur war, "Watch Updated Contacts" als Trigger zu nutzen. Resultat nach Umstellung: die monatlichen Operations fielen von 35 Millionen auf 22.000. Tarifkosten von 1.500 Euro pro Monat auf 29 Euro pro Monat. Über zwölf Monate gerechnet: rund 17.000 Euro Ersparnis, durch eine Designänderung, die unter eine Stunde Arbeit brauchte.

Dritte Lektion. In Make-Tarifen ist die Operation-Zahl die entscheidende Variable. Wer "Watch all" oder "Search all" als Trigger nimmt, statt einen Delta-Trigger zu nutzen, verbrennt Geld. Die Plattform belohnt schlampige Architektur mit höheren Rechnungen. Wer das nicht aktiv überprüft, zahlt unnötig hohe Gebühren.

Im selben Audit fand ich ein zweites, ähnliches Szenario. Es lief alle 5 Minuten, um "wenn ein neues Item in einer Airtable-Basis ist, lege es in einer zweiten Airtable-Basis ab", mit einer Verzögerung. Das Szenario löste pro Tag 200 bis 400 Operations aus, die alle nichts taten, weil in 99 Prozent der Ausführungen kein neues Item da war. Die simple Umstellung: Airtable-Webhook statt Polling. Resultat: 96 Prozent weniger Operations, dieselbe Funktionalität, geringere Verzögerung beim Trigger.

Make, Zapier und n8n haben unterschiedliche Tarif-Strukturen. Make rechnet pro Operation, Zapier pro Task, n8n pro Workflow-Execution. Wer die jeweilige Tarif-Logik nicht versteht, baut Szenarien, die auf einer Plattform günstig wären, auf einer anderen aber teuer.

Tag vier: die Geheimnisse der Verbindungen

Tag vier war der unangenehmste. Ich öffnete die Verbindungsliste in Make. 89 Verbindungen waren angelegt. 12 davon waren ausgegraut, weil die zugehörigen Plattformen ihre OAuth-Tokens widerrufen hatten. 7 zeigten "Token expired" oder "Authentication failed". Die restlichen 70 sahen "aktiv" aus, aber das ist im Make-UI keine Garantie für Funktion. Aktive Verbindungen können trotzdem stille Fehler werfen, wenn die Berechtigungen auf der anderen Seite eingeschränkt wurden.

Was mich am meisten beunruhigte. Ich konnte aus den Namen oft nicht ableiten, wem diese Verbindungen gehörten. "HubSpot Connection 3", "Stripe Account 2", "Google Sheets Production". Wer hatte sie angelegt? Welche persönlichen Zugangsdaten waren darin hinterlegt?

Es kam heraus. 31 der 89 Verbindungen waren von Mitarbeitenden angelegt worden, die das Unternehmen mittlerweile verlassen hatten. In manchen Fällen war die ehemalige Person laut Make noch immer der "Owner" der Verbindung. Was bedeutet: wenn diese ehemalige Person ihren HubSpot-Account auflöst oder die Berechtigungen ändert, sterben alle Workflows, die von dieser Verbindung abhängen, sofort.

Im konkreten Audit fanden wir auch zwei Verbindungen, deren Owner laut interner LinkedIn-Recherche bei der Konkurrenz arbeiteten. Theoretisch hätten diese Personen über ihre noch in Make hinterlegten Zugangsdaten weiterhin auf die Plattformen zugreifen können, falls die Plattformen die OAuth-Sessions nicht automatisch beim Account-Löschen invalidieren. Es ist nicht klar, ob Daten abgeflossen sind. Aber die Tatsache, dass es theoretisch möglich war, hat den CISO eine Stunde lang nicht schlafen lassen.

Vierte Lektion. Verbindungen sollten nicht auf persönliche Accounts laufen. Sie sollten auf Service-Accounts laufen, die der Firma gehören und nicht an einzelne Mitarbeitende gebunden sind. In Plattformen wie HubSpot, Stripe, Salesforce oder Pipedrive lassen sich solche Service-Accounts anlegen. Bei Google Workspace funktioniert das über Service-Account-Keys. Bei Plattformen wie Notion oder Airtable über Integration-Tokens. Was nicht funktioniert, ist die naive Annahme, dass "die Person, die das Szenario gebaut hat, eh in der Firma bleibt".

In diesem Audit empfahl ich eine systematische Umstellung. Für jede produktiv genutzte Verbindung wurde ein Service-Account beim jeweiligen Anbieter angelegt, die Verbindung in Make neu erstellt mit den Service-Account-Credentials, und die alte Verbindung gelöscht. Aufwand: drei Tage Arbeit eines Inhouse-Operations-Mitarbeiters. Resultat: Resilienz gegenüber Personalwechseln, klarer Audit-Trail, deutlich einfachere DSGVO-Argumentation gegenüber dem Datenschutzbeauftragten.

Eine Anmerkung, die mir wichtig ist. Service-Accounts sind kein Allheilmittel. Sie haben eigene Risiken. Wenn der Service-Account-Schlüssel kompromittiert wird, ist der Schaden potenziell größer als bei einem persönlichen Account, weil mehr Workflows betroffen sein können. Service-Accounts brauchen daher Rotationsregeln, klare Verantwortliche, restriktive Berechtigungen. Sie sind das geringere Übel, nicht die ideale Lösung.

Tag fünf: das Pause-Experiment

Tag fünf war der spannendste. Ich nahm die wichtigsten 8 Szenarien und mappte sie zu konkreten Geschäftsprozessen. Frage. Was tut dieses Szenario, welches Geschäftsziel verfolgt es, was würde passieren, wenn es nicht mehr läuft?

Bei drei der acht Szenarien konnte ich diese Frage nicht beantworten. Niemand im Unternehmen konnte es. Diese drei Szenarien liefen seit über einem Jahr, hatten in dieser Zeit insgesamt rund 280.000 Operations konsumiert, also geschätzt rund 800 Euro Make-Tarif-Anteil. Niemand wusste mehr, was sie taten oder ob jemand sich auf ihre Outputs verließ.

Ich machte ein Experiment, das ich allen Kunden empfehle. Ich pausierte diese drei Szenarien. Nicht löschen, nur pausieren. Reversibel. Wenn jemand sich beschwert, ist das Szenario wichtig. Wenn niemand sich in 30 Tagen meldet, ist das Szenario löschreif.

Tag 15 nach der Pause: ein Mitarbeiter aus der Produktentwicklung beschwerte sich, dass "der Wettbewerber-Tracker" nicht mehr lief. Aha. Eines der drei Szenarien war ein Scraper, der täglich öffentliche Preisseiten von drei Wettbewerbern in eine Google-Sheets-Tabelle schrieb. Verteidigt wurde es als Marktbeobachtung. Wir reaktivierten es, aber dokumentierten es danach sauber, mit Eigentümer, Geschäftszweck, Fehler-Handler.

Tag 22: zwei der drei verbleibenden pausierten Szenarien hatten weiterhin keinen Beschwerdeführer. Tag 30: beide wurden endgültig gelöscht. Eines davon hatte sich als alter Migrations-Workflow herausgestellt, der mal benutzt worden war, um Daten aus einer alten Salesforce-Instanz in die neue zu schieben. Die Migration war seit 18 Monaten abgeschlossen. Das Szenario hatte trotzdem alle 6 Stunden gepollt.

Fünfte Lektion. Was niemand vermisst, gehört weg. Workflows haben einen tendenziell ewigen Lebenszyklus, wenn niemand sie aktiv kürzt. Sie kosten Operations, sie kosten kognitive Last bei jedem Audit, sie kosten Risiko in Form von potenziellen Datenabflüssen. Wenn niemand mehr verteidigen kann, warum ein Szenario läuft, gehört es in den Papierkorb.

Manche Kunden tun sich mit diesem Schritt schwer. Verständlich. Was, wenn es doch jemand braucht? Genau dafür ist die Pause-Methode da. Eine Pause ist reversibel. Eine 30-Tage-Frist gibt allen Beteiligten genug Zeit, sich zu melden. Wer sich in 30 Tagen nicht meldet, hat das Szenario nicht aktiv genutzt. Das ist ein Datum, kein Bauchgefühl.

Tag sechs: die Dokumentation, die niemand geschrieben hat

Ein klassisches Problem bei No-Code-Plattformen ist die Dokumentation. Make hat seit einigen Versionen ein Notizfeld pro Modul. Theoretisch könnte man dort die Logik hinter jeder Entscheidung dokumentieren. Praktisch findet sich in 95 Prozent der Szenarien keine einzige Notiz.

Was fehlte konkret in diesem Audit.

Warum bestimmte Filter gesetzt waren. Wir fanden 23 Filter, deren Funktion sich nicht aus dem Modulnamen ableiten ließ. Beispiel: ein Filter mit dem Namen "Filter Region", welche Region wird gefiltert, warum, wer hat das entschieden? Stand nirgendwo.

Was die Mapping-Logik in komplexen Transformern macht. Bei sechs Szenarien war die Datentransformation so dicht, dass sie ohne Notizen eine Stunde oder mehr zum Verstehen brauchte. Verschachtelte If-Then-Logik, Regex-Matches, Datums-Konvertierungen, Lookup-Mappings.

Welche Geschäftsregel hinter einer Verzweigung steckte. Bei drei Szenarien gab es Verzweigungen mit nicht offensichtlichen Bedingungen. Beispiel: "wenn Lead Score > 70 und Industry = Finance und Country in DACH, dann route to Senior Sales". Warum genau diese Schwelle, warum genau diese Branche? Hatte jemand vor Monaten entschieden. Niemand erinnerte sich.

Was wir gemacht haben. Pro aktivem Szenario eine Markdown-Seite in der internen Dokumentation. Jede Seite folgte demselben Muster.

• Welchen Geschäftsprozess unterstützt dieses Szenario?
• Welcher Trigger startet es, mit welcher Frequenz?
• Welche externen Systeme sind betroffen?
• Welche Annahmen werden getroffen, die im Szenario nicht explizit sichtbar sind?
• Welche Person ist verantwortlich für Wartung und Fragen?
• Welche typischen Fehlermodi gibt es, und wie reagiert man darauf?

Bei 23 aktiven Szenarien ergab das 23 Seiten. Aufwand für den Audit: etwa drei Tage Arbeit, weil viele Annahmen erst aus den Daten und aus Stakeholder-Interviews rekonstruiert werden mussten. Resultat: ein lesbares Manual, mit dem jeder Operations-Mitarbeiter in der Firma in Zukunft selbst nachvollziehen kann, was ein Szenario tut.

Sechste Lektion. Visuelle Workflows sind keine Dokumentation. Sie sind die Implementierung. Dokumentation ist das, was erklärt, warum die Implementierung so aussieht. Wer keine separate Dokumentation pflegt, hat den ersten Schritt zum Bus-Factor-Problem schon gemacht.

Tag sieben: meine Empfehlungen für die nächsten zwei Jahre

Am siebten Tag schrieb ich meine Empfehlungen zusammen. Sechs Punkte, die ich in fast jedem Audit-Mandat empfehle. Sie sind nicht originell. Sie sind das, was jeder Software-Entwickler aus seinem Tag-Job kennt. Code Reviews, Monitoring, Dokumentation, Aufräumarbeit. Was bei klassischer Softwareentwicklung selbstverständlich ist, ist bei No-Code-Automatisierung oft nicht da. Genau darin liegt das Problem.

Eins. Monatliche Reviews. Jeden ersten Freitag im Monat schaut ein Operations-Mitarbeiter eine Stunde lang in das Konto. Was sind die Fehlerraten der letzten 30 Tage? Welche Szenarien hatten unerwartete Ausführungen? Welche Verbindungen sind in einem Warning-Zustand? Eine Stunde reicht, wenn die Tabelle aus dem Audit als Ausgangspunkt vorliegt.

Zwei. Quartalsweise Aufräumarbeit. Einmal pro Quartal werden alle Szenarien, die seit 90 Tagen nicht gelaufen sind, geprüft und entweder gelöscht oder aktiv reaktiviert. Verbindungen, die seit drei Monaten ausgegraut sind, werden gelöscht. Diese Routine verhindert das Anhäufen von kognitivem Müll.

Drei. Service-Account-Pflicht. Keine Verbindung mehr auf einem persönlichen Account. Wer eine neue Verbindung anlegt, muss sie auf einem Service-Account der Firma anlegen. Das bedeutet mehr Bürokratie beim Erstellen, dramatisch weniger Schmerz bei Personalwechseln.

Vier. Error-Handler in jedem produktiven Szenario. Wenn ein Modul scheitert, fließt der Fehler in einen zentralen Slack-Kanal oder ein Issue-Tracking-System. Stille Fehler sind das Schlimmste, was einem Operations-Team passieren kann, weil sie nur durch externe Beschwerden auffallen. Ein Workflow ohne Error-Handler in Produktion ist wie eine Server-Anwendung ohne Logging.

Fünf. Cost Monitoring. Eine simple Tabelle mit monatlichen Operations pro Szenario. Wenn ein Szenario plötzlich 30 Prozent mehr Operations konsumiert als im Vormonat, ist das ein Signal. Entweder ist die zugrundeliegende Daten-Volumen-Hypothese kaputt, oder das Szenario hat einen Bug. In beiden Fällen lohnt es sich, hineinzuschauen, bevor die Plattformrechnung kommt.

Sechs. Dokumentationspflicht für jedes neue Szenario. Wer ein neues Szenario in Produktion nimmt, schreibt vorher die Markdown-Seite mit den oben genannten sechs Feldern. Vorher, nicht nachher. Wer nicht dokumentieren möchte, soll nicht in Produktion gehen. Diese Regel klingt streng. Sie ist es. Sie ist auch der einzige Weg, das Bus-Factor-Problem dauerhaft zu vermeiden.

Was es kostet, das nicht zu tun

Bevor ich diesen Artikel abschließe, eine direkte Rechnung. Diese Forensik-Woche hat den Kunden 7 Beratungstage gekostet, also rund 9.000 Euro netto. Was haben wir gefunden?

Eine fehlende Buchhaltungs-Integration mit fünf Monaten Datenlücke. Nacharbeitskosten in der Buchhaltung: ungefähr 6.000 Euro, weil zwei Mitarbeitende zwei Wochen lang Zahlungen manuell rekonstruieren mussten.

Eine überdimensionierte Mailchimp-Sync mit rund 17.000 Euro unnötigen jährlichen Plattformkosten. Über zwei Jahre rückblickend: rund 34.000 Euro, die in fehlerhafte Trigger geflossen waren.

Eine Lead-Routing-Lücke, die acht Monate lang österreichische Leads verloren hatte. Bei einer geschätzten Konversionsrate von 8 Prozent und einem durchschnittlichen Deal-Wert im DACH-Geschäft des Kunden: rund 80.000 Euro entgangener Umsatz, vorsichtig geschätzt.

Eine Sicherheits-Lücke durch 31 Verbindungen ehemaliger Mitarbeitender. Potenzielle Schadenshöhe nicht abschätzbar, aber DSGVO-relevant. Bei einem realen Datenabfluss wären die Bußgelder im sechsstelligen Bereich plausibel gewesen.

Was hat der Kunde durch die 9.000 Euro Audit direkt gespart oder verhindert? Direkt nachweisbar rund 20.000 Euro im ersten Jahr durch Tarifoptimierung und Datenrekonstruktion. Indirekt verhindert deutlich mehr, schwer zu quantifizieren.

Diese Rechnung ist nicht universell. Manche Audits finden weniger, manche finden mehr. Aber das Muster ist konsistent. Jeder produktive Make- oder Zapier-Account, der zwei Jahre lang nicht systematisch gepflegt wurde, hat genug versteckte Probleme, dass ein Audit sich rechnet. Ich habe das mittlerweile in über 30 Mandaten gesehen. Die genauen Zahlen variieren. Das Muster nicht.

Was ich daraus mitnehme

Ich erzähle diese Geschichte oft Kunden, die mich zum ersten Mal anrufen, weil sie "schnell ein paar Automatisierungen brauchen". Die unausgesprochene Annahme dabei ist meistens: man baut etwas, es läuft, man freut sich. Die Realität ist anders. Man baut etwas, es läuft, und nach 18 Monaten ist es ein versteckter Albtraum, weil niemand mehr weiß, was es tut.

Das ist nicht spezifisch für Make. Bei Zapier, n8n, Power Automate, Workato und n8n-Self-Hosted sind die Muster ähnlich. Visuelle Workflows haben den großen Vorteil, dass sie schnell gebaut sind. Sie haben den großen Nachteil, dass sie ohne Disziplin schnell zu einem nicht-lesbaren Erbe werden.

Wer Automatisierung ernst meint, behandelt sie wie eine eigene Software-Disziplin. Mit Reviews, Monitoring, Dokumentation, Versionsmanagement. Wer sie nicht ernst meint, hat in 18 Monaten ein Konto voll mit Magie, die niemand mehr versteht. Beides ist legitim. Aber man sollte wissen, welche Wahl man trifft, bevor man im zweiten Jahr von einem fehlenden Buchhaltungsabgleich überrascht wird.

Audits sind unbequem. Sie kosten Zeit, sie kosten Geld, sie zeigen Versäumnisse. Sie sind auch die einzige Versicherung gegen den Tag, an dem ein Workflow ausfällt und niemand mehr weiß, wo anzufangen ist. Ich empfehle pro Jahr einen Audit-Tag pro 10 produktive Szenarien, mindestens einen Tag, maximal eine Woche. Bei einem mittelgroßen Konto sind das zwei bis drei Tage. Das ist nicht viel im Vergleich zu dem, was eine vergessene Lücke kostet.

Wenn Sie wissen möchten, wie viel Schmerz in Ihrem eigenen Konto schlummert, oder ob es überhaupt schon Zeit für eine Audit-Runde ist, ist der kostenlose Automations-Check ein guter Ausgangspunkt. In rund 30 Minuten haben Sie einen ersten Eindruck. Was Sie dann mit der Information machen, ist Ihre Entscheidung.