// 90-Tage-Pilot
Wie läuft die Einführung in 90 Tagen ab?
Zuletzt fachlich geprüft: · Andreas Schönfeld
In vier Phasen, an einer Baureihe oder einer Anlage, und jede Phase endet mit einem Kriterium, das sich prüfen lässt.
Phase 1 · Woche 1–2
Pilot-Pipeline
TIA-Projekt in Git · Jenkins per Docker · Compile automatisch
Abnahme · erster grüner Build
Phase 2 · Woche 3–4
Test und KI
PLCSim-Smoke-Tests · 10 Build-Fehler per KI analysiert
Abnahme · Test bei jeder Änderung
Phase 3 · Woche 5–8
OT-Strecke
OT-Proxy in Staging · Wartungsfenster · Trockenlauf der Produktionssperre
Abnahme · Trockenlauf bestanden
Phase 4 · Woche 9–12
Nachweise
SBOM je Build · IEC-62443-Bericht · Flotte einer Baureihe · Übergabe ans Team
Abnahme · Pilot abgenommen
Phase 1 · Woche 1–2
Pilot-Pipeline
TIA-Projekt in Git · Jenkins per Docker · Compile automatisch
Abnahme · erster grüner Build
Phase 2 · Woche 3–4
Test und KI
PLCSim-Smoke-Tests · 10 Build-Fehler per KI analysiert
Abnahme · Test bei jeder Änderung
Phase 3 · Woche 5–8
OT-Strecke
OT-Proxy in Staging · Wartungsfenster · Trockenlauf der Produktionssperre
Abnahme · Trockenlauf bestanden
Phase 4 · Woche 9–12
Nachweise
SBOM je Build · IEC-62443-Bericht · Flotte einer Baureihe · Übergabe ans Team
Abnahme · Pilot abgenommen
Phase 1 · Woche 1–2
Bestandsaufnahme
Eine Anlage erfasst · Stände abgeglichen · Abweichungsliste
Abnahme · Abweichungen bekannt
Phase 2 · Woche 3–4
Git und Freigabe
Git-Server im Netz · Projekte versioniert · Systemhaus angebunden
Abnahme · erster Merge Request
Phase 3 · Woche 5–8
Abgleich
OT-Agent in der Zone · Abgleich nachts · Sicherung je Station · Wiederherstellungstest
Abnahme · Rücksicherung geprüft
Phase 4 · Woche 9–12
Nachweise
Export nach § 30 BSIG · B3S WA oder Katalog · Bereitschaft geschult · Übergabe an Betrieb
Abnahme · Pilot abgenommen
Phase 1 · Woche 1–2
Bestandsaufnahme
Eine Anlage erfasst · Stände abgeglichen · Abweichungsliste
Abnahme · Abweichungen bekannt
Phase 2 · Woche 3–4
Git und Freigabe
Git-Server im Netz · Projekte versioniert · Systemhaus angebunden
Abnahme · erster Merge Request
Phase 3 · Woche 5–8
Abgleich
OT-Agent in der Zone · Abgleich nachts · Sicherung je Station · Wiederherstellungstest
Abnahme · Rücksicherung geprüft
Phase 4 · Woche 9–12
Nachweise
Export nach § 30 BSIG · B3S WA oder Katalog · Bereitschaft geschult · Übergabe an Betrieb
Abnahme · Pilot abgenommen
// 01 Abnahme
Was ist am Ende jeder Phase abgenommen?
Je Phase ein prüfbares Kriterium; erst wenn es erfüllt ist, beginnt die nächste.
| Phase | Maschinenbau | Energie- und Wasserversorger |
|---|---|---|
| Phase 1 · Woche 1–2 | Bestandsaufnahme und Pilot-Pipeline. Abnahme: Ein Commit auf dem Pilot-Branch löst ohne manuellen Eingriff einen Compile aus, das Ergebnis steht im Dashboard. | Bestandsaufnahme einer Anlage. Abnahme: Für jede Station ist der Ist-Stand gelesen und gesichert oder begründet als nicht lesbar markiert. |
| Phase 2 · Woche 3–4 | Simulationstest und KI-Fehleranalyse. Abnahme: Kein Merge in den Hauptzweig ohne grünen Simulationstest; die Zeit bis zur Fehlerursache ist gegen die Ausgangsmessung dokumentiert. | Git und Freigabe im eigenen Netz. Abnahme: Die erste Änderung des Systemhauses ist über einen Merge Request mit Freigabe des Betreibers eingespielt. |
| Phase 3 · Woche 5–8 | OT-Strecke mit Wartungsfenster und Produktionssperre. Abnahme: Die Produktionssperre greift im Trockenlauf, und der Rollback gelingt ohne manuellen Eingriff an der Steuerung. | Abgleich, Sicherung und Wiederherstellung. Abnahme: Der nächtliche Abgleich läuft für alle Stationen, und die Bereitschaft stellt eine Station ohne das Systemhaus wieder her. |
| Phase 4 · Woche 9–12 | Nachweise, Flotte und Übergabe. Abnahme: Das Nachweispaket für ein Release ist vollständig, und Ihr Team führt ein Release ohne Comquent durch. | Nachweise aus der Historie und Übergabe. Abnahme: Das Nachweispaket für die Pilotanlage ist vollständig, und Ihr Team erzeugt es ohne Comquent. |
// 02 Eckdaten
Was brauchen wir von Ihnen?
Etwa einen Tag pro Woche im Fachteam, einen Linux-Server oder eine VM und eine Netzfreigabe für den OT-Proxy.
- Dauer
- 90 Tage in vier Phasen, je Phase ein messbares Abnahmekriterium
- Umfang Maschinenbau
- Eine Baureihe, ein Engineering-Projekt, eine Pilotmaschine im eigenen Werk oder beim Kunden
- Umfang Versorger
- Eine Anlage mit ihren Stationen, etwa ein Wasserwerk mit Pumpwerken, Hochbehältern und Brunnen, einschließlich Leitzentrale
- Aufwand bei Ihnen
- Etwa ein Tag pro Woche im Fachteam, punktuell IT, Informationssicherheit oder Service
- Infrastruktur
- Ein Linux-Server oder eine VM, ein Build-Agent bzw. eine Engineering-VM mit Ihren Werkzeugversionen, eine Netzfreigabe für den OT-Proxy
- Preis
- Festpreis, den wir nach dem Erstgespräch nennen, weil er von Toolchain und Anlagenzahl abhängt
Mitwirkung Maschinenbau
- /01eine Beschreibung der Toolchain: Steuerungsplattform, Werkzeugversionen, vorhandener CI-Server
- /02ein Engineering-Projekt der Pilot-Baureihe
- /03eine Pilotmaschine mit planbarem Wartungsfenster oder eine Simulationsumgebung
- /04je eine Ansprechperson aus Steuerungstechnik und IT
Mitwirkung Versorger
- /01die Liste der Stationen der Pilotanlage mit Steuerungen, Fernwirkanlagen und Kommunikationswegen
- /02die Engineering-Werkzeuge mit Versionen und den Ort, an dem sie heute laufen
- /03einen Platz für Git-Server und OT-Agent im eigenen Netz, auf Wunsch in der Zone der Leittechnik
- /04je eine Ansprechperson aus Leittechnik, Informationssicherheit und dem Systemhaus
// 03 Was sich messbar ändert
Woran messen Sie, ob es sich lohnt?
Im Maschinenbau an der Zeit vom freigegebenen Stand bis zum bestätigten Ist-Stand auf der Maschine.
−80 %
Deployment-Zeit im Median, gemessen in sechs Comquent-Referenzprojekten der Jahre 2022 bis 2025.
Quelle: Comquent-Projekte 2022–2025Beim Versorger an Gewissheit und Wiederherstellbarkeit; die Zahl der Deployments ist dort bewusst nachrangig.
Die Ausgangswerte messen wir in Phase 1, damit der Vergleich am Ende auf Ihren eigenen Zahlen steht.
| Messgröße | Vorher | Mit IndustrialFlow |
|---|---|---|
| Deployment-Zeit | Stunden | −80 % im Median |
| Firmware-Rollout auf 47 Maschinen | 6 Stunden manuell | 45 Minuten automatisiert |
| Fehlersuche bei Build-Fehlern | manuelle Log-Analyse | −70 % Zeit mit KI-Analyse |
| Versionskonflikte | im Feld entdeckt | im Build erkannt |
| Kennzahl | Typisch heute | Ziel nach dem Pilot |
|---|---|---|
| Zeit bis Klarheit | Stunden, in der Nacht einer Störung | Minuten bis Ist-Stand und letzte Änderung bekannt sind |
| Sicherungsabdeckung | Laptops und Netzlaufwerke | Sicherung je Station, jünger als sieben Tage |
| Wiederherstellungstest | selten oder nie | jede Station mindestens einmal in zwölf Monaten |
| Nachweisstand | vor dem Audit gesammelt | Nachweispaket je Anlage auf Knopfdruck |
Das erste Ergebnis
Das erste Ergebnis liegt meist vor, bevor die Pipeline läuft.
Es ist eine Liste: Maschinen, deren Stand in keinem Projektordner liegt, im Beispiel des Whitepapers drei von zwölf einer Baureihe.
Sie geht in Woche 2 an den Service.
Beim Versorger steht auf derselben Liste die Station, für die die passende Version der Engineering-Software nur noch auf einem einzigen Laptop installiert ist.
Was Kunden vor dem Pilot fragen
Q.05Wie läuft der Einstieg ab, und was kostet er?
Der Einstieg ist ein Pilot über 90 Tage zum Festpreis: im Maschinenbau eine Baureihe mit einer Pilotmaschine, beim Versorger eine Anlage mit ihren Stationen.
Jede der vier Phasen endet mit einem messbaren Abnahmekriterium, und am Ende betreibt Ihr Team die Pipeline selbst.
Den Festpreis nennen wir nach dem Erstgespräch, weil er von Toolchain und Anlagenzahl abhängt; die Betriebskosten danach richten sich nach Pipelines, Umgebungen und Support-Level.
Q.06Brauchen wir IndustrialFlow, wenn wir schon ein Backup- und Versionierungswerkzeug wie octoplant haben?
Nicht unbedingt: Wer nur sichern und den laufenden Stand mit dem freigegebenen vergleichen will, ist mit einem Change-Management-Werkzeug wie octoplant gut bedient.
IndustrialFlow setzt einen Schritt früher an.
Jede Änderung läuft als Merge Request durch Compile, Simulationstest, Security-Gate und Freigabe, bevor sie die Anlage erreicht, und aus jedem Build entstehen SBOM und Nachweispaket.
Ob das bei Ihnen den Aufwand rechtfertigt, klären wir im Erstgespräch.
Q.07Wie kommen Änderungen eines externen Systemhauses in die Plattform?
Das Systemhaus reicht Änderungen als Merge Request in einen Git-Server im eigenen Netz ein, über den bestehenden Fernwartungszugang, und der Betreiber gibt frei.
Wer ändert, kann nicht selbst freigeben, kritische Anlagen brauchen eine zweite Bestätigung.
Eine Änderung ohne Merge Request fällt im nächsten nächtlichen Abgleich auf und wird der zeitlich passenden Fernwartungssitzung zugeordnet.
Nächster Schritt
Erstgespräch zum Pilot.
Ob sich ein Pilot für Ihre Anlagen lohnt, klären wir vorher.
Im Erstgespräch gehen wir Toolchain, Baureihe oder Anlage und die Rolle Ihres Systemhauses durch, und Sie wissen danach, wie die erste Pipeline aussähe.
30 Minuten · unverbindlich · kein Vertriebsgespräch