How Intelligent Manufacturing Planning Reduces Supply Chain Disruptions

Ein Wort an unsere Community

Hallo vom LMNAs-Team,

bevor wir mit irgendetwas anderem beginnen: Der Juni war der Monat, auf den wir hinter den Kulissen schon lange hingearbeitet haben, und wir können es kaum noch erwarten. Etwas Großes steht kurz davor, enthüllt zu werden, und die Juli-Ausgabe wird deshalb ein wenig anders aussehen als sonst. Lies einfach weiter – wir haben uns die Enthüllung für das Ende dieser Ausgabe aufgehoben, und das Warten lohnt sich.

Nun zu dem, was uns diesen Monat beschäftigt hat.

In diesem Monat kamen wir immer wieder auf eine Frage zurück, die sich jede Führungskraft im Delivery-Bereich mindestens einmal gestellt hat, meist direkt nach einer Sprint-Retrospektive:

Wenn das Team stark ist und der Plan solide war, warum verzögert sich die Bereitstellung dann trotzdem?

In der gesamten IT-Auslieferung liegt die Antwort nicht in der Leistung eines einzelnen Teams. Sie liegt im Raum zwischen Planung und Ausführung – dort, wo ein Plan aufhört, die Realität widerzuspiegeln, lange bevor es überhaupt jemand bemerkt.

Diese Ausgabe verfolgt diese Lücke von ihrem Ursprung bis zu dem Punkt, an dem sie geschlossen wird.

Bevor Du weiterliest

Stell dir Folgendes vor.

Zwei Teams hatten genau die gleiche Sprintlänge, genau die gleiche Anzahl an User Stories und eine in etwa gleiche Teamgröße.

Das eine Team lieferte pünktlich ab und hatte sogar noch freie Kapazitäten. Das andere verfehlte das Sprintziel, schob es auf „unvorhergesehene Aufgaben“ und startete bereits im Rückstand in den nächsten Sprint.

Gleiche Länge. Gleiche Stories. Gleiche Größe. Völlig unterschiedliche Ergebnisse.

Behalte dieses Bild im Hinterkopf. Bis zum Ende dieser Ausgabe wird der Grund dafür klar sein.

IT-Planung verdient die gleiche Disziplin wie die Produktionsplanung

Die Fertigungsindustrie hat das schon vor Jahrzehnten verstanden.

Bevor eine Fabrik auch nur eine einzige Einheit produziert, kennen die Planer bereits den Bedarf, die Kapazität, die Materialien und die Engpässe.

IT-Teams prognostizieren auf die gleiche Weise – nur eben mit Arbeit statt mit physischen Einheiten.

Anforderungen → Kapazität → Ressourcen → Technische Bereitschaft → Auslieferung → Release → Kontinuierliche Verbesserung.

Wird eine Abhängigkeit übersehen, verzögert sich die Auslieferung. Wird eine Schätzung falsch eingeschätzt, überlastet das Team. Untersuchungen des PMI bestätigen dies – sich verschiebende Prioritäten sind der Hauptgrund für das Scheitern von Projekten.

Die erfolgreichsten Organisationen sind nicht die mit den besten Entwicklern. Es sind die mit der besten Planungsdisziplin.

Wo also bricht diese Disziplin eigentlich ein?

Planst du noch oder reagierst du nur auf die Arbeitslast?

In jeder Delivery-Organisation gibt es fünf Phasen – Prognose, Bedarf, Ressourcenplanung, Ausführung, Auslieferung. Jede einzelne verliert still und leise den Bezug zu den anderen:

Prognosen basieren auf veralteten Annahmen
Zusagen werden gemacht, ohne die Kapazitäten zu prüfen
Ressourcen werden auf dem Papier bestätigt, verspäten sich jedoch in der Praxis
Die Ausführung übernimmt fehlerhafte Annahmen und muss ungeplante Arbeit auffangen
Das Monitoring bemerkt das Scheitern erst, wenn es zu spät ist, um gegenzusteuern

Am ersten Tag sieht ein Plan noch realistisch aus. An Tag neunzig gleicht er oft einem Märchen.

