Von der Idee über Entwicklung, Fertigung und Inbetriebnahme bis Betrieb, Service, Retrofit und Stilllegung

„SE erstreckt sich über den gesamten Systemlebenszyklus“

SE-Prinzip 11 nach INCOSE

Wenn Du Lebenszyklus-Aspekte früh integrierst, sinken Gesamtaufwände (LCC), werden Upgrades schneller möglich, und Risiken in Betrieb und Service nehmen messbar ab. Der Schlüssel sind lebenszyklustaugliche Anforderungen, durchgängige Nachverfolgbarkeit, klare Verantwortlichkeiten, geeignete Gate-Reviews und schlanke Artefakte, die zu Eurem KMU passen.

Was meint „Lebenszyklus“ im Mittelstandskontext wirklich?

Ein System – z. B. eine Verpackungsmaschine, eine Roboterzelle oder eine modular erweiterbare Fördertechnik – lebt: Es wird konzipiert, gebaut, in Betrieb genommen, genutzt, gewartet, erweitert, umgerüstet und irgendwann stillgelegt oder recycelt.
Prinzip 11 fordert, dass Dein Vorgehen alle diese Phasen berücksichtigt – nicht nur Entwicklung und SOP, sondern ebenso Service, Ersatzteilstrategie, Retrofit-Fähigkeit, Software-/Sicherheits-Updates, Obsoleszenzmanagement und den Rückbau.

Warum ist das entscheidend? Weil 70–80 % der späteren Betriebskosten und -risiken schon in der Design-Phase festgelegt werden. Wer den Lebenszyklus im Blick hat, vermeidet teure Überraschungen: schwer zugängliche Komponenten, fehlende Diagnosen, unklare Updatepfade oder nicht dokumentierte Varianten.

Typische Fallstricke in KMU – und wie Du sie vermeidest

1. „Projekt endet mit FAT/SAT“
   ➜ Korrigieren: Lifecycle-Ziele (Verfügbarkeit, MTTR, Upgradekorridor, Recyclingquote) als messbare Anforderungen definieren – und bis in Design und Test runterbrechen.

2. Service wird zu spät eingebunden
   ➜ Korrigieren: Service/After Sales als verbindliche Stakeholder früh beteiligen; Feedback aus Feld-/Störungsdaten ins Anforderungs-Backlog zurückführen (Closed Loop).

3. Doku endet bei der CE-Mappe
   ➜ Korrigieren: Betriebs- und Service-Informationen als „First-Class-Citizen“ behandeln: Diagnosekonzept, Ersatzteillisten, As-Built-Stückliste, Updateleitfäden.

4. Software wächst „organisch“
   ➜ Korrigieren: Release- und Konfigurationsmanagement mit klaren Baselines, Änderungsanträgen (CRs) und rückwärtskompatiblen Schnittstellen.

5. Retrofit ohne Architektur
   ➜ Korrigieren: Modulare Systemarchitektur mit definierten Erweiterungspunkten (mechanisch/elektrisch/PLC/IT), damit Upgrades planbar bleiben.

So setzt Du Prinzip 11 pragmatisch um

1) Lebenszyklus-Ziele als Anforderungen

Formuliere wenige, aber harte „Non-Functionals“ mit Metriken:

• Verfügbarkeit (A) und MTTR: z. B. A ≥ 97 %, MTTR ≤ 30 min für definierte Fehlerszenarien.

• Upgrade-Fähigkeit: z. B. „Firmware-Update im Feld ohne Werksbesuch, ≤ 15 min, rücksetzbar“.

• Diagnose/Transparenz: z. B. „Alle Antriebsfehler mit Klartext + Ursache + empfohlener Aktion im HMI“.

• Obsoleszenz: z. B. „Kernkomponenten mit ≥ 5 Jahren Lieferzusage oder Second-Source-Strategie“.

• Entsorgung/Recycling: z. B. „≥ 80 % des Gewichts recyclingfähig, Kennzeichnung kritischer Stoffe“.

Diese Ziele verankerst Du in Eurem Anforderungsset, referenzierst sie in der Systemarchitektur und verifizierst sie über den Systemtestkonzept.

2) Architekturen, die Altern und Wachsen erlauben

• Mechanik: Freiräume und Befestigungsraster für Optionen, Zugang für Service (Werkzeugfreiheit, Wartungsfenster).

• Elektrik: Reserven in Leistung/IO, standardisierte Steckverbinder, dokumentierte Schaltpläne mit Funktionskennzeichen.

• Automation/Software: Kapselung in Funktionsbausteine, klare API/Signal-Schnittstellen, Versions- und Feature-Toggles, Logging-/Tracing-Konzept.

3) Durchgängige Nachverfolgbarkeit (Traceability), schlank umgesetzt

• Req → Architekturelement → Testfall → Bauzustand: Einfache Tabelle reicht zu Beginn, Hauptsache gepflegt.

• Änderungsmanagement: Jede Änderung referenziert eine Anforderung und eine getestete Version; Baseline pro Auslieferung.

• Digitale Kette: Stückliste (mBOM/eBOM/sBOM), Software-Versionen, Parametrierungen – as-designed vs. as-built klar unterscheidbar.

4) Service-Design als eigenes Arbeitspaket

• Diagnose & HMI: Fehlerbilder, Ursachen, Handlungsempfehlungen, Ersatzteilnummern; Ferndiagnose vorsehen.

• Wartung: Intervallpläne als exportierbare Liste; Ersatzteile mit alternativen Freigaben.

• Dokumentation: Kompakte, rollengerechte Doku (Bediener/Techniker), QR-Codes an Baugruppen, verlinkt auf aktuelle Online-Doku.

5) Gate-Reviews mit Lebenszyklus-Brille

Ergänze Eure Meilensteine um LC-Checks:

• LC-Konzept (frühe Phase): Ist Service eingebunden? Gibt es Zielmetriken?

• LC-Design (vor Detaillierung): Sind Erweiterungspunkte/Reserven definiert?

• LC-Nachweis (vor SOP): Wurden Verfügbarkeit/Update/Diagnose getestet?

• LC-Betrieb (nach 3–6 Monaten Feld): Lessons Learned ins Backlog zurückgeführt?

Schlanke Artefakte, die im KMU sofort wirken

• Lifecycle Canvas (1 Seite): Zielmetriken, kritische Use-Cases, Service-Konzept, Upgrade-Korridore, Obsoleszenzstrategie.

• Systemtestkonzept: Verknüpft Anforderungen mit Prüfungen, Akzeptanzkriterien und Ergebnissen.

• As-Built-Paket: Exportierbare Stückliste + Software-Versionsreport + Parametrierung pro Auslieferung.

• Updateleitfaden: Schrittfolge, Fallback, Downtime-Schätzung, Verantwortlicher.

• Obsoleszenz-Watchlist: Top-10 Komponenten mit EOL-Risiko, Alternativen, Bewertung.

Kennzahlen (KPIs), die Prinzip 11 sichtbar machen

• MTTR / MTBF / Verfügbarkeit je Anlage/Serie.

• First-Time-Fix-Rate im Service.

• Durchlaufzeit für Sicherheits-/Funktions-Updates vom CR bis Feldrollout.

• Anteil Variantenoptionen, die ohne Mechanikänderung nachrüstbar sind.

• EOL-Risikoindex (kritische Teile ohne Second Source).

• Lebenszykluskosten (LCC) über 3/5/10 Jahre je Konfiguration.

Mini-Beispiel: Retrofit-fähige Roboterzelle

Ausgangslage: Kunde A startet klein, plant aber zusätzliche Greifer und eine Vision-Option.
Lebenszyklus-Umsetzung:

• Mechanisch: Aufnahmepunkte + Kabelwege für spätere Vision-Einheit.

• Elektrisch: +20 % IO-Reserve, getrennte 24 V-Schienen, dokumentierte Klemmen.

• Software: Baustein „Vision_IF“, heute Stub, morgen aktivierbar; Feature-Toggle im HMI.

• Service: QR-Codes zu Explosionszeichnungen, Ersatzteilliste mit Alternativen.
  Ergebnis: Nach 18 Monaten wird die Vision-Option in 6 Stunden nachgerüstet – ohne Schaltschrankumbau; Software-Release über geprüften Updatepfad, Rollback möglich.

Dein 30-Tage-Plan zum Einstieg

Woche 1:

• Lifecycle Canvas für Dein aktuelles Leuchtturmprojekt ausfüllen.

• Drei harte LC-Zielmetriken definieren (A, MTTR, Upgrade).

Woche 2:

• Service-Review: 60-Minuten-Workshop mit After Sales, Top-5 Feldprobleme erfassen, zwei Diagnoseverbesserungen festlegen.

Woche 3:

• As-Built-Paket pilotieren: Eine Auslieferung vollständig versionieren (BOM + SW + Parameter).

• Einfaches Änderungsformular (CR) einführen.

Woche 4:

• LC-Gate in Eurem nächsten Meilenstein verankern.

• Zwei Testfälle zur Verfügbarkeit/Updatefähigkeit praktisch durchführen und dokumentieren.

Häufige Einwände – und Antworten

• „Zu viel Aufwand für KMU“ – Starte mit Canvas + As-Built + zwei KPIs; der Nutzen zeigt sich schnell im Service und bei der nächsten Variante.

• „Unsere Kunden zahlen das nicht“ – LC-Fähigkeiten sind Alleinstellungsmerkmale: schnellere Upgrades, kürzere Stillstände, längere Nutzungsdauer.

• „Tools sind zu komplex“ – Excel + Versionsdisziplin reichen für den Anfang; Tooling kann später schrittweise reifen (MBSE, PLM).

Fazit

Prinzip 11 zwingt uns, über das Projektende hinaus zu denken: Wenn Du Anforderungen, Architektur, Tests und Doku entlang des gesamten Lebenszyklus ausrichtest, erhältst Du Systeme, die wartbar, erweiterbar und wirtschaftlich sind – und Du reduzierst Risiken im Feld drastisch. Für den Maschinenbau- und Automatisierungs-Mittelstand ist das kein Luxus, sondern eine handfeste Wettbewerbsfähigkeit über Jahre.