Wie kommt die Pizza zum Gast? CI/CD und der Weg live, erklärt (Teil 3)

1. Juli 2026

Auf einen Blick

Eine fertige Pizza geht nicht direkt an den Gast, sie nimmt einen Weg: Küche, dann Ausgabe, dann Gast. Bei Software heißt das Entwicklung (dev), Test (stage) und Produktion (live).
An der Ausgabe wird geprüft: Ist die Pizza gut? Genau diese automatische Prüfung ist der Kern von CI/CD.
CI heißt: Jede Änderung wird sofort getestet, solange ein Fehler noch klein ist. CD heißt: Besteht sie, geht sie automatisch und sicher raus.
Der Nutzen für dich: Nichts geht ungetestet auf deine Seite. Kein „nach dem Update war alles kaputt“.

In diesem Teil erklärt: CI/CD · Deployment · Staging

In Teil 2 haben wir gesehen, wie neue Zutaten sicher auf die Pizza kommen. Jetzt die letzte Frage: Wie kommt die fertige Pizza eigentlich sicher zum Gast? Denn zwischen „in der Küche fertig“ und „der Gast isst“ liegt ein Weg, und genau der macht den Unterschied zwischen Profi und Chaos.

Der Weg der Pizza: Küche, Ausgabe, Gast

Eine Pizza geht nicht direkt vom Herd auf den Tisch. Sie nimmt drei Stationen:

Die Küche. Hier wird gekocht und probiert. Alles darf schiefgehen, kein Gast merkt davon etwas. Bei Software: die Entwicklung (oft „dev“ genannt).
Die Ausgabe. Die Pizza steht fertig unter der Wärmelampe, und es gibt einen letzten prüfenden Blick, bevor sie rausgeht. Bei Software: Staging (kurz „stage“), eine originalgetreue Kopie des echten Systems zum letzten Test.
Der Gast. Die Pizza kommt auf den Tisch, jetzt zählt es. Bei Software: Produktion (live), das, was deine Besucher sehen.

Küche, Ausgabe, Gast. Dev, Stage, Produktion. Das ist der Weg von der Idee bis live.

Die Frage an der Ausgabe: ist die Pizza gut?

Bei einer guten Pizzeria läuft dieser Weg nicht auf Zuruf. An der Ausgabe wird jede Pizza geprüft, bevor sie zum Gast geht: richtig belegt, durchgebacken, nichts vergessen? Nur wenn sie besteht, geht sie raus.

Genau diese eingebaute, automatische Prüfung ist der Kern von CI/CD:

CI (Continuous Integration), fortlaufendes Zusammenführen. Jede kleine Änderung wird sofort mit dem Rest zusammengefügt und automatisch getestet. So fällt ein Fehler auf, solange er noch klein und billig zu beheben ist, nicht erst beim Gast.
CD (Continuous Deployment), fortlaufendes Ausliefern. Besteht eine Änderung alle Tests, wird sie automatisch und sicher live gestellt. Kein manuelles Herumkopieren, bei dem nachts jemand das Falsche hochlädt.

Das Ausliefern selbst, also die fertige Pizza auf den Tisch bringen, heißt Deployment (englisch für Ausbringen). „Deployen“ ist einfach: live stellen.

Der Nutzen, in einem Satz

Für dich als Auftraggeber lässt sich der ganze Aufwand in einem Satz zusammenfassen: Nichts geht ungetestet auf deine Seite. Kein „nach dem Update ist plötzlich alles kaputt“, kein Bangen bei jeder Änderung. Das ist kein Luxus, sondern der Unterschied zwischen einem Profi-Setup und Gebastel.

Was das für dein Projekt heißt

Ob dein Projekt so ausgeliefert wird oder ob jemand Änderungen direkt und ungetestet ins Live-System schiebt, merkst du erst, wenn es kracht. Mit einem sauberen Weg über Küche, Ausgabe und Gast passiert genau das nicht: Jede Änderung wird geprüft, bevor sie deine Besucher erreicht. Und geht doch mal was daneben, kommt man dank Versionierung (siehe Teil 1) einfach auf den letzten funktionierenden Stand zurück.

Genau so bauen wir bei isarcode: versioniert, über eine saubere Pipeline, mit automatischer Prüfung. Nicht weil es schick klingt, sondern weil es dein Projekt vor den Pannen schützt, die sonst richtig teuer werden.

Häufige Fragen

Was ist CI/CD? Ein automatischer Ablauf, der jede Änderung an einer Software erst testet und dann, wenn sie besteht, sicher live stellt. CI steht fürs fortlaufende Testen, CD fürs fortlaufende Ausliefern.

Was ist der Unterschied zwischen Dev, Stage und Production? Dev ist die Entwicklung (die Küche), Stage der letzte Test auf einer Kopie des echten Systems (die Ausgabe), Production das Live-System, das die Nutzer sehen (der Gast).

Was bedeutet deployen? Software live stellen, also den fertigen, getesteten Stand für die Nutzer verfügbar machen. In der Pizza-Analogie: die geprüfte Pizza zum Gast bringen.