Nicht, weil die Teams versagt haben – sondern weil sie den Sprint damit verbracht haben, einen Plan zu schützen, anstatt ihn anzupassen.

Das ist die Diskrepanz aus der Vogelperspektive. Und so fühlt es sich beim Standup an.

Die Lücke im Sprint-Management, von der die meisten Teams nichts wissen

Keine Echtzeit-Übersicht über den Sprint-Status. Kein Dashboard für Velocity, Burn-down oder die verbleibende Zeit. Geplanter Urlaub wird vor den Zusagen nicht berücksichtigt.

Das ist kein Disziplinproblem. Es ist ein Tooling-Problem.

Tabellenkalkulationen, E-Mails, Insiderwissen – und niemand kann mit Sicherheit sagen, was tatsächlich zugesagt, in Arbeit oder gefährdet ist.

Wenn es funktioniert, sieht es einfach aus: Live-Dashboards, im Voraus berücksichtigter Urlaub, Arbeitslast verteilt nach tatsächlicher Kapazität, kontinuierlich überwachte Sprint-Gesundheit.

Nach drei Beiträgen ist das Problem auf jeder Ebene offensichtlich. Nun – was schafft tatsächlich Abhilfe?

Kapazitätsplanung formt die Stabilität der Auslieferung – Tag für Tag

Der Sprintplan am Montag sieht solide aus. Am Mittwoch tut er es nicht mehr.

Ein Bug am Dienstag. Meetings ohne Pause am Mittwoch. Ein Produktionsfehler am Donnerstag. Die Story verschiebt sich am Freitag.

Warum? Weil Kapazitäten nur einmal pro Sprint geplant werden – und nicht einmal pro Tag.

Tägliche Planung verändert die Dynamik:

Präzise sehen, wer an welchem Tag verfügbar ist
Code-Reviews anhand der realen Verfügbarkeit zuteilen
Urlaub einplanen, bevor er zur Überraschung wird
Den Plan für morgen anpassen, sobald heutige Engpässe sichtbar werden

Teams, die so planen, machen keine leeren Versprechungen mehr, sondern liefern konstant ab.

Das ist die Lösung auf Sprint-Ebene. Die nächsten beiden Beiträge übertragen dies auf das Testen und die Entwicklung.

Manuelles Testen hat den Release-Zyklus blockiert

Ein ganzes Jahr Rückstand bei den Frappe/ERPNext-Upgrades. Nicht aus Mangel an Willen – sondern wegen des schieren Aufwands für manuelle Tests bei Berichten, Transaktionen, Workflows, APIs und E-Mails.

LATP (LENS AI Test Pilot) hat das alles automatisiert.

Upgrade-Frequenz: vierteljährlich → wöchentlich (4x schneller)
Testdauer für 10 Standorte: 2–3 Wochen → 2 Tage (95% schneller)
Benötigte QA-Mitarbeiter: 8–10 Personen → 2 (75% Reduzierung)
Versionsrückstand: 1 Jahr → 3 Monate (9 Monate aufgeholt)

Ein Zweierteam testet jetzt das, wofür früher acht bis zehn Personen nötig waren.

Das Testen ist nicht länger der Flaschenhals. Die nächste Lücke lag in allem, was davor geschah.

Die Planung war solide. Das Testen war automatisiert. Die Entwicklung war eine Blackbox.

Releases wurden geplant. Tests wurden automatisiert. Dennoch schlugen Releases fehl.

Die Schwachstelle war die Entwicklung selbst – isolierte Workflows, verstreute Dokumentation, Auswirkungen von Änderungen wurden erst von der QA entdeckt, statt vorher abgefangen zu werden.

Chordium hat diese Lücke geschlossen – direkt in die IDE eingebettet, verfolgt es jede Änderung, warnt frühzeitig vor Auswirkungen und verwandelt die Historie automatisch in Dokumentation.

Qualitätsmängel: 5–10% → 1–2%
Release-Zyklen: 2–3 Wochen → wöchentlich
Ein standardisierter Workflow, keine Silos mehr

LENS IPS für die Planung. Chordium für die Entwicklung. LATP für das Testen. Drei Phasen, eine vernetzte Pipeline.

