Vom Prototyp in den Betrieb: Was Industriesoftware wirklich tragfähig macht

Der Proof of Concept läuft. Die Daten einer Maschine landen in einem Dashboard, das Modell erkennt die ersten Anomalien, die Präsentation überzeugt. Ein halbes Jahr später ist es still um das Projekt. Niemand weiß, wer es betreibt, die Architektur trägt keine hundert Maschinen und der Code liegt auf einem Laptop.

Das passiert oft. Selten liegt es am Algorithmus. Meist fehlt der Weg vom Prototyp in den Betrieb. Dieser Artikel zeigt, welche Entscheidungen diesen Weg bestimmen und wann Sie sie treffen sollten.

Architektur nach Anforderung

Nicht jedes Projekt braucht von Tag eins eine Plattform für tausend Geräte. Wir gestalten die Architektur deshalb anforderungsgerecht.

Schlank, wenn ein PoC oder MVP schnell Klarheit bringen soll. Dann zählt die Frage, die der Prototyp beantworten muss. Wenige Komponenten, kurze Wege, bewusste Abkürzungen. Wichtig ist, diese Abkürzungen zu dokumentieren. Sonst werden sie später zu Altlasten.

Von Anfang an skalierbar, wenn ein großer Rollout ansteht. Dann gehören Mandantenfähigkeit, Rollen und Rechte, ein sauberes Datenmodell und automatisierte Deployments in die erste Version. Nachrüsten ist teurer als Einplanen.

Entscheidend ist, dass diese Wahl bewusst fällt. Der Übergang von schlank zu skalierbar ist ein geplanter Schritt, kein Zufall.

Edge, Cloud oder Web

Industriesoftware läuft selten an nur einem Ort. An der Edge, nah an der Maschine, zählen kurze Latenzen, Vorverarbeitung und Betrieb auch ohne stabile Verbindung. In der Cloud laufen flottenweite Auswertungen, das Training von Modellen und alles, was mit der Zahl der Maschinen wachsen muss. Im Web sehen Bediener, Service und Management ihre Daten, ohne etwas zu installieren.

Meist greifen alle drei ineinander. Die Edge bereitet Daten vor und sendet sie per MQTT, die Cloud aggregiert, eine Web-App zeigt das Ergebnis. Dieses Zusammenspiel planen wir von Anfang an mit, auch wenn der Pilot nur eine Ebene braucht.

Zweiwöchige Sprints mit lauffähigen Ständen

Wir entwickeln in zweiwöchigen Sprints. Am Ende jedes Sprints steht ein lauffähiger Zwischenstand, den Sie mit Ihrem Team prüfen. Kein Foliensatz, sondern Software, die Sie ausprobieren können.

Das hat drei Effekte:

1. Sie sehen früh, was entsteht. Missverständnisse fallen nach zwei Wochen auf, nicht nach sechs Monaten.
2. Sie steuern mit. Prioritäten lassen sich nach jedem Review anpassen, wenn sich Anforderungen ändern.
3. Risiken werden sichtbar. Eine Schnittstelle, die nicht liefert, oder Daten, die nicht taugen, zeigen sich im ersten Sprint, in dem sie gebraucht werden.

„Fertig“ heißt bei uns: getestet, dokumentiert und automatisch auslieferbar. Der Code liegt versioniert in Git, Tests laufen in einer CI/CD-Pipeline, die Infrastruktur ist als Code beschrieben. So ist jeder Stand reproduzierbar.

Ein Prototyp beweist, dass etwas geht. Der Betrieb beweist, dass es trägt.

Der Quellcode gehört Ihnen

Sie bekommen den Quellcode, die Dokumentation und die Pipelines, mit denen sich die Software bauen und ausliefern lässt. Betreiben können wir, Sie selbst oder ein Dritter.

Das ist keine Formalie. Maschinen und Anlagen sind oft viele Jahre im Einsatz, die Software darauf auch. In dieser Zeit wechseln Teams, Dienstleister und Prioritäten. Wer den Code besitzt und ihn bauen kann, bleibt handlungsfähig. Wo es sinnvoll ist, setzen wir auf Open-Source-Komponenten und offene Standards wie OPC UA und MQTT. Das hält Ihre Lösung austauschbar.

Betrieb von Anfang an mitdenken

Ein System im Feld braucht Pflege. Wer den Betrieb erst nach dem Rollout plant, plant ihn unter Druck. Vier Themen gehören deshalb von Beginn an in die Architektur.

Monitoring

Sie sollten von einer Störung wissen, bevor Ihr Kunde anruft. Dazu gehören Metriken, zentrale Logs und Alarme. Nicht nur für Server, sondern auch für Edge-Geräte und Datenflüsse: Kommen die Daten an, und sind sie aktuell?

Updates

Betriebssysteme, Bibliotheken und Container brauchen regelmäßig Sicherheitsupdates. Bei einer Flotte von Edge-Geräten heißt das: OTA-Updates, gestaffelt ausgerollt, mit der Möglichkeit, zurückzurollen.

Backups

Ein Backup ist nur so gut wie die letzte erfolgreiche Wiederherstellung. Deshalb gehören feste Sicherungsintervalle, getrennte Speicherorte und regelmäßige Wiederherstellungstests dazu.

Reaktionszeiten

Wenn eine Störung auftritt, muss klar sein, wer reagiert und wie schnell. Feste Reaktionszeiten und ein klarer Eskalationsweg gehören vor dem Rollout geregelt, nicht danach.

Auf Wunsch übernehmen wir diesen Betrieb für Sie: Monitoring, Updates, Backups und feste Reaktionszeiten bei Störungen.

Vom Pilot zum Rollout

Wir starten mit einem überschaubaren Pilot. Ein Use Case, echte Daten, fester Zeitrahmen. Am Ende steht ein messbares Ergebnis. Erst wenn der Pilot im Alltag funktioniert, rollen wir auf weitere Maschinen und Standorte aus.

Bevor Sie den Schritt vom Pilot in den Rollout gehen, lohnt der Blick auf fünf Fragen:

1. Welche Frage hat der Pilot beantwortet, und woran messen Sie den Erfolg im Rollout?
2. Trägt die Architektur die Zahl an Maschinen, Standorten und Nutzern, die geplant ist?
3. Wie kommen Updates auf die Geräte im Feld?
4. Wo liegt der Quellcode, und wer kann ihn bauen und ausliefern?
5. Wer betreibt die Lösung, und welche Reaktionszeit braucht Ihr Betrieb bei einer Störung?

Wenn Sie diese Fragen beantworten können, ist Ihr Projekt bereit für den Betrieb. Wenn nicht, ist jetzt der richtige Zeitpunkt, sie zu klären.

Wie wir Architektur, Entwicklung, KI und Betrieb zusammenbringen, lesen Sie auf der Seite zu unseren Services. Wenn Sie vor genau diesem Schritt stehen, sprechen Sie uns an.