Ist CI/CD Overkill für kleine Projekte? Nein. Gerade kleine Projekte profitieren, weil ein Ausfall dort oft niemand auffängt. Der Ablauf lässt sich schlank halten, weglassen sollte man ihn nicht.

Und jetzt?

Du willst wissen, wie sauber dein aktuelles Projekt ausgeliefert wird, oder von Anfang an ein Setup ohne böse Überraschungen? Lass uns reden. Wir schauen es uns an und sagen dir ehrlich, wo es steht.

Development

Branch, Merge, Fork: neue Ideen ohne Chaos, mit Pizza erklärt (Teil 2)

1. Juli 2026

Auf einen Blick

Die Margherita ist der offizielle Stand, das, was jeder bekommt. In der Git-Welt heißt der main (oder master, nur ein anderer Name).
Willst du etwas Neues ausprobieren, baust du es daneben auf (ein Branch), ohne die Margherita anzufassen.
Ist die neue Zutat gut, wird sie Teil der Pizza. Das nennt man Merge.
Ein Fork ist mehr: Du machst aus der Pizza eine ganz eigene, unabhängige Linie mit eigenem Stand.

In diesem Teil erklärt: Branch · Feature-Branch · Merge · Fork · Main / Master

In Teil 1 haben wir geklärt, was Versionierung, Git und ein Repo sind. Jetzt geht es um die Frage, die im Alltag am häufigsten aufkommt: Wie kommen neue Ideen in ein Projekt, ohne dass das, was gerade funktioniert, kaputtgeht? Und wieder hilft die Pizza.

Die Margherita ist der offizielle Stand: main

Stell dir deine Pizza als das fertige Produkt vor. Die Margherita ist die Standard-Pizza, die auf der Karte steht und die jeder Gast bekommt. In der Git-Welt ist das der main (früher meist master genannt, dazu gleich mehr): der offizielle, ausgelieferte Stand. Was in main steht, ist das, was zählt. Deshalb baut man daran nicht mal eben leichtfertig herum.

Etwas Neues ausprobieren, ohne die Margherita zu ruinieren: der Branch

Jetzt kommt ein Wunsch rein: „Ich hätte gern eine Salami-Variante.“ So ein Wunsch heißt im Fachjargon Feature Request, auf Deutsch schlicht die Anforderung, etwas Neues zu bauen.

Du wärst verrückt, dafür die Margherita der wartenden Gäste umzubauen. Stattdessen fängst du daneben an: Du nimmst die Margherita als Ausgangspunkt und baust in Ruhe deine Salami-Version auf. Die Original-Pizza bleibt völlig unberührt.

Genau das ist ein Branch (englisch für Zweig, gesprochen „Bräntsch“). Auf Deutsch: eine Abzweigung, an der man gefahrlos werkeln kann. Weil es hier um genau eine neue Sache geht (die Salami), nennt man das eine Feature-Branch, den Zweig für ein bestimmtes neues Feature.

Die Salami kommt auf die Pizza: der Merge

Deine Salami-Variante ist fertig und gut. Jetzt soll sie offiziell werden, also Teil der echten Pizza. Dieses Zusammenführen heißt Merge (englisch für verschmelzen, gesprochen „Mördsch“). Aus Margherita plus erprobter Salami wird jetzt offiziell die Pizza Salami. Die neue Zutat ist eingearbeitet, sauber und bewusst.

Meistens klappt das reibungslos. Manchmal haben zwei Köche gleichzeitig an derselben Stelle geschraubt, der eine will Basilikum, der andere Oregano. Dann gibt es einen Merge-Konflikt: Das System sagt „hier widersprechen sich zwei Änderungen, das kann ich nicht allein entscheiden“, und ein Mensch legt fest, was draufkommt. Kein Drama, nur eine bewusste Entscheidung an der richtigen Stelle.

Eine ganz eigene Pizza-Linie: der Fork

Ein Branch ist eine Zutat mehr auf derselben Pizza. Ein Fork ist etwas anderes: Du nimmst die ganze Pizza und machst daraus deine eigene, unabhängige Linie.

Beispiele: Du nimmst die Margherita, wirfst die Tomatensauce raus und machst eine weiße Pizza. Oder du nimmst nur den Teig und machst daraus Pizzabrot. Ab diesem Moment lebt deine Version ihr eigenes Leben, mit ihrem eigenen offiziellen Stand, ihrem eigenen main. Sie hat mit dem Original nichts mehr zu tun.

Das ist ein Fork (englisch für Gabelung): eine eigenständige Kopie des ganzen Projekts, die einen eigenen Weg geht. In der Open-Source-Welt entstehen so aus einem Projekt viele.

Main oder Master? Nur ein Namenswechsel

Kurz zur häufigsten Verwirrung: Mal heißt der offizielle Stand main, mal master. Das ist dieselbe Sache, nur ein neuerer Name. Früher war „master“ üblich, heute nennen die meisten Projekte und Plattformen wie GitLab und GitHub ihn „main“. Inhaltlich ändert sich nichts, es ist und bleibt die Pizza auf der Karte.

Was das für dein Projekt heißt

Der Grund, warum das existiert, ist einfach: So kann ein Team an vielen neuen Dingen gleichzeitig arbeiten, ohne sich gegenseitig das Funktionierende kaputtzumachen. Jede neue Idee wächst sicher in ihrem eigenen Zweig heran und kommt erst dann in die offizielle Version, wenn sie fertig und geprüft ist.

Wie diese Prüfung automatisch abläuft und wie die fertige Pizza dann sicher zum Gast kommt, schauen wir uns in Teil 3 an.

Häufige Fragen

Was ist ein Branch in Git? Eine Abzweigung, an der man etwas Neues bauen kann, ohne den offiziellen Stand (main) anzufassen. Ist das Neue fertig, wird es zusammengeführt.

Was ist ein Merge? Das Zusammenführen einer fertigen Änderung mit dem offiziellen Stand. Aus der Margherita plus erprobter Salami wird die offizielle Pizza Salami.

Was ist der Unterschied zwischen Branch und Fork? Ein Branch ist eine Variante innerhalb desselben Projekts. Ein Fork ist eine komplett eigene, unabhängige Kopie mit eigenem offiziellen Stand.

Was bedeutet main bzw. master? Beides bezeichnet den offiziellen, ausgelieferten Stand eines Projekts. „main“ ist die modernere Bezeichnung für dasselbe.

Und jetzt?

Du willst, dass neue Features in deinem Projekt sauber und ohne Risiko fürs Laufende entstehen? Genau so arbeiten wir. Lass uns reden, wir zeigen dir, wie das in der Praxis aussieht.

Development

Was ist Versionierung? Git, GitLab und Repo mit Pizza erklärt (Teil 1)

1. Juli 2026

Auf einen Blick

Versionierung heißt: Bei jeder Änderung wird der Stand festgehalten, sodass du jederzeit nachschauen und zu einem früheren Stand zurück kannst.
Git ist das Werkzeug, das diese Stände verwaltet. Es ist der Standard in der Software-Entwicklung.
GitLab und GitHub sind nur Anbieter, bei denen so ein Projekt online liegt. Wie E-Mail und Gmail: das eine ist das Prinzip, das andere ein Dienst dafür.
Ein Repository („Repo“) ist der Ort, an dem dein Projekt samt seiner kompletten Geschichte lebt.

In diesem Teil erklärt: Versionierung · Git · GitLab · GitHub · Repository

Wenn du mit Software-Leuten zu tun hast, fallen dauernd dieselben Wörter: Git, Repo, GitLab, versioniert. Und selbst wenn man es selbst benutzt, ist es gar nicht so leicht, das jemandem zu erklären, der nicht täglich damit arbeitet.

Also machen wir es an etwas fest, das jeder kennt: einer Pizza. Stell dir dein Projekt wie eine Pizza vor, die nach und nach belegt wird. In Teil 1 klären wir die Grundbegriffe. In den nächsten Teilen kommen dann Branch, Merge und der Weg live dazu.

Warum überhaupt Versionierung?

Stell dir vor, du belegst deine Pizza Schritt für Schritt: erst Tomatensauce, dann Käse, dann Basilikum. Und bei jedem Schritt machst du ein Foto. Wenn dir am Ende der Basilikum doch nicht passt, ist das kein Problem, du schaust auf das Foto von vorher und weißt genau, wie die Pizza ohne Basilikum aussah. Du kannst jederzeit zurück.

Genau das ist Versionierung: Bei jeder Änderung wird der aktuelle Stand festgehalten. Nichts geht verloren, jeder Schritt ist nachvollziehbar, und du kannst zu jedem früheren Stand zurückspringen. Bei Software ist das Gold wert: Geht nach einer Änderung etwas kaputt, holt man einfach den letzten funktionierenden Stand zurück, statt in Panik zu suchen.

Git: das Werkzeug dafür

Diese Fotos macht bei Software nicht ein Mensch, sondern ein Werkzeug. Das gängigste heißt Git. Git hält jeden Zwischenstand deines Projekts fest, merkt sich, wer wann was geändert hat und warum, und lässt dich jederzeit zwischen den Ständen hin und her springen.

Git ist der De-facto-Standard, also das, was praktisch alle in der Software-Welt benutzen. Du musst es nicht selbst bedienen können. Aber es hilft zu wissen: Wenn dein Dienstleister „mit Git arbeitet“, heißt das, dein Projekt ist sauber versioniert und nichts geht unkontrolliert verloren.

Git, GitLab, GitHub: was ist der Unterschied?

Hier verwechseln viele etwas, und die Auflösung ist simpel:

Git ist das Prinzip, das Werkzeug.
GitLab und GitHub sind Anbieter, bei denen dein Projekt online liegt und wo das Team zusammenarbeitet.

Auf Deutsch wie bei der Post: E-Mail ist das Prinzip, Gmail oder Outlook sind Anbieter, die E-Mail für dich bereitstellen. Genauso ist Git das Prinzip, GitLab und GitHub sind zwei bekannte Anbieter dafür. Wir bei isarcode arbeiten mit GitLab, funktional nehmen die beiden sich wenig.

Das Repo: wo dein Projekt lebt

Bleibt ein Wort: Repository, kurz Repo. Das ist schlicht der Ort, an dem ein Projekt mit seiner kompletten Geschichte liegt. In unserem Bild: der Ordner, in dem deine Pizza und alle Fotos von jedem Belegungs-Schritt aufbewahrt werden.

Ein Projekt, ein Repo. Darin steckt alles: der aktuelle Stand und die ganze Historie. Liegt das Repo bei GitLab, kann das ganze Team darauf zugreifen, gemeinsam daran arbeiten und trotzdem den Überblick behalten, wer was gemacht hat.

Was das für dein Projekt heißt

Du musst nichts davon selbst können. Aber wenn du die vier Wörter einordnen kannst, verstehst du, was hinter „wir arbeiten sauber und versioniert“ steckt, und das ist kein Nice-to-have:

Nichts geht unkontrolliert verloren.
Jede Änderung ist nachvollziehbar.
Geht was schief, gibt es immer einen Weg zurück.

Das ist der Unterschied zwischen einem Profi-Setup und „wir haben da mal was hochgeladen und hoffen, dass es hält“. Wie aus diesen Grundlagen ein sicherer Weg bis zur fertigen, live geschalteten Software wird, schauen wir uns in den nächsten Teilen an.

Häufige Fragen

Was ist der Unterschied zwischen Git und GitHub? Git ist das Werkzeug zum Versionieren, GitHub ist ein Anbieter, bei dem Git-Projekte online liegen. Wie E-Mail (das Prinzip) und Gmail (ein Anbieter). GitLab ist ein weiterer solcher Anbieter.

Was ist ein Repository? Der Ort, an dem ein Projekt samt seiner kompletten Änderungs-Geschichte gespeichert ist. Meist kurz „Repo“ genannt.

Brauche ich als Auftraggeber Git-Kenntnisse? Nein. Es reicht zu wissen, dass es Versionierung gibt und dass ein guter Dienstleister sie nutzt. Genau das schützt dein Projekt vor Datenverlust und Chaos.

Ist Versionierung nur was für große Projekte? Nein. Gerade kleine Projekte profitieren, weil ein verlorener Stand dort oft niemand auffängt. Der Aufwand ist minimal, der Schutz groß.

Und jetzt?

Du willst wissen, ob dein aktuelles Projekt eigentlich sauber versioniert ist, oder von Anfang an auf ein Setup ohne böse Überraschungen? Lass uns reden. Wir schauen es uns an und sagen dir ehrlich, wo es steht.

Automation

Produktion, die sich selbst plant: wie aus Bestellungen ein Röstplan wird

1. Juli 2026

Auf einen Blick

In vielen produzierenden Betrieben liegen die Planungsdaten in getrennten Systemen: Shop, Warenwirtschaft, B2B-Vertrieb. Wer plant, muss alles von Hand zusammenführen.
Bei einer Kaffeerösterei hat isarcode diese Systeme über ihre Schnittstellen verbunden, sodass sich der Röstplan (welche Bohnen, welche Mischung, welche Menge) aus den echten Bestellungen selbst ableitet.
Der Mensch bleibt im Spiel: Das System plant vor, die Produktion entscheidet (Human-in-the-Loop).
Das Muster ist nicht kaffeespezifisch und lässt sich auf jede Branche übertragen, sobald die Systeme über APIs erreichbar sind.

Eine Kaffeerösterei klingt erst mal nicht nach High-Tech. Bohnen rein, rösten, raus. Aber wer schon mal in einer Produktion stand, weiß: Die eigentliche Arbeit ist die Planung. Welche Bohne, welche Mischung, welche Menge, bis wann? Und die hängt an Zahlen, die überall liegen, nur nicht an einem Ort.

Genau das war der Ausgangspunkt für eines unserer Lieblingsprojekte.

Die Ausgangslage: drei Welten, die nicht miteinander reden

Wie in vielen produzierenden Betrieben lagen die entscheidenden Daten in getrennten Systemen:

Der Online-Shop wusste, was Endkunden bestellen.
Die Warenwirtschaft wusste, was auf Lager und in Arbeit ist.
Der B2B-Vertrieb wusste, was Großkunden abnehmen.

Drei Quellen, drei Wahrheiten. Wer den Röstplan machte, musste alles im Kopf oder in Tabellen zusammenführen. Das funktioniert, solange das Volumen klein ist und die richtige Person da ist. Es funktioniert nicht gut, wenn beides nicht mehr stimmt.

Die Idee: die Bestellungen sollen den Plan machen

Statt dass ein Mensch die Daten zusammensucht, sollten die Systeme das selbst tun. Die Logik dahinter:

Bestellungen aus Shop und B2B laufen zusammen.
Daraus ergibt sich, welche fertigen Produkte gebraucht werden.
Die wiederum bestehen aus bestimmten Bohnen in bestimmten Mischungsverhältnissen.
Abgeglichen mit dem Lagerbestand entsteht: ein konkreter Röstplan. Welche Bohnen, welche Menge, welche Mischung, wann.

Aus „jemand setzt sich hin und rechnet“ wird „der Plan steht, weil die Daten da sind“.

Wie wir es gebaut haben

Wir haben Shop, Warenwirtschaft und B2B-Vertrieb über ihre Schnittstellen (APIs) verbunden und die Planungslogik als automatisierten Workflow abgebildet, mit n8n als Schaltzentrale. Sauber versioniert über eine Dev-Stage-Production-Pipeline, DSGVO-konform, in der EU gehostet.

Wichtig dabei: Der Mensch bleibt im Spiel, wo es zählt. Die Planung schlägt vor, die Produktion entscheidet. Automatisierung heißt hier nicht „Maschine macht blind“, sondern „Maschine macht die Fleißarbeit, Mensch trifft die Entscheidung mit besserer Grundlage“.

Was das bringt

Das Prinzip löst genau die Probleme, die getrennte Systeme verursachen:

Kein manuelles Zusammensuchen mehr. Die Planungsgrundlage steht automatisch.
Weniger Abhängigkeit von Einzelpersonen. Das Wissen steckt im System, nicht nur in einem Kopf.
Schnellere Reaktion. Ändern sich die Bestellungen, ändert sich der Plan, ohne Verzögerung.
Transparenz. Alle schauen auf dieselbe Datengrundlage.

Konkrete Zahlen zu diesem Case (eingesparte Zeit, Mengen, Durchsatz) tragen wir nach Freigabe nach. Wir erfinden hier nichts.

Und das geht nur bei Kaffee? Nein.

Das Spannende: Das Muster ist nicht kaffeespezifisch. Überall, wo Produktion an Bestellungen, Lager und Vertrieb hängt, lässt es sich übertragen. Lebensmittel, Möbel, Bauteile, Manufakturen jeder Art. Die einzige echte Voraussetzung: Die beteiligten Systeme müssen über Schnittstellen erreichbar sein. Und das sind sie meistens.

Wie aus einzelnen Insellösungen eine zusammenhängende Infrastruktur wird, liest du in Schluss mit Insellösungen.

Regional nah, international erprobt

isarcode ist eine Münchner Agentur mit Office im Chiemgau. Heißt für dich: ein Partner, der lokal ansprechbar ist und trotzdem mit internationalen Projekten und großen Agenturen mitspielt. Regionale Nähe, internationale Liga. Egal ob du am Chiemsee, in Rosenheim oder in München sitzt.

Häufige Fragen

Müssen wir unsere Maschinen anfassen? Nein. Es geht um die Daten- und Planungsebene, nicht um die Maschinensteuerung. Wir setzen auf den Systemen auf, die du eh schon hast.

Was, wenn unsere Software exotisch ist? Solange sie eine Schnittstelle hat, lässt sie sich anbinden. Ob das der Fall ist, klären wir früh und ehrlich.

Ist das ein Riesenprojekt? Wir starten mit dem Teil, der am meisten weh tut, und bauen von da aus. Kein Alles-oder-nichts.

Bleibt die Kontrolle bei uns? Ja. Das System plant vor, ihr entscheidet. Human-in-the-Loop an den wichtigen Stellen.

Und jetzt?

Bei dir hängt die Produktionsplanung auch an Tabellen und an einer Person, die alles im Kopf hat? Lass uns reden. Wir schauen, ob sich dein Plan aus deinen Daten ableiten lässt.

Automation

Kleine Teams, große Wirkung: Prozesse automatisieren ab 10 Mitarbeitern

1. Juli 2026

Auf einen Blick

Prozessautomatisierung lohnt sich nicht erst im Konzern: Je kleiner das Team, desto stärker zählt jede automatisierte Stunde.
Faustregel: ab etwa 10 Mitarbeitern, sobald wiederkehrende Handarbeit anfällt (Daten umtippen, Montags-Reportings, Standardanfragen).
Es geht nicht um Stellenabbau, sondern darum, dass Mitarbeiter aufhören, Maschinenarbeit zu machen.
Einstieg über einen Discovery-Workshop, Umsetzung mit n8n in kleinen Schritten. Kleine Projekte starten im niedrigen vierstelligen Bereich.

Es gibt diesen Mythos, dass Automatisierung was für Konzerne ist. Große Budgets, große IT-Abteilung, große Projekte. Stimmt nicht. Die Wahrheit ist fast das Gegenteil: Je kleiner dein Team, desto mehr bringt dir jede automatisierte Stunde.

Denn im Zehn-Personen-Betrieb hat keiner Zeit übrig. Wenn drei davon halbe Tage mit Copy-Paste zwischen Tools verbringen, fehlen die woanders. Genau hier setzt Prozessautomatisierung an, und sie ist näher und günstiger, als du denkst.

Woran du erkennst, dass sich Automatisieren lohnt

Du brauchst keine Prozessberatung mit 80-Seiten-Gutachten, um die Kandidaten zu finden. Frag dich einfach:

Tippt jemand regelmäßig dieselben Daten von einem System ins nächste?
Gibt es eine Aufgabe, die „halt jeden Montag gemacht werden muss“?
Wartet etwas regelmäßig auf jemanden, der „nur kurz“ was bestätigen oder weiterleiten muss?
Liegen eure Zahlen in mehreren Tools, die niemand zusammenbringt?

Jedes Ja ist ein Kandidat. Das sind die Abläufe, die klar geregelt und wiederkehrend sind. Und genau die lassen sich automatisieren.

Wo es sich am schnellsten auszahlt

Ein paar Klassiker aus dem Mittelstand, die fast immer Zeit zurückgeben:

Bestellungen und Lager. Eingang im Shop löst automatisch Lagerbuchung, Bestätigung und Rechnung aus.
Reportings. Statt Montag-Excel ein Dashboard, das sich selbst aus allen Quellen füllt.
Standardanfragen. Wiederkehrende Kundenfragen vorqualifiziert beantworten, die kniffligen landen beim Menschen.
Onboarding. Neuer Mitarbeiter, neuer Kunde, neuer Lieferant: Checklisten und Zugänge laufen automatisch an.

Keine Raketenwissenschaft. Aber in Summe schnell ein, zwei freigeschaufelte Arbeitstage pro Woche.

Was es nicht ist: Leute wegrationalisieren

Ein Missverständnis vorweg, weil es oft aufkommt: Es geht nicht darum, Stellen zu streichen. Es geht darum, dass deine Leute aufhören, Maschinenarbeit zu machen. Die Routine übernimmt die Automatisierung, der Kopf bleibt für das frei, was wirklich Menschen braucht: Kunden, Qualität, Ideen. Gerade kleine Teams werden so handlungsfähiger, nicht kleiner.

Wie wir starten

Wir kommen nicht mit einem fertigen Tool, das du dann irgendwie einbauen musst. Wir starten mit einem Discovery-Workshop: ein paar Stunden, in denen wir uns deine Abläufe ansehen und gemeinsam die lohnendsten Kandidaten finden. Daraus wird ein konkreter Plan mit klaren Paketen.

Die Umsetzung läuft dann über n8n (ein etabliertes Automatisierungs-Tool), sauber versioniert, DSGVO-konform, in der EU gehostet. Und nicht alles auf einmal, sondern Ablauf für Ablauf, mit sichtbarem Effekt nach jedem Schritt.

Der Einstieg ist bewusst niedrigschwellig: Das fängt bei kleinen Projekten an, nicht bei einem Sechsmonats-Programm.

Regional nah, international erprobt

Häufige Fragen

Ab welcher Größe lohnt sich das? Faustregel: ab etwa zehn Mitarbeitern, wenn wiederkehrende Handarbeit anfällt. Es geht nicht um die Zahl, sondern um die Routine.

Brauchen wir IT-Know-how im Haus? Nein. Wenn nötig, betreiben wir den laufenden Betrieb mit.

Was kostet der Einstieg? Kleine, klar abgegrenzte Projekte starten im niedrigen vierstelligen Bereich. Was sich für dich lohnt, klären wir vorher, nicht hinterher.

Wie lange dauert das? Erste automatisierte Abläufe oft in Wochen, nicht Monaten. Wir liefern in Schritten, nicht im großen Knall.

Und jetzt?

Dir fällt beim Lesen schon ein, welcher Montags-Job bei euch automatisch laufen könnte? Dann lass uns kurz reden. Wir sagen dir ehrlich, ob sich der Aufwand lohnt.

Automation

Schluss mit Insellösungen: warum deine Systeme endlich miteinander reden sollten

1. Juli 2026

Auf einen Blick

Getrennte Systeme (Shop, Warenwirtschaft, CRM, Reporting-Excel) kosten täglich Geld: doppelte Pflege, manuelle Übergaben, Blindflug bei den Zahlen.
API-first-Integration verbindet die vorhandenen Systeme über ihre Schnittstellen, ohne dass du alles neu kaufen musst.
Ergebnis: Reportings ziehen sich live aus allen Quellen zusammen, Routine läuft automatisiert, Mitarbeiter werden für echte Arbeit frei statt weggespart.
isarcode setzt das mit n8n um, schrittweise, DSGVO-konform, versioniert und ausfallsicher.

Kennst du das? Die Bestellungen stehen im Shop. Die Lagerbestände in der Warenwirtschaft. Die Kundendaten im CRM. Die Zahlen fürs Reporting in einem Excel, das jeden Montag jemand von Hand zusammenklöppelt. Vier Systeme, vier Logins, und dazwischen: Mitarbeiter, die Daten hin- und herschaufeln, damit das Ganze überhaupt zusammenpasst.

Das ist kein Einzelfall. Das ist der Normalzustand in den meisten mittelständischen Firmen. Und es ist teurer, als du denkst.

Was Silos wirklich kosten

Getrennte Systeme kosten dich nicht nur Nerven. Sie kosten dich Geld, jeden Tag:

Doppelte Pflege. Eine Adressänderung an drei Stellen eintippen. Einmal vergessen, schon stimmt nichts mehr.
Manuelle Übergaben. Jemand exportiert, jemand importiert, jemand prüft. Reine Verwaltungsarbeit, die niemandem Spaß macht und keinen Umsatz bringt.
Blindflug. Weil die Zahlen erst zusammengetragen werden müssen, siehst du das Gesamtbild immer zu spät. Entscheidungen triffst du auf Datenstand „letzte Woche“.
Fehler, die keiner merkt. Bis sie wehtun. Falscher Bestand, falsche Rechnung, doppelte Bestellung.

Das Fiese: Diese Kosten stehen nirgends auf einer Rechnung. Sie verstecken sich in Arbeitszeit. Und genau deshalb wachsen sie unbemerkt mit jeder neuen Software, die du dazukaufst.

Die Alternative: Systeme, die selbst miteinander reden

Fast jedes moderne System hat eine Schnittstelle, eine API. Heißt: Es kann mit anderen Systemen Daten austauschen, ohne dass ein Mensch dazwischensitzt. Diese Schnittstellen sauber zu verbinden, nennt man API-first-Integration. Und das ist der Punkt, an dem aus deinem Software-Zoo eine zusammenhängende Infrastruktur wird.

Konkret heißt das:

Eine Bestellung im Shop aktualisiert automatisch den Lagerbestand, legt den Kunden im CRM an und taucht im Reporting auf. Ohne Klick.
Reportings ziehen sich live aus allen Quellen zusammen, statt montags von Hand. Ein Dashboard, eine Wahrheit.
Wiederkehrende Abläufe laufen automatisiert, bei Bedarf mit KI-Unterstützung an den Stellen, wo Entscheidungen nötig sind.

Der schöne Nebeneffekt: Du sparst dir die Leute nicht weg, du setzt sie frei. Die Stunden, die heute in stumpfer Verwaltung versickern, stecken morgen in echter Arbeit.

Wie wir das angehen

Wir bauen auf n8n, einem etablierten Open-Source-Tool für genau solche Workflows, und verbinden deine Systeme über ihre APIs. Kein Rundumschlag, bei dem du erst mal alles neu kaufen musst. Wir docken an das an, was du schon hast.

Was uns dabei wichtig ist:

DSGVO-sicher. Hosting in der EU, meist in Deutschland. Deine Daten bleiben, wo sie hingehören.
Versioniert und ausfallsicher. Alles läuft über eine saubere Pipeline (Dev, Stage, Production). Getestet, bevor es live geht. Kein Kartenhaus.
Schritt für Schritt. Wir reißen nicht alles auf einmal ein. Wir fangen mit dem Ablauf an, der am meisten weh tut, und bauen von da aus weiter.

Unser eigenes Monitoring Hawkeye läuft genau nach diesem Prinzip. Wir bauen nichts, was wir nicht selbst nutzen.

Wie das in echt aussieht

Für eine Kaffeerösterei haben wir Shop, Warenwirtschaft und B2B-Vertrieb so verbunden, dass die Produktionsplanung sich aus den echten Bestellungen selbst ableitet: welche Bohnen, welches Mischungsverhältnis, wann in die Röste. Vorher drei getrennte Welten, jetzt ein durchgehender Fluss. Die ganze Geschichte in Produktion, die sich selbst plant.

Regional nah, international erprobt

Häufige Fragen

Müssen wir dafür unsere bestehenden Systeme rauswerfen? Nein. API-first heißt: Wir verbinden, was du hast. Austauschen nur, wenn ein System partout nicht mitspielt.

Was, wenn ein System keine Schnittstelle hat? Gibt’s, wird aber seltener. Auch dafür gibt es Wege. Das klären wir im Discovery-Workshop ehrlich, bevor irgendwer was verspricht.

Lohnt sich das schon für kleine Firmen? Gerade da. Je kleiner das Team, desto teurer ist jede Stunde Handarbeit.

Wie fangen wir an? Mit einer Bestandsaufnahme deiner Systeme und Abläufe. Daraus wird ein Plan mit klaren Paketen, kein Big-Bang.

Und jetzt?

Du hast mehr Logins als Mitarbeiter und montags keine Lust mehr auf Zahlensalat? Lass uns reden. Wir schauen uns deine Systemlandschaft an und sagen dir, wo sich Verbinden am schnellsten auszahlt.

Was ist ein LLM? Large Language Models in Klartext, ohne Hype

1. Juli 2026

Auf einen Blick

Ein LLM (Large Language Model) ist ein Programm, das gelernt hat, Sprache vorherzusagen, also welches Wort am sinnvollsten als Nächstes kommt. ChatGPT ist das bekannteste Beispiel.
Stark bei Texten, Zusammenfassen, Übersetzen und Strukturieren. Schwach bei Fakten aus dem Stegreif (es kann überzeugend „halluzinieren“), Rechnen und Aktuellem.
Für Firmen zählt nicht das Modell selbst, sondern die richtige Einbindung: mit eigenen Daten, klaren Grenzen und einem Menschen an den kritischen Stellen.
KI und DSGVO sind kein Widerspruch, wenn man EU-Hosting und Datenregeln von Anfang an mitbaut.

LLM, GPT, generative KI: Die Begriffe fliegen dir seit zwei Jahren um die Ohren. Jeder redet drüber, gefühlt jeder verkauft was damit. Und du willst eigentlich nur wissen: Was ist das jetzt genau, und muss ich mich als Geschäftsführer wirklich damit beschäftigen?

Kurz: ja, aber entspannt. Hier ist die Erklärung ohne Doktortitel.

Die Ein-Satz-Version

Ein LLM (Large Language Model) ist ein Programm, das gelernt hat, Sprache vorherzusagen. Es hat enorm viel Text gesehen und daraus ein Gespür dafür entwickelt, welches Wort als Nächstes am sinnvollsten passt. Genau das macht es, immer und immer wieder, blitzschnell. ChatGPT ist das bekannteste Beispiel dafür.

Klingt simpel, ist aber mächtig: Aus „das nächste Wort vorhersagen“ wird Texte schreiben, zusammenfassen, übersetzen, Fragen beantworten, Code erzeugen.

Wie es funktioniert (ohne Mathe)

Stell dir jemanden vor, der unfassbar viel gelesen hat. Bücher, Webseiten, Foren, Handbücher. Irgendwann hat er ein Gefühl dafür, wie Sprache tickt: Auf „Sehr geehrte Damen und“ folgt fast sicher „Herren“. Auf eine Kundenbeschwerde folgt ein bestimmter Ton.

Ein LLM macht genau das, nur in einem Maßstab, den kein Mensch erreicht, und ohne zu verstehen wie ein Mensch. Es rechnet Wahrscheinlichkeiten. Deshalb kann es brillant klingen und trotzdem danebenliegen. Was uns direkt zum wichtigsten Teil bringt.

Was ein LLM kann, und wo es patzt

Stark bei:

Texte formulieren, umschreiben, zusammenfassen
Übersetzen und Ton anpassen
Aus unstrukturiertem Wust (E-Mails, Notizen) Struktur machen
Fragen auf Basis von Material beantworten, das du ihm gibst

Schwach bzw. gefährlich bei:

Fakten aus dem Stegreif. Ein LLM kann überzeugend Dinge erfinden („halluzinieren“). Ohne Faktenbasis ist es kein Lexikon.
Rechnen und harte Logik. Dafür gibt es bessere Werkzeuge, an die man es anbinden kann.
Aktuelles. Was nach dem Training passiert ist, weiß es nur, wenn man es ihm gibt.

Die Kunst liegt nicht im Modell selbst, sondern darin, es richtig einzubinden: mit deinen Daten, klaren Grenzen und einem Menschen an den richtigen Stellen.

Was das für deine Firma heißt

Du musst kein LLM trainieren, das machen ein paar große Anbieter. Für dich zählt die Frage: Wo nimmt mir das sinnvoll Arbeit ab? Realistische Einsätze im Mittelstand:

Kundenanfragen vorsortieren und Entwürfe für Antworten erzeugen
Angebote und Texte schneller draften
Lange Dokumente, Protokolle, Verträge zusammenfassen
Wissen aus euren eigenen Dokumenten durchsuchbar machen

Der eigentliche Hebel entsteht, wenn ein LLM nicht allein im Chatfenster sitzt, sondern an deine Systeme angebunden ist und Teil eines automatisierten Ablaufs wird. Wie das aussieht, liest du in Agentic AI für den Mittelstand.

Der Datenschutz-Teil, weil er wichtig ist

„KI“ und „DSGVO“ klingen für viele nach Widerspruch. Sind sie nicht, wenn man es richtig baut: EU-Hosting, klare Regeln, welche Daten überhaupt ins Modell gehen, und Architektur, die das technisch absichert. Genau so setzen wir KI ein: DSGVO-konform, in der EU, meist in Deutschland.

Regional nah, international erprobt

Häufige Fragen

Ist ein LLM dasselbe wie ChatGPT? ChatGPT ist eine Anwendung, die auf einem LLM läuft. Das LLM ist der Motor, ChatGPT das Auto drumherum.

Müssen wir ein eigenes Modell trainieren? Fast nie. Sinnvoller ist, ein vorhandenes Modell mit deinen Daten und Regeln einzusetzen.

Kann man dem Ding trauen? Mit Faktenbasis und sauberer Einbindung: für viele Aufgaben ja. Als alleinige Wahrheitsquelle: nein. Deshalb gehört ein Mensch an die kritischen Stellen.

Lohnt sich das für kleine Firmen? Ja, sobald du wiederkehrende Text- oder Sortier-Arbeit hast. Da fängt der Nutzen an.

Und jetzt?

Du fragst dich, wo KI bei euch konkret etwas bringen würde, ohne Hype und ohne Datenschutz-Bauchschmerzen? Lass uns reden. Wir sagen dir ehrlich, wo sich der Einsatz lohnt und wo (noch) nicht.