Vernetzte Auslieferung in Zahlen

4x schnellere Upgrade-Frequenz
95% weniger Zeitaufwand für Tests über verschiedene Standorte hinweg
75% weniger QA-Ressourcen benötigt
9 Monate Versionsrückstand in nur 3 Monaten aufgeholt
Qualitätsmängel von 5–10% auf 1–2% gesunken
Release-Zyklen von 2–3 Wochen auf wöchentlich verkürzt

Das sind keine minimalen Verbesserungen. Es ist der Unterschied dazwischen, einen fehlerhaften Plan zu verteidigen oder genau zu wissen, was man tatsächlich liefern kann.

Die Antwort!

Zwei Teams. Gleiche Sprintlänge, gleiche Stories, gleiche Größe. Das eine lieferte mit freien Kapazitäten ab. Das andere verfehlte den Sprint und gab „unvorhergesehener Arbeit“ die Schuld.

Der Grund war nie die Arbeit – oder die Menschen.

Ein Team plante die Kapazität einmal pro Sprint anhand einer Momentaufnahme. Das andere plante sie jeden Tag neu, direkt an der Realität.

Das tägliche Team sah den Bug am Dienstag und die Meetings am Mittwoch kommen und passte sich an, bevor daraus die verfehlte Story am Freitag wurde. Das wöchentliche Team bemerkte dies erst, als der Sprint bereits gelaufen war.

Derselbe Plan auf dem Papier. Ein völlig anderer Bezug zur Realität.

Was uns aufgefallen ist

Die Engineering Productivity Benchmarks 2026 von Plandek, erhoben aus den Auslieferungsdaten von mehr als 2.000 Software-Engineering-Teams, beziffern genau die Lücke, um die es in dieser Ausgabe ging.

Leistungsstarke Teams verbringen über 41% ihrer Entwicklungszeit mit der Umsetzung der Roadmap. Weniger leistungsstarke Teams verbringen damit weniger als 21% – der Rest wird von Bugs, Vorfällen und ungeplanter Arbeit aufgefressen. Die Kluft bei der Vorhersehbarkeit ist ebenso unübersehbar: Spitzen-Teams schaffen mehr als zwei Drittel von dem, was sie sich für einen Sprint vornehmen, während das untere Viertel weniger als die Hälfte schafft.

Die interessanteste Erkenntnis des Berichts betrifft jedoch die KI. Teams schreiben Code schneller als je zuvor. Aber bei Teams mit unbeständiger Planung oder langsamen Review-Zyklen führt diese Geschwindigkeit nicht zu einer schnelleren oder berechenbareren Auslieferung – sie deckt den Engpass lediglich auf, anstatt ihn zu beseitigen. Schnelleres Tippen repariert keinen fehlerhaften Plan.

Das ist genau dieselbe Geschichte, die wir den ganzen Monat erzählt haben, nur gestützt auf einen anderen Datensatz.

Zukünftige Updates

Juli: Der Beginn einer KI-nativen Enterprise-Plattform

Der Juli markiert einen entscheidenden Meilenstein für LMNAs.
Nach Monaten der Entwicklungsarbeit, unzähligen Architekturentscheidungen und einer klaren Vision für die Zukunft von Unternehmenssoftware,

stellen wir LensCloud vor.

Nicht als eine weitere Hosting-Plattform.
Nicht als einen weiteren Deployment-Service.
Sondern als das Fundament für die nächste Generation von Unternehmensanwendungen.

Wir sind der Meinung, dass die Infrastruktur im Hintergrund verschwinden sollte. Entwickler sollten sich auf den Aufbau von Geschäftsmöglichkeiten konzentrieren – und nicht auf die Verwaltung von Kubernetes-Clustern, Zertifikaten, Backups oder Deployments. Unternehmen sollten schneller innovationen vorantreiben können, ohne durch betriebliche Komplexität eingeschränkt zu werden.
Diese Philosophie hat LensCloud geprägt.
Auf einer Kubernetes-nativen Architektur aufgebaut und speziell für das Frappe-Ökosystem entwickelt, ermöglicht LensCloud es Unternehmen, ERPNext mit Enterprise-Level-Zuverlässigkeit bereitzustellen, zu betreiben und zu skalieren – und sich gleichzeitig auf das vorzubereiten, was als Nächstes kommt: KI-native Geschäftsanwendungen.
Und das ist erst der Anfang.

LensCloud ist die Plattform, auf der die gesamte LENS Experience Suite laufen wird – von LENS ERP und CRM bis hin zu CPQ, LENSIPS und den intelligenten Services, die sie miteinander verbinden werden.
Denn wir glauben nicht, dass KI ein nachträgliches Add-on sein sollte.
Wir glauben, KI sollte Teil der Plattform selbst sein.

Diesen Juli...

future updates

Den ganzen Juli über nehmen wir dich mit hinter die Kulissen und teilen die Entwicklungsarbeit, die Ideen und die Philosophie hinter LensCloud:

LensCloud Launch – Lerne die KI-native Plattform kennen, die speziell für das Frappe-Ökosystem entwickelt wurde.
In wenigen Minuten von Null zum ERP – Erlebe, wie schnell eine Unternehmens-Infrastruktur hinter einem nahtlosen Bereitstellungsprozess verschwinden kann.
Die Entwicklung von LensCloud – Erfahre mehr über die Architekturentscheidungen, das Kubernetes-native Fundament und die Platform-Engineering-Prinzipien hinter dem Produkt.
Mehr als nur Hosting – Warum wir glauben, dass sich Unternehmensplattformen vom Infrastrukturmanagement hin zu intelligenten Funktionsplattformen entwickeln müssen.
Einblick in die Plattform – Verfolge die gesamte Customer Journey, von der Bereitstellung bis zum täglichen Betrieb.
Entwickelt für Enterprise-Skalierung – Zuverlässigkeit, Sicherheit, Automatisierung und die Engineering-Praktiken, die Unternehmen auf Wachstum vorbereiten.

Ganz gleich, ob du deine ERPNext-Reise planst, deine Infrastruktur modernisierst oder die Zukunft KI-gestützter Unternehmenssoftware erkundest: Die Juli-Ausgabe bietet dir einen exklusiven Einblick in die Philosophie, Architektur und Technologie, die das nächste Kapitel der LENS Experience Suite prägen.
Dies ist nicht nur der Launch einer Plattform.
Es ist der Beginn unserer Vision davon, wie Unternehmenssoftware gebaut werden und wie sie sich im Zeitalter der KI weiterentwickeln sollte.

Hier abonnieren – das solltest du auf keinen Fall verpassen.

Vielen Dank fürs Lesen – und für das Vertrauen, das du uns jeden Monat entgegenbringst.

Team LMNAs

Leserecke

IT-Planung verdient die gleiche Disziplin wie die Produktionsplanung „Die besten Organisationen sind nicht die mit den besten Entwicklern – es sind die mit der besten Planungsdisziplin.“

Planst du noch oder reagierst du nur auf die Arbeitslast? „Was als Ausführung des Plans begann, wurde nach und nach zum Schutz des Plans.“

Die Lücke im Sprint-Management, von der die meisten Teams nichts wissen „Es ist nicht so, dass die Teams nicht besser planen wollen. Es fehlt ihnen einfach an einem einzigen, vernetzten System.“

Kapazitätsplanung formt die Stabilität der Auslieferung – Tag für Tag „Tägliche Transparenz zeigt das, was eine Planung auf Sprint-Ebene verbirgt.“

Manuelles Testen hat den Release-Zyklus blockiert Ein Zweierteam testet jetzt das, wofür früher acht bis zehn Personen nötig waren.

Die Planung war solide. Das Testen war automatisiert. Die Entwicklung war eine Blackbox.„Ein Planungssystem, das die Leute nicht nutzen wollen, ist kein Planungssystem. Es ist eine teure Schwachstelle.“

Feedback und Vorschläge

Wenn dich etwas in dieser Ausgabe besonders angesprochen hat – oder wenn du vor einer planerischen Herausforderung stehst, die wir noch nicht thematisiert haben –, würden wir uns sehr über eine Nachricht von dir freuen.