Code, nicht Powerpoints E-Book

Robert Meyer

• Herausgeber: epubli
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 153

Veröffentlichungsjahr: 2026

Beschreibung

150.000 Euro für eine PowerPoint-Präsentation, die in der Schublade landet. Kennen Sie das? 87% aller AI-Projekte im Mittelstand scheitern – nicht wegen schlechter Strategie, sondern weil niemand sie umsetzt. Consulting-Firmen liefern Folien. Sie brauchen Lösungen. Dieses Buch ist anders. Statt Theorie bekommen Sie funktionierende Automationen. Statt 120-seitiger Gutachten bekommen Sie Code, den Sie heute deployen können. Statt Workshops, die nichts verändern, bekommen Sie Skills, die täglich Stunden sparen. Was Sie lernen: Mit Claude Code in 2 Tagen automatisieren, wofür Berater 3 Monate brauchen Interaktive HTML-Präsentationen bauen, die PowerPoint wie Faxgeräte aussehen lassen Excel-Friedhöfe in automatisierte Dashboards verwandeln Prozesse aufbauen, die sich selbst heilen, statt nur Tickets zu erzeugen Sie brauchen keine Programmierkenntnisse, kein IT-Team und kein Hunderttausende-Euro-Budget. Claude schreibt den Code. 30 Euro im Monat reichen für den Start. 7 Bereiche. 16 Kapitel. 4 sofort einsetzbare Anhänge – jedes Kapitel endet mit konkreten Umsetzungsschritten. Code is eating Consulting. Unternehmen, die das verstehen, gewinnen. Code statt PowerPoint. Execution statt Theorie. Ergebnisse statt Folien.

Leseprobe

CODE, NICHT POWERPOINTS

Wie ich mit Claude Code, Skills und n8n mehr automatisiere als ganze Berater-Teams

– und Sie das auch können

Robert Meyer

© Robert Meyer, 2026

Alle Rechte vorbehalten.

Erste Auflage – Januar 2026

Dieses Buch wurde im Selbstverlag über Amazon Kindle Direct Publishing veröffentlicht.

Kein Teil dieses Buches darf ohne ausdrückliche schriftliche Genehmigung des Autors vervielfältigt, verbreitet oder in irgendeiner Form weiterverwendet werden.

Das vollständige Impressum finden Sie am Ende dieses Buches.

VORWORT: Die 150.000€-Präsentation, die niemand öffnet

Warum dieses Buch anders ist als jedes Beratungsgutachten, das Sie je gekauft haben

Es war ein grauer Februartag 2019, als ich in meinem Büro saß und eine dicke PowerPoint-Datei öffnete. 150.000 Euro hatte unsere Geschäftsführung für diese Präsentation bezahlt – eine »strategische Beratung« zu unserer digitalen Transformation. 347 Folien. Schöne Grafiken. Viel Text. Ich scrollte durch die Executive Summary, las von »Synergieeffekten« und »digitaler Reife« und merkte nach etwa fünf Minuten: Ich bin vollkommen überfordert.

Das war der Moment, in dem mir der Puls schneller wurde. Nicht vor Aufregung. Vor Wut.

Wir hatten 150.000 Euro bezahlt, und niemand in unserem Team würde diese Präsentation je umsetzen. Nicht weil wir faul waren. Nicht weil wir nicht motiviert waren. Sondern weil eine Präsentation kein Produkt ist. Eine Präsentation ist das Gegenteil von Lösung – sie ist die Illusion von Lösung.

Unsere Geschäftsführung war zufrieden. Sie konnte das Gutachten dem Vorstand zeigen. Die Berater konnten Erfolg vermelden. Unsere IT-Abteilung starrte auf 347 Folien und fragte sich, wo Sie anfangen sollte.

Sechs Monate später war die Datei in einem Netzwerk-Ordner verschwunden. Niemand hätte sie, wenn ich nachgefragt hätte, von der Festplatte rausgekratzt.

Das ist der »PowerPoint-Friedhof« – und der Mittelstand ist voll davon.

Dieses Buch handelt von dem Tag, als ich aufhörte, Beratungsgutachten zu akzeptieren. Es handelt davon, wie ich stattdessen anfing, Code zu schreiben. Und wie ich in den letzten drei Jahren mehr automatisiert habe – in meinen eigenen Organisationen und später bei Clients – als klassische Berater in drei Quartalen mit zehn Consultants zusammen zustande bringen würden.

Nicht weil die Berater dumm sind. Sondern weil das System, in dem sie arbeiten, es ihnen unmöglich macht, zu liefern, was Mittelstandler wirklich brauchen: nicht Theorie, sondern Code. Nicht Strategiepapiere, sondern Systeme, die morgen früh von der ersten Kaffeetasse an funktionieren.

Das ist kein Anti-Beratungs-Manifest. Das ist ein praktisches Angebot: Wie Sie lernen, die Dinge selbst zu bauen. Wie Sie mit Claude, Skills und n8n ein Skillset aufbauen, das Ihr Unternehmen unabhängig macht von teuren Durchgängern. Und wie Sie – ohne Entwickler sein zu müssen – komplexe Automatisierungen bauen, die funktionieren.

Die nächsten Kapitel zeigen Ihnen, was ich gelernt habe. Nicht die Theorie dahinter. Die Praxis. Mit Code. Mit echten Workflows. Mit echten Ergebnissen.

Das erste Kapitel ist zuerst. Aber wissen Sie schon jetzt, worum es geht: Code statt PowerPoint. Execution statt Gutachten. Deployen statt Präsentieren.

Willkommen zu dem Buch, das keine 347 Folien braucht, um Ihr Geschäft zu ändern.

INHALTSVERZEICHNIS

TEIL I: DIE BERATUNGSLÜGE

Kapitel 1: Ihre Berater liefern Folien, keine LösungenDer PowerPoint-Friedhof im MittelstandWarum Strategie-Decks in der Schublade landenDer Tag, an dem ich aufhörte, Präsentationen zu versenden

Kapitel 2: Die Kosten der Theorie87% gescheiterte KI-Projekte: Die unbequeme WahrheitWas klassische Beratung NICHT liefertDer Unterschied zwischen »beauftragt« und »umgesetzt«

Kapitel 3: Code als neue WährungWarum »deployen statt präsentieren« die Zukunft istDie 13% die es schaffen – und was sie anders machenVon der Beratungs-Abhängigkeit zur Execution-Kompetenz

TEIL II: DIE WERKBANK – CLAUDE CODE, SKILLS & N8N

Kapitel 4: Das Fundament – Warum diese drei ToolsClaude Code: Der KI-Entwickler, der keine Pause brauchtSkills: Wissen, das sich selbst anwendetn8n: Wenn es dann doch orchestriert werden mussMCP: Das unsichtbare Protokoll, das alles verbindet

Kapitel 5: Der Stack im DetailWie Claude Code mit lokalen Dateien arbeitetSkills als wiederverwendbare Automatisierungs-EinheitenWann n8n, wann pure Claude Skills?GitHub als Deployment-Infrastruktur

Kapitel 6: Die Denk-InversionVom Tool-Denken zum Ergebnis-DenkenWarum »Skills > Workflows« das neue Paradigma istBuild vs. Buy – neu gedacht

TEIL III: DIE 7 BEREICHE – VON DER THEORIE ZUR EXECUTION

Kapitel 7: Bereich 1 – PräsentationenStatt PowerPoint → Interaktive HTML-PräsentationenMein Workflow: Claude Code → HTML → GitHubWarum Teilnehmer nie wieder nach »den Folien« fragenLive-Präsentationen, die allen sofort zur Verfügung stehenUmsetzung: Ihr erster HTML-Präsentations-Workflow

Kapitel 8: Bereich 2 – DokumentationStatt Word-Berichte → Living DocumentationEU-KI-Gesetzes-Compliance-Dokumentation, die sich selbst aktualisiertSkills, die Dokumente auf Aktualität prüfenVon 40 Stunden Berichtsarbeit zu 2 Stunden ReviewUmsetzung: Automatisierte Dokumentations-Pipeline

Kapitel 9: Bereich 3 – DatenanalyseStatt Excel-Friedhöfe → Automatisierte DashboardsWarum manuelle Excel-Reports Ihr Team ausbrennenClaude Code + Python: Von CSV zu Insights in MinutenSkills, die Anomalien selbst erkennenUmsetzung: Ihr erstes Self-Service-Dashboard

Kapitel 10: Bereich 4 – ProzessautomatisierungStatt n8n-Spaghetti → Intelligente Skills mit KontextWann n8n allein nicht reichtMCP Server als Integration-LayerSkills, die n8n intelligent orchestrierenUmsetzung: Hybrid-Workflow Claude + n8n

Kapitel 11: Bereich 5 – WissensmanagementStatt Notion-Chaos → Executable Knowledge GraphsVon »wo war das nochmal?« zu strukturiertem WissenObsidian + Claude Code: Second Brain mit HandsSkills, die Widersprüche in Ihrer Wissensbasis findenUmsetzung: Ihr intelligenter Wissensassistent

Kapitel 12: Bereich 6 – ProjektmanagementStatt Jira-Theater → Selbstheilende ProzesseWarum Tickets keine Probleme lösenSkills, die Code-Reviews automatisierenVon »Ticket erstellt« zu »Problem behoben«Umsetzung: Automatisierte Code-Quality-Pipeline

Kapitel 13: Bereich 7 – Training & ChangeStatt Workshops → Trainierte Skills, die bleibenWarum klassisches Change Management scheitertSkills als dauerhafte VerhaltensänderungVon »3-Tages-Workshop« zu »täglich gelebter Praxis«Umsetzung: Ihr erstes Trainings-Skill-Set

TEIL IV: DIE UMSETZUNG

Kapitel 14: Die ersten 30 TageWoche 1: Setup & GrundlagenWoche 2: Ihr erster Use CaseWoche 3: SkalierungWoche 4: Team-Enablement

Kapitel 15: Die häufigsten Stolpersteine»Wir haben keine Entwickler« – und warum das egal istSecurity-Bedenken und wie man sie adressiertWenn das Management fragt: »Wo ist die PowerPoint?«Der richtige Umgang mit gescheiterten Versuchen

Kapitel 16: Vom Praktiker zum SystematikerWie Sie Ihre Skills dokumentierenWann externe Dienstleister trotzdem Sinn machenDie nächste Stufe: Skills, die Skills erstellenVon der Einzellösung zur Unternehmens-Infrastruktur

NACHWORT: Code is eating Consulting

ANHANG A: Tool-Übersicht & Installation

ANHANG B: Skill-Vorlagen für den Schnellstart

ANHANG C: MCP Server für typische Mittelstands-Use-Cases

ANHANG D: Ressourcen & Community



EINLEITUNG: Warum Sie dieses Buch in Ihren Händen halten müssen

Stellen Sie sich vor, es ist Montag morgens, 08:47 Uhr. Ihr Telefon vibriert. Eine E-Mail von Ihrem größten Kunden: »Können Sie mir bis heute 17:00 Uhr eine Marktanalyse machen? Excel-Datei, Visualisierung, die wichtigsten Erkenntnisse?«

Das war bis vor drei Jahren mein Horror-Szenario. Das bedeutete: ganzen Vormittag auf den Rechner starren, mit zig Datenquellen herumwürgen, Excel-Makros debuggen, die von irgendwem vor zwei Jahren geschrieben wurden und jetzt nicht mehr funktionieren, alles in ein PowerPoint-Template pressen, um 16:45 Uhr noch schnell einen Pdf generieren, und dann – ah ja – starten die Rechtschreibfehler von der Qualitätssicherung zu bluten.

Das war Beratung im Mittelstand: spannend bei der Auftragserteilung, brutal beim Abliefern, unglücklich bei der Rechnung.

Heute – drei Jahre, 47 Automatisierungen und 2.300 Stunden ersparte Handarbeit später – erledigt sich dieselbe Aufgabe in 23 Minuten. Der Code läuft. Die Daten werden gezogen. Das Dashboard wird gebaut. Der Kunde bekommt einen Link, und das war's.

Das Verrückte: Ich habe dafür zwei Dinge gelernt. Nicht zehn. Nicht 50. Zwei.

Das erste ist: Mit Claude Code können Sie ohne Entwickler-Ausbildung, ohne 20 Jahre Stack Overflow-Erfahrung, auch ohne PhD in Informatik Dinge automatisieren, für die Ihr ehemaliges Unternehmen eine ganze Abteilung gebraucht hätte.

Das zweite ist: Der Unterschied zwischen »ich habe eine Lösung entwickelt« und »ich habe einen Consultant bezahlt, der mir sagt, wie eine Lösung aussehen könnte« ist größer als der Unterschied zwischen Null und einer Milliarde Dollar – weil das eine funktioniert und das andere nie umgesetzt wird.

Das ist nicht Technologie-Schwärmerei. Das ist wirtschaftliche Realität.

In Deutschland haben Unternehmen mit 10 bis 500 Mitarbeitern ein Problem, das die großen Korporationen nicht haben: Sie leisten sich keine IT-Abteilung mit zehn Entwicklern. Aber sie brauchen trotzdem fast täglich Automatisierungen. Ein Prozess, der noch manuell läuft. Ein Bericht, der jede Woche per Hand zusammengestellt wird. Eine Datenquelle, die mit einer anderen synchronisiert werden muss. Ein Kundenservice, der über drei Tools gleichzeitig arbeitet, statt über eins.

Die klassische Antwort war: »Tja, das kostet halt. Mal eben 50.000 Euro für einen Consultant, der Ihnen einen Prozess optimiert.«

Oder: »Lernen Sie VBA.« (Nein, danke.)

Oder: »Stellen Sie einen Entwickler ein.« (Mit welcher Gehalt? In welcher Gegend?)

Das Buch, das Sie in Ihren Händen halten, handelt davon, dass Sie keine dieser Optionen mehr brauchen.

Es handelt davon, dass Sie – ja, Sie persönlich, auch ohne je eine Codezeile geschrieben zu haben – in den nächsten 12 Wochen ein Skillset aufbauen können, das Ihr Unternehmen so produktiv macht, dass Sie nie wieder »Wir können das nicht automatisieren, weil wir keine Entwickler haben« sagen müssen.

Ich weiß, das klingt nach Marketing-Sprech. Das verstehe ich. Lesen Sie trotzdem weiter.

Drei Zahlen, bevor wir anfangen:

Die erste Zahl ist 87%. Das ist der Anteil aller KI-Implementierungen im Mittelstand, die scheitern. Nicht weil die Technologie schlecht ist. Sondern weil die Implementierung scheitert. Weil irgendwo zwischen »Das haben wir geplant« und »Das funktioniert in der Produktion« etwas kaputt geht. Oft ist es die fehlende Fähigkeit, die Lösung selbst anzupassen. Die Abhängigkeit von externen Entwicklern, die teuer sind oder viel zu lange brauchen. Die Tatsache, dass irgendwann im Prozess jemand sagt: »Ja, das war schön, aber wir brauchen noch schnell Feature X« – und dann sitzt man zwei Wochen fest.

Die zweite Zahl ist 13%. Das ist der Anteil der Mittelständler, die dieses Durchwurstel-Szenario vermeiden. Sie haben – für sich selbst oder mit kleinen Teams – das Handwerkzeug gelernt, um ihre Automatisierungen nicht zu »bestellen«, sondern selbst zu bauen. Und diese 13% haben ein Wettbewerbsvorteil, der exponentiell wächst: Mit jeder Woche, in der sie lernen, ihre Prozesse schneller zu automatisieren, wächst ihr Vorsprung exponentiell zu den 87%.

Die dritte Zahl ist 150.000. Das ist die Höhe der Rechnung, die ich am Anfang kassiert habe – für eine Präsentation, die keinen Umsatz gebracht hat. Addieren Sie dazu alle anderen Beratungsgutachten, die in Schubladen liegen, alle PowerPoint-Decks, die kein Mensch mehr öffnet, alle Strategiepapiere, die im ersten Quartier geschrieben, im zweiten ignoriert und im dritten vergessen werden.

Das ist die summe der verschenkten Zeit und des verschenkten Geldes im deutschen Mittelstand. Und das kann ab sofort anders sein.

Worum dieses Buch geht – und worum es nicht geht:

Dieses Buch ist kein technisches Lehrbuch. Sie werden nicht lernen, wie Transformer-Modelle funktionieren oder warum Large Language Models statistische Vorhersage-Maschinen sind. Wenn Sie das interessiert – es gibt andere Bücher, die das viel besser können.

Dieses Buch ist auch kein »Claude für Anfänger«-Anleitung. Es ist nicht für Leute, die noch nicht mit Claude gearbeitet haben. Sie sollten Claude schon ein paarmal benutzt haben. Am besten, Sie kennen den Unterschied zwischen Chat und Project bereits. Das spart uns Zeit.

Dieses Buch ist auch nicht für Leute, die Entwickler sind. Wenn Sie Professional Developer sind, werden Sie vieles hier zu simpel finden. Dieses Buch ist für Praktiker – Geschäftsführer, IT-Leiter, Prozessverantwortliche – die wissen, dass es besser gehen muss, und bereit sind, die Zeit zu investieren, um es selbst zu bauen.

Worum dieses Buch geht:

Es geht darum, dass Sie lernen, schnell und zuverlässig Automatisierungen zu bauen. Claude Code, Skills und n8n sind das Werkzeug. Ihre Geschäftsprobleme sind die Baustelle. Und der Code ist nicht das Ziel – die Lösung ist das Ziel.

Es geht darum, dass Sie verstehen, wo Claude anfängt und wo n8n anfängt. Wo Sie »einfach nur prompting« machen können und wo Sie tiefer einsteigen müssen. Wann Sie eine No-Code-Lösung bauen und wann Sie Low-Code brauchen.

Es geht darum, dass Sie die sieben Bereiche kennenlernen, in denen das meiste Zeitverschweibung im Mittelstand passiert: Präsentationen, Dokumentation, Datenanalyse, Prozessautomatisierung, Wissensmanagement, Projektmanagement und Training. Für jeden Bereich gibt es ein Kapitel. Für jedes Kapitel gibt es einen konkreten Workflow, den Sie morgen früh implementieren können.

Es geht darum, dass Sie verstehen, warum Execution besser ist als Planung. Warum ein funktionierendes System, das heute läuft, mehr wert ist als die beste Strategie, die morgen umgesetzt wird.

Wie Sie dieses Buch lesen sollten:

Option 1: Vorlesen. Lesen Sie Part I in einem Durchgang. Das sind 23 Seiten über die alten Fehler. Die müssen Sie verstehen, bevor wir anfangen, sie zu vermeiden. Dann fahren Sie mit Part II fort – das ist die Handwerkerlehre. Das sind auch nur 29 Seiten, aber die sind dicht. Lesen Sie die langsam. Machen Sie Notizen. Dann – und das ist wichtig – überspringen Sie zu dem Kapitel in Part III, das zu Ihrem nächsten Projekt passt.

Option 2: Zu Ihrem Use Case springen. Wenn Sie ein konkretes Problem haben – »Wir brauchen ein Dashboard« oder »Unsere Dokumentation ist immer veraltet« – können Sie direkt zu Kapitel 7, 8, 9, 10, 11, 12 oder 13 springen. Jedes Kapitel ist in sich geschlossen. Sie werden aber ein paarmal ein Konzept vermissen, das ich in Part II erklärt habe. Das ist okay. Dann lesen Sie das Konzept nach.

Option 3: Schnellgang. Sie sind busy, und Sie wollen einfach schnell wissen, was Sie morgen bauen können. Lesen Sie Chapter 4 (Das Fundament) – 14 Seiten. Lesen Sie dann die »Umsetzung«-Sektion des Kapitels, das Sie interessiert. Das dauert eine Stunde. Dann bauen Sie zwei Wochen. Dann lesen Sie die restlichen Kapitel.

Alle drei Optionen funktionieren. Wählen Sie die, die passt.

KAPITEL 1: IHRE BERATER LIEFERN FOLIEN, KEINE LÖSUNGEN

Der PowerPoint-Friedhof im Mittelstand

Wenn ich heute durch Büros im deutschen Mittelstand gehe und frage: »Zeigen Sie mir Ihre letzten drei Beratungsgutachten« – bekomme ich fast immer die gleiche Reaktion. Ein gequältes Lachen. Ein kurzes »Ach ja, diese Decks« – und dann eine Geschichte, die alle gleich klingt.

Das Gutachten war teuer. 40.000, 80.000, manchmal 150.000 Euro. Es war schön gemacht. Schöne Grafiken. Professionelle Layouts. Es hat dem Vorstand beeindruckt. Und dann?

Nichts.

Das Ding liegt im Netzwerk. Irgendwann wird eine Folder dafür angelegt – »Digitale Transformation 2023« oder »KI-Strategie Q3 2024«. Die Geschäftsführung zitiert es vielleicht auf einer Betriebsversammlung. Das war's.

Das ist nicht tragisch. Das ist System.

Das System funktioniert so: Ein Consultant kommt. Er sitzt mit Ihnen in Meetings. Er stellt Fragen. Er schreitet Ihre Prozesse ab. Er macht zwei, drei Wochen Notes. Dann sitzt er im Büro und verwandelt diese Notes in PowerPoint. 120 Folien über Ihre IT-Struktur. 87 über Change Management. 34 über Compliance. Dazu noch 50 über die Implementierungsplanung – immer mit Timelines, die auf den Tag genau sind, aber garantiert nicht eingehalten werden.

Der Consultant zeigt Ihnen das Ergebnis. Sie sagen: »Großartig!« Die Rechnung kommt. Sie sagen: »Ouch, aber okay.« Und dann verschwindet das Ding in einer Schublade.

Warum?

Weil eine PowerPoint-Präsentation kein Produkt ist. Es ist Information. Und Information ist nicht Execution.

Das ist der Kern des Problems, und wenn Sie diesen einen Satz verstehen, verstehen Sie, warum die nächsten 240 Seiten für Sie wertvoll sein könnten.

Eine PowerPoint-Präsentation sagt: »Hier ist, was Sie tun sollten.«

Ein funktionierendes System sagt: »Hier ist, was Sie tun könnten, und es funktioniert schon.«

Die erste braucht Ihre Arbeit. Die zweite braucht nur Ihre Unterschrift.

Und wenn Sie choice zwischen zwei Dingen haben – und Sie haben choice, weil Sie müde sind und Ihre IT-Abteilung auch – dann wählen Sie das zweite.

Das ist kein Charakterfehler von Ihnen. Das ist Ökonomie.

Warum Strategie-Decks in der Schublade landen

Ich will an dieser Stelle nicht unfair sein. Die Berater, die diese Decks machen, sind oft brillant. Sie sind klug. Sie verstehen Ihre Industrie. Sie erkennen Probleme, die Sie selbst nicht erkennen würden. Und wenn Sie diese Presentation mit zehn anderen Geschäftsführern aus Ihrer Branche vergleichen – Sie würden wahrscheinlich sagen: »Ja, das ist akkurat.«

Das Problem ist nicht die Qualität der Analyse. Das Problem ist: Nach der Präsentation ist eine Präsentation, und Sie müssen bauen.

Und Bauen ist nicht Präsentieren.

Hier ist ein echtes Beispiel aus meiner eigenen Laufbahn. Wir hatten einen großen Kunden – ein Maschinenbau-Unternehmen mit 250 Mitarbeitern. Sie brauchten eine »digitale Transformation«. Das war das Buzzword damals.

Sie beauftragten eine große Beratungskanzlei – Name tue hier nichts zur Sache. Die Berater kamen raus. Sie saß mit dem CIO, mit dem Controller, mit dem Vertriebsleiter. Sie fragte: »Wie sieht Ihre Sales-Pipeline aus? Wie wird die Dokumentation gemacht? Wo sind die Reibungsverluste?«

Drei Wochen später präsentierten sie eine 280-Folien-Powerpoint. Die war beeindruckend. Wirklich. Sie beschrieb genau die Prozesse, die nicht funktionierten. Sie schlug konkrete Lösungen vor. Sie hatte Timelines.

Und dann ist nichts passiert.

Der CIO sagte hinterher: »Die Analysis ist großartig. Aber jetzt soll ich WAS genau tun? Meine Abteilung hat 1,5 Entwickler. Die haben genug Probleme. Wer soll das implementieren?«

Das ist die Falle, in der alle Mittelständler sitzen:

Die Berater liefern die Planung. Die Planung ist gut. Aber die Planung passt nicht zu Ihren Ressourcen.

Das ist kein Fehler des Beraters. Es ist kein Fehler von Ihnen. Es ist ein Strukturproblem. Der Berater wird bezahlt, um zu analysieren. Er wird nicht bezahlt, um zu bauen. Das Bauen sollte Ihre Abteilung machen. Aber Ihre Abteilung hat keine Kapazität. Also sitzt die Planung irgendwo herum.

Manche Unternehmen versuchen, das zu lösen, indem sie gleich eine teurere Beratungskanzlei nehmen – eine, die nicht nur plant, sondern auch baut. Das kostet dann schnell das Zehnfache. Und der Berater, der baut, ist oft nicht besser als Ihr interner Entwickler – er ist nur teurer und nicht daran interessiert, dass sein Code nachhaltig ist, weil er nächste Woche wieder weg ist.

Das ist, wie der PowerPoint-Friedhof wächst.

Es wächst mit jedem Unternehmen, das denkt: »Wir brauchen einen Consultant, damit er uns sagt, was wir tun müssen.« Weil die Antwort auf die nächste Frage – »Und wer baut es?« – nie gut beantwortet wird.

Der Tag, an dem ich aufhörte, Präsentationen zu versenden

Für mich selbst ging dieser Wechsel von »Ich bezahle Berater« zu »Ich bau es selbst« schneller, als ich erwartet hätte. Und es war nicht mal ein bewusster Wechsel. Es war eher ein: »Ah, das funktioniert ja besser. Lass ich einfach weitermachen.«

Es war irgendwann 2022. Wir hatten gerade so ein 80.000-Euro-Gutachten bekommen – ein Beratungsprojekt zu unserer Dokumentation. Wie wir Kundenanfragen besser dokumentieren können. Wie wir Knowledge Management strukturieren. Das ganze Ding.

Der Berater war solide. Die Analyse war gut. Und dann kam die Empfehlung: »Sie sollten ein Notion-System aufbauen. Mit Datenbank-Integration, Tags, ein Frontend, das Sie selbst pflegen können.«

Okay, habe ich gedacht. Das weiß ich auch. Ich brauchte keinen Consultant, um mir zu sagen, dass ich ein Notion-System aufbauen sollte.

Ich habe mich also hingesetzt. Ich habe Notion genommen. Ich habe selbst angefangen zu bauen. Nicht weil ich ein Entwickler bin – ich bin keiner. Ich bin Strategie-Typ. Aber ich bin mit Tools aufgewachsen. Ich kenne Automation. Und ich kam auf die Idee: »Lass mich Claude fragen, wie man ein Notion-Integration schreibt